
The Senior Engineer’s Guide to Helping Others Make Decisions - Nycto
http://silverwraith.com/blog/2017/10/the-senior-engineers-guide-to-helping-others-make-decisions/
======
duncanawoods
The real way a senior engineer trains juniors is by selecting appropriate
work. They thread the needle of a number of factors: it needs to be done, its
within reach, will build their skills, will educate them on
product/business/process, they will find rewarding, will give ownership,
relevant staff can support them etc. These factors are so important that the
senior engineer might need to negotiate with the product manager to bring
appropriate work forward to avoid failure or killing the enthusiasm of the
junior.

What can't really happen is for a junior to suggest work. The experience and
context they lack is for the business, the user and the strategy. The junior's
biases for what they think matters are usually much worse that the senior's
for what works e.g. they want to improve cosmetic factors or add cool
features. Its not that they are wrong, the product might be offensively ugly
and the cool features might be game changers, but professional development is
a parade of gut wrenching compromises because the constraint is time and
resources not imagination and ambition.

That said, I agree with the thrust of the article - the risk of senior
engineers "fighting the last war" and accruing a set of limiting beliefs is
very real and the naive optimism of a junior challenging them is part of the
value they bring.

~~~
kelnos
> What can't really happen is for a junior to suggest work.

Junior engineers should feel welcome to suggest work. They should also be ok
with having that suggestion rejected or put on the back burner because it's
not pertinent to the current product/business goals.

Depending on how the company is run, the senior can make the call, or involve
a product owner, as to whether the junior's suggestion is something that they
should be working on or not. But I think the OP's point about tone is
important: being dismissive about it is demoralizing and isn't helping the
junior grow. Explaining why (to borrow the example from the article) it might
be ok to lose a week's worth of data, or even why they just currently have
bigger fish to fry, but will revisit the idea later... that shows respect for
the junior's desire to grow and establish ownership while giving them a taste
of knowledge and experience that you have but they don't.

~~~
nkjoep
> They should also be ok with having that suggestion rejected

I agree at one condition: explain them why their suggestions are not
appropriate (out of context, lack of resources, not a priority etc...).

That way you simply teach them more about the team/company business and will
help them to step up their decisional skills.

~~~
avh02
I agree but have to be careful with this one. I'm relatively junior and we had
a lot of "it's not the time for this right now" when I believed it was... You
have to win somebody over with your arguments rather than a unilateral
explanation IMO. (edit: what I'm saying is - prove your explanation and
convince the person of the business priorities, you can't say "it's
confidential" or "we can't talk about why" or "the decision was made above our
head".)

Also when your team has many priorities and are tackling many fronts and one
of your frustrations - as a team - is your rarely addressed tech debt (due to
business/monetisation priorities), then the team is up for demotivation.

~~~
kelnos
> I'm relatively junior and we had a lot of "it's not the time for this right
> now" when I believed it was... You have to win somebody over with your
> arguments rather than a unilateral explanation IMO.

Yes and no. I think the best kind of rejection is the kind that convinces the
rejectee that the rejection is well and proper, certainly. But at the end of
the day I want to see some measure of humility in a junior engineer. Blind
trust is a bit much, to be sure, but the junior should have some grasp on the
idea that they don't know everything, can't know everything, may not have all
the context (context which they do not always need to do their job), and they
should just accept it and move on. Some battles are worth fighting, but many
are not.

Put another way: a company is not a democracy. Consensus is nice, but if we
had to build consensus around literally everything we did, we'd get a lot less
done. Sometimes it's absolutely fine and proper to say "we're not doing that
right now, and I don't have the time to get into the nuts and bolts of why".

> (edit: what I'm saying is - prove your explanation and convince the person
> of the business priorities, you can't say "it's confidential" or "we can't
> talk about why" or "the decision was made above our head".)

Agreed, those are crappy, insulting, disrespectful explanations.

~~~
avh02
oh yeah, i'm definitely not expecting an on the spot explanations of every
single thing, but eventually i'd like an insight in to why something was
rejected (if it's a major thing), 'tis all. That can be later on in the week
or when appropriate, or after fires are out or whatever.

Not saying there needs to be consensus (i.e: I agree), I don't necessarily
have to agree with every single thing I've been asked to do in order to do it,
sometimes a job's a job.

When I was composing that post I was thinking at a relatively coarse level of
a previous experience (which to be fair is at a different level to the
original article).

------
wallflower
I saved this comment from jlcfly from an AskHN that was answered a long time
ago and have reposted it many times, as I feel it is an excellent philosophy
for making your team better.

"Teach them to be better than you. That may seem counterproductive. I have a
type A personality, and I have decent coding skills. I've been in your
situation a number of times. I also know there's these mythical expert
developers out there that I can't seem to find (or afford). So, what to do? A
few years ago I realized that if I continue down this path, I'll end up with
some serious health issues due to the stresses that come along with having a
reputation for being a really good developer. So, I decided that instead of
searching for developers better than me, I would teach developers I work with
how to BE better. It's taken a lot of patience. And it's taken me quite a bit
to LET GO of my way of doing things. I had to take my ego out of the picture.
(VERY hard to do.) Nowadays, I realize that developers don't have to BE better
than me. I simply have to ALLOW them to do what they do without being so
obsessive about it. Turns out, even junior developers really CAN do good work.
They just need a little guidance that only comes with experience, and then
they need me to get out of their way."

[https://news.ycombinator.com/item?id=8649415](https://news.ycombinator.com/item?id=8649415)

~~~
Terr_
I'm not sure I'd be comfortable calling myself "senior" in job titles, but I
often end up saying:

> I know this is a "do what I say not do what I do" situation, but please X
> because we've had problems with Y.

------
asadjb
I agree with the core premise of this post; you shouldn't put down ideas by
junior developers by just flatly saying no. But we can't just go around
letting junior developers do whatever they feel is a good idea because "it's a
learning opportunity".

I get that the most direct way of learning is to make mistakes and learn from
those. But there's an easier way too. Read books, talk to people, get the
benefit of others experience without needing to make those same mistakes
again.

We don't go about individually discovering why modular design is a good thing,
or why at certain scales microservices are a better option. We do the
research, talk to others, and figure out that the general consensus is a
reasonable one that we can use.

There are many learning opportunities even once you implement the currently
best known solution. You'll eventually grow beyond what the best solution can
achieve, and I feel it's a better use of our times to try to push the
boundaries of knowledge at the edge, rather than making junior developers
learn the same things over again. As they say, learn the rules before trying
to break them.

\--

I do agree that senior developers need to do a better job at communicating
with junior developers. I think that in the transition between junior and
senior developer, there comes a time when you just start assuming that
everyone has the same context and knowledge that you do.

When you say "it won't scale" to a junior developer, you might believe that
they understand all the subtle connotations that phrase holds. But from the
perspective of the junior developer, it feels like an arrogant know it all
trying to run from an argument.

I think we need to do a better job at explaining _why_ something is a bad idea
to junior developers. Learn to see things from their perspective, and
communicate in a way that relates to their experience rather than ours.

But that's just good advice for life, not just development.

~~~
jdmichal
I use a "touching a hot stove" analogy:

There's a hot stove in the room. Do you want every engineer to touch the hot
stove to find out it's hot? Or do you want to take one engineer who's well
equipped to find out how hot the stove it, find out it's hot, then notify
everyone that it's hot?

I don't usually use the analogy for this particular argument, but it works
here also.

~~~
aequitas
However on the other end of the spectrum you have The monkey experiment, where
you end up with 5 monkeys that don't climb the ladder for the banana reward,
but none of them knows why not to.

I sometimes still find it a challenge to walk the line between sticking to a
principle and letting it go. But it's my opinion you should always stay open
to let any of your principles be challenged (by someone else or yourself). And
it still surprises me how I can shatter some of my deep rooted principles
because of a new/different look on things.

~~~
cema
Document your decisions, explain assumptions, limitations, and reasoning. It
helps immensely.

~~~
aequitas
Indeed, I also started moving from documenting what code does to explain what
I intend the code to accomplish (because code already explains clearly find
what it does by itself). By communicating at this level the overarching idea
does not get lost and allows for much better refactoring or debugging.

------
partycoder
The problems here, to start with, are:

\- "senior" means a wide range of things to different people.

\- "engineer" means a wide range of things to different people.

Some people are senior because they have technical skills, some are good with
processes, some have years of experience, and others due to superficial traits
associated with dominance (e.g: posture, voice pitch/amplitude/speech rate,
verbosity, being good at interrupting others), some due to interviewing
skills... or anything to be honest.

This gives origin to a wide range of decision making processes:

\- from pragmatic to unpractical

\- from rational to dogmatic

\- from collaborative to competitive

\- from respectful to antagonistic

\- from constructive to unproductive

If your discussions look like the "Argument clinic" from Monty Python, you've
got a problem. If your discussions are toned down because noone wants to sound
negative, you've got a problem. If all discussions end up with someone pulling
rank, you've got a problem. Try to have: pragmatic, rational, collaborative,
respectful, constructive discussions. And focus on the problem at hand, not
the person.

------
aequitas
"Being a senior engineer means realising not everything should be done the way
you want it to be."

I think it's funny how these opinions can completely flip over or oscillate
over time. In this case:

As junior you known nothing so not everything can be done the way you want,
then later you think you know a lot more and everything should be done your
way, after that you really know a lot more and realise not everything should
be done the way you want it to be.

Same like Friday deployments. First time you always deploy on Friday until you
deploy that bug and you weekend gets destroyed. You never deploy on a Friday
again. Until you discover testing and CI which makes Friday deploys trivial
again. (maybe until the next time it breaks?).

~~~
dogruck
That’s a good observation. I’ve also worked at organizations where the policy
pendulum swings.

For example, “Gotta release code quickly” to “quick is good, but all code must
have unit tests and rigorous code reviews” to “gotta be quicker, can’t always
be holding things up because of a rejected code review!”

I’ve also worked places where that didn’t happen because management, and the
engineering culture, were strong.

------
sb8244
Language is basic stuff, but hard to do well all of the time. This is a great
reminder for the way our language and questions can affect the outcome of
work.

The only thing that I couldn't help thinking, at the end, is that the senior
engineer gives up potential conflict around the language (which it seems to be
known may be difficult to maintain) in order to empower the junior engineer to
own the decision. However, I get the feeling that this wouldn't be best for
the business/team in the real world. In the real world, the question might be
posed "What would the perl language give you that language X wouldn't, for
this problem?"

------
shados
The article is excellent, and the way it suggests to communicate is great. I'm
certainly taking notes. As a team lead myself, I've screwed up on this more
than my share of times. Within a team, these advises are gold.

At a higher level though, I can't help but feel our industry is taking so long
to mature because everyone has to keep making the same mistakes over and over
and we don't learn from history.

Conversations often go like:

Engineer A: "I'm going to do XYZ".

Engineer B: "Hmm, we've tried XYZ, it exploded in our face"

Engineer A: "I've had experience with XYZ on my side project/little startup,
it works fine!"

Engineer B: "Yeah, it works at first but eventually problems arise and it will
blow up"

Engineer A: "Whatever, I'm doing it anyway"

<6 months later>

Engineer A: "See, it worked fine!"

Engineer B points at the beggining of some problems

Engineer A: "That's normal!"

<6 months later>

Engineer B: "Welp, as expected, it all went to hell. Where's Engineer A?"

Engineer C: "Oh, Engineer A got bored and quit/joined another company. Looks
like you're inheriting it, Engineer A!"

Repeat...hundreds of times...for everything.

~~~
avleenvig
Thanks, glad you liked it :-)

There's definitely a strong bias in our industry towards "greenfield" things -
everyone wants to do the fun, exciting, initial work. But once the new shiny
coating has worn off there's a ton of really hard work to do with resilience,
robustness, scaling, etc. Too many people just give up at that point, get
bored, and do something else.

------
OliverJones
Senior engineers are, by definition, survivors in the engineering trade. We
weren't driven out to open pizza shops or become midlevel product managers.

Most of us senior engineers have made our share of mistakes. We've had people
help us understand and correct our mistakes. "rollback!"

The job of any engineer is to work ourselves out of every job, so we can do
other jobs.

Our job as senior engineers is this: give junior engineers the power to become
senior engineers. Help them use their fresh-out-of-school knowledge to solve
real problems in sustainable ways. When they make mistakes, don't punish them.
Instead help them correct the mistakes, learn from them, and move on. They
will have to live with the consequences of their decisions

Help them gain perspective on broad systems and industry issues. In this
article's example, that might be by asking the question "PERL, huh? Maybe you
should take a quick look at job openings for PERL folks. When your system
becomes totally mission critical you'll want to hire somebody to help you."
You could say the truth: "PERL sucks, I know because I hacked PERL for three
years when I was a wee little lad." But saying that doesn't help somebody
beccome a senior engineer.

This all is especially true when we have the privilege of following the rule,
"never hire anybody unless they're smarter than you."

~~~
nyc111
"Help them use their fresh-out-of-school knowledge to solve real problems in
sustainable ways."

I always wonder why waste the best and most creative years of young people at
school teaching them things that they will not use in real world work
environment. Is it not much better if the novice programmer enters the work
environment without going to school first and learns the job by doing?

I especially object to the academic way of teaching a subject which requires
the student to learn the whole field before issuing him a license to practice.
This is like teaching someone who wants to tend to his small garden the entire
science of botanics and require him to know all the plants in the world before
allowing to play in his backyard garden.

Sorry for off-topic comment.

------
ilaksh
My thought is that really good juniors need to be treated as less experienced
peers in most (but not all) interactions. A smart, hard working, capable
programmer is going to need to feel respected. So the number of times 'junior'
and 'senior' get thrown around here is problematic.

Which is not to say that there shouldn't be clarity in terms of who gets final
decision making or that there is no hierarchy at all. But in most discussions
you should treat them as a smart person who probably has good ideas that
should be respected. Otherwise why did you hire them? I'm not _quite_ getting
that tone from this article.

~~~
avleenvig
I completely agree, and in writing this post it was one of the pieces of
feedback that came up. Ultimately we decided to go ahead with the verbiage
because it would be the most easily understood, but the _message_ here is not
about junior vs senior or organisational hierarchies. It's about peers and
interactions between more and less experienced persons.

I interact with people daily who are far more "senior" to me on specific
topics, and I to them on other topics.

------
avleenvig
As the author of this blog post I'd just like to say: 1\. Thank you everyone
for the positive tone of comments 2\. Thank you for the feedback and
perspectives :-)

------
nullymcnull
There are some very good points here, but letting the junior go ahead and use
Perl (or any language / platform that the company doesn't generally use or
support, and that there's no overwhelming benefit to taking on for one small
improvement), just to avoid discouraging them and helping them grow?
Definitely not.

I do realize that part of becoming a senior engineer is being able to make and
learn from mistakes like this - that sometimes loose/absent leadership is the
crucible that makes them. But at this point the hypothetical senior is
allowing unnecessary complexity into things, it's verging on outright
dereliction of their bigger picture duty to keep things reasonably homogenous
and maintainable. Mentoring juniors into seniors is something that a good
senior engineer should spend quality time on, no doubt, but it's far from
their primary function - and you certainly don't let your system descend into
unmaintainable multiplatform anarchy for the sake of doing so in an optimally
non-discouraging way. There's still always going to be a lot of blocking of
dumb ideas - it comes with the territory, and not all ideas are salvageable -
it's harsh but sometimes you need to hear that to grow, too.

Not every junior is a senior waiting to blossom, either - some are just
solidly junior and not really equipped with the curiosity or drive to progress
no matter what you do. Yes, there's room for bias to seep in here, but still,
there's little sense in trying to make seniors out of devs who just aren't cut
out for it (some of whom are still solidly dependable pairs of hands for day
to day code slinging).

------
photonios
Excellent points. I'd like to think my job is making sure everyone around me
ends up better than me.

~~~
Consultant32452
I have landed on the phrases rising tide vs shooting star. Early in my career
I wanted to be the shooting star, the bestest most productive person there.
Now that I'm older I want to be a rising tide that raises all ships. Did you
experience a similar transition, or were you always a rising tide type?

~~~
photonios
Yeap. I was the most productive in the room and it was becoming a problem.
Others simply couldn't keep up and it was slowing us down on the long run
rather than making it go faster and better. I was disappointed with the
improvements others in my team were making and started wondering what I could
do to make that go better.

I realised that one of the freedoms I had early in the career was the freedom
to experiment and fail. This taught me a lot and turned me into the software
engineer I am today. I realised was robbing them of that valuable experience.
I am more ok now with letting them pick a sub-optimal solution, as long as it
doesn't directly affect the business.

I like the term. I am going note that down. Thanks!

~~~
Consultant32452
Apologies, this kind of became a novella.

>Yeap. I was the most productive in the room and it was becoming a problem.
Others simply couldn't keep up and it was slowing us down on the long run
rather than making it go faster and better.

It was a problem for me too, but in a different way. I feel like I was
resented by my teammates for being a shooting star. I was younger then so
there's a strong possibility I was hot-dogging it a bit unintentionally. I was
definitely getting first pick at all the coolest projects, which of course I
enjoyed.

I'm not entirely confident that more is being accomplished now that I'm a
rising tide. Statistically I think there's some evidence that isn't the case.
For example, there's Price's Law which states that half the productivity is
completed by the square root of the people in the domain. The following is
really rough math just to put some plausible numbers on it... So if there's 9
people on the team, I was one of the 3 people doing half the work, and the
other 6 did the other half of the work. That means I was individually
accomplishing 16.6% of the work, and the 6 were each accomplishing 8%. If by
being a rising tide my individual productivity is cut in half, then the other
6 people have to improve their individual productivity by nearly 3% of the
total work, or 35% over what they were doing before. I have no confidence that
the other people have improved their productivity by 35%. If I could reliably
improve worker productivity by 35%+ I'd be a lot wealthier. However, I do
believe people enjoy working with me more, and consequently I have a better
experience at work.

------
pugworthy
> Being a senior engineer means realizing not everything should be done the
> way you want it to be.

A real corollary is, you really don't know as much as you think you do
sometimes.

~~~
kelnos
I think the point (something I struggle with personally) is more that even if
you do happen to know the ideal way to do something, it doesn't need to be
done that way, and letting someone junior figure out how to do it their own
way can still be sufficient. That has the added bonus that the junior will
learn much better than if you were to dictate their path exactly.

Of course, sometimes letting a junior engineer do something their own way can
fail to be sufficient entirely; knowing your junior engineers and their
capabilities well enough to know how much rope to give them on a particular
task is yet another skill to be honed.

------
thisisit
I normally use the - Half way there approach, trying to explain in detail as
to why - realizing well that there are my biases at play but in the world of
agile and fast moving changes, it is difficult to justify time for experiment
and see what happens.

But then I look at author's claimed non-bias approach. The perl conversation
is still the "half way approach". If a particular language is not used
frequently it is easy to lose track of changes and new features/issues popping
in.

Then there are company coding standards. Sometimes I look at a project where
majority of the stuff is written in Java while a particular component is in
C++. A lot of time the answer is, it was "easy to do". Even with
documentation, it only leads to issues.

------
thinkersilver
This methodology is an effective way to leverage the developers in your team.
It does rely on a certain discipline that juniours often don't have to drive
and refine an exploratory solution into production code.

It requires curiosity, an openness to measuring and validating an idea and
then driving it home. This sounds a lot like what I'd want from a team lead;
but as someone pointed out some juniors aren't destined for leadership either.

I love the idea and have made it work, a lot less though than desirable.

------
luckydude
This article works in theory, not so much in practice. The theory is fine,
it's the reality of working in the real world where it is less fine. I think
the author needs to rethink his approach in the context of a limited budget.

If your goal is to grow your junior engineers at any cost, great article. If
your goal is to balance the benefit to the company/project with growing a
junior engineer, less great.

And perl? For production code? I love me some perl, I really do, and I've
written production code in perl (but it took 2 complete rewrites before I
figured out how to do maintainable code in perl). I would not let a junior
engineer anywhere near perl for production code.

~~~
tboyd47
It takes creativity to carve junior-level tasks out of a real backlog. But it
can be done. You just need to have buy-in from your manager. They hired the
junior not expecting them to be productive right away. What they usually don't
realize is that they need the seniors to spend time mentoring them in order
for them to ever be productive. If they can't allow time for that then it's
just not a good place for juniors.

~~~
avleenvig
Indeed. As your business grows (it _is_ growing, right - that's why you hired
more engineers?) you need to scale yourself. If you don't, eventually you'll
become the bottleneck.

Following this process has a definite cost up front. You have to give up doing
some work in order to help someone else grow and learn the system. But once
they do, your business now has an extra version of you. Not as experienced,
but hopefully still pretty good. Let that person handle more work, trust them,
and hire another person. Rinse and repeat.

The truth is that when you get more senior, you almost have to stop focusing
solely on knocking out code or fixing problems yourself, and commit to helping
others learn how to do it.

If you become the bottleneck, the business will start to work around you and
then you will become irrelevant.

------
quickthrower2
Nice this is just what I need, as I am being asked to take on more senior
responsibility

~~~
avleenvig
You should definitely make sure this - the teaching and growing of other
engineers - is part of your responsibility. It's the only way to scale
yourself up.

------
v4tab
In one of the YC videos someone says that in Silicon Valley when you suggest
an idea people think about what would happen if it did work rather than all
the possible failure modes. From that perspective, the article starts with
failure modes and ends up with success modes. YC startups tend to be young
people, I suspect because they don't have "experience." While the
junior/senior dichotomy is one aspect, the article is even more interesting
when framed in the context of success-mode thinking versus failure-mode
thinking and how to take effective action.

------
bpicolo
This feels like fundamentally the same problem as the whole big company
inertia/innovator's dilemma situation. There's value in known-entities, but
also a lot of value in trying to reinvent the wheel now and again.

Another problem is it doesn't leave as much room for people to learn from
mistakes as companies grow larger and larger. You need wiggle room to get
dirty for that to happen.

------
psyklic
In my experience, typically the junior's suggestion can possibly be done.
However it often would be complicated to implement well, and I would be
concerned how long it would take the junior to complete (if they would
complete it satisfactorily at all). So, I agree with the suggestions that it
is often more productive if a senior engineer suggests appropriate work.

~~~
psyklic
Of course, I'm sure this highly depends on the individual person, the type of
work, and the project itself.

------
z3t4
With the landscape constantly changing you could argue if we take too much
weight on senior perception. For example: "Those 10GB of data would take up
too much space, it's BIG DATA, we can't afford that!" ... Junior: We could use
my laptop, it has 2 TB.

~~~
PretzelPirate
I don't think any competent senior engineer would say that backups are too
expensive without looking at the actual cost first.

Your example doesn't work though - using someone's laptop is likely not
secure, reliable, and definitely not appropriate for any compliant data. It
really doesn't meet the actual requirements of a true backup.

My backups sit on disks that supports disaster recovery, are proven to be
reliable, and meet all compliance requirements for the data we store.

------
amq
Next level: look into ways of doing hot backups.

