
What's a senior engineer's job? - akshaykumar90
https://jvns.ca/blog/senior-engineer/
======
venantius
One thing that I consider to be a really important part of a senior engineer's
job that's not enumerated here is: helping more junior engineers come up with
estimates for difficulty and time on projects they're about to undertake. To a
senior engineer, there are a large number of projects that are fairly easily
scope-able, e.g. "add a new API endpoint"; "refactor this medium-large model"
that a junior engineer may not have the necessary degree of confidence to
estimate. While this can sometimes be the responsibility of an engineering
manager, not all EMs are sufficiently technical to know how long it'll take a
_junior_ engineer to take on an otherwise easily-scoped task.

~~~
mlthoughts2018
Speaking as a senior engineer myself, I disagree because time estimation in
software is not a useful activity. The only thing it helps is political
manipulation in a layer of management above you. Engineering work takes as
long as it takes and often there are unknown blockers or surprise aspects of a
problem that make it far more difficult than expected, so frequently that the
initial estimate has no value to anyone, not even in a rough sense like, "will
it take 2 hours or 30 hours." In my experience, a task estimated at 2 hours is
equally as likely to take 30 hours as to actually take 2 hours, and there is
no systematic way to know which case you're in.

Regular check-ins to catch the blocking issues early is much more important,
and so teams should not waste time making estimates or tracking velocity. It's
pure junk. Instead, start working and meet often to detect blocking issues as
you go.

~~~
fipple
> I disagree because time estimation in software is not a useful activity.

Anyone who can say this has the privilege of being fully insulated from
revenue generation. But at some level of the company, resourcing decisions are
made, and they depend on understanding the costs and benefits of various
tasks. If you are deciding between having your engineering team build an
Android app and adding an API integration, you need to understand how much
revenue it will bring you and how much it will cost, and that’s where
estimation comes into play.

Man months are very non mythical when it comes time to write paychecks.

~~~
mlthoughts2018
> “Anyone who can say this has the privilege of being fully insulated from
> revenue generation.”

You are incorrect. I work in a directly client-facing capacity and often have
phone calls to help our actual clients and their product managers, and I have
many internal stakeholders for my team’s work that are sales-facing and
client-facing. Most of the quarterly planning meetings I am required to give
input into are directly focused on revenue generation.

Because software velocity estimates do not have any correlation to the actual
delivery timeline, yet they will be used for political bikeshedding by people
who don’t know about the technival details, it is exactly in revenue critical
situations that you want to get rid of the pretense of estimation and admit
the truth that you have to simply measure by doing and frequently reporting
blockers.

~~~
fipple
If you can’t at least say which of two projects will take longer, the
architecture must be fucked to hell.

~~~
mlthoughts2018
Usually it is sociological, and has not much to do with good or bad
architectures. The more surprising blockers tend to happen when someone on
another team can act as a gatekeeper to a resource you need, like permission
to make a change, and uses this blocking for some political purpose.

It can cause bang-simple engineering tasks to take weeks, during which time
you never know how much longer you’ll need to wait, and depending on political
capital of the entity blocking you, you may not even be allowed to publicly
explain they are blocking you, and you are forced to absorb the negative
externalities of their choice to block you.

------
mabbo
> I put “write code” first because I find it surprisingly easy to accidentally
> let that take a back seat

As a first-year-out-of-school developer, I shadowed an interview once from a
"Principle Engineer" at another company. By the end of the interview, we
understood two things: 1: He did not code in his job and hadn't in a while. 2:
He could not code anymore.

This role was for a senior engineer position, where he would need to mentor
people on writing software. It was a pretty hard 'no' by the time we did our
group follow-up with the other interviewers.

~~~
dunpeal
> As a first-year-out-of-school developer, I shadowed an interview once from a
> "Principle Engineer" at another company.

A lot of people don't realize how easy it is to get impressive titles at very
small or low-quality outfits.

If it's just you and the CEO running the place, you would be a "CTO" even if
you couldn't pass a phone screen for any decent entry-level engineer position.

We constantly get resumes from "senior engineers" working for no-name tiny
companies and startups. They are often our worst candidates, especially when
it comes to hard skills like coding.

Reality is that these skills are rare, and no-name outfits will be competing
for the rare candidates who can code against all the better employers out
there. The results are what you'd expect.

~~~
Novashi
>We constantly get resumes from "senior engineers" working for no-name tiny
companies and startups. They are often our worst candidates, especially when
it comes to hard skills like coding.

That's funny because I remember not too long ago about complaints regarding
Senior Engineers at BigCorp that got too comfy and also couldn't code. It
seems the walls are closing in.

It's a good anecdote that titles are bullshit in our particular field. It's
also why I've opted to remove 'Senior' from my titles for external resumes to
avoid people making judgments too soon.

~~~
dunpeal
> It's also why I've opted to remove 'Senior' from my titles for external
> resumes to avoid people making judgments too soon.

I wouldn't go quite so far. The fact that titles don't mean much in sub-par
outfits doesn't contradict the fact they can mean a lot in solid companies.

------
amriksohata
Totally disagree with the section "What’s not part of the job"

Part of any job is stepping up and deputising for your manager, sure if you
don't want career progression or want to go into the technical side you could
argue they would try and do some of that instead, but if you want to be a
senior you have to be a rounded individual that can mentor new starters, help
with sprint planning when your boss is not around. Thats part of being a
senior, otherwise you are just a good Mid.

~~~
UK-Al05
I find help with sprint planning something every engineer should do. Sprints
are owned by the team not the product owner

~~~
mosselman
People should do what lies within their realm of capabilities. I know enough
people who are fine programmers but who lack the overview or sense of
connectedness between certain task or the ability to think about the business
value of certain tasks in order to make decisions when things start to take
too long or become too complex. Those people should not take care of handling
the sprint when the person who normally does that is away.

So no, not every engineer should take care of the team's planning.

~~~
UK-Al05
Well in my team sprint planning is a team job. Everybody gets together and
plans the next stories. Usually different people have knowledge/interests on
different stories, so nearly everyone gets some input.

Heck in the scrum guide this is the way it's meant to be.

If your engineers can't factor in business value, or work dependencies its
usually because people are hoarding knowledge so they dont have the ability to
factor that in.

~~~
mosselman
I didn't say the team as a whole wouldn't be able to contribute. I was saying
that not all people are able to take over day to day planning individually.

"its usually because people are hoarding knowledge so they dont have the
ability to factor that in."

That is like saying that everybody who isn't smart, must be good with their
hands. Some people are just not good at certain things, no matter how much
they are enabled to do those things. Which is completely fine.

------
srazzaque
Good read, I like JE's posts. But I definitely feel like this falls into the
trap that a lot of similar posts fall into - attempting to "bullet-point" a
role description inevitably will result in people criticising the inclusion or
exclusion of individual points. Which is a shame because it detracts from the
overall spirit of what's being said.

Struggling to find the link now, but I read another post on the subject of
seniority, and it basically summarised the crux of it for me. This unravelled
everything. Seniority is measured contextually by asking: "to what degree can
I leave stuff with this person and expect it to get it done with high quality?
Further, to what degree can I NOT leave stuff with this person and _still_
expect that to get done."

From this, one can derive their own context-appropriate "check list". In an
environment such as finance, where an engineer is absolutely not the expert,
can I trust that this person can work with the experts to get to an
appropriate solution? In an environment where you have many intermingled
teams, will s/he be able to propose solutions and get buy-in across the org?
In a consulting/client scenario, can this person represent our company? What
might they need help in? In a bootstrapping startup scenario, can I entrust
them with the entire build of (some major component)?

In different contexts, the above set of questions would unroll a different set
of measurements for seniority, and may require a different mix of
soft/technical skills. But that's fine, there's no one-size-fits-all seniority
ladder.

~~~
jkmcf
I’d love to read that link.

I usually summarize the role as doing what’s necessary to get the job done
reasonably, but your point about knowing what to entrust others with is spot
on.

------
yitchelle
In the section where she explicitly mentioned what is not part of her job, I
bring two of her points which I disagree with.

* Make sure work is allocated in a fair way

* Make sure folks are working well together

While she is not directly responsible for these two items, she and everyone
else on the team should be responsible for alarming their manager/team leader
when either of these items are not working. With more eyes and ears monitoring
the team, it helps to reduced the risk of bad behaviour disrupting the team's
cohesion.

------
fogetti
I think what the author described is mostly any engineer's job. You don't need
a title for this.

------
marmaduke
I think there are some less concrete responsibilities. This post assumes all
your colleagues give a shit, while some work might get delegated to a
colleague who then waits for you to step them through it. How do you motivate
people to take responsibility for their work (when firing or changing teams
isn’t possible)?

I think a senior engineer is also going to be one writing fundamental proofs
of concept when time is tight (or at least I have been doing this)

------
vkjv
> "...review design docs"

In my opinion, one of the most important and most difficult parts of the job.
Architecture and design shouldn't be limited to senior engineers--it won't be
in practice, anyway. Doing so is a sure fire way to stilt the growth of your
team.

But, reviewing designs is hard. It requires recapturing much of the context
that the engineer gathered in a very short period of time. I also find it
sometimes difficult to separate, "this is a fatal design flaw" from "this
isn't how I would do it." I really like the suggestion of providing feedback
via additional information.

Mistakes are a very important part of learning. I try to make sure everyone
has the opportunity to make their own instead of making mine.

~~~
jiveturkey
what ive found works is to /always/ pair a jr with a sr engineer to write any
ddoc. 2nd, always assign a specific sr reviewer. only after that review,
release the hounds. others that have interest or particular insight can
reflect on deficiencies (or, rarely, strengths) without the dread feeling of
having to deeply understand the context or underlying dependencies.

same reason you don’t just throw a code review out to “everyone”. everyone =
no one

------
rlaanemets
I think that setting explicit job boundaries is a good thing to do. Otherwise
you end up with role creep and potential burnout. This happened to me. There
is a considerable pressure to pick up as many activities at the job as you can
as hiring more developers is hard or impossible at some locations as the
demand for developers has skyrocketed. This demand buries you even deeper
under tasks once your colleagues leave elsewhere for better offers.

------
mzanchi
It's interesting the author mentioned estimating but said they are not very
good at it yet. I have read somewhere else that what distinguishes a senior
engineer from a junior engineer is exactly the skill in estimating work.

~~~
collyw
As I said in another reply, it really depends. If its a task that I have done
before and new code, then I can give a fairly good estimate. If its something
new, I have no idea. If it's on a monstrous old codebase, then there are a lot
of unknowns to add into that.

And most people expect you to do such estimates on the spot.

------
nojvek
Jvns does it again. We need more women like her in the industry. Such an
awesome engineer and educator.

------
visviva
What's a senior *software engineer's job?

------
fit2rule
I have my own sort of loose rules about this. I long ago came up with it, and
it works for me, but maybe there are a few holes worth poking.

Basically it goes like this: There are no 'senior'/'middle'/'junior' level
developers. There are _A, _B and _C.

_A guys sit at the top. _B supports _A. _C support _A and _B, and .. other
_C's. _A supports all _B's, all _C's, and of course.. all other _A's.

The position is self-determined, i.e. up to the individual. Occasionally, when
enough _A's, _B's and _C's serve together, they self-organise. Sometimes, you
need to tweak a few things.

For example, there is a kind of _A who doesn't want to work on things without
a few multiples of _C around to clean up after him. This guy needs a _B.

Then there are _B's who ignore _C's and just wanna work with _A's. This guy
needs a better _A. And, also, a few _C's.

And there are _C's who want to be _A's, while ignoring their duty to _B. This
guy needs a few more _A's, and either becomes a _B, or an _A. (Or a _D, which
is 'goes and does marketing stuff instead'.)

Either way, there is another 'type' of developer, and this guy is an _X. He
gets all the _A's and _B's and _C's happily playing together, executing on the
plan. He can be an _A or a _B or a _C: he doesn't care, as long as things are
executing.

~~~
Aeolun
Why would you try to argue this point with A,Bs and Cs? Even if you called
them monkeys, horses and lions it would have been more understandable. There’s
a reason we don’t use these kind of variable names...

