When is a senior engineer not a senior engineer?
mooreds.com
mooreds.com
Other companies, with higher standards, demanding management, and highly productive customers, mandate the domain experience - if by sheer job task difficulty alone. "Senior" here indicates siloed domain experience.
It can be good experience to oscillate between the 2 - join a team needing a generalist to learn how everything works, then leave for a team needing a specialist in a specific domain. Because silos are constantly becoming general standards, being a "block-shaped" engineer means being "T-shaped" in different fields.
That blog post is embarrassing.
They fired an average to poor performer who somehow managed to convince them he was some sort of genius until it became evident that he was not.
Either that guy was not their top talent (in which case why did they call him that?) or their other developers are even worse, which is terrifying.
He ended overworked, but the root problem is not in his tech skills. It was in his social skills, in the inability to cooperate leading to doing it all alone and in the way management enabled all that due to his past performance.
Management aimed at 6 months project. Which got longer due to bugs and mismanaged analysis. Saying that they aimed for something complicated is untrue. They wanted 6 month project and were happy with delivered smaller scope.
For that matter, spending a lot of nights in work should not beat "having superior actual results". He did not had results by the end. And he is adult. Managing your own overwork, especially when you have strong negotiation power, is part of what you are expected to do. He failed at that, he was not ready to work independently.
Your comment sounds like very willful misreading of original article. There is nothing to suggest that other collegues very lazy or complacent or stupid - zero.
I inferred lower competence of colleagues from the project they delivered with, as you say, smaller scope. There was also an insightful comment on that article from somebody describing point of view of high performers surrounded by mediocre developers, how they purposefully isolate themselves from dysfunctional teams in order to deliver something and not having their motivation destroyed by complacent teams comprised of people that stopped evolving the moment they got their graduate degrees.
As for your next comment, thanks for spotting the author was a "new guy", I confused him with somebody from upper management in that company that was there from the start.
Literally.
Project planned originally for 6 months took 2 years and still was not delivered and that is somehow proof of superior ability. Much wow.
Simple fact is that Ricks approach failed and people he considered less then him succeeded - through they still have to be coupled with someone assertive enough to be manager.
Last note: a lot of pointless overtime in this industy is result of celebrating Ricks and calling teams able to manage work schedule lesser. So people.instead of trying to learn how to manage scope and expectations look down on those who are capable to do it.
They didn't succeed; they finished a significantly reduced project, likely for management to finally show some results to investors. If you were ever writing some complex project, there are things you might not have anticipated that need a lot of care to be resolved, which is why making estimates is so difficult in creative industries.
Let's have a different take: imagine "Rick" was working on proper distributed transaction support in e.g. inter-banking communication from the scratch, as that was what business needed. He underestimated the complexity in the beginning, finding more and more corner cases that would reduce high availability that was crucial for the product. This led him to work days and nights in order to solve every single issue that appeared, if he wanted to be honest to himself, his conscience, and not sell a fraud as his final product. Unfortunately, he didn't see anyone in his team capable of actually helping him share the burden. He could have probably done a PhD thesis with the amount of work it required.
Now, investors/management after plenty broken deadlines for this overly optimistic project decided to fire Rick and move on with the rest of the team. In order to ship anything, they decided to remove transactions completely, making it a simple CRUD app, that cannot be used for financially critical tasks and was appealing to a much smaller market (imagine small banks vs large multinationals). This app was what the team delivered quickly. They finally could show the results to their investors, and were supper happy and proud of their achievement. As some investors still had a bad taste in their mouth from broken promises, management decided to blame/shame Rick publicly to identify proper scapegoat.
Rick is now burned out, soon to be homeless, trying to recover from the 2 insane years, and likely out of doing any great work for the foreseeable future, if not forever. Moreover, his name is now blacklisted, because everybody in the industry took the side of management/investors and will never hire him.
I did worked on complex projects and estimations, negotiation and communication about delays is more important there, not less. So is ability to work with people you don't like or consider lesser.
Given that the same team was able to produce smaller scope project, it is pretty sure they were able to do at least some parts of original project.
The rest frankly reads like fanfiction. As heroic as decision to spend nights in work and do it alone was, it was not rational decision.
It doesn't seem to me like there was a root problem. There were several. The primary problems being that he was a bad developer, an asshole and non-cooperative.
He wrote idiosyncratic bad code, copy pasta and documented nothing - that wasn't about him being an asshole - that's a lack of basic tech skills. Those are actually the things that led to the company not being able to deliver. I know plenty of perfectly nice junior developers who have done the same thing and if unchecked it causes the same problems they experienced.
It doesn't say it, but it's strongly implied that it wasn't just others that had a problem understanding and maintaining his code because of his poor skills - he likely inadvertently made it difficult for himself too.
When he did get initial good reputation, he was able to solve problems, he was able to help etc. I think that we should not expect perfection of him nor we need to convince ourselves that he was completely incapable.
He was unable to estimate how much time will maintenance of everything take and from there on, he could not win.
The conclusion seems to be "smart people are bad at software" not "Rick wasn't so smart." Maybe it's worth considering both possibilities.
In the last months of our collaboration, majority of the projects he was leading were failing - he was not managing with the deadlines neither wanted to delegate tasks. That time, he would also arrive to the office on monday and would leave home on friday evening or saturday, having just a quick chat with his family in the evening. Without proper sleep, always tired and with huge amounts of stress, he was getting into the loop. He always just needed this extra few hours, almost being there. As a small team, we were strongly pushing him to take holidays, to grab some rest. We were also pushing for us taking more responsibility in the projects - we had quite having quite some personal discussions, but without any success (in the end, we are all just humans and even when you're being managed by a "bad" guy, when you see him completely burning out and losing mind, at least you try your best just to help; knowing that there's his wife with two little daughters waiting for the dad coming from work doesn't make this situation easier).
In the end, he just "left" the company (not to face being fired) to a new one, leaving so too our team (we were just re-assigned to other teams) and to build a new one in a new place.
Our Rick since the beginning had mental issues, which most of colleagues were not aware. At first sight, he was a very intelligent, charismatic and nice guy. However, the ones who had more contact or worked with him could agree that he exhibited behaviours as in typical Asperger syndrome, behaving also quite often schizophrenic. It's a pity that topic of mental health is quite often neglected, as a proper therapy and an early diagnosis, I guess, could help here, him, his family and his future.
It’s amazing how rarely this question is asked outside the context of specific technology skills.
Most of the time people spend hours interviewing lot of people looking for that one brilliant engineer but as the reality dawns on them, they end up hiring who has some essential skills.
Later they bemoan that he/she is not good at an non-essential skill. At that time when you say, well, why don't we hire someone with those non-essential skills? It comes down to money.
Do they think your going to leave but have legacy knowledge which they need you for?
In the organization I currently work the salary level for a regular engineer is generally too low to get good candidates so everyone tends to be a senior engineer or better.
These can be internal systems which focus on more efficient processes for the organization or external facing systems which generate revenue.
I've worked with a LOT of engineers that have never built and delivered anything of real value. That's not to blame them, as there's a tremendous amount of waste in both the public and private sector driven by middle management layers.
But in my book, if one wants the title Senior Engineer then one has to have built and shipped something that generates more revenue (directly or indirectly) than what the system cost to build and maintain.
Wouldn't that eliminate engineers at companies that never found product market fit, or figured out their monetization strategy? Many projects get shipped, delivered, and used without generating revenue.
In some environments that means technical leadership or project management over a team. In others it may mean being a domain and tech stack expert who can do it themselves. Other times it's someone who can quickly jump into a new domain and get things done.
A senior developer can get stuck, but never gives up. There's always a way. Read source code, google around, be creative, trust your intuition (which is really just accumulated experience). Come up with a plan and make good use of available resources.
So either developer-tasks, operations-tasks, or developer-operations-tasks, if we were wondering.