
The curse of the gifted programmer (2000) - nkurz
http://lwn.net/2000/0824/a/esr-sharing.php3
======
WalterBright
> Your tendency to undervalue modularization and code-sharing is one symptom.
> Another is your refusal to use systematic version-control or release-
> engineering practices. To you, these things seem mostly like overhead and a
> way of needlessly complicating your life. And so far, your strategy has
> worked; your natural if relatively undisciplined ability has proved more
> than equal to the problems you have set it. That success predisposes you to
> relatively sloppy tactics like splitting drivers before you ought to and
> using your inbox as a patch queue.

I hang my head in shame at this. I'm lucky, though, that the other members of
the D team talked me into using modern tools like github and bugzilla. I'm
grateful for that.

P.S. yes, I really did use email as a patch queue and database.

~~~
knodi123
I've seen this sort of version control done twice in a professional setting,
and both were by programmers much more gifted than me.

I once saw a guy who wrote a robust e-store web app in C. Not C++, but C. Tons
of complexity, and it worked _fine_ , but then when I dived in to work on it,
it was a nightmare. He told me "You want main_app.version3.old.c, That's the
one that gets compiled and pushed to the production server. Not main_app.c,
that one's old and we don't use it anymore." He built a build system from
scratch, did his own version control in his head, and kept everything in one
monolithic C file.

Of course, he was the shittiest _software developer_ I've ever seen. Just a
brilliant _programmer_. He needed a manager the way a jet needs a pilot.
Sadly, he was 30 years my senior, and not amenable to being told what to do,
so after a long talk with our CEO, we decided to let him go. He was the only
one who knew how our system work, but I built a comparable one using best
practices and open-source software in less than a month.

~~~
rwmj
C isn't a terrible language to write a web framework in. (Not using version
control _is_ a terrible idea). About 15 years ago I wrote a simple high level
framework in C for writing web apps:

[http://git.annexia.org/?p=c2lib.git](http://git.annexia.org/?p=c2lib.git)
[http://git.annexia.org/?p=pthrlib.git](http://git.annexia.org/?p=pthrlib.git)
[http://git.annexia.org/?p=rws.git](http://git.annexia.org/?p=rws.git)
[http://git.annexia.org/?p=monolith.git](http://git.annexia.org/?p=monolith.git)

It actually does stuff that even current frameworks cannot achieve, such as
providing long-lived stateful web apps entirely in HTML (no JS required),
although you are entitled to doubt if that matters these days since JS has won
and is available pretty much everywhere.

The best thing about it was that it was so fast, because the code + data of a
small web app would fit entirely in the L1 cache of the CPU.

~~~
pcx
C _is_ a terrible language to write a web framework in. The kind of high-level
constructs modern programming languages provide are just not possible in C. It
is also very easy to write buggy code and is too low level for the use case.

~~~
rwmj
You should try looking at the code before declaring that. The C used a pool
allocator, had some high level structures (vectors and hash tables, basically
the same as Perl), loads of safe string functions, try/catch, coroutines,
cooperative threads, and other stuff I've forgotten[1].

It was possible to write safe code in that framework, and in fact we did write
a lot of code used daily by tens of thousands of UK schoolchildren until quite
recently.

[1] Invoking
[https://en.wikipedia.org/wiki/Greenspun's_tenth_rule](https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)
although I like to think our code was very minimal, elegant and not too buggy.

~~~
pcx
> You should try looking at the code before declaring that.

Attempting to write a web framework in C is great!

Even though you end up building the high-level programming constructs, C web
dev is still just too hard compared to other alternatives. Because of this it
is not possible to build a large community around it, which I would say is the
most crucial part of today's web framework like Django/Rails.

------
nkurz
Here are a few earlier discussions of this email:

    
    
      Curse Of The Gifted (2000) 606 points  
      luu  2 years ago  365 comments  

[https://news.ycombinator.com/item?id=7219872](https://news.ycombinator.com/item?id=7219872)

    
    
      Eric S. Raymond - The Curse of the Gifted (2000) 243 points
      vinutheraj  6 years ago  59 comments  

[https://news.ycombinator.com/item?id=1167754](https://news.ycombinator.com/item?id=1167754)

    
    
      The curse of the gifted programmer (ESR's email to Torvalds) 95 points
      semmons  6 years ago  38 comments  

[https://news.ycombinator.com/item?id=1221756](https://news.ycombinator.com/item?id=1221756)

It's interesting to compare the quality of discussion over the years. In this
case, I think the more recent ones come out looking pretty good.

~~~
IsaacL
[https://news.ycombinator.com/item?id=1221756](https://news.ycombinator.com/item?id=1221756)

The first two comments on this thread were definitely snarkier and more
aggressive. Part of me thinks there were advantages to the earlier culture of
HN, though. People were more likely to be challenged on their statements, and
forced to defend their beliefs.

------
ktRolster
ESR showed his wisdom. That is a nice post. I like this quote:

    
    
      > When you were in college, did you ever meet bright
      > kids who graduated top of their class in high-school 
      > and then floundered freshman year in college because 
      > they had never learned how to study? 
    

Yeap. I also met a few who thought they were smart, then gained a secret
terror that they were secretly stupid because they found CS hard.

Some things you have to work at before you learn them.

~~~
no_wave
Was he at all correct in thinking that this applied to Torvalds? Time seems to
have proven that ESR was completely off-base.

~~~
toyg
To be fair, Linus _did_ change. That charge about not valuing version control
and systematic release practices? He built git in 2005. Kernel release
practices are now a well-oiled machine. And overall the kernel has likely got
more modular, not less, over the years (although I have not had a look in a
while, but that was the trend a few years ago).

ESR might have been wrong on the specific item at hand (I have not read the
whole thread, and he, ESR was wrong on _a lot_ of things over the years) but
some of his arguments are definitely right - at least seen from a "gifted
something" who flopped in uni ;)

~~~
qb45
But was it due to ESR's ramblings or due to patches overflowing his inbox
capacity?

Personally, for years I had been completely ignoring everybody who framed
something as "a better alternative to talent" (wtf?) or said the magic words
"you are smarter than me". They correlated too well with "stupid ideas I knew
(or quickly checked) to be wrong".

Nowadays I'm trying to fish for useful information even in messages which push
my bullshit-o-meter out of scale, but it takes work.

If you want to maximize your chance of being treated seriously, stick to
constructive arguments about the problem at hand, not some generic
unfalsifiable wisdom.

~~~
lilbobbytables
The reason for that way of phrasing is because it appeals to ego. If you want
someone to do something, particularly someone with a known ego, then this is
an effective way to get them to listen to you and not dismiss you.

Of course, there's a fine line between stroking and patronizing, though.

~~~
qb45
No, it's a trap.

It works until you get to those with really big egos who take pride in
dismantling such tricks and gaming others by pretending to fall for their
games. These need higher levels of gaming.

But in the end, if you truly think that something is a good idea for everyone
involved, just explain why.

------
cubaia
It doesn't seem like this has anything to do about Linus raw talent, or the
"curse of the gifted".

Quite the opposite, it seems it was an opinion evolved through experience.

[https://lkml.org/lkml/2000/8/22/52](https://lkml.org/lkml/2000/8/22/52)

Linus point was apparently about avoiding crappy interfaces when one goes
about having common code just because it looks like they do the same thingy.
He seems mindful enough that sharing code _is hard_.

[https://lkml.org/lkml/2000/8/23/47](https://lkml.org/lkml/2000/8/23/47)

On the contrary, a raw talented engineer would usually jump into the
opportunity to refactor and share common code, without realizing when the
challenge is above one's ability.

In this aspect, even a few decades of experience in software (fragmented in
many separate projects) can be less valuable than a single 5 year stretch in
_the same_ code base.

~~~
klagermkii
Indeed, rather than being anti-code sharing it looks very similar to the risks
presented by The Wrong Abstraction that was posted a little while back.

[http://www.sandimetz.com/blog/2016/1/20/the-wrong-
abstractio...](http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction)

------
optimusclimb
What an amazing email from ESR.

I feel like I've had the issue he describes happen to me in multiple facets of
life, at different points.

College? Check - There definitely was a point where I couldn't cruise and
catch up by cramming. High school was a joke in comparison with some of the
learning challenges I finally encountered.

Task management? Hah! Todo lists are for old people. I cruised by on this one
for a LONG time due to (at least my own perceived) pretty large short-medium
term memory before personal life + work life (and moving up the chain) meant
that there's no way I'd remember everything that needed tending to unless I
adopted some sort of system.

More guilty one? Tests. For better or for worse, I worked professionally in an
environment where we a) had a compiler, b) had a QA group, and c) managed to
put out a lot of working software without a test suite. It definitely made me
finally give in to "code should have at least SOME test suite, if not a pretty
comprehensive one" after much kicking and screaming. To this day, in my mind,
I harbor feelings that it's possible to pump out largely working (i.e. with a
defect rate not much worse off than any other project, because no software is
without any) software incredibly faster and make the users/customers/people
who wanted the thing built happy WITHOUT writing tests. That said, I also know
it's completely irresponsible and not scalable to do so.

~~~
mbrock
With tests, there's also the idea that writing them helps you write better
code.

That's something that doesn't happen automatically. If you approach tests as
something you have to do because somebody told you to, and I think this is
pretty common, then your tests are probably not going to be great, and it's
not going to help your code...

But if a team really takes to heart the whole principle of testing, and start
to design things with testing in mind... then they start to ask questions up
front like "how will we really know that this works?" and "how can we isolate
this component so that we can test it independently?" and "how can we write
fast tests for this?" and "can we make this into more of a pure, simple data
structure?" and so on and so on.

Especially this one: "How can we get the important business logic here to be a
clear and distinct module with verifiable correctness?"

And that's a cascade of wonderful benefits. Enforcing a culture of "you must
write tests" might possibly help with QA, especially in the more obvious cases
of algorithmic correctness, but the true benefits are so much deeper.

------
hex13
Seeing this post in context of whole conversation will show that Linus' stance
was not that bad:

[https://lkml.org/lkml/2000/8/22/12](https://lkml.org/lkml/2000/8/22/12)
(quote from Linus' post)

` _It 's true that "simple and tested code means less bugs". And quite often,
code sharing will imply that the code gets (a) more complex and (b) has cases
that people who make changes will never be able to test.

No, I'm not saying that sharing is bad. Sharing is good. But anybody who makes
a blanket statement like "sharing reduces bugs" is full of crap.

Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using
your brain before you code something up reduces bugs.

But making a very complex driver that handles ten different variations on the
same hardware? No. That does _not_ reduce bugs. It's quite often more
efficient to have two people work on two drivers that are independent of each
other, than to have two persons working on the same driver. Alan put it well
at some point: the way to create working open source software is to minimize
the amount of communication needed._`

I think he's _veeeeery_ reasonable in this. This reminds me "Wrong
Abstraction" article.
[https://news.ycombinator.com/item?id=11032296](https://news.ycombinator.com/item?id=11032296)
Sometimes it is better to create two separate things than create some weird
obscure abstraction which cover all the cases.

------
bbtn
I have seen these people who have "curse of the gifted." One of them is me,
another is my step-son.

Problem is people's approach to your gifts, first; your parents. If they say
continuously that you are gifted, very smart, very beautiful, adorable etc and
you can do anything you want because you are so smart, you are most likely
doomed later in life.

Now, my step-son about to finish high school. His mother, always complimented
him starting from kindergarten. He was smart all along, did all problems from
his mind easily without much effort. His parents and teachers complimented him
everyday. He was happy, and proud of himself to be smart, his parents were
also proud.

High school required more disciplined work. He couldn't make it, too many
distractions around. He was thought to be a very special person when he grow
up, but now, he is below average, and sadly, he accepts that even though he
had the potential. I see how he will fail more in college, and can't help.

My only difference from him was that he is failing in high school, I failed in
university.

I have a small daughter, 4 years old, and I am afraid as hell not to spoil
her. She looks very smart and gifted. I always say she is not gifted, she is
just normal. I don't want her to be very special person when she grow up, I
want her to be happy and healty, that's all. Only thing I am trying to do is
not to say her that "she is gifted, she is very smart".

I don't know how to solve his brother's problem. Looks it is very late.

~~~
zelos
I believe there's a fair amount of evidence that praising effort, not
cleverness or 'being gifted', is much more productive for children in the long
run.

~~~
Jemmeh
Yes, this! Praise effort. Tell them it's okay to fail, heck it's even GREAT to
fail because each failure puts you closer to success.

It's not a "You are talented or not". Sure some people start out with an
advantage but everyone has to hone their skills through practice and effort.

------
henrik_w
Previous discussion (632 points, 2 years ago, different URL):

[https://news.ycombinator.com/item?id=7219872](https://news.ycombinator.com/item?id=7219872)

And here is a good comment:

[https://news.ycombinator.com/item?id=7220508](https://news.ycombinator.com/item?id=7220508)

From it: "Eric writes using vague generalizations about age and experience;
Linus writes with specifics about his experience with the kernel."

And: "Also, compare this message from Linus earlier in that thread
[https://lkml.org/lkml/2000/8/22/52](https://lkml.org/lkml/2000/8/22/52) with
a post of his from yesterday:
[https://lkml.org/lkml/2014/2/10/575](https://lkml.org/lkml/2014/2/10/575),
especially regarding abstraction."

~~~
icebraining
Sounds like his position hasn't changed, despite the tremendous growth of the
kernel since then. Maybe he was right after all.

------
taneq
I don't know about the specifics talked about here, but he's absolutely right
that no matter how much raw talent you have, eventually you will find yourself
facing a challenge that you can't beat. And at that point, if you want to keep
improving, you will have to start learning the same kinds of engineering
discipline and using the same kinds of external aids that everyone else has
had to use all along.

I've seen a few people go through this process (and experienced it myself) at
various stages in their careers and everyone has a rough patch after hitting
that wall. Eventually they admit that what they've been doing is no longer
working, and they become better engineers because of it. But it's tough when
you're in the middle of it, and for a while your work definitely suffers.

~~~
linuxkerneldev
> I don't know about the specifics talked about here

The specifics matter a lot here. ESR was trying to get his patchset for his
rather complex configuration/menu language into the kernel (to be used to
configure kernel configs/options) which seemed to have to do more with ESR's
need to be perceived as a "kernel hacker" rather than any concrete problem.
Fortunately, Linus said no. ESR responded with some weird tirade which had
nothing to do with the matters being discussed. Luckil

~~~
icebraining
Was it a patch by ESR? From the earlier Linus message, it seems the patch was
from another dev:
[https://lkml.org/lkml/2000/8/21/25](https://lkml.org/lkml/2000/8/21/25)

------
V-2
This letter reminds me of a historical anecdote (I read about it in some
history book, it could be apocryphial though) in which Hitler's generals were
faced with some ludicrous strategical concepts of his. But, of course, noone
really dared to speak up. And finally one gray-haired general clears his
throat and says "mein Fuhrer, I'm afraid you are mistaking Stalin for a genius
equal to yourself!"

------
onion2k
The greatest realisation I've had as a developer is that no matter how much I
learn and how clever I think I'm being, I'm always going to be limited by the
number of hours in the day. If you want to build brilliant, audacious,
complicated applications then you simply _have_ to work with other people
because you physically can't do everything yourself.

If you're a "lone gunman" you'll have to accept you're limiting yourself to
things you can make in your available, very limited time.

~~~
marktangotango
To me this is where the allure of the 10/100x developer myth comes in, if I
were truly gifted I would build tools that multiplied my ability, so I could
do more. But I haven't so I must not be. Is it a myth? I don't know.

------
jacquesm
Thinking is like 4 wheel drive. You still get stuck but in harder to get out
of places.

~~~
nowarninglabel
Which is why you learn to install a winch or have a friend handy with a
4-wheeler to pull you out. Having the right tools or right people to turn to
for help can get you out of almost any situation.

~~~
taneq
Precisely, and this is all the email is saying; that it's better to learn how
to use a winch or a snatch strap before you get yourself fully bogged.

~~~
protomyth
Side story: My Dad once worked for Pacific Bell in the 70's and they had
International[2] trucks with a winch. One night they need to go up an Oregon
mountain road in a blizzard to fix something[2]. They got stuck in the 4 wheel
drive and basically hauled the truck up the mountain road by using the winch
to pull it up. One would walk to the next pole or tree and then they would
pull the truck up. I guess they really needed to fix that thing right then.

1) A truck that was as impossible to destroy as it was hated

2) I never really heard what they were fixing, I did hear a lot of cuss words
referring to said item.

------
arethuza
I knew an _incredibly_ gifted developer who was CTO of a company I joined as
VP of Engineering. He was a genius level developer but didn't believe that any
of the normal rules of software development applied to him - so no backups of
product source code (which of course he wrote all the complex bits), no
revision control, no build process, deployments by RAID...

Just before I joined, the CEOs nerves had taken a bad hit when CTO had power
cable to only laptop with source for product stretched out at ideal tripping
height, he runs to get something, trips over cable, smashes laptop...

Mind you he destroyed my nerves as well... <sigh>

Edit: Prize to anyone who can guess how "Deployment by RAID" worked...

~~~
lmm
Stag machine has a raid1 setup, when it's time to go to prod you take out one
of the drives and put it in the prod machine? That would actually have some
quite good properties.

~~~
throweway
Staging?? What Bureaucracy!

~~~
arethuza
More like "spend money on a server that just sits around not earning money?"?
This was in the days before VMs or the cloud.

What if you only have on site production servers? :-)

------
draw_down
It is, shall I say, suspiciously easy to recognize oneself in this piece. In
doing so, you get to be gifted at the small psychic price of being cursed.
(For a narcissist, that's actually a win-win.) I submit as evidence most of
this comment thread.

Maybe not every one of us is a hugely gifted reserve of untapped potential.
Maybe some of us are just people with shitty habits and a reluctance to
change.

------
hnhamdani
This rings bell to me and I tried to applied it myself. "The importance of
fundamentals". Some of the hard parts are be honest to myself and admitting
it, then re learn everything from scratch. I used to be able to get away with
"instinct" but fundamental theory/knowledge is important too.

Pete Carroll preach about it and emphasize it in his team. Elon Musk also
talked about the usefulness of sound fundamentals when it comes to learn about
any fields of knowledge.

------
isomorphic
Linus' gifted-child problems aside, calling Linus out over a refusal to use
"systematic version-control" might have had some small role in causing Linus
to write Git, if for no other reason than spite. That alone makes this an
amazing email.

~~~
amboar
It was more that Tridge "reversed"[1] the Bitkeeper protocol, leading to
licensing issues and the eventual separation of Linux from Bitkeeper. The need
for a high performance, distributed replacement motivated Linus to write a
git.

[1] [https://lwn.net/Articles/132938/](https://lwn.net/Articles/132938/)

~~~
lmm
The license issues were there all along. Tridge just made it harder to ignore
them.

------
ktRolster
Does anyone know how Linus responded? I can't find it anywhere after a quick
search, and it doesn't seem to be on lkml.org

~~~
kluck
It seems that the contents are copy/pasted from a bunch of different messages.
Here is the list of messages from that day:
[https://lkml.org/lkml/2000/8/22](https://lkml.org/lkml/2000/8/22) .
Torvalds's responses are in there as well.

~~~
ktRolster
Thanks. Here are some fun Linus quotes from that day:

    
    
      > It's a stupid lie, and one we should ignore at all times it comes up.
    
      > Make good interfaces. THAT will reduce bugs.
    

Showing that Linus is abrasive, but he's also right.

~~~
jack9
Making "good" interfaces is subjective.

------
mianos
> "I still worry about what will happen if the complexity of the kernel
> exceeds the scope of your astonishing native talent before you grow up."

It never did and he never grew up. LOL.

~~~
insulanus
This is the true ending to that fairytale.

~~~
st3v3r
Is it? The kernel now has comprehensive version control, and is arguably more
modular.

------
ryan-allen
That was an epic read. I've only ever known ESR from his 'edge' opinions but
this email feels like a pearl from the wise.

He mentioned code sharing and using his inbox as a queue, was this pre-source
control? Stupid question, but does anyone have any context to what it was like
when this was written?

~~~
varjag
No, things like SCCS were already around in the 80s but not in the PC world.
At the time of writing though, it was common to use CVS, or if you were a
Windows shop, the soul crushing MS SourceSafe. Distributed version control
systems would not appear until BitKeeper.

------
known
Both of them have tons of ego.

------
0xdeadbeefbabe
Man they ought to call it the curse of the stupid everyone else.

------
aashu_dwivedi
for those who are curious the whole discussion thread can be read here
[http://markmail.org/message/kndbnthmmlai2ky6#query:+page:1+m...](http://markmail.org/message/kndbnthmmlai2ky6#query:+page:1+mid:2gklodigelhzd4pi+state:results)

------
pklausler
That's just one weird e-mail message, a mash-up of Uriah Heep and self-
aggrandized condescension.

------
jorgecurio
This kind of toxic snarkism fueled by fratboy within insecure adults produce
toxic working culture. Like literally shitting on anything the other person
says or does, makes a pretty tough environment to work together.

~~~
lumpypua
I really dislike the sensitivity to negative feedback that has become more
common over the past ten years. It used to be possible to communicate that
someone's behavior is harmful without being accused of literally shitting on
them.

ESR's email conveys strong negative feedback—as Linus needed—and in the most
deeply respectful and complimentary way I've ever seen in an "email rant".
Especially from ESR lol. It's very clear that he means it from a heartfelt
place and intends it to be productive.

If you read that email and feel snark from it, that's projection on your part,
and it speaks to an uncomfortability with criticism in your world view. You
might find life happier if you see that people give negative feedback not to
shit on you or snark, but because they care and want to see you succeed.

~~~
giancarlostoro
It's really hard to give any kind of critique that benefits someone without
them and everyone around them being offended. I always try to give advise
about what should be done instead of what is currently being done when I find
someone's done something highly inconvenient, sadly a lot of people take my
comments as "pooping" on them. It is not easy trying to help people who think
they're fully entitled to be higher than you no matter what. They would be too
good if they did receive feedback for self-improvement though I suppose? :)

~~~
humanrebar
> It's really hard to give any kind of critique that benefits someone without
> them and everyone around them being offended.

These days, now that people define themselves, people _will_ have their
identities wrapped up in the things they make and do. In that case, I'm not
sure there's a simple way to keep things from getting personal. That's a job
for a rabbi, priest, pastor, mentor, or counselor, not a boss or coworker.

See also: discussing politics, money, diet, weight, etc.

And, yes, I'm disappointed to come to that conclusion. It seems to mean that
we have to continually "handle", patronize, and manipulate people for the
greater good. I'd rather treat everyone with respect and transparency. I also
think I'm not particularly good at dissembling.

