
How To Become A Better Programmer By Not Programming - davidjnelson
http://www.codinghorror.com/blog/2007/01/how-to-become-a-better-programmer-by-not-programming.html
======
edw519
_From what I've seen, there's just no crossing the skill chasm as a software
developer. You've either got it, or you don't. No amount of putting your nose
to the grindstone will change that._

What a scary thought. Good thing it's not true.

One of the many reasons I became a programmer was that the sky was the limit.
Still is. Want to learn something new? Learn it. Want to build something cool?
Build it. The only real limitations are your belief that you can do it and
your willingness to perservere until you do.

We are not like basketball players or musicians or chess masters where only
the extremely gifted (who also work hard) can rise to the top of their craft.
With few exceptions, we all can.

I didn't always think this way. I had a college math professor who once said,
"Many of my students are simply not suited for the sciences." And I was stupid
enough to believe him! In retrospect, his comment said more about his weakness
as a teacher than anything about his students.

How do I know this? Because I learned the hard way. When working with my first
mentor, I was always too quick to blame someone else for their limitations
slowing progress. Until he said, "So teach them!" He believed that _almost_
anyone can learn and get good at _almost_ anything. This seemed
counterintuitive but after a while, I was able to adopt this belief system,
and it has made all the difference.

There are many reasons why so many programmers suck, but "not being able to
cross the chasm" isn't one of them. Just a few of the real reasons:

    
    
      - They never learned right in the first place.
      - They never built anything of real substance.
      - They were a tiny cog in a machine and never saw the big picture.
      - They got pigeon-holed into a small area for a long time.
      - Other things in their life took over.
      - They had shitty teachers.
      - They had to build on top of pre-existing shit and couldn't do it right.
      - They were stuck in environments where excellence never mattered.
      - They went into management too soon.
      - They got trapped into old technologies and methodologies.
      - They made too much money to make a career u-turn.
      - They just didn't care enough.
      - <add your own>
      

My programming has always gotten better every year. Sometimes I read my old
code and can't believe I wrote it. And I still have tons of room for
improvement.

I'm firmly convinced that almost any of us can get better, much better. And
even become "elite", whatever that means. Please don't listen to anyone else
who tells you otherwise.

~~~
jdietrich
Why isn't writing software like chess or sport?

The highest ranked player in the world is twenty years old. Any local chess
club is full of people who have studied the game for years but failed to break
1400. I've taught people who were just incapable of the most rudimentary
strategic thinking and people who just naturally saw things that it took me
years to learn.

The evidence is clear that there are people in the world who just can't solve
FizzBuzz, many of them people with degrees in CS. Some people just seem unable
to grok the basic abstraction of programming. What if that isn't a binary
state, but just one extreme of a spectrum?

I can run 10k in 40 minutes any day of the week, but I sprint like an
asthmatic Samoan. I just have distance genes, nothing I can do to change it.
No amount of training would ever make me a competitive sprinter. I've got too
little fast twitch fibre, I'm too short, too lean, my heart and lungs are too
small. Is it completely implausible to suggest that there are cognitive
equivalents that would pertain to programming?

Why couldn't mental stamina be as genetically ingrained as physical stamina?
There are obviously natural geniuses in our field, why not natural dunces?

~~~
jerf
"Why isn't writing software like chess or sport?" ... "There are obviously
natural geniuses in our field, why not natural dunces?"

Precisely because 5-standard-deviation-above-average natural talent isn't
_required_ for success in our field. There's only one chess champion in the
world and a handful of grandmasters, by definition, and those are gonna be the
ones with talent and hard work. But to succeed as a programmer requires more
work than genetic luck. An average person can probably do it with enough work.

(But I would point out there is, by necessity, a floor of base talent required
somewhere. But it isn't necessarily as high as commonly supposed.)

~~~
gnosis
_"There's only one chess champion in the world and a handful of grandmasters,
by definition, and those are gonna be the ones with talent and hard work."_

There are in fact over 1000 grandmasters.[1]

Originally there were just 5, but as you can see, over time the ranks of
grandmasters have swelled.

Many in the chess world lament that it's too easy to attain (or even buy) a
grandmaster title these days, and that it doesn't mean nearly as much these
days as it used to.

[1]
[https://secure.wikimedia.org/wikipedia/en/wiki/Grandmaster_(...](https://secure.wikimedia.org/wikipedia/en/wiki/Grandmaster_\(chess\)#Title_inflation)

~~~
jerf
In a world of 6 billion people, 1000 is metaphorically a handful, as far as
I'm concerned. In the context that we're talking about, there's certainly more
than 1000 "good programmers".

------
yaongi
So many sentences in bold, yet so little substance. What he seems to be saying
is that to be a better interface between development and
customers/management/etc requires more than pure programming ability. Yeah,
ok. And maybe this is beneficial for business or, if there really is a lack of
this talent, for career prospects. But it's not being a better programmer. The
pithy title is not very relevant to the content.

As regards the pithy title though, and the earlier part of the article, I
disagree. Programmers can and do develop. There is a large difference in
ability between people who stick with the craft for a large number of years
(and actively develop their abilities), and those who are new to it. When I
was younger I would have probably agreed, yeah, programmers are just good or
bad (and I'm good). But I wasn't good. I've become better since. And there's
still a lot to learn and pursue. It takes time.

Having said that, it's definitely possible not to progress as a developer
despite programming every day. It requires some amount of contemplation.

------
rickmb
This article just confirms my notion that in the debate about "what makes a
great programmer" there is a fundamental disconnect between the concepts of
being "a programmer" and being "a maker of software".

Making software consists of way more than just programming, and in that
respect I agree with Atwood. However, that ignores two other things I consider
to be proven truths:

1\. You don't have to be a great programmer to make great software. Some of
the best products are build from horrible code, not just by people who
deliberately rushed things, but by people who simply didn't know any better.

2\. You can definitely become a better programmer by simply practicing the
craft a lot, even after many years. It doesn't however make you a better
"maker of software", just a better coder.

~~~
drzaiusapelord
This is such a good point. I've noticed that the personality style of
"algorithm obsessed, Knuth worshiping, all about optimization, hardcore coder"
doesn't have a lot in common with "creative, new software, good UI, unique
application builder" personality. While its important to have some of the
former under your belt, its the latter that gets shit done and makes things. I
consider myself a maker, not a coder or a computer scientist. I'm getting a
little sick of the attitude that you need to be this hotshot coder to be into
software. Its just this geek macho poseur mentality that's harmful. A mediocre
coder with a few good ideas is all it takes. I'd rather see a slow python app
or a simple web app that's unique than some super-fast C or low-level me-too
implementation.

I feel this dichotomy is typical of geeks. My poor metaphor is we learn the
notes, scales, and do our practices, but at the end of the day we're supposed
to be writing songs, not waxing philosophic on music theory or who makes the
best pianos. Geeks are just too prone to being "technically correct, the best
kind of correct!" and those of us who want to create unique things really need
to think more like artists than engineers half the time. Oh well, back to our
typical barrage of "Why PHP sucks" and "real coders walk like this..."
articles

~~~
davidjnelson
I like your point. It reminds me of how facebook was initially cobbled
together with some (likely) hodgepodge php and mysql code. It was a great user
experience and took off. After it becoming a hit, they optimized it and
improved it.

------
St-Clock
"I agree with Bill. From what I've seen, there's just no crossing the skill
chasm as a software developer. You've either got it, or you don't. No amount
of putting your nose to the grindstone will change that."

This is a very condescending look on humanity and I did not know that Jeff had
said such things.

To anyone thinking the same, let me introduce you to the concept of deliberate
practice (how to __really __improve a skill) and please, even if it wasn't
published then, read "Talent Is Overrated" by Geoff Colvin. This will probably
change your perception on things like excellence, creativity, so-called
"talent" and whether it's true that you must be born a genius to become one.

And by the way, that does not mean that everything is an american dream and
that anyone can become a self-made person. Geoff shows through many examples
and studies in his book that superstars in music, sports, and science had an
exceptional learning environment in their childhood. They did not suffer from
hunger and extreme poverty. He also talk about a study that demonstrated that
ordinary people could increase their short term memory (remembering up to 100
items if I recall correctly, no pun intended) by doing deliberate practice.

~~~
silverbax88
When I was first starting as a programmer, I would have agreed with you. But
over the years I've learned that it is 100% accurate that some people can
program while others simply cannot.

But it's not a matter of stupid/smart. It's actually the same reason why Paul
Graham's 'Hackers and Painters' analogy is so apt. The reality is that some
people can think in abstract terms, while others cannot.

Someone who can think in abstract terms can be a graphic artist or a
programmer. Consider that even in mathematics, the most concrete things are
numbers, which are completely abstract. If you understand that, then guess
what? You can think in abstract terms.

~~~
philgo20
I totally agree with the 'thinking in abstract terms' thing but I would never
reduce programming to that. It's not always so abstract.

I tend to think that it'soften good rhetoric skills. A great ability with the
three different types of rhetorical proof: ethos, logos, pathos.

<http://en.wikipedia.org/wiki/Rhetoric>

~~~
St-Clock
Since I'm recommending books today, I really liked "Thank You for Arguing" by
Jay Heinrichs. Very fun and instructive intro to rhetoric.

I can see how rhetoric (and religion!) can come into play in design meetings
:-)

------
szany
"When, in the late sixties, it became abundantly clear that we did not know
how to program well enough, people concerned with Programming Methodology
tried to figure out what a competent programmer's education should encompass.
As a result of that effort programming emerged as a tough engineering
discipline with a strong mathematical flavour. This conclusion has never been
refuted, many, however, have refused to draw it for the unattractiveness of
its implications, such as

1\. good programming is probably beyond the intellectual abilities of today's
"average programmer"

2\. to do, hic et nunc, the job well with today's army of practitioners, many
of whom have been lured into a profession beyond their intellectual abilities,
is an insoluble problem

3\. our only hope is that, by revealing the intellectual contents of
programming, we will make the subject attracting the type of students it
deserves, so that a next generation of better qualified programmers may
gradually replace the current one.

The above implications are certainly unattractive: their social implications
are severe, and the absence of a quick solution is disappointing to the
impatient. Opposition to and rejection of the findings of programming
methodology are therefore only too understandable. We should remember that the
conclusion about the intrinsically mathematical nature of the programming task
has been made on technical grounds, and that its rejection is always for
political or emotional reasons."

EWD611
([http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD611.html))

~~~
cageface
Some of the most productive programmers I've known toss code together in a
horrifying slapdash fashion but somehow get great things done. And sometimes
people with far more precise and mathematical minds just get mired in their
beautiful architectures. The common trait I've seen in all exceptional
programmers is an ability to keep a tremendous number of details in memory at
one time. Most real world code is not lambda calculus but a barely controlled
mess.

Humanizing technology is a bigger win than technologizing humans, IMO.

~~~
Chirono

      The common trait I've seen in all exceptional programmers is an ability to 
      keep a tremendous number of details in memory at one time
    

Would you care to elaborate on this? I'm a programmer with 'precise and
mathematical mind' and I'd say that my one big weakness is exactly that: I
struggle to large numbers of disconnected facts in my head at one time.

~~~
danielharan
Same here - the best could just read APIs and start using them, while I was
always referring back to them.

I've started meditation again; dual n-backed games are next to try and improve
my working memory and concentration. Also, just regularly re-reading the core
APIs I'm working with.

~~~
xom
On the usefulness of N-back (scroll to heading "Notes from the author"):

<http://gwern.net/DNB%20FAQ>

------
agentultra
Programmers are not born. They're made.

You may have a certain aptitude or talent for software development. However
talent without discipline fizzles out or produces wildly varying results.
Talent is like that.

What makes a good programmer, mathematician, sports player, etc is discipline.
The love of the craft/sport/etc that pushes a person to believe that all the
discipline and hard work is worth it. People are naturally lazy. However if
they really believe in something they will work on it and become better.

~~~
cloudhead
I completely agree, but at the same time, discipline alone doesn't make a good
programmer. You need the other half.

~~~
agentultra
I think you can become a great programmer without any natural talent for it at
all. I just don't think you'll find it that interesting... so staying
disciplined will probably be very masochistic.

------
viandante
Why people are so focused on the top x% of something? I really don't see the
point. Sometimes what you need is a person with great ideas, not a top x% that
believes to be some sort of god.

------
gwern
Times like this, I wish everyone could be made to read _The Cambridge Handbook
of Expertise and Expert Performance_ (
<http://dl.dropbox.com/u/5317066/cambridge-expertise.pdf> ) or at least the
original deliberate-practice paper ( [http://www.gwern.net/docs/1993-ericsson-
deliberatepractice.p...](http://www.gwern.net/docs/1993-ericsson-
deliberatepractice.pdf) ).

------
philjr
I make the distinction between "Programming" and "Development" in my own head.
In fact, I try to avoid using the phase programming, I call it coding. i.e.
putting the code on the screen with a keyboard.

I see Jeff talking more about "development" here - coders get better at coding
by writing and reading more code. But there's no point being good at putting
code on the screen if it doesn't do the thing your end users need to do.

------
csomar
_I agree with Bill. From what I've seen, there's just no crossing the skill
chasm as a software developer. You've either got it, or you don't. No amount
of putting your nose to the grindstone will change that._

Not true with the current neuroscience. Well, in reality, that's what is
happening. But do you know why? I'll tell you: Because I'm obsessed with
programming. The typical programmer that is not obsessed will just make use of
the skills he got while programming and learning. These skills are limited to
the time he spent learning/coding.

I'm obsessed; I learn and code even when I'm not in front of the computer.The
time of my experience expand. Add to that, the fact that I'm obsessed. I'll
brainstorm code/ideas/tricks/google... to get that thing working. I'll make
any opportunity in life to learn more about programming. This gives me
advantage over that typical programmer that disconnects when he quits his job.

------
geek_silk
What bill is talking about programmers at MS or any big company like facebook,
google etc just like super start sports person or musician, but in general
there are lots of requirement of programmers who don't need to those kind of
super programming skill but programming with business value.

Comparing programming with sports is not a good idea because you are comparing
super start sport person with avg programmers.

Even in sports or other fields there are people who were avg or above avg
sport person but latter they become great coach .

So it is quite subjective. If your heart say you can become programmer and you
are doing enough for the same and you are improving day by day then you are on
right track.

In my view just writing code is defiantly not going to make good programmer.
Code, understanding end user and domain is going to make you better software
maker.

------
coliveira
I think this article says more about the corporate culture where programmers
work than about their capacity. What happens in Microsoft, as in most other
companies, is that they make a decision about what a person can do in about 1
to 3 years. After that period, they will no longer give exciting assignments
to the programmer and he will be forever viewed by management as doing the
same old job. Many times this happens because of lack of determination from
the part of the employee, but frequently because he didn't have the right
opportunities and didn't know how to look for them.

Usually when this happens, either the employee will leave the company in a
short period, looking for better opportunities, or resign itself to do the
same thing until retirement (or until he gets lucky).

------
snarfy
Part of the controversy with this article is that it is combining two separate
ideas into one concept, blurring the differences.

Implementing software is something you can absolutely get better at with
experience, discipline, and practice. You only need to look at your old code
for evidence of this.

Designing software takes imagination and creativity. Experience and practice
may give you a tool chest of preconceived ideas to use when designing your own
software, but it isn't going to help you conceive completely new ideas
yourself. That requires thinking outside of the box, and it's not something
you learn by studying the nuances of implementation. It's not even something
you learn by studying programming. IMO this is what Atwood is talking about.

------
kragen
Well, I may not be a great programmer, but after programming for 30 years, I'm
a hell of a lot better than I was after programming for three or four years.
The story of my evolution as a programmer is at
[http://lists.canonical.org/pipermail/kragen-
tol/2007-March/0...](http://lists.canonical.org/pipermail/kragen-
tol/2007-March/000849.html).

Even after 25 years, I was doing things that I didn't have the knowledge or
skill to do five years before. (On the other hand, sometimes I look at kragen-
hacks posts from ten years ago and say, "Whoever did that must be a lot
smarter than I am ---" before remembering it was me.)

~~~
Revisor
Thank you for the high-level overview and the book recommendations in your
post.

~~~
kragen
I'm glad you enjoyed it!

------
usedtolurk
Maybe 4 years at Microsoft is enough to tell if you have what it takes, but I
doubt it. If you work elsewhere you can find yourself moving backwards if
you're surrounded by poor practises, particularly early on in your career.

My programming wasn't much cop to begin with and declined in the first 4 years
of my career. After 8 years it leaped forward when I read Code Complete (by
Steve McConnell). Only later on, when I was maintaining other peoples code
rather than writing from scratch, did I realise the pain I had been inflicting
on others earlier on.

Another leap occurred when I found myself as the most senior programmer in a
(small) company - when the buck stops with you, you're forced to stretch. My
every day programming has also been improved by my attempts at architecture.

Its taken me about 15 years to feel reasonably confident and I can't be the
only slow learner out there. So although I disagree with Jeff Atwood that you
either have it or you don't, I suppose he does have a point - it was largely
non-programming tasks that were the break-throughs.

It can be tempting to write-off a junior programmer as having no hope but I
was that guy once and I came right eventually - there is hope for everybody.

------
montages
Umm... that pours the whole theory of deliberate practice and (more
importantly) rocky style style montages for programming down the toilet.

------
cloudhead
There's definitely a confusion between "product designer" and "programmer".
Sometimes they are the same thing, other times not. So I don't think it's a
useful metric. There are truly great programmers... Andrew Appel, SPJ,
McCarthy etc who have no need or interest in making "products", yet that
doesn't disqualify them from being _great_. Sure, communication skills are
important, especially writing, but I wouldn't push the idea much further.

------
riledhel
I'll just keep the "You won't-- you cannot-- become a better programmer
through sheer force of programming alone. You can only complement and enhance
your existing programming skills by branching out. Learn about your users.
Learn about the industry. Learn about your business." quote. I think that's
the main point of the article. Also, the article is more than four years old,
I'd like to read what he thinks now or five more years from now.

------
jeffreymcmanus
The fact that programmers tend to not get better has little to do with
programmers' inherent worth or talent. It has everything to do with how
programmers are trained. Employers are doing less and less to train their
technical staffs, which has fostered a generation of programmers who believe
that the right way to learn something is by Googling it or experimenting
randomly on their own. Of course you're not going to get better this way.

~~~
cloudhead
Part of talent is knowing how to learn the right way.

~~~
jeffreymcmanus
Maybe true, but "knowing how to learn" doesn't completely cover it.

It's absolutely possible to make middle-of-the-road developers into good
developers through training and mentorship. It's just that many (possibly
most) developers don't get opportunities for good training. They're expected
to use their "talent" to figure things out on their own, which in most cases
means Googling or trial-and-error experimentation. These are among the
poorest, least efficient ways to learn.

~~~
cloudhead
I agree, it's sad that not everyone gets the opportunity to have a great
mentor. But somehow, when it's meant to be, most will still push through.

------
wyclif
_You can only complement and enhance your existing programming skills by
branching out._

A big part of that branching out in my opinion is expanding vistas in areas
unrelated to engineering, like reading good literature, creating or
appreciating art, and travel.

~~~
mattgreenrocks
I've wondered if engineering/CS undergrads should be forced to take a Design
101 class to learn:

    
    
      * design is everywhere
      * having a sense of taste is vital to anyone who makes things
      * end users are severely affected by every design decision you make
    

I run into too many engineers that try to disregard the subjective aspects of
development (architecture/UX/etc) because they believe the only worthwhile
things are the logical ones.

~~~
EponymousCoward
what's subjective/"not logical" about architecture???

~~~
flamingbuffalo
the aesthetics

------
alecco
The "gift" is borderline-masochistic obsession coupled with good abstract
thinking.

------
asimjalis
There are two types of people: those who peak early and those who evolve
gradually but steadily over a longer period.

~~~
dj_axl
This is missing what I will quote from another post above "If they really
believe in something they will work on it and become better." If you peak at
something this makes you good. If you work ard at something this makes you
good. If you peak at something _and_ work on it and become better, this makes
you great. Evolving gradually but steadily might increase one's belief that
hard work is rewarded, however you will never become great, merely good.

------
maeon3
Programming is about representing the world with structures that are adaptable
to how the world really changes, so it pays off to read books about human
psychology (normal and abnormal), statistics, game theory, and war.

When you get a intuitive feeling for how the world morphs and changes around
you according to stimuli, then better code structures strike you, and those
superior code structures will have much longer lifespans and will be more
adaptable to the needs that the users don't know they have yet. It's all about
predicting the future, and in order to predict the future of a complex worldly
system, you have to KNOW it inside and out.

------
leon_
So at least Mr. Atwood can now stop pretending being a programmer.

------
rubyinghana
One company tell me I'm bad programmer, then other company teach me Ruby in
Rails. Now everything wonderful.

------
choxi
I hate that Bill Gates quote, why would you cite the opinion of a guy who
isn't known for his programming ability nor has any history of hiring good
programmers?

~~~
gwern
Well, the thing is, Gates _was_ an expert programmer. His coding on BASIC was
impressive. He transitioned to management pretty quickly, but that doesn't
mean much.

