
What Makes a Great Software Engineer? Just My Thoughts - elliotchance
http://elliot.land/what-makes-a-great-software-engineer
======
hliyan
Fewer lines of code don't always mean simpler code. Sometimes it means
cleverer code (read: harder to understand and maintain). Three quotes I
frequently repeat in this context:

1\. Duplication is better than the wrong abstraction

2\. Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.

3\. Code must be written for people to read, and only incidentally for
machines to execute

~~~
elliotchance
One of my biggest pet peeves is code duplication from lazy copy/pasting. I
find it's a good exercise for myself to sometimes pretend like the copy/paste
key are not available to me.

I had to think about the first one for a moment, but I do agree. It's better
to abstract later with greater knowledge than the much more difficult task of
trying to debug or fix it later.

It's an outstanding list and great rules to work by!

~~~
neurostimulant
> I find it's a good exercise for myself to sometimes pretend like the
> copy/paste key are not available to me.

This is a great idea! I'll try to remember this whenever I have the urge to
lazily duplicate some code (which is quite often now that I think about it).

------
andrewstuart
I wrote on characteristics of a great software developer a while back.

[http://www.supercoders.com.au/blog/50characteristicsofagreat...](http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml)

The problem is that people try to recruit for these things.

When recruiting, follows Joel's advice - smart and gets stuff done.

~~~
bastijn
Probably the first time a see a list of 50 points in which I wouldn't object
to any of them. Impressive.

~~~
lopatin
How did you finish the list? I'm still processing the last two items.

------
segmondy
What do you most developers hate? Legacy systems!

Why? so difficult to change, poor documentation, no tests, etc.

A great software engineer, goes for simplicity but not in terms of laziness.

1\. They keep the system simple enough and decoupled in the right way so that
it's easy to change!

2\. They have tests, not just unit tests, unit, functional, integration.

3\. They document everything, code docs, design docs, design decisions docs,
data structures docs, how to build, how to debug, how to maintain and change,
etc

4\. They do the really difficult stuff, they don't write the software for
themselves, the develop for humans, customers. It's not about what you like,
it's about what your customers like. This means having meeting and talking to
others, getting feedbacks.

5\. They keep learning, but they don't jump and adopt every fancy new
technology, they stick to well proven stacks, so they tend to be boring.

------
kator
I've heard people say laziness is important. However that is a misnomer, the
reality is the best inventors and engineers are sort of long-term lazy. They
will spend 40 hours building something to automate a thing you can do in 15
minutes. But, they know that they or others will push that button so many
times the 40 hours will come back quickly over time.

An example of this is a strong senior engineer might take a lot of time laying
the foundations of a project, the scaffolding needed to really make coding a
breeze and enjoyable in the future. This is because they're lazy, they want
the future to be easier so they invest today to make the future just a little
bit easier.

~~~
manaskarekar
Related XKCDs:

[https://xkcd.com/1205/](https://xkcd.com/1205/)

[https://xkcd.com/1319/](https://xkcd.com/1319/)

[https://xkcd.com/974/](https://xkcd.com/974/)

~~~
marcosdumay
The mouseover text of that last one is very relevant to the discussion.

~~~
elliotchance
Yep, here it is for everyone that doesn't want to waste a browser tab:

"I find that when someone's taking time to do something right in the present,
they're a perfectionist with no ability to prioritize, whereas when someone
took time to do something right in the past, they're a master artisan of great
foresight."

------
highCs
Good post. I think too that reducing code is key. Here is how I like to show
it.

Let's see what impact "size of code" has on "time it takes to add a feature".
Just consider a graph where the X axis is "size of code" and the Y axis is
"time it takes to add a feature". Obviously, the function is increasing, and
probably faster than linearly.

Let's see what impact "size of code" has on "number of bugs". Same thing.

Let's see what impact "size of code" has on "time it takes to find a bug".
Same thing.

Let's see what impact "size of code" has on "time it takes to resolve a bug".
Same thing.

Let's see what impact "size of code" has on "time it takes to refactor a piece
of code". Same thing.

Let's see what impact "size of code" has on "time it takes to a newcomer to be
productive on that codebase". Same thing.

And on and on and on.

There is two canonical points on those functions. The first canonical point is
when the codebase is too big for the value it brings. When you are here, you
are in deep trouble. Basically, the cost of doing anything in that codebase is
too high in comparison of the value it brings. A sign you are here is when you
spend more time in meetings discussing what to do, than time coding.

The second canonical point is when the codebase is notably small for the value
it brings. When you are here, the project looks like magical. The programmers
look like 10x programmers. Indeed, doing anything on the codebase costs
surprisingly little in comparison of the value it brings. A sign you are here
is when you are not asked for estimations.

~~~
elliotchance
You should totally turn this into a xkcd-like comic ;)

------
seanwilson
Great list. One I would add would be understanding what the client's problem
and building an appropriate solution. Too many times I've seen developers just
dive in coding up the solution the client suggested without trying to
understand the problem the client is trying to solve. For example, by adapting
the problem to using an existing CMS or SAAS you can avoid a huge amount of
custom coding.

A good developer would be able to write simple code for a given solution but a
better developer would suggest a simpler solution leading to even simpler
code.

~~~
Joeri
This is exactly the thing that makes a person a "10x" developer. Being able to
write lots of reliable code in a short amount of time is a good trait, but
knowing when not to write code is equally important.

------
progman
> 1\. Simplicity Reduces Code

I always follow the KISS principle, if possible. It makes maintainability so
much easier, not only in Software but also in Hardware. Every additional layer
of complexity adds to the probability of failure.

------
makecheck
There should not be long strings of commits that focus on features. Continuous
development means continuously looking after developers, too: intersperse
commits that remove code, increase documentation, update versions of
dependencies, fix ancient bugs or whatever else eases maintenance.

Test suites should not just be thrown together, where every test is a "diff"
of a giant log file! You do NOT want to be constantly fixing “tests” that
“fail” due to trivial differences. Ensure that your code can _completely_
expose all _relevant_ state for one feature so that you can write precise
checks and ignore any other output.

There should be no compile-time options (like #ifdef) that are not
automatically built before every commit. Developers change things, and they
have to know _exactly_ what can break by doing so (especially with languages
like C++, where a tiny change can cause true chaos). Put another way, don’t
set yourself up to discover problems weeks from now at the worst possible
moment; build defensive code and infrastructure.

------
pklausler
Great programmers write code that even bad programmers can understand. Bad
programmers write code that _only_ great programmers can understand.

~~~
elliotchance
That's great, I'm totally using that:
[https://twitter.com/elliotchance/status/751926458658852864](https://twitter.com/elliotchance/status/751926458658852864).
I couldn't find your twitter?

------
thallukrish
Nice, you drove home the point of simplicity in building software which
largely occurs over time in the hands of a good software engineer. Do more
with less code.

Coincidentally, I had similar views in this piece some time back..
[https://medium.com/@thallukrish/on-
coding-e3c03771a369#.bb5k...](https://medium.com/@thallukrish/on-
coding-e3c03771a369#.bb5kuf6zq)

~~~
elliotchance
Cheers, great article. Left my own comment ;)

------
mooreds
The unspoken subtext is, of course, "as simple as possible while still adding
business value". For example, there may be external constraints (contracts,
regulations) that require more convoluted code. There may be certain business
situations where there just has to be complexity.

In these cases, we should strive to understand: * the complexity and the
sources of it * how the complexity will change, and how much (as best we can,
as predicting the future is hard) * what, if any, of that external complexity
needs to be in the system we're building, and what can be pushed into human
hands * how best to encapsulate that complexity so it doesn't spill over into
parts of the system where it needn't be

It's all well and good to say "keep it simple", but that can be difficult when
there are external forces that are saying "the system must do X when Y, A when
B, and C when D, except when X. Oh, and if Y then C, except when A", etc,etc.

~~~
bitwize
It's not just contracts and regulations.

Example: Bob the sales manager doesn't want to view reports through your handy
web portal. Bob wants them formatted in Excel sheets, zipped, and emailed to
his corporate Exchange account daily. Bob is the only person in the whole
company who doesn't like your portal, but he is powerful enough that his whims
automatically become mission critical requirements. You either give Bob what
he wants, messing up your clean design to implement functionality _just for
Bob_ , or you have failed to meet the business's needs and will lose the
contract, end of story.

------
meeper16
Being able to step outside software engineering when engineering software.

~~~
jomamaxx
Yeah! This.

'Perspective' ...

Mini perspective: step away from the desk, do something literally creative. I
play my guitar.

Major perspective: get the hell out of the city, actually do something on a
weekend. Come back - all of a sudden you have fresh eyes and see things more
clearly.

I actually think that soft devs should take more vacation.

You know that professional concert musicians only practice a few hours a day -
any more is pointless. You just can't concentrate that long.

A really gutsy move would be for Google to give a bunch of 'long weekends'
where nobody can work, or even more vacation. And see what the results are.

~~~
elliotchance
Fresh eyes on the problem is always good, usually after lunch or you have
slept on it.

I find when my brain starts to grind to a halt I just go an do another un-
related task to force myself to completely forget about the original task. It
does help because when I go back to the original task my brain has to context-
switch back into it and in doing so it may look at the problem a different
way.

Extra holidays would be great! However, I think more holidays would make some
engineers more productive and some less productive... I'm not sure if Google
is still doing their 20% time, and if they are I know it doesn't apply to all
the FTE engineers.

------
andreygrehov
There is a fine line between short code and readability, which is, by far, one
of the most important factors of code quality. Say you have a code:

    
    
      $this->executeAfter(5);
    

This is a short code, but it's not readable. What the hell is 5 here? Let's
improve it a little bit.

    
    
      class Time {
        
        protected $seconds;
    
        private function __construct($seconds)
        {
          $this->seconds = $seconds;
        }
    
        public static function inSeconds($seconds)
        {
          return new self($seconds);
        }
    
      }
    
      $this->executeAfter(Time::inSeconds(5));
    

I've just added ~10 lines of code, but the readability of _executeAfter_ is
way better. In addition, the _executeAfter_ method is more flexible, since it
can manipulate the _Time_ object now.

This is a very basic example to illustrate what I meant when drawing a line
between the short code and readability.

~~~
jamescostian
I believe you have missed the author's point - "Using more code is actually
the lazy fix." The author would recommend something like:

    
    
        $this->executeAfter(5); // Execute after 5 seconds
    

The above code is only 1 line, and is very clear. It does not add a brand new,
unnecessary class, nor does it increase the surface area for bugs (adding a
new class opens up the potential for new bugs, while adding a comment does
not).

~~~
andreygrehov
This is not entirely true. It depends on the language, but the definition of
_executeAfter_ for the most of dynamic languages would be something like

    
    
      public function executeAfter($seconds)
    

This code does not guarantee that the value of $seconds is _correct_ , whereas
this:

    
    
      public function executeAfter(Time $time)
    

...will help engineer to not make silly mistakes.

It definitely depends on the language, but I personally like self-explanatory
code and tend to think that inlined comments should only describe things that
require explanation, such as complex logic.

------
lwhsiao
Great write up. One of the challenges is definitely finding a system that
recruiters can use to prioritize these things.

~~~
elliotchance
I'm generally not a fan of recruiters simply because the vast majority of them
are sales people first, and tech people second (or often no technical
experience at all). Compounded by the fact some people interview very badly
but are good engineers and visa-vera.

Even if you have experienced engineers doing the screening process (separate
from the company being applied for) I still think it would be challenging
because theres no "correct" way for a team to work and companies are so vastly
different.

It definitely is something to think about. If you do some up with something,
let me know :)

------
adrianggg
Great article. I think you have hit on something here that only comes with a
lot of experience and looking back and what really worked. I rarely see an
article that I think YES. TOTALLY. Well done!

~~~
elliotchance
Thank you for the kind words :)

------
paulftw
Before you aim to become great by reducing your code please become competent
in absolutely necessary basics: DRY, separation of concerns, basic patterns,
security, etc.

~~~
elliotchance
Yes and no. I think we read these things in textbooks and either don't truly
understand why they exist until we've made the mistakes or we go too far the
other way and start dictating best practice on to everything.

It's best to be be somewhere in between. It can only be learned by doing, not
studying.

------
hakunin
My thoughts conveying similar message from a different angle:
[http://hakunin.com/cms-trap](http://hakunin.com/cms-trap) (for those who
might've missed it when it got upvoted on HN 3 years ago).

------
BerislavLopac
In my experience, laziness is one of the most important traits of a _good_
developer.

~~~
SlySherZ
You have to be careful how you define 'lazy' in this case. Suppose a developer
just quickly writes code that fixes the current problem, but doesn't care
about the consequences long term, or doesn't fix the underlying problem - not
good.

Now, if you define 'lazy' as someone who will go to great lenghts to not do
boring tasks in the future, yes, I completly agree :)

~~~
elliotchance
Spot on in my opinion ;)

------
mannykannot
"The best engineer will write zero code" \- unfortunately, the author has
forgotten to tell us what she does do.

~~~
elliotchance
I'm a software engineer. If that's not clear from the article, you should be
able to tell from the bio at the top and bottom of the page.

~~~
mannykannot
I'm sorry, I may have been ambiguous. I was actually wondering what the best
engineer does.

------
dmolony
You probably want to the right thing

~~~
elliotchance
Thanks, I've fix it up.

------
phyalow
Autism.

