As you move up the business ladder, or indeed start your own business, it's interesting to see how priorities evolve.

When you're a coder, the code matters. It can be frustrating to see resources allocated to say marketing.

When you are responsible for acquiring resources, then there's more to care about, more to balance. When to market. When to get new hardware.

Programmers care about code performance, code elegance, getting every pixel perfect, perfect design (for when we have s billion users). Business owners care about shipping, and getting paid. Without that the doors close.

As we grow older, as our position evolves, we have to care about more, but in some ways less deeply. There's more nuance, more compromise, more acceptance that it needs to be "good enough" - better than that even - but that perfection is an expensive goal either small returns.

I'm not arguing for mediocre, we all want the product to be better, and incrementally we move towards that. But that movement is in balance with all the other cares.

Very true. The thing that really helped me as I got into the third decade of my career was the realization that things can always be improved, but only if agency and accountability go hand-in-hand, and are widely distributed so that everyone has some ability to influence and optimize something. Obviously this requires a willingness to compromise from all involved, and can easily go off the rails into the worst sort of design-by-committee debacles if the wrong people are given the wrong authority, but when it’s done right that’s the definition of a team gelling. It’s rare in a corporate environment due to sheer volume of individuals involved and the communication/alignment overhead, but still possible, and always feels a bit magical when it happens.

It's not about age, it's where your interests lie in.

I think GP is making an (obviously incomplete) assumption that with age comes movement up the org chart, away from code, and towards an awareness of other departments and ultimately owning/directing the business worrying about cash flows.

Not really. The specifics about how a product is differentiated might seem like irrelevant minutia (fps or rendering times, for example) to an outsider while still being critical for market success.

Installing people into senior positions does not make them better at recognizing these factors, or more incentivized to care.

The point is that a senior can use your argument to trivialize the efforts of an engineer, seem reasonable to outsiders, and be wrong.

I don't see that as the point, or at least it wasn't mine, but I'd probably disagree in most cases anyway. What is critical for market success isn't for someone to bet their time on unless they stand to directly control the outcome of that market success, kn what would otherwise be labelled agency or a stake in it.

If I'm over here spending my late nights trying to pare down our webpack bundle, but my actual day is already done because it was decided that it should be spent doing something else, then someone is liable to get frustrated with how little influence they have over the outcome or reward system. If a customer then comes back and says "oh I love how snappy it is" you can certainly pat yourself on the back for it, but you have no real control over whether that translates into compensation for your effort, either in terms of accolades or money or product direction, unless you're the one making those decisions already.

Part of the reason, in that specific case, is that not only is it hard to say as an IC what the results would be otherwise had you not done X, but also what future results might be if you were to do X again.

It's not that those choices are irrelevant or that they don't have an impact, but if you don't get to allocate company resources to it, and are hoping for a better outcome but can't control that outcome or perception of your work, then it's not worth it.

If I'm John Carmack, I'm going to care deeply about rendering performance of my game, because if it's great, I might make millions, and I get to decide that that's what my employees are optimizing for. If I'm one of those employees, I'm going to meet his expectations, and if I'm very lucky, he'll think highly of me later on. That's... it. Unless I have decent shares or something.

Likewise if you're repeatedly trying to position yourself as the tryhard, you run the risk of reducing your capacity for doing literally anything else in life, which should be a real concern, because if you're not allocating resources at the company to your time, then you're devaluing your own time and resources for no reason; burnout.

Now out yourself in the same position at a massive company that has hierarchies of managers who's sole job it is to check that the status of tickets have changed or whatever. The chance your extracurricular work will influence a better outcome for you is basically nil, because the value of anyone's job is not defined by anything related to quality.

When you have a certain level of investment of time and effort, you don't have to be John Carmack (owner/founder with your name in the end titles) to care about it. Many people feel pride and ownership of code and parts of products they created, and their investments are responsible for the at least some of the success of the products. These achievements can become defining for their careers, and I think it's appropriate to allow and recognize this.

Management that denies engineers this sense of ownership and achievement is a likely cause of burnout. I think we agree mostly agree, but in my view management shares responsibility in this case.

All of that should be predicated on the answer to the question "How much of the outcome of this work do I truly have influence over?" and if the answer is none, and those extra hours making sure your code is really nice, should only be spent within the constraints you're being paid for. Are your requirements fulfilled, but you were pretty fast and have a bit of extra time to clean things up? Great, that's fine. If you spent your 8 hrs that day, the requirements are complete and there's no more time you're getting paid for, and you don't get to determine what the positive outcome for you is if you donated your weekend to fixing something management doesn't care about and won't pay you for, then don't, and stop having pride in it.

You own it if you own it, keep your personal investment at arms length, lest you become a Jason Bateman character desperately putting in those extra hours so one day hopefully you'll be blessed with that VP position or w/e.

That said, of course if you've achieved something within a fairly tight constraint, ideally you're compensated or recognized somehow for it. Extra worthwhile hours should also be compensated for obviously. But if nobody is willing to pay you for it, it's probably your own undoing.

Seems like we agree in everything except you seem to think that the management's judgement about value is a priori correct and final.

What I am saying is that value in a product can be "discovered" along the way. An engineer that demonstrates how to add value through individual efforts will probably experience burnout if management chooses to ignore their efforts. But more mature managers will figure out how to work with it.

I would say this is more about maturity than the level to which you care about things. Understanding that there are considerations other than the ones you care most about relates to maturity imo. You would probably hope that the more a person is made responsible for, the more they come to understand this. But I think your interpretation implies that prioritisation requires a decreased level of caring about the lower priority issues, which I don’t think is true.

Yeah, i totally agree. The more years I have behind my belt as developer the less I care.

I do what I'm paid for. I do it to best of my abilities, but I don't care much.

I care for my wife, my unborn child, my dog, myself. Seriously live is so much more than work and code.

I learned to balance myself. I need job for $ and that's it.

If I won lottery I would still code, just not as much (2 h/day) and only fun stuff. Work is usually borning.

Do you still learn new practices/technologies/stacks/...? I'm asking because that's my problem. As I start to care less, I also care less to keep myself up to date with new tech stacks.

Consequently, it's becoming painfully aware to me that if I were to lose my amazingly well-paid job in which I (feel like I truly) excel, it'd be a pain to look for a new one. Because of my niche, I would, most likely, have to go down with my pay by one or even two seniority levels to be a standard SWE in a different company right now.

I also don't very frequently, but not just because it's not interesting most of the time. It's because as you learn enough of them, the same realization happens; most of what they do, aren't as important as you just building the thing quickly in your stack of choice. Truly new tech and categorically different tech is different, but a new JS framework or w/e doesn't really matter much at all.

Well, I don't. I try to focus on basics and rest I learn on the job.

To be honest I know that I have less value on the market because of that. It is just I don't want second job of just keeping up.

I read article here and there when I have moment, but that's about it.

On other hand I find ecosystem in JS (my slice of cake) is slowing down. There is no new framework every week like it used to be. No ground braking changes.