
What Makes a Good Programmer Good? - Veraticus
http://joshsymonds.com/blog/2013/11/03/what-makes-a-good-programmer-good/
======
greenyoda
" _Whatever you call it, most programming problems you’re likely to encounter
have been solved in some form already... In the form of libraries on GitHub,
blog posts on the Internet, or just getting in touch with experienced
individuals, good programmers know to do the research before they try to solve
a problem._ "

This depends a lot on the domain you're programming in. For example, if you're
working on a proprietary application like high frequency trading or code for
an embedded device, it's not likely that you'll find an open source library to
do whatever you need, or get a lot of help from Google or Stack Overflow.

Also, a lot of open source libraries are not robust enough for commercial
applications that have requirements like support of legacy East Asian
character encodings (pre-Unicode). Not all programmers work on web apps where
you get to control the environment (hardware, operating system, database,
languages, etc.) you run on. Lots of software has to be built to run in the
customer's existing environment.

~~~
VLM
You probably will get a lot of google help for embedded stuff. Treat it like
psuedocode even if its C++. Not as easy as adding a open source library and
using it, but much easier than replicating the theory from nothing, or even
worse not knowing a problem can exist.

Did you know, that if you make a control loop running basically newton's
method of approximation (more or less), it can be statically stable in
continuous analysis but when you run it on real world discrete math with
short-ish rounded floating point it can get squirrely and oscillatey (are
those even words?) so that's why you ram the output thru a low pass filter to
damp out the oscillations. Or at least that's one way to fix it.

Oh another funny one is picking a local maxima / minima that randomly happens
to have a near zero derivative. From memory Newton doesn't like that very
much. Another funny one is any time you have tiny rounded floats divided by
other tiny rounded floats, who knows what you'll get as an answer. You can fix
that by fuzzing the input first guess with some random noise. Makes your
execution speed non-deterministic, but stuff is fast now a days isn't it, and
its faster than doing double/quad floating point anyway, which may or may not
help much.

Sure the google found some python or fortran or mathematica which on the
surface is useless, but psuedocode is psuedocode and compilable fortran is a
tighter syntax than any random human generated psuedocode so in some ways its
better.

This is before you hit the "well, that library speaks to 16x2 LCD displays, I
guess I'll have to start over from scratch because I'm using a 20x2 LCD..."
Well, typically, no.

For HFT I agree, you're stuck behind layers and layers of patents and trade
secrets. But embedded is not a problem to get google-type help.

~~~
derefr
> Did you know, that if you make a control loop running basically newton's
> method of approximation (more or less), it can be statically stable in
> continuous analysis but when you run it on real world discrete math with
> short-ish rounded floating point it can get squirrely and oscillatey (are
> those even words?) so that's why you ram the output thru a low pass filter
> to damp out the oscillations. Or at least that's one way to fix it.

I encourage anyone who wants to get an intuitive grasp of simulations to just
write a simple little 2D game engine, and try to work up toward a simple two-
player realtime LAN system with predictive physics for expected network input.
_Seeing_ sprites shudder and vibrate against their integer pixel positions,
jump instead of smoothly curving when a correction is issued, etc., is a
visceral learning experience.

------
keithwarren
It may be an oversimplification, but the best indicator I have seen for
someone and their coding competence, is desire to get better.

The best programmers I have ever worked with sought continual improvement
personally. They viewed themselves and their career as a system that they
monitored and acted upon.

I focus on this because it is a factor that ignores the variables that often
influence or weight the typical measures. Age, Experience, Education - all of
these things affect the quality of work and the perception of skill so I have
constantly sought that thing I can look to outside of that which is indicative
of long term value.

So far, desire to improve, is the best I have found.

It sounds trivial yes, but people who actually embody this are very different
than those who give lip service to it. Ask 100 programmers is they wish they
were better and 99 will say yes (there is always one dude...). Ask those same
100 what they do each week to make themselves better and you find 10 or less
actually doing the work in their spare time that it takes to become a master.

------
amenod
I agree wholeheartedly with most of the article, except for this:

 _" To put it more simply (and, perhaps, too obviously): if you see someone
excitedly grabbing problems and acting on them, chances are you have a good
programmer on your hands"("They just do it")_

it depends on the type of person someone is, more than the quality of the
programmer. I know bad programmers who are excited to jump from problem to
problem (never doing much good on any of them). And I know great programmers
who think twice about taking a problem - because they are working on something
else and wish to finish it properly, because they want to think it through,...
there are many reasons.

Also, I wonder how many of us identify ourselves with the good ones? As
someone said, it is very interesting to observe that about 80% of programmers
are in top 5%. ;)

------
gluejar
I disagree that "great programmers are always programming". I find that great
programmers are interested in lots of things; programming is just a tool that
makes some things more interesting.

~~~
SiVal
I think it's somewhere in between his description and yours. I would say that
great programmers do a lot of programming on their own time just because they
enjoy it.

I'm often surprised at the fact that most professional programmers do almost
no programming on their own time. They're no more interested in it than most
plumbers are interested in unclogging toilets for fun after work. Most
programmers program for a paycheck, because they'd rather do that than clean
toilets.

Great programmers ARE often interested in other things, too, but they are
interested enough in programming to do it as a hobby outside of work; they're
not just doing it for a paycheck. (And, yes, I exclude those who are currently
going through day-job death marches at work and need something _completely
different_ to recover after work. I've been there, too, but when the tide
changes, I'm back to programming my own projects for fun.)

------
rjd
He dismissed just plain experience to easily. Having intuition where a
customer is likely to change its mind later down the track and throwing in a
factory or an interface declaration so that just a small tweak doesn't cascade
into into a weeks worth of refactoring.

------
robbfitzsimmons
The key consideration for me here is "they communicate well."

As someone who's just recently started to consider full-time hires beyond our
founding team, it's ridiculous how important this is relative to how little
it's talked about. The other traits - "avoiding crises", "doing their
research" \- often boil down to effectively working together with your
teammates and finding information / reaching decisions quickly.

And I do think it's got something to do with educating programmers. Working
with interns and contractors we've had at Harvard, MIT, etc., the best have
been Olin College ([http://olin.edu](http://olin.edu)).

I'm not going to gush about it in this comment too much, but suffice it to say
the best communicators about technical problems are usually the ones who spend
the most time working in teams and presenting their work, and those are
Oliners to a tee.

------
VLM
A good article. I'd expand and generalize "They read error messages (and act
on them)" to something like "made plenty of mistakes in the past, learned from
them, not scared of making some more mistakes". Its a craft. You can't become
a good carpenter without making a lot of firewood when you're just staring
out, or zillion other analogies with cooks, mechanics, authors. Some of the
perl I wrote in the 90s, ... ugh. The stuff I wrote in GWBASIC in the 80s was
worse.

------
bliti
1\. The ability to develop a solution within the tight confines of the
problem.

2\. Being able to recognize a bad design and improve upon it.

3\. Not wanting to re-invent the wheel every time the code base stinks.

4\. The understanding that no problems in general might be new, but some
specific problems inside a particular situation might be.

5\. The importance of listening and taking into account the solutions others
provide.

6\. Being able to deliver. I have met too many _full stack rockstars_ whose
code never works and is as tight-coupled as melted cheese to bread.

------
UK-AL
Can programmers have a life? All I see about programmers these days is that
good ones program 24/7? Don't they have social lives or family?

That's not a life worth living.

~~~
jasonlotito
Having a social life and a family doesn't preclude one from programming a lot.
And you don't have to be programming 24/7\. What it takes is learning how to
combine the two. Meeting up with people and learning about programming (or
other aspects related to programming), or joining a book club that reads books
that cover elements of programming.

No one sits in front of a computer 24/7 to program. No one. Hell, Linus talks
about how he spent so much time programming Linux in the very early days in
the book "Just For Fun" and he even has time for socializing.

> That's not a life worth living.

For you, maybe. Don't assume your values apply to others. The other side is
that it's not a life worth living if you spend 40 hours a week doing something
you avoid the other 128 hours.

~~~
UK-AL
"The other side is that it's not a life worth living if you spend 40 hours a
week doing something you avoid the other 128 hours." \- Its not that you hate
it. But you should not fill your life with just one activity.

You should be networking, talking, going out, learning, traveling and filling
your life with a wide variety of things. Yet the start up programmer lifestyle
is programming 24/7\. It's not healthy. I can guarantee you a lot of start up
founders, don't work the hours their programmers do.

------
mendem
"Ultimately great programmers view their profession not just as a means to
make money, but as a means to make a difference. I think that’s what makes the
best programmers who they are. Coding, to them, is a way of shaping the world.
And that’s what I truly respect and admire."

This is not only the essence and truth of this article, but also what I
believe is the core of all good people - shaping the world into something
beautiful.

------
FrankenPC
One of the nicest all around behaviors I've seen is the tenacity to never give
up. But, the BEST behavior I've ever seen is the same tenacity tempered with
wisdom. Knowing WHEN to give up. When to ditch your approach, reverse all your
changes, and go in the most efficient direction regardless of the pain
involved.

------
hsmyers
While I've only been playing the game for 35 years, I didn't see anything to
argue against.

------
grandpoobah
IMO, you could add to that list - Good programmers like to program in their
spare time, working on pet projects and the like.

Of course there are exceptions to every rule, and I'm probably biased.

~~~
gaius
Just like good lawyers like to sue people in their spare time, and good
doctors try a little home surgery?

I strongly suspect this sort of thing is HR-compliant code for "we'd like
someone in their 20s with no family who won't mind doing unpaid overtime".

~~~
kyzyl
Yeah, I get that feeling a lot too. The kicker: I'm in my 20s and have no
family, although I DO mind doing unpaid overtime!

What strikes me is that this notion seems to have developed in the software
industry that people working on code in any significant capacity should be
living and breathing code. I've seen it said here that there is no excuse not
to have a flourishing github account in this day and age. Well, what if I
don't use github for my stuff? What if my work is pretty much all proprietary?
Side projects you say? Like my personal algorithmic trading platform, I should
put that on github? No thanks. How about the field of math I've been teaching
myself over the last three years? That doesn't count because it doesn't go on
github?

For me it comes down to the fact that developers seem to be expected to have
no life, but simultaneously expected to have a diverse set of
skills/interests. I have a ton of side stuff going on, but it's not all
public, and it's not all programming!

------
throwmeaway2525
My reflex is to say it's the opposite of whatever I am. But according to this
article, I'm pretty darn good!

