
What Makes a Great Software Engineer? [pdf] - vshan
https://faculty.washington.edu/ajko/papers/Li2015GreatEngineers.pdf
======
vmarsy
I don't get the "9 to 5 wouldn't make you a great engineer" about not being
passionate, some people are passionate but have other life obligations like
kids or other activities.

Being personable: "Can I have a beer with this guy?" is the worse in my
opinion. I care about your professional skills and if you're communicating
well, but you definitely don't have to be a beer buddy, we might have 15 years
difference, a very different background and share very few topics in common
over a beer (assuming you even drink beer) but you could still be a great
engineer to work with.

Also you don't have to be a guy! The authors recognize that they only
interview 5% women in the end...

So overall some good advice, but it has a huge sampling bias. therefore the
definition of a "great software engineer" is only valid in certain
circumstances. For instance the authors recognize creativity is important, but
one could argue some of the most creative engineers that can be found are the
people who do another, very creative activity on the side (arts etc). These
people would tend to be "9 to 5" because their "6 to 8" are already booked, so
even if they appear less "passionate" they can be a huge asset to the team.

~~~
jasonjei
> I don't get the "9 to 5 wouldn't make you a great engineer" about not being
> passionate, some people are passionate but have other life obligations like
> kids or other activities.

I think what the engineer is trying to convey is that a great software
engineer thinks about code beyond just the job. I don't think the engineer
literally means being a workaholic or the literal 9am-5pm shift, but the
engineer has pet projects of his or her own that aren't necessarily related to
work, as well as thinks of programming beyond just a paycheck as a personal
interest (just as a photographer or any other craftsman would).

I've hired many programmers. The most disappointing ones were ones that only
did exactly what their work told them to do. They would never read technical
stuff or things like Hacker News on their days off.

The best programmers were the ones that built pet projects for their own
needs. I remember one guy would write a script to download new wallpapers for
his laptop to cycle through the hours of the day. If I recall correctly, Gmail
was an engineer's pet project (when 20% time existed). Some contribute to
Stack Overflow; others to open-source and to blog posts.

It's a lot like being a good restaurant cook or musician. You enjoy cooking,
not just for the pay, but for how the craft empowers you. A good cook will
think about what sides will pair with that steak, while an average cook will
probably robotically sling together a dish. A good engineer will show passion.

~~~
avip
I hear this sentiment a lot. I don't think it has much merit if any. Were
musicians practicing scales daily 9-5 (+ occasional overtime when a customer
urgently needs a modus they're not familiar with) - would you expect them to
"enjoy" another 3h of fingering, possibly on some other instrument, in their
spare time - because it "empowers" them and it's "a passion"?

~~~
stfwn
I have been in music for some time, and this is almost exactly what great
musicians do. There is definitely a time for activities that are ‘neccessary’
or ‘good practice’ to spend time on, and then there is a large amount of time
they almost subconsciously spend in their field: they just enjoy having a beer
with friends (at a jam session), having a chat (about music), hanging back
(with their instrument), waste time on YouTube (watching poor quality phone
recordings of musicians they look up to). Some don't think about anything
else. Some have other interests. But I cannot think of one great musician that
doesn't touch music when they're ‘off from work’.

~~~
Retric
There is a difference between coding in your off time and reading Hacker News.
What you're describing is someone who is relaxing not working. Aka great don't
work long days mastering an instrument, just put in their 9-5 and casually
have fun. So sure, if someone does not keep abreast of computing in their free
time that's not a great sign, but deliberate practice works best a few hours a
day not 10+.

PS: What side projects do provide is a way to have more experience than your
number of years in the field would suggest. But, that has heavy diminishing
returns.

------
virgilp
"Great" is in the eye of the beholder - to a large extent.

An engineer that is great in a startup ("hacker", "moves fast and breaks
things") may be pretty bad in a well-established product that just needs
maintenance. And the opposite is also true - a very thoughtful engineer that
takes time to create thoughtful, simple & extensible designs may just move too
slow when the idea was bad to begin with, and just needed to be invalidated.
Also - who is "great", a generalist or a specialist? Depends a lot on what you
need...

It is true that some engineers are simply better than others (I'll take Peter
Norvig any day over someone who fails at fizzbuzz, regardless of the
context/problem that needs being solved) - but it is also equally true that
people need the right context to really shine. E.g. I bet Peter Norvig would't
have done his best work working for, say, Accenture.

------
andrewstuart
I wrote a post a few years ago "50 characteristics of a great software
developer"
[http://www.supercoders.com.au/blog/50characteristicsofagreat...](http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml)

Having said that, and having written it, I still believe the absolute core
issue in all technical recruiting is that no-one knows _exactly_ what a great
software developer is.

In fact, it is entirely subjective, and simply a matter of opinion.

I put it to you that most recruiting processes aren't worth a bent cent
because the initial question cannot be adequately answered "OK, you're looking
for 'the best' software developers..... PRECISELY what is that" And if an
interviewer can't define precisely what they are looking for then how the heck
do they know they found it with sufficient confidence to say "here is the
right person for the job".

Most recruiting is simply Voodoo Recruiting, a collection of myths, legends,
whispers, misplaced beliefs and pure nonsense. Does this person get the job or
not? Shake the bones, look at the tealeaves, throw a rabbit over your shoulder
and choose the person who gave the interviewer the best feeling.

------
lordnacho
Seems to boil down to the same old tropes that apply to every kind of work,
and every kind of person. A good {worker} works hard, works well in a team, is
self-reliant(!) blah blah. A good person is honest, forthright, etc.

Outside of very specific fields I haven't seen anyone come up with specific
qualities that identify great workers. And the useful attributes will be
specific to a field. For height for basketball players, chances created for
soccer players, on-base percentage for baseball, etc.

We don't like to say it, but maybe there's something similar in Software
Engineering, like "Can code FizzBuzz in under 5 minutes". At the same time I
recognise that coding quizzes are not the latest word on what makes a guy good
at coding.

~~~
luckydata
It is definitely "ability to stay on task".

The difference between a great engineer and a mediocre one is the latter will
just get distracted, stop working the problem and decide to go for good
enough.

The great ones will work the problem, try multiple angles until something
doesn't just work but offers the right balance of simplicity, elegance, future
proofing and does the job well. You can't get there if every 5 minutes you
take a facebook break, or can't grind through technical documentation and make
experiments.

~~~
newfoundglory
Huh, I would probably include "the ability to stop at good enough" in my
criteria for greatness. I've worked with people who couldn't resist looking
for a better solution instead of checking in the one they had - even for time
critical bug fixes.

------
nikkwong
I'm surprised to not hear an engineer's memory as an important correlator to
skill. I find that working memory especially (or the lack thereof) really can
hinder my performance when dealing with a complex problem. Sometimes I think
it is THE defining factor!

~~~
barrkel
Notetaking makes working memory much less of a issue. I recommend you find a
way that works for you, if you're interested in career longevity as an
engineer. Personally I alternate between todo lists for completion and
coverage, and dialectics of theory and test for design and troubleshooting.

~~~
nikkwong
Yeah, I've never really understood the note taking thing. I'll be working on
simple algorithm problems that require me to hold 3-4 elements in my mind and
constantly have to mentally reference them over and over. "what was the value
of x again?" — which distracts from solving the actual problem! Maybe the
experience that others have is different.

~~~
bordercases
One can use notetaking as extended working memory by visually cross-
referencing facts back and forth from the same page. More like a logbook.

------
robocat
This article seems to limit itself to the "enterprise" definition of a great
software engineer.

The greatest software engineers in small businesses (or personal projects)
don't do much development work. Instead they are working as true engineers:
making good compromises and solving problems outside of the software which
usually leads them into roles that don't have "software" or "engineer" in the
title.

~~~
snarf21
So true. It is about solving problems with software, adding value to the
project and just generally giving a crap about the work they do. The last is
one of the hardest as so many people are what I refer to as "hack 'n slash"
devs, with an attitude of "I just did what I was told....".

------
yeukhon
Here is why working on your programming pet projects shouldn't become a
metric.

The Japanese bullet train was redesigned by observing how nature works:
[https://www.vox.com/videos/2017/11/9/16628106/biomimicry-
des...](https://www.vox.com/videos/2017/11/9/16628106/biomimicry-design-
nature)

"A moment of inspiration from engineer and birdwatcher Eiji Nakatsu changed
all that."

Nakatsu did not become a birdwatcher to become a great engineer. So if you
want to become a great engineer you follow what you want to do with your free
time.

Also, I think people put too much emphasis on the degree of technicality over
humanism. A unethical technical genius is not a great software engineer
because there is no art in the engineering work. Great architects, chefs, and
musicians view their work as arts with thoughts.

~~~
bordercases
I can see both of these statements being misinterpreted, and in opposite
directions, so I will offer my commentary.

(1) Metrics. Metrics tend to destroy the sort of motivation that allows a
"task to be done for its own sake", where you are capable of immersing
yourself fully in the details of a situation without excluding any "secondary"
information (with respect to the metric or super-goal). Mastery of a task
comes in part from being familiar with the fullest extent of phenomena within
a domain. Pleasure proxies mastery by creating immersion, and is common for a
hobby.

A master physicist knows all of physics. A civil engineer knows enough to
build bridges. Only one of these people I would trust to make be able to
create a new method of building bridges that wasn't incremental, or was based
on a novel theoretical insight.

[building bridges might not be the best example because it's an older domain
with a lot of time to be refined]

(2) I don't see technicality as being the culprit so much as an overfocus on
technology. The "art" comes from either the amount of /craft/ that is put into
the use of the technology or the amount of /humanity/, that is, consideration
and care for how the users will perceive and receive the technology in an
interpersonal manner. You mention three domains where aesthetics count but I
don't think a focus on the study of aesthetics is necessary for us to apply
the concept of art. These things can be done on engineering's terms.

------
jorgec
A good engineer solves problems in the most feasible and working way possible.
If its fast, cheap and usable then its fine. A good software engineer solves
problems by generating software. Its amazing the amount of self called
software engineers that are unable to design from start to end a simple
software. So, a good software engineer is mainly a PROGRAMMER.

------
erickj
Well obviously compiling a 10 page PDF, replete with references to 37 other
sources, in order to establish the core 53 traits to identify the next great
SWE is the simplest way to identify great engineers.

Just hand this doc over the HR and ask all hiring managers to memorize it.

------
tkyjonathan
I'm gonna go on a limb here, but I would say a great software engineer is
someone that can block out email, slack, meetings, the huge noise of open
offices and get some 'deep' work done.

~~~
surrey-fringe
I'm offended!

------
chrisweekly
People skills. Empathy is hugely underrated and profoundly important. Whoever
said "software is meant for other people to read, and only incidentally to be
executed by machines" was on to something. All meaningful projects require
cooperation and collaboration with other people. Most of the time, a solid
coder with exceptional EQ will have more impact and effectiveness than an
exceptional coder with indifferent (let alone subpar) people skills.

~~~
jorgec
In small companies, a software engineer is a social job, it requires to talks
with lot of people, specially with the customer (may be not all customers) but
also, with others colleagues, with the people of infrastructure, sometime even
with the people of finances (such as asking for a new server), with marketing
or sales (if any), with design and so on.

In a big business, a software engineer is only a cogs that follows specific
orders. I remember a blog of a former engineer of Microsoft that talked about
it, he said that, in the past, Microsoft was direct, and having a technical
meeting with Bill Gates was something usual. However, the company grow and
those perks are long gone, now MS has a lot of bureaucracy and level and sub
levels of complexity (so many executives and managers).

------
RandomInteger4
The ability to take a diverse sample from their interviewee pool and not just
take the top 10 perfect looking resumes from recruiters for people they choose
to spend time interviewing.

So many diamond-in-the-rough developers out there that would make good team
members, but simply lack prestigious resumes or failed to put skill points in
"Job Search" or attribute points in Charisma.

------
atmosx
Homer doesn't spent time describing Helen in the Iliad. He knew one thing or
two about describing an _ideal_ I guess. Of course _beauty_ is orders of
magnitude harder to define. The baseline principle is the same though: The
moment you restrain what a good engineer _is /looks like_ your argument starts
loosing ground.

------
Manglano
This study seems to be asking, "What makes a great Microsoft software
engineer," given their sample cohort.

~~~
miranda_rights
Agreed. The paper treated having a Microsoft-only sample as being good since
it's a "large sample size", but the skill set of an engineer can be perceived
as good or bad at different sizes of companies, and not addressing that seems
like a huge oversight.

------
paulus_magnus2
Articles like this one never look from the side of the engineer and / or never
consider his opportunity cost.

Why would anyone work for you on an engineer salary if they are "great" and
have all the CEO skills. They shouldn't.

Selecting for passion is selecting for people, usually young who have no life
outside work, don't know their real market value and have easy to abuse
personality, will tolerate agile micromanagement etc etc. Women usually have
more social skills, enough to know not to become software engineers in bigco.

------
darepublic
At the end of the day this seems to me to be still anecdotal and not very
testable. Would it be possible, given the code history of n number of
developers + quality of the output code, to create a predictive model of a
software engineer's 'greatness'? Seems daunting and fraught with potential
problems but of a lot more value than just the typical platitudes; 'honesty,
creativity, passion' (take three virtues, earthporn background etc)

------
msmith10101
youth, gullibility, and the desire to please

------
vectorEQ
if you enjoy what you can do, only then you can master it. that would of been
much simpler explenation ;D.... goes for all things too! And to be honest, 9
to 5 would make you a nice engineer. a lot of people like code, all day and
night, but really, 8 hours of productive learning and coding each day is
plenty to become very good at it...

I always reccomend anyone to learn whatever is below their current interest in
the 'stack'. for example if you like to learn java code, learn what assembly
code and perhaps even C code is, learn to implement oop systems in C or
assembly and you will have a much finer understanding of why certain decisions
are made in your platform, and what motivates these decisions oposed to
others. for a web developer, learning what your browser is doing is very
important, and to understand why certain things work that way in the end, you
might want to learn about cpus, network hardware, assembly code and all that
jazz. dig deeper and deeper for greater understanding. it might seem like a
lot of work, but if you enjoy what you do, it's never to much and never to
deep ;D

------
w_t_payne
How can you even ask this question? Different teams have such different
dynamics, such different ways of working: different tools; different
practices: I would be exceedingly surprised to find any commonality
whatsoever.

The discipline of software engineering is no undifferentiated mass: but a
cultural kaleidoscope of different textures and colors; and a person who
excels in one environment can easily tank in another.

For safety critical embedded code: a meticulous personality is essential; only
someone who is a stickler for rules and processes will survive, let alone
thrive. In a fast paced and creative environment, this person would be
absolutely terrible!

The size of the organization is also a critical in determining who thrives and
who does not. In a small team, being an independent self-starter and problem-
solver is critical; whereas in a large team, that sort of independence will
quickly get you into real trouble.

Different organizations have different values and assign different priorities
to the various qualities and attributes of the product and the people who
design it.

My advice: be as humble and as flexible as possible; do your best to fit into
your team and your organization; but do not be afraid to recognize when you
are bending yourself out of your comfort zone: Be prepared to move around a
few times to find the organization and the team that fits you, too. There is
no shame in this, and you will be happier in the long run.

------
purplezooey
Sorry folks, it's pretty much like high school out there. It doesn't matter
what or who you know, it's the kind of person you are.

------
ndh2
I believe this should have (2015) in the title.

------
bjourne
Ny mom did!

------
stratigos
I stopped reading at "59 engineers...at microsoft"

------
austincheney
You make a great software engineer by practicing solving hard problems. There
isn't any secret formula or mystique. It is thousands of hours spent solving
problems of ever greater difficulty.

If you confine your practice to the 9 to 5 job then you are investing fewer
hours than somebody who writes open source at night, and will likely be a
weaker programmer. If you aren't independently finding new problems to solve
then you will be a weaker programmer than somebody who is constantly stepping
up their game. If you lack confidence and need frameworks, abstractions, and
other bullshit to write a couple lines of code you will be a weaker
programmer.

Simple. No magic.

~~~
yeukhon
> If you lack confidence and need frameworks, abstractions, and other bullshit
> to write a couple lines of code you will be a weaker programmer

So you like to reinvent everything? Do you reinvent HTML & CSS because they
are FRAMEWORKS, one of the foundational frameworks of today's web.

If your job only ask you to fix a bug, there here is how to make yourself
valuable AND technically challenging:

* go through the bugs and analyze if you can extract any correlations

* propose better process with other fellow engineers and product owners

* implement changes

For example, someone might be duplicating some code to write tests, how about
you write a test harness or adopt some open-source harness? How about work
with your fellow engineers to begin start collecting some metrics.

Otherwise, time to look for a new opportunity. The absolute worst kind of
programmers are the ones who don't don't take care of their health.

~~~
austincheney
Perhaps if you wrote software in addition to doing that which is strictly
assigned to you your question would answer itself. This isn't rocket science.

~~~
yeukhon
But there is creativity. You don't have to go an extra mile though, but you
can. My response is to this:

> If you aren't independently finding new problems to solve then you will be a
> weaker programmer than somebody who is constantly stepping up their game.

