
Senior Engineers Reduce Risk - arohner
https://medium.com/@ztellman/senior-engineers-reduce-risk-5ab2adc13c97#.1msimf79r
======
StevePerkins
My gripe with the "Senior Engineer" title is that I've NEVER met anyone with
5+ years experience who didn't view themselves as "senior". Usually 3+ years.

In a market where there are more job openings than employable candidates, and
competition for talent leads to rampant ego-stroking and title-inflation...
the term "senior" has become just another word for "competent". Someone who
can work independently without hand-holding.

So how do we verbally distinguish _that_ from, " _No, I really DO mean
'senior'_"? Most people get 40+ working years in a career. How do you
encourage humility and self-awareness, so that people don't honestly believe
they've reached the 90th percentile after the only first 10% of that journey?

~~~
allengeorge
Allow me to offer myself as a counterpoint ;) I've worked for well over 3
years (8ish now?) and there's a lot I've yet to learn about when to take one
design approach vs. another, how to identify risks early, etc. etc.

And, for what it's worth, I agree: one should not be considered "senior" after
3, or 5 years. Actually, tenure matters less than perspective and problem-
solving approach.

~~~
alexbanks
Some (me) would argue that tenure should not be considered when deciding a
developer's skill.

~~~
StevePerkins
I think that the number of different companies you've worked for (and the
diversity in how they operate) is more important than the raw number of years
you've worked. Also, how your role has grown or varied from job to job.

Rookies worry too much about "job hopping". I can't count the number of people
I've interviewed who had "10 years experience"... but really they just had
"the same year 10 times".

~~~
alexbanks
More jobs = more diversity = more experience, no? Both models are flawed I
think, as 10 jobs in 10 years brings a ton of understanding of the overarching
principles of working as a dev, but has a total lack of long-term team
success.

2 jobs in 10 years brings an understanding of that long-term team success but
a relatively small window into dev jobs as a whole.

------
swalsh
Here's my world view.

A junior engineer is proud he got his code to work, an experienced engineer is
proud of the code he wrote to get the feature to work, and a senior engineer
is proud of the code he didn't have to write to get it to work.

~~~
sreque
I've seen some senior engineers take this too far. It's as if they are burnt
out from all the code they shipped into production that broke things. They
tend to favor solving problems operationally rather than through correct code.
They also favor dumping problems onto third party libraries to the point of
causing more problems than they would by allowing a more specific
implementation.

Some fallacies I've seen from senior engineers:

"Let's ship the simpler solution even though it has clear problems. We'll hide
it behind a feature flag and deploy it to a few machines first to make sure
nothing disastrous happens."

"Let's coerce a third party library to do the thing we want even though it
wasn't really designed to do what we want. By using the third party library we
don't have to take ownership of what we are writing! So much less code to
maintain!"

The second bullet in particular can be ironic because I've seen senior-
engineer-written code break production because it tried to rely on a third
party library to do something without doing any unit, functional, or
performance testing to ensure it was doing the right thing and doing it fast
enough.

After having been in the software engineer for close to a decade, I see an
increasingly worrying trend where companies just assume their engineers are
incompetent and favor delegation to third party libraries, external services,
and devops/metrics/monitoring to solve all problems. As someone who considers
himself a competent engineer, I find the trend saddening because I'm not
trusted to write correct code either.

~~~
angryasian
To answer your points from the perspective of a senior.

1\. "Let's ship the simpler solution even though it has clear problems." You
wouldn't believe how many times I've had to try to convince younger engineers
that we don't need to over optimize and can't initially create the perfect
solution because 9 times out of 10, the feature will change significantly, or
get abandoned completely. Shipping the simpler solution is a way to test the
waters and make sure you're building what is expected or wanted.

2\. "Let's coerce a third party library to do the thing we want even though it
wasn't really designed" Same point as #1. Whats the easiest way to get
something out so that we can test and measure assumptions.

Overall if you've read the article its about reducing risk. I don't want my
team to spend 6 months on a feature to find out the feature is something that
business or users want, nor do I want complete crap. The idea is where is the
middle ground. Believe me I've dealt with many younger engineers like yourself
that believe we should always roll our own solutions when its just not
feasible. This is a clear distinction between a senior engineer and younger
ones.

~~~
sreque
"Whats the easiest way to get something out so that we can test and measure
assumptions."

I was focusing less in my comment on time-to-market and more on risk aversion
to code ownership. But, to address your concern, doing things the right way up
front can often cost less time and money than doing it the wrong way and
working around the brokenness. This can be truth for both initial time to
market as well as the more obvious long-term maintenance costs.

At the end of the day it's a calculated judgement call, and I've seen senior
engineers get it wrong as well as juniors.

------
ascotan
>>>The interviewers know the real problems facing the company, but the polite
fiction is that they’re only temporary, and soon everyone will be able to
focus entirely on the algorithms, which are what really matter. Since most
companies tell the same story, candidates have to read between the lines to
see if there’s a good fit.

I've walked away from a few places because of the interview process. It's like
the old song the gambler by Kenny Rodgers. You need to know when to walk away
and know when to run.

If I get put in a room with a puzzle sheet and they lock the door for 20
minutes, I'm out. Not because I can't solve the problems, but because any
company that thinks my ONLY value is in solving puzzle questions has no idea
how to hire people and have devaluated the role of the senior SE's at that
company. You can tell a lot about a company by the way in which they conduct
the interview process.

~~~
xyience
I just ask the interviewers how much freedom they have in the interviewing
process (usually it's pretty clear) and whether they would do something
different or not if they could. This kind of follows naturally from questions
about non-dev responsibilities that devs have. A lot of fellow engineers at my
current company believe their little quizzes actually have a lot of signal
value when they really don't, I avoid working with them since they tend to
have other weird beliefs. If my interviewer is giving me a whiteboard problem
somewhat reluctantly because it's what he's supposed to do rather than what
he'd like to do, he's probably OK to work with. The followup question is then
whether I'd be working with him or not, since so many of these companies just
throw you in an interview loop with whoever is available that day...

------
beat
I'm reminded of an experience many years ago, when talking to a couple of
other senior engineers about a talented but hotheaded young manager who
couldn't understand why we were all so cautious about new ideas. We decided
that what he really needed was a death march - the experience of being stuck
on a project that is inevitably doomed, and having to push on through to the
bitter end anyway. That'd teach him!

~~~
nsxwolf
... and you executed on this death march idea? Did he learn anything, and was
it worth the toll you put on yourselves?

~~~
vinceguidry
Senior engineers with the foresight and savviness to execute on such a plan
are also going to be savvy enough to not allow it to exact a toll on
themselves. Especially with junior managers.

Pressure will be created and focused onto the non-technical problem creator
and reliefs for that pressure will be similarly engineered in precisely the
same manner. All the while, the engineers will keep a smug, knowing look on
their faces while the manager flounders around a technical terrain that they
can't begin to fathom and that has suddenly become utterly hostile.

The manager will eventually 'get it', realizing that he has to work with the
engineering team and not against them. Then all problems magically evaporate
and a new understanding is reached.

~~~
nsxwolf
Frankly, this sounds absolutely insane. How is a death march that doesn't
exact a toll a death march? Does anyone work a 40 hour a week death march?

Why wouldn't you just look for a new job? Why waste your own time on a doomed
project?

I certainly hope all the engineers are in on the joke, because if I found out
some others on my team conspired to create this situation without letting me
decide to be involved or not I would be super pissed.

~~~
vinceguidry
Nobody non-technical knows what an engineer is really doing while he is
sitting at his desk. He might be at his desk 50+ hours a week, earning time-
and-a-half on top of his already lucrative salary, but he won't actually be
contributing anything that the company actually needs. The senior engineers
certainly won't be working more than 40 hours a week. That's for the younger
fellas.

If you got handed a bunch of bullshit tasks by your senior engineer with or
without a generous amount of winking and subtle sarcasm, you'd pick up on it
pretty quick. You'd have all sorts of questions about why X needs to be done
and would be getting no straight answers. Eventually you'd either get the
picture or someone will take you aside and delicately let you in on it. Think
that scene in Silicon Valley where Big Head is having his new "role" described
to him, only done by the engineers rather than an HR manager.

If it looks like you need a lesson in savviness yourself, they won't let you
in on it and let you flounder around just like the manager.

------
arohner
Great article. I really appreciate that the OP describes a more closed-form
solution to what makes a senior engineer, rather than platitudes like "learn 5
languages".

One nit I'd pick with it though is that many large and bureaucratic companies
won't appreciate an engineer who decides it on them to fix hiring, culture,
product marketing fit and marketing. If you find yourself in this position,
it's time to move on to somewhere else that will. Typically, those companies
are startups.

~~~
vonmoltke
The great frustration is that the longer you spend tilting at those windmills
at large companies, the less likely you are to get a startup to actually hire
you, since you are too "corporate" or "enterprisey".

~~~
crpatino
Don't VCs require more "enterprisey" people at later stages, when product
discovery is done and operations/scaling up takes precedence?

~~~
tedmiston
The types of problems experienced in mid to late stage are definitely more
relevant to someone with experience at ops and scale. Late stage startups or
enterprise (the line blurs) are popular places to pick such talent, and for
these needs specifically, Netflix is one popular source.

------
ChuckMcM
This captures the role quite well.

------
enlightenedfool
Please share this with your interviewers. It's stupid to reject senior
engineers just because they didn't implement algorithm optimization towards
the end of an interview...ignoring everything else they are capable of.

~~~
jiaweihli
Another way to look at this is that interviews are like tests where you
already know what the topics are. So a company with a 'standard interview
process' is testing your ability to study for and do well on a test. That's a
crude measure of how well you can pick up new things and apply them, within
certain bounds.

A large majority of these interviews are also testing for non-technical skills
too - like communication, patience, humility, and thought process.

Don't stress out too much about interviews, they're something like 30%
technical, 30% non-technical, and 40% luck.

~~~
collyw
Yes and its bollocks. I have 13 years experience on my CV. The only time I
have ever needed to implement a sorting algorithm was for university exams and
interviews. What's the point in studying for something irrelevant to the job?
I have better things to do with my time.

------
jrochkind1
This is very incisive, and matches my experience.

------
alexandercrohde
I find this article fundamentally confused. The author spends a lot of time
talking about what he invisions a senior engineer ought to be in his opinion
(which involves all kinds of ownership). But senior engineer is just a title,
it can't be used wrongly, because it's inherently a meaningless cat-and-mouse
money game between employees and companies. It's politics; it's a name.

Much in the same way that somebody founding a startup can be "engineer" or
"CTO" or "Software king Ninja Level 7 dan grandmaster." Titles will _never be
objectively consistent_ , this is why the whole industry is now discussing
consistent interviews instead hiring based on titles on resumes.

