Since my top-comment is #1 and it's a bad example, I'll give a positive example here.

In this company I joined I worked really hard. It was very exciting work, an innovative startup, pretty good pay (for my locale), great coworkers and manager. I still worked around ~8h/day, but those were VERY intense 8-hours and after few weeks it was clear that our office/team was shipping A LOT faster than other teams in HQ. It was a really nice combination IMHO:

- Our manager was amazing at getting the work requests and converting them into technical tasks/projects, while shielding us of the BS that was literally raining from HQ. No one lasted too long when he eventually left, and they even closed the office a bit after.

- Because of the timezone difference, we had meetings for 1-2h in the morning and then calm for the rest of the day to execute on those tasks. Our manager had more, but that was a really good balance for IC.

- While we had different levels of seniority (and all hired as the same "mid-level"), we worked well together and all were reasonably knowledgeable, no one needed handholding.

So yeah, after few months/1 year we got some major projects finished. One of which I made the major technical part, for which I struggled and fought like never before, and successfully delivered it. Our CEO used this project even for presentations to our investors and clients (was supposed to be an internal tool). So my manager got me from mid-level ("Software Engineer") to Staff Engineer, a whole 2-level bump and 40%-50% salary increase approx.

So sometimes working hard does pay off :)

you were just leveling with your teammates which were also hard workers. I experienced this in my last job and I'm trying to reproduce it, but I find it difficult to recreate in another environment.

It is different than being a super hero and hand hold a project while your teammates watch you from the side.

Every way you just mentioned seems to depend on a layer of managers assessing things?

I ask that because I've observed in both deeply hierarchical (and dysfunctional as all hell) Amazon, and super flat (at least for a long time) Apple, and your characterizations only fit the bureaucracies. (I've observed the same at other places as well.)

You bring up an interesting point. I have not seen this in flat or small companies as I have not worked in many. But I imagine that those surrounding the engineer will still feel that their expectations are no longer met if the engineer tries to return to normality from their superhero role. Though perhaps the colleagues might understand the full circumstances of the situation better in a tighter or less hierarchical team.

Ultimately, if someone has the engineer's back when they need to stop being the proverbial "Atlas who holds up the world", then maybe things could end better. But there are few managers that have the insight to notice it and grace to do something about it. The kind manager (or colleague) described in the article we are discussing is not common.

So whatever the circumstances, generally it does end badly if the engineer significantly over-commits to save the project.

True

> If yes, good luck burning out while blocking your own career progression.

Is there a career blockage if you don't stick around? The more you do, the more you learn, the more you learn the faster you do, the faster you do, the more you do.

> management won’t want to promote them out of the situation

Management can pay a higher salary to retain them. A vertical career into management is not for everyone.

> they will ruin their health through stress, and then the consequences of returning to 1x workload and being an “under-performer” will follow anyway.

Doesn't look like that if you leave a paper trail of everything you do.

> A vertical career into management is not for everyone.

That's a different question which is even more polarizing - should good engineers become managers. But to be clear, I brought up promotion because that's why many people make the decision to take on these responsibilities to save the project. It could be a pay raise or a promotion to a higher engineering level.

> Doesn't look like that if you leave a paper trail of everything you do.

It works this way from what I've seen, I'm sorry to say. But I've seen a lot. The paper trail is good evidence in a grievance situation but it's hard to restore one's reputation through the grievance process - formal or informal.

> Is there a career blockage if you don't stick around?

No, and leaving, to my mind, is the easiest healthy choice if an engineer finds themselves in this situation. However, it is still an undesirable situation to put oneself in if one wants career growth. If leaving is the way they wish to achieve that, it's better to just leave than to suffer for a while and then leave. If they wish to achieve career growth in the company, this will block them. In any case, it's wasted time from a career advancement perspective.

You could say that working in a high-pressure situation would teach the engineer something, and maybe it's true. But mostly it will make the engineer make many mistakes and be overwhelmed. Which is why most people argue that learning in a relaxed environment is much more practical.

Even people who study extreme medicine (battlefield medicine, mountain rescues, and similar topics) study it in a safe environment. They do real life simulations but in a supervised way. Throwing an engineer into the fire to teach them handling a pressure-cooker situation would be much like asking an extreme medicine doctor to learn on the battlefield. You could say they would learn, but probably a lot of what they would learn is to make mistakes.

It doesn't always end sadly -- it really depends on the individual and the company.

In my case, I ended up doing the job of maybe 5-10 developers for a year and a half leading up to the launch of a product at a large tech company. It was tough, but I believed in the product and wanted it to succeed, so I didn't mind putting in the extra time. I was also fairly young at the time, so I could handle marathon coding sessions without burning out.

After it launched (successfully), I developed a reputation within the company that let me basically have my pick of projects for the remainder of my time there. Additionally, I was awarded a 7-figure stock grant that ended up being worth 8 figures by the time it fully vested, so it worked out well financially too.

I view that project as sort of a career-defining moment, and I'm extremely glad I did it.

This is a very simplistic view of the situation. It doesn't usually work like that in the real world.

In the company I left few years ago I was a lead developer in a department which started with me alone, then at times grew up to four developers and shrank to just two.

Here's what it looked like: we were almost always advertising a position in my department, and about once a week I had to meet another Python developer with X years of experience in infra, who was barely literate... No, really, it was that bad.

After each such interview, I had to go back to my boss and decide whether we should give this guy / girl a chance, or should we spend more time and money looking for more candidates. I tried both strategies. I tried to hold out until we find a better candidate, and we were simply wasting time running in circles. I tried to advocate hiring someone simply on a basis that they looked promising. I had to promise my boss to bring them up to speed, and that was a year of misery of dealing with someone who made such a painstakingly slow progress, being such a huge time sink that in the end I had to abandon that person to have at least something done.

Infra projects, especially in large-scale products tend to be this way. Outside, theres' a huge pool of "Python programmers", but most of them are really "Django programmers", they have no idea how computers work, and will require years of mentorship to obtain that knowledge. Few will see that as valuable as it's not a common enough requirement. Few will have the determination or passion to get to the point where they are confident and independent that they may continue their education on their own.

On the other hand, those who gained such experience don't like infra jobs for the very reason that they end up recruiting novice programmers and leave for more system-like jobs. And this dynamic affects every department both at a macro and at a micro level: people either learn how to be good and leave, or they never do and get replaced by the next batch.

In the end, it's fairly typical that infra department will be "carried" by a single employee who's spend ages working there + a number of younglings who come and go never contributing anything of note. I wouldn't say it's a management problem. Infra isn't the only department which sees that kind of dynamics. QA is pretty much the same way. Front-end used to be more like that, but I don't know what the situation is today. It's caused by the pathological relationship which reinforces itself with time that prevents expertise from growing both locally in an org and generally in the field.

    I don't think the engineer in the OP did a good job. They were the last link in the knowledge chain. It's on them to pass the knowledge along and onboard the newbies.

I find it weird that you’re blaming the Engineer and not the managers or culture. Isn’t it on them to make sure that knowledge is passed as well?

That's forcing the engineer to do what they should be doing. You can blame them for not doing that but that doesn't absolve the engineer of not doing what they should be doing.