One team's senior engineer is another team's junior engineer. Some companies feel like "training companies", with low technical standards, lenient management, and forgiving customers. Often, the senior engineer here is tasked with being the person to learn a new technology and evangelize/disseminate. "Senior" here indicates technology generalist leadership.
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.
This question gets rehashed a lot, and I like some of the answers posted. Personally, I mostly go with "It depends." But the one thing I hold to is what a senior engineer is NOT. An amazing coder who doesn't help the team, doesn't step up at crunch time, and/or chooses their own path to the detriment of the needs of the business... is not a senior engineer.
>I dove into the source code. Rick was right: no-one could possibly understand what Rick had created. Except for Rick. It was a reflection of the workings of his own mind. Some of it was very clever, a lot of it was copy-pasta, it was all very idiosyncratic, and it was not at all documented.
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 was their top talent, because he did knew more then others in the beginning and had more merit in the beginning. He became untouchable, so any disagreeing collegue got blamed and any criticism of got ignored. It became his way or no way, so everyone else became passive.
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.
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.
I hear you, but those failing happen to pretty much everyone who overworks himself too much and don't have feedback. You loose sigh of it, because your brain get it. And you are tired and sleep deprived. Everyone makes mess occasionally and we should not judge people by their worst performance. (Meaning here that he produced both bad and good code).
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.
IMO that was a massive management fail. They had a great workhorse doing miracles for them, the guy ended up surrounded by lazy/complacent/incompetent colleagues that just wanted to have good time, he was evidently on the verge of burnout for over a year and then finally fired and blamed for all that was evil in the company. The replacement team of mediocre employees created a very dumbed down version of what they were aiming for and management called it a success. The author of that post should be ashamed of himself they let it go that far due to their complete incompetence. Now reading that HN readers take it as a recipe for their own companies... Oh well.
Negotiating/clarifying requirements is seniors job. Delivering working software instead of something that never seem to be finished and has still bugs is superior leadership.
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.
Yes, I agree he should have communicated better and likely his own pride got in the way of suggesting he is overworked. However, management should have never allowed so much strain on a single employee; if one works nights for so long, likely they must have seen his health deteriorating and all kinds of warning signals. That's simply mismanagement at its finest. Ask some top athlete to run marathons every week and see what a shell of a person they become, even if they do that voluntarily. They should have sent him to 2 weeks retreat on Seychelles instead, even forcefully.
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.
You inferred lower skill from them being able to manage scope and from finishing the project within alotated time.
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.
Have you even read article? Customer was happy with smaller scope and it was agreed upon in advance! The original project got large also due to change requests and conflicting requerements, these got managed this time.
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.
Obviously I was using a hyperbole, amplifying some angles, to get my point across as I thought that in your replies there was a lot of one sidedness. Frankly, I have seen many companies normalizing mediocrity and chasing away their best developers, or even blaming them for their own shortcomings, instead of fully utilizing what they could offer them, which IMO is a tragedy. So instead of just agreeing to what most replies alluded to, i.e. the Rick was a mediocre, uncommunicative and disorganized asshole with a heroic complex, I offered an alternate point of view that maybe the bigger problem was on the other side, for the sake of balanced view.
I'm puzzled that the author doesn't spend some time considering the possibility that Rick might be an idiot. His code was disorganized and possibly way more complex than it needed to be, he had control of his own time but was missing his own ship dates, he was yelling at people ... this isn't necessarily the profile of a genius.
The conclusion seems to be "smart people are bad at software" not "Rick wasn't so smart." Maybe it's worth considering both possibilities.
Rick's not bad, nor is he an asshole (or at least not permanently an asshole). This is what mental illness looks like. I can't say who's to blame for this - the absurd working hours were clearly done willingly - but regardless management could probably have done more to fix the situation. To my mind, Rick needed a forced vacation, a psychologist, and a non-computer related hobby.
Unfortunately, I cannot agree here more with you. I had also a "pleasure" working with such Rick. He was our team leader. At the beginning of our collaboration, things were looking quite ok. However, on the surface, he had serious problems with self-management, managing people and controlling. Later, he would preferably work alone in the office, strongly believing that he is surrounded by "idiots". Often he was not respecting others work, neither the requirements nor deadlines posed by higher management, as he "knew better". Without any doubts, he had a great knowledge, was a very skilled and intelligent guy, but, unfortunately, was becoming unbearable to work with. Putting such person in a management position was definitely a good idea, but, as far as I know, at that time he had the needed expertise to set up the crucial processes in the company.
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.
I've also heard them called them simply assholes. I think it was a the Pinterest CEO talking about their hiring a few years ago, ie "we don't hire assholes".
I have never understood the need for a moonshot applicant - someone who is good at everything.
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.
I think more broadly people just don't think as much as they should about what they really (and realistically) need in a hire and if their hiring process actually selects for that.
I would add in larger organizations its merely pay grade issue where senior engineer is typically one pay grade and regular engineer is typically a lower pay grade.
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.
To me a senior engineer is one who can lead a team in the design, documentation, implementation, deployment and maintenance of a system which realizes a quantifiable ROI for the organization and they've preferably done this with different tech stacks.
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.
> 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.
To me a Senior Engineer is one I can trust to implement a successful project end-to-end with minimal hand holding.
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.
I think this minimal hand-holding is also my "pet criteria".
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.
> Development support/operations/devops: this is the glue around your application that helps your application function. These tasks can range from developer focused tasks like a coding style guide or maintaining the developer docker image to operations tasks like setting up the monitoring system to devops tasks like debugging the failing jenkins job.
So either developer-tasks, operations-tasks, or developer-operations-tasks, if we were wondering.
I generally understand the title of senior engineer at an organization as indicating that the so titled person can be relied on to solve the majority of engineering needs of that organization - essentially, a senior engineer is the person you ask how to do something when you don't know how to do something.
"Senior engineer" is just a boilerplate pay grade description for someone who isn't straight out of undergrad school. Some of these people know what they're doing and some don't. Some of them want to do what really needs to be done, and some don't.
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.