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."
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 if someone really should be fired and it is only obvious to their direct report then something seriously wrong has happened. Firing should never be a surprise to anyone. Good tech cultures are good at making expectations clear.
I'm a "Lead" Developer without direct firing power, but I know my CTO has my back. If I ever recommended firing someone out of the blue his response would be, "How did you let it get this bad without looping me in sooner?" And he would be correct.
I'm glad I don't have autocratic power and I would never work for a company that handed that much power to one person.
Summarizing some of Michael O. Church's screeds on the topic (https://michaelochurch.wordpress.com), I would say that the value of fresh graduate developers comes mostly in how much they undervalue themselves, and therefore how much excess generated value can be "skimmed off" by the company.
A software consulting firm, after all, is usually a bunch of fresh grads headed by one "architect" with experience. Most of the work is done by, and most of the decisions are made by, the fresh grads, but the work is being billed at a rate that assumes the senior "figurehead" developer, and others like him, are doing the work. (This is also true in law, finance, advertising...)
That's part of it, but I also find recent grads tend to be useless on the hard/fun parts of development, but great for the tedious crap. Sure, with a lot of supervision interns can fill the same tasks, but recent grads tend to stick around for much longer.
There is also a huge nebulous gap after that where cost and talent is not that closely connected. You can have two people with similar resumes where one is worth 200+$/hour and the other is barely better than an intern. Worse this can get very project specific. People that do great things for one project can bomb another that's superficially similar.
Recent grads may be of near universally low quality, but it's predictably bad.
> A senior developer is intimately familiar with their own failure... and is obsessed with simplicity.
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".
It's something that I noticed too. I had what I think was a pretty unique opportunity to be involved in project(s) from the very beginning to the 'end' (i.e. support phase) from my early working days - since my very first year. That allowed me to fully experience writing really underengineered code, then subsequently vastly overengineered, then a chance to clean it up - all while having no one else to blame but myself for any shortcomings. I'd like to think it taught me a lot and of all the rules-of-the-thumb and catchy acronyms, it seems like KISS and YAGNI sank in the most.
Also, a lot of the points the article makes about the senior engineer seem to be about a 'business sense' - what the actual business problems you're solving are and how your solutions influence the business itself. I really like to know all that - in fact, those are my starter questions as a candidate in any job interview - but I don't know if it's just an innate trait that some people have, if it's something you pick up, or maybe both to a degree...?
And I don't consider myself a senior engineer, not by a long shot...
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.
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".
I have worked with some incredible engineers in my life in 5 different companies and several divisions within those companies. I have met but a handful of senior devs who had what, when I was greener, an innate or better yet sixth sense as to what/how things should be done. The rest are intermediate developers. While I would love to believe a 3yr. engineer could be "senior" I've never met one who has the indepth knowledge to play the role.
Also, many companies have created multi-tier systems: Jr. Eng, Software Engineer, Sr. Engineer, Lead Engineer, Principal Eng, and so on
Sometimes it is just about pay grade and rewarding people with a title. I am not saying you should not speak your true mind to a SVP or ESVP, but you should expect that people with more prominent title have more authority and more say, because ultimately someone has to make a decision on yay or nay.
I feel finding a place where you can truly have impact even as a junior is incredibly important, if not, more than a title. People respect those who work hard, capable and honest, but title still matter.
My former employer's titles went Engineer, Senior Engineer, Principal Engineer, Senior Principal Engineer, Fellow, Senior Fellow, Principal Fellow. Each "Engineer" title had two levels, and one needed to be in each level at least two years in order to advance, so a "Senior" needed a minimum of four years. In practice, you needed more unless you had an advanced degree.
The "seniority" titles don't really measure anything useful; that's why they don't really transfer between companies. A "senior engineer" might become a "lead engineer" or just an "engineer" at a different company—which means there's no objective measurement going on there.
I much prefer a guild-like system for measuring actual aptitude:
• apprentices know one thing well enough to do it (the average "Java developer");
• journeymen have a good picture of the field, know what "the best tool for the job" is in most cases (even if they don't know that tool), and have the meta-skill required to efficiently pick up a new language/framework/paradigm/whatever else in order to solve a problem that requires it;
• masters have enough experience to flinch away from bad design/architecture. They've been burned by every category of problem it's been possible to be burned by, such that they have a complete high-level picture of all the moment-to-moment considerations involved in "the art." They know what questions to ask about a proposed pull request to determine its quality. To get here, they've likely completed a major "masterpiece" work on their own, and maintained it under heavy use by others.
These aren't categories that match social standing, or seniority, or experience, per se. In fact, they don't even form a tight match to the kind of "skill" people look for in job ads; you can become a "master" at 15 if you accidentally build something really popular, even though you still need a cheat sheet to remind you what's in your language's stdlib.
But these categories are able to be objectively fit to people (it's pretty clear in which one a particular person sits); they can be carried between organizations with no loss of meaning; each category is a strict superset of the skills of the former; and they tell you something that's very useful to know.
Interestingly, it would be fully possible to set up an educational curriculum that could make every graduate a "master" by the criteria above. Right now, though, colleges only make apprentices. Companies sort of make journeymen, though rarely. And no part of "the system" has any chance of making someone into a master; they have to pursue such a trial on their own.
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..."
Basic economics dictates that there is only a shortage if prices are increasing, and they are not, certainly not relative to overall price increases.
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.
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.
Cant find senior developers? Quick trick -- raise the salary and see them pour in for interviews!
It's unclear if they mean to imply that 1) there are more vacancies of any type than people entering the field or 2) there are plenty of people entering the field but not enough experienced senior developers to cover the vacant senior developer positions.
1) is a sentiment I've seen frequently expressed, but is not really panned out by the number or type of job postings in secondary hubs outside the Bay (e.g. Chicago). 2) makes more sense, but the article doesn't really address how to solve the root issue when hiring managers aren't willing to hire from the previous two buckets.
You can certainly say "raise the salary" but try convincing upper management that it's worth it. That, in my experience, is the main cause of the lower salaries.
Also note that "worth" is not really at issue here. Salaries are set by supply and demand for a specific skill-set. If the salary is not "worth" it, then the project cost-benefit-analysis was wrong.
> 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.
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).
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.
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.
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.
"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."
This terrifies me every day. Any ideas how to solve this problem?
Wasn't this posted, like, two weeks ago? Same thing applies here as applied there.
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.
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.
Any small change in the URL will let it get through. We leave it porous on purpose, to give good stories multiple chances at getting attention. The downside is that more dupes get through as well, but we catch most of those and users point out most if not all of the rest.
It's on our list to make a more sophisticated dupe detector, but I don't know when we'll get to that.
I think you're misunderstanding me. There is no specific quality that makes them better. A senior engineer is just, on average, better than a junior engineer on every quality that makes an engineer an engineer.
For a specific number (I don't think I implied that), their inner product is higher.
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.
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.
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.
"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: https://en.wikipedia.org/wiki/Overconfidence_effect
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.
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.).
...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.
35 comments
[ 0.16 ms ] story [ 1449 ms ] threadThat'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'm a "Lead" Developer without direct firing power, but I know my CTO has my back. If I ever recommended firing someone out of the blue his response would be, "How did you let it get this bad without looping me in sooner?" And he would be correct.
I'm glad I don't have autocratic power and I would never work for a company that handed that much power to one person.
I do wonder if most of their value comes not from their brains but from their pliability and capacity to be overworked?
A software consulting firm, after all, is usually a bunch of fresh grads headed by one "architect" with experience. Most of the work is done by, and most of the decisions are made by, the fresh grads, but the work is being billed at a rate that assumes the senior "figurehead" developer, and others like him, are doing the work. (This is also true in law, finance, advertising...)
Or, in other words: http://marginalrevolution.com/marginalrevolution/2012/02/rob...
There is also a huge nebulous gap after that where cost and talent is not that closely connected. You can have two people with similar resumes where one is worth 200+$/hour and the other is barely better than an intern. Worse this can get very project specific. People that do great things for one project can bomb another that's superficially similar.
Recent grads may be of near universally low quality, but it's predictably bad.
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".
Edit: grammar
Also, a lot of the points the article makes about the senior engineer seem to be about a 'business sense' - what the actual business problems you're solving are and how your solutions influence the business itself. I really like to know all that - in fact, those are my starter questions as a candidate in any job interview - but I don't know if it's just an innate trait that some people have, if it's something you pick up, or maybe both to a degree...?
And I don't consider myself a senior engineer, not by a long shot...
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".
Also, many companies have created multi-tier systems: Jr. Eng, Software Engineer, Sr. Engineer, Lead Engineer, Principal Eng, and so on
Sometimes it is just about pay grade and rewarding people with a title. I am not saying you should not speak your true mind to a SVP or ESVP, but you should expect that people with more prominent title have more authority and more say, because ultimately someone has to make a decision on yay or nay.
I feel finding a place where you can truly have impact even as a junior is incredibly important, if not, more than a title. People respect those who work hard, capable and honest, but title still matter.
I much prefer a guild-like system for measuring actual aptitude:
• apprentices know one thing well enough to do it (the average "Java developer");
• journeymen have a good picture of the field, know what "the best tool for the job" is in most cases (even if they don't know that tool), and have the meta-skill required to efficiently pick up a new language/framework/paradigm/whatever else in order to solve a problem that requires it;
• masters have enough experience to flinch away from bad design/architecture. They've been burned by every category of problem it's been possible to be burned by, such that they have a complete high-level picture of all the moment-to-moment considerations involved in "the art." They know what questions to ask about a proposed pull request to determine its quality. To get here, they've likely completed a major "masterpiece" work on their own, and maintained it under heavy use by others.
These aren't categories that match social standing, or seniority, or experience, per se. In fact, they don't even form a tight match to the kind of "skill" people look for in job ads; you can become a "master" at 15 if you accidentally build something really popular, even though you still need a cheat sheet to remind you what's in your language's stdlib.
But these categories are able to be objectively fit to people (it's pretty clear in which one a particular person sits); they can be carried between organizations with no loss of meaning; each category is a strict superset of the skills of the former; and they tell you something that's very useful to know.
Interestingly, it would be fully possible to set up an educational curriculum that could make every graduate a "master" by the criteria above. Right now, though, colleges only make apprentices. Companies sort of make journeymen, though rarely. And no part of "the system" has any chance of making someone into a master; they have to pursue such a trial on their own.
Basic economics dictates that there is only a shortage if prices are increasing, and they are not, certainly not relative to overall price increases.
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.
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.
Cant find senior developers? Quick trick -- raise the salary and see them pour in for interviews!
1) is a sentiment I've seen frequently expressed, but is not really panned out by the number or type of job postings in secondary hubs outside the Bay (e.g. Chicago). 2) makes more sense, but the article doesn't really address how to solve the root issue when hiring managers aren't willing to hire from the previous two buckets.
Think of this analogy, suppose you are looking to fill your car up with gasoline at $1/gallon. You cant find any. Is it a shortage?
Nicely put. Good read.
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.
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.
This terrifies me every day. Any ideas how to solve this problem?
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.
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.
It's on our list to make a more sophisticated dupe detector, but I don't know when we'll get to that.
For a specific number (I don't think I implied that), their inner product is higher.
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.
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.
...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.