The further up the ladder you go, the less this is true.
I tell people about a senior plateau - after this point, the growth gets smaller. Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
Further, as organizations grow larger, there are more implications to every extra feature. That is, all of the easy stuff is done and the hard stuff means a change in multiple parts of the system, introducing fragility and cross-team coordination.
In some cases, the effort in coordination outweighs the effort in code. And that's what I need a senior developer to do - can they understand multiple systems, work with multiple teams, or do they need engineering managers to figure it all out and give it to them bite-sized?
And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
Good points. It makes sense overall. I'm wondering if the perception is that high level engineering doesn't have as much business value as lower level engineering that allows teams to work in parallel.
> Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
I believe this is mostly a business decision, although one that could be justified. In theory, systems can be built such that changes and updates are simple configuration changes, including new features. Another example is using advanced techniques to guarantee no bugs. So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers. As the system matures the cracks become visible and unless there are sophisticated techniques, codebases tend to deteriorate and that introduces otherwise unnecessary business costs to fix issues or even build a new system. The main reason I can think of why this is an accepted "sacrifice", is that a team of high level engineers cannot be as transparent as multiple teams with lower level engineers and managers. High level engineering is often opaque to everyone except others that have the knowledge.
> And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
So yes, this makes sense but I think it's only a bottleneck if others are not as technically proficient. Speed comes as a result of more technical knowledge, and it seems to me at some point software companies are cutting that off in favor of using that experience to get everyone else up to speed, instead of continuing to leverage the direct skillset and building teams of highly proficient engineers, which in my opinion would deliver exponential business value (by coding sophisticated systems that can do virtually anything).
> In theory, systems can be built such that changes and updates are simple configuration changes, including new features.
Taken to the extreme, that's a low code platform. However, the complexity I am speaking of is the intersection of what a product should do today, what it does do today, what it should do tomorrow, and what technical debt prevents this from being obvious.
(For example, if the system has grown in a way that what was one team is now four and they are all trying to work in an intermingled codebase that made sense in a smaller organization.)
The solution may be 1,000 lines of code, but it takes the analysis from someone who provides a 1,000 line rather than a 10,000 line solution. That 1,000 lines might even be obvious once the problem is defined.
A senior developer, in this case, is someone for whom the mechanical translation of an idea to code is not the limiting part.
> So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers.
That's entirely true. However, there are more organizations than high level engineers. And how do you manage to build those high level engineers if all we (as an industry) do is keep hiring from a small group?
> And how do you manage to build those high level engineers if all we (as an industry) do is keep hiring from a small group?
Right, scaling teams would be a problem. The alternative would be a company entirely led by engineers since most projects would eventually become too complex for others to manage. Great points, thank you.
I tell people about a senior plateau - after this point, the growth gets smaller. Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve.
Further, as organizations grow larger, there are more implications to every extra feature. That is, all of the easy stuff is done and the hard stuff means a change in multiple parts of the system, introducing fragility and cross-team coordination.
In some cases, the effort in coordination outweighs the effort in code. And that's what I need a senior developer to do - can they understand multiple systems, work with multiple teams, or do they need engineering managers to figure it all out and give it to them bite-sized?
And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.