Hacker News Reader

There are two types of senior engineers. One is the type talked about here. Someone who loves to design and code, but wants to have more impact, and finds that guiding other engineers is a more effective use of their time. See the examples in the article: Creating a new RFC process, introducing a post check-in hook for security audits, setting up a new platform team that builds libraries for everyone else.

All of these things multiply the work of everyone else. They make what everyone else is doing faster/more effective/easier.

Then there is the other kind of senior engineer -- the one that can output well structured, efficient, self documenting, code quickly. The one that you give the thorniest problems and they surprise you with a solution a few days later. Solving things that junior engineers simply couldn't.

There is value to both kinds of senior engineers. The first kind is much more valuable though because most orgs aren't doing the deep tech that the second kind of engineer is good at solving.

I'm the number two and must I agree, the need is punctual and there's quite some networking required to be able to reach to those corners of the (big) organization where they feel lost. It's almost always about some legacy thing and it's way cheaper to get me to fix and document it, right before thinking of rewriting/replacing.

Realistically you want a little bit of A and a little bit of B as well.

The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on; at the end of the day, sometimes parallel workstreams are more effective, and relying too heavily on a senior engineer can create a bad bus problem.

> The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on

That's what person A does.

Agreed that having a super senior engineers is bad for the bus factor (FYI people are calling it the lottery factor now, as in "what if they won the lottery and retired") but sometimes you don't have the luxury of having backup people.

That's silly though because even if they won the lottery they'd probably at least have an exit period while they sorted out their winnings, and you could potentially pay them to work a reduced schedule or something, especially if they like working there.

If I won the lottery I wouldn't stop working immediately, I'd give notice and could do some hand over.

Bus factor though - if a bus hits me I am immediately gone and people have to catch up without hand holding

The “lottery” framing is the normalized and gentle way of asking “What’s our plan for when Stripe / OpenAI offers them a $1M/yr Staff role but only if they start immediately?” Think about the great engineers you’ve met, and how many of them would say “Sorry, but no - my current team relies on me, and I should help them transition”.

I feel like a team that won't accept

> Sorry, but no - my current team relies on me, and I should help them transition

as a reason to allow a transition period is setting themselves up for failure. Isn't that the kind of engineer you want?

> only if they start immediately

Maybe this is a cultural thing, but here it's pretty well understood that people have notice periods built into their contracts. Absolutely no employer would be hiring any staff with any expectation that they be able to start the next day if that person is already employed.

In the US two weeks notice is the cultural norm, although there are horror stories about bad employers who don’t respect that all.

Probably the more relevant framing is “what if person just suddenly quits/takes leave?” Which has a whole host of valid reasons for happening.

Lottery framing is the gentle way of saying, what if they die.

But sure, go with the "other" lottery.

That's why we called it a Truck number.

It's just a nicer way of saying that they left without implying that they died.

Tbh the newspeak version of this is terrible. If someone immediately quits their job (presumably without transition so you can hire someone else) you have failed as a leader

The first sounds like an architect or engineering manager in disguise without the title (and probably without the pay), but probably gets to skip out on some of the more boring meetings

That leads us to wider communication problems for hiring:

1) pay is usually searched by title

2) job postings are also posted with titles

3) with those titles as ambiguous, you have to dig in to find out what kind it is

The link from title to pay and the confusion around it is advantageous to companies because it means calling someone a Senior Engineer, but giving them more responsibilities, still justifies a lower pay range

Excellent, thanks for the input.

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.

Add extra features... because of the implications

Job levels are tied to the amount of business value one provides. At some point in one's journey, for most developers, they will hit diminishing returns in terms of what they can provide from just their hands on keyboard contributions.Thus at some point people will tend to either peter out level-wise or need to find ways to augment what they bring to the table in terms of coding.

As an example, senior devs can be spending time mentoring, teaching, and guiding the junior devs in their team/org. Bringing up those around them will often, again not always, provide more business value than what they could have done on their own in that time.

> Job levels are tied to the amount of business value one provides.

The other replies have told you already this broadly isn't true, so I will ask this: Do you have an example of a company where what I quoted is the truth? Normally promotions are almost entirely political, I'd love to see some examples (or even one) where this isn't the case.

> Job levels are tied to the amount of business value one provides.

How do we measure business value? Do all those new products that Google launch and kill off add value? But they create promotions...

It's more like the illusion of business value.

> Job levels are tied to the amount of business value one provides

In many companies they aren’t tied to anything besides a meaningless title someone negotiates

It's not true everywhere but it's pretty much rewarded everywhere. Software engineering is pretty difficult to evaluate and managers will default to evaluating "soft skills" because they haven't looked at a PR in a decade. Also, the problems most organizations solve don't require much ability.

That said, I also do not think the author means admin/business related tasks, but non-"coding" things like software design, technical vision, etc.? You might want to look at earlier stage start ups that don't need the management/pseudo-management positions (if it fits your life). Warning that you'll have to jump ship as the startup becomes successful and you get pushed into non-technical roles. :)

I hear you. The so-called (full stack) jobs they have you doing everything under the sun not necessarily because you are proficient at any given assignment but because you can identify risks and bad practices quickly out of experience. The worst the job the more experience developers they need. I only once had a job where we were doing things right. The customer received our solution and it was so good, the customer said: "This is great, your solution is well put-together and well documented, your API's work out-the-box as expected, and they are fully tested. We can take it from here, thanks". Layoffs started a month later.

Note that the examples of non-code output are ultimately still code - just not code written by the senior engineer. Part of what an effective senior person does is to take their own knowledge and wisdom, and externalise it in ways that let their colleagues take advantage of it without having to learn it from scratch.

One of the most obvious ways of doing this is writing reusable code. Maybe you know the ins and outs of reliably spawning a child process in OS/2; you write a spawn_child_process_os2 function which does it, so others can take advantage of it.

But there are less obvious, and sometimes more powerful ways to do this.

The example of an RFC process externalises the engineer's understanding of how to rigorously think through and effectively communicate large changes.

The example of security check-ins externalises the engineer's understanding of how to write secure code.

The example of a platform team externalises the engineer's understanding of all sorts of code and build details particular to the organisation.

I am very glad to hear you liked it :)

That's a really good point - I suppose you could rephrase to say "the work that's easiest to discuss achievements in the first round interview is rarely code"

Basically, it's hard to explain, even to a technical person, how hard a code problem was, even if your solution was brilliant. But being able to do stuff that isn't code is a really easy way to showing you can 'getting shit done'

I actually cover this in my follow-up post, around the difficulty in detecting strong technical proficiency in a short first-round interview.

Would you rather the person making the decisions about the code you write be a developer too, or not?

I’d rather be managed by developers, and you only get that by promoting developers into management.

You can stay an individual contributor if you want, and the pay is still very good. If it doesn’t work at your company, you can find others that will let you stay an IC.

That's funny. I studied information sciences because I loved systems but didn't want to get stuck coding all day and (no offense?) was less introverted than many of my fellow tech majors (to where even my professors would be surprised when I'd take on a coding role in a project because they stereotyped me as not fitting the part.). We studied things like documenting systems, workflows, use cases, project management, networking and introductory programming courses in databases and several coding languages. In theory it sounded great. But I the job market it's actually extremely difficult to get those code-adjacent jobs when you don't have coding experience.

Your job isn’t to code, it’s to solve business problems. To make more money for the company. That’s it.

“Your job as a bricklayer isn’t to lay bricks. It’s to solve building problems.” If you’re actually looking for an architect or designer or salesperson or manager, hire them instead of berating developers for not doing all of those jobs at once.

Also in most countries devs don’t get paid enough to solve business problems. American tech wages are the exception.

Which would actually lead to an awesome job description:

   "Full Stack bricklayer."

If the title is software engineer, it is though. Solving business problems is not engineering. I get that at the end of the day it's about making money, but these expectations are not clear and the title ultimately reflects your expertise. I think part of the problem is the lack of standards in software engineer compared to other engineering, which have code of ethics and often require a license to practice. Those other engineering jobs are probably not doing management or solving business problems.

I personally know a senior mechanical engineer who’s basically doing what other posts are complaining software engineers end up doing — managing and solving business problems.

I think this is more common than you’d think.