Wasn't this posted, like, two weeks ago? Same thing applies here as applied there.<p>I know you admit that it's a gross oversimplification but this kind of talk still bothers me a lot. It's a lot like when, to use a (honestly shoddy) metaphor, people talk about rankings in a video game like League of Legends. Some times you'll hear talk like "the difference between a bronze and silver player is game sense!" or "objectives control!" or "mechanics!". The truth is it's all of these things and none of them. A silver player is simply better than a bronze player.<p>I think the same goes here. There's not some magic thing that a senior developer has that a junior developer is missing. They are simply, overall, better.
The article lost me on paragraph 1: "...There is a much higher need for developers than can be satisfied by new developers coming into the field. This is a problem that has existed for years, and it is getting worse as time goes on...
We have a serious shortage of talent to meet the demand..."<p>Basic economics dictates that there is only a shortage if prices are increasing, and they are not, certainly not relative to overall price increases.<p>Secondly, there are plenty of developers -- but like me they go into other job roles. The reality is that a developer salary does not support a family in developer-job-rich areas. You might find junior developers because they are willing to share apartments or live in shacks, but once you start speaking about senior developers you are often also talking about someone married, possibly with children.<p>The problem is certainly not a lack of developers but a lack of hiring managers paying a living wage for that stage of someone's life.<p>Cant find senior developers? Quick trick -- raise the salary and see them pour in for interviews!
> More than that, our industry values wicked smart young guys fresh out of university.<p>I do wonder if most of their value comes not from their brains but from their pliability and capacity to be overworked?
> A senior developer is intimately familiar with their own failure... and is obsessed with simplicity.<p>There are many paragraphs in that post that I agree with, but this one struck me particularly as my motto of the last 5 years or so has been to "keep it simple".<p>Edit: grammar
> A senior developer will understand that this job is to provide solutions to problems, not write code. Because of that, a senior developer will always think of what they are doing in terms of how much value it brings to their organization and their clients vs how much effort they are putting in.<p>Nicely put. Good read.
This post seems imbued with the philosophy that programming is fundamentally a trade skill, with a skills development path that is roughly equivalent to becoming a master carpenter or mechanic (which are significant accomplishments, but that's a separate topic).<p>One cannot become a cardiothoracic surgeon simply by being a doctor for 10+ years, or even by taking part in thousands of open heart procedures as an anesthesiologist.<p>Unfortunately for our profession, looking for a 'solid CS background' or an active github repo haven't proven universally effective as methods for identifying self-sufficient people capable of building reliable systems that solve complex problems. Those people are more easily distinguished by being in exceedingly comfortable positions already, or enjoying early retirement.
There have been quite a few of these "stages of development expertise" articles and in most of them, including this one, I get the distinct impression that the "what is a senior dev" section consists mostly of humblebragging.<p>I don't think these are descriptions of senior developers per se, but rather of people who have gathered enough experience to both drop the arrogance, realize the uncertainty in even the best projects, and to appreciate the importance of all those parts of our profession that are not Writing Code.<p>To me, this isn't exactly being a "senior", but is rather the minimum required to count as a professional. It says something about our industry that attaining such a state is worthy of so many words.
I think this article is pretty insightful. But I disagree with this in most contexts I've seen: "A senior developer understands that leadership is not about power, it is about empowerment. It is not about direction, it is about serving."<p>That's an ideal statement about servant leadership, a posture that often works wonderfully. But given real-world dev cultures, you also need straight-up power to protect yourself from other devs, if you don't have hiring/firing power. Those juniors/intermediates are often trained/filtered to be unpleasant examples of humanity. I wish it were otherwise (and there must be many exceptions), but all that "cultural fit" stuff generally means something bleak.
I think that seniority is closely correlated to understanding tradeoffs. Where a junior and a senior can make from time to time the same decision, how they do it is different. For junior it's often the only option he sees, or doesn't even realize he's making the decision that will have consequences. Whereas senior will think of the context and what are the possible options. All of them will be suboptimal and tradeoffs will be involved. And he'll pick the one that makes most sense with limited information from the context (tech properties, people impacted by the decisions, effort vs importance etc.).<p>...And senior's decision will unfortunately often be suboptimal as well, but that's what it is. He at least tried to understand the consequences and didn't have access to more information to evaluate it better. But he tried and will reflect on the failure and hopefully do slightly better next time at least in similar context.
Does anybody think that all the Sr. Engineers they work with are of the same value and experience? Why do we need separate job titles? It's OK to have a continuum of skills within a job, as you develop and grow.<p>I think if an engineer is inclined to leadership, and has grown T-shaped in some way, then a Sr Engineer title after 3 years doesn't concern me. A successful engineer with 3 years experience is vastly more valuable to me on a team than an engineer right out of school. And I'd much rather have "Engineer, Sr. Engineer, Principal Engineer" than "Junior Engineer, Engineer, Sr. Engineer".
"A senior developer is intimately familiar with their own failure. They have written code both under, and over designed, and have seen both fail."
I have been developing software full time for 30 years now and this is so true. In fact, it's a well researched bias: <a href="https://en.wikipedia.org/wiki/Overconfidence_effect" rel="nofollow">https://en.wikipedia.org/wiki/Overconfidence_effect</a>
Even in these comments you see new-ish developers supremely confident this is not true because they think know.
That said, there is a place for this delusion, sometimes, due to luck and/or really hard work some team pulls of something the old guy says is going to be hard and that's a great thing.
"The sad fact is that the vast majority of not only senior developers, but team leaders are in fact, intermediate devs. Most do not realize this, and have the best intentions, but have simply never worked with anyone who is at a higher level."<p>This terrifies me every day. Any ideas how to solve this problem?
A senior developer is such when they know not just how and why (through experience), but can teach and explain to someone else, and have them understand to a reasonable degree.
I can recall in my early days, a more experienced developer who was paired up with me and another junior colleague, that her job was not necessarily to try and teach us about all possible experience and gained knowledge - we would both have to gain our own badges and scars, and learn from the experiences. She would be there to direct generally, help us back onto the main path if we wandered too far, help with some of the larger leaps and jumps when we were ready, and to of course point out obvious pitfalls and perhaps some less obvious ones too.