Comment by TeMPOraL | Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.

I've been thinking about a more charitable interpretation of this recently. Another thing I rant about[1] is that tools we use for programming are not expressive enough. It takes too much work to say simple things, the coding feedback loop is ridiculously long. So how this connects? In a way, junior programmers can be seen as a Mechanical Turk version of a Sufficiently Smart Compiler - it lets the more experienced people skip some of the tedium with the tooling and deal with higher-level concepts, which get translated to actual code by an army of juniors and interns. Except, this doesn't work that well - the coding feedback loop is even slower.

--

[0] - https://news.ycombinator.com/item?id=27417462

[1] - https://news.ycombinator.com/item?id=28568053

This definitely resonates. I've often talked about how the key transition to 'lead engineer' is when you learn how to wield a team of programmers to solve a technical problem, instead of solving it yourself, and to higher levels it's when you learn how to wield an entire organization to some technical purpose.

These ARE much clunkier tools than a compiler.

Another way I've expressed it is how the tool you use to get started on implementing a change shifts as you grow more senior (if you'll forgive an IDE-centric kind of view - this is meant to reflect life in a Big Org - feel free to substitute with appropriate emacs commands)

- Junior Dev: File > Open

- Dev: File > New

- Senior Dev: File > New Project

- Lead Dev: File > New Diagram

- Principal Dev: File > New Powerpoint Presentation

- Staff Dev: File > New Recurring Meeting Request

Love this metaphor and progression, but I thought Principal was ahead of Staff in the Ladder?

There may be a sort of sweet spot in the progression where a programmer can advance to a point where they spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of, with some code reviews here and there, rather than coding as much themselves (but they still code, especially the critical pieces). This lets them still be a key player as far as programming is concerned but there's also a space for more junior programmers to learn and grow without trashing the whole project in the process. The Godot engine seems to be turning into this sort of sweet spot model with its tech lead. However in a company this seems like an unstable situation, since I've seen such leads advance another step and now the only thing they "architect" is business strategy via all-day meetings, like any other executive, and the last time they coded anything was years ago. You might get them on a rare code review but they've become so far removed from the details they're not as helpful as they used to be, which in turn leads to not including them anymore. This distance hurts again because now that they have at least some influence (not as much as the 'equivalent' managerial track position, 'mysteriously') to address long-standing dev pains they are too far removed from the pain to spend their limited influence fighting it.

My own filter for how likely a company is to fall (or be) in this trap: does the CTO code at all?

Is this not what old-school corporate dev environments did? Grunts filling in interfaces? I’m sure I’ve read this sort of thing before

>> spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of

I think a good use of the experienced programmer is to write some critical components well. I'm also with you on system level design: These are the important interfaces, you write this piece and you write that one.

Another example, I have an Oculus Quest 2 VR headset. It was fantastic when I got it in March. Now they've got some glitches where the rendering STOPs for a brief instant and the view is not updated with motion. I'm wondering if this is because John Carmack is no longer full time there and someone compromised some design principle in order to implement something. Once the glitches are in, they're going to be very hard to get back out as time goes on.

There is that joke about the University Professors talking about the best high level language, throwing out various languages until one just replied with "Grad Student".

It does make a lot of sense, you describe the problem in a very high level and abstract way and at the end of the process you get an executable out of it.

But yeah, as you go up the ladder, even the technical one, you end up needing people skills more and more than any technical or programming skill. Usually by senior level you're the best that you'll ever be at technical topics (hand wavy description here, don't nitpick), and the only way to progress up is to improve communication. No amount of extra technical knowledge will help you if you cannot communicate well.

Juniors are beginners, learners, apprentices, and are bound to make mistakes and design things poorly. The issue is there are so few high-quality engineers relative to the demand, and it's hard to prove who is high-quality before they're onboard for a few months. So, if someone is high-quality, you really don't want to lose them, so you promote them, pay them more, try your best to keep them on-board. There's a benefit to elevating them out of the weeds, because often they can glance at the weeds and tell someone else how to clean it up easily, without spending their effort to actually do it.

Furthermore, they can glance at 10 patches of weeds, 10 junior engineers, and find the couple that need more guidance than the others. They can leverage their knowledge through others, assessing their strengths/weaknesses as coders in ways juniors never could.

It seems like companies are creating independent contributor tracks to remedy this issue. You can have people who are legendary programmers float around and contribute where they wish.

This is well-said and resonates with me quite a bit. How do we build expertise in an engineering organization where the best engineers are incentivized not to engineer?

I really appreciate this perspective. Better tooling to enable individuals to penetrate more layers of abstraction sound great. To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever. However, I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.

> To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever.

This is not ideal though. Cloud services have a pretty short half-life, and trap you in business relationships that you shouldn't need just to build software.

(I know, I can't stop complaining.)

> I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.

That is true, but I still think the idea is sound - there's much more universal, transferable programming-related experience juniors gain than things they'll need to unlearn later. The problem I see here is that, just as those developers gain that experience, they get pushed out to management / faux-management. In principle, this should lead to at least some improvement in quality - as increasingly better people are tutoring the next generation and directing it - but I feel we've reached a fixed point in terms of software skill, with most software being written at a pretty low level.

Quite right. Not many companies follow Fred Brooks' "surgical team" model and I would like to see more try it.

Reply on news.ycombinator.com