
Great Hackers (2004) - olalonde
http://paulgraham.com/gh.html
======
benjaminwootton
Please add (2004) to the title.

Nobody understand and articulates what hackers want better than PG, and its
great that he benefits from this via YC.

In a way this is similar to Joel Spolskys view of the world of optimising for
programmer hapiness and enjoying business success as a side effect.

The genuinely optimal setup for me in terms of work quality and volume would
be unrecognizable the average corporate job. For instance, choosing my own
working hours and tools would improve my output by 25%.

~~~
michaelochurch
_For instance, choosing my own working hours and tools would improve my output
by 25%._

I'd be surprised if it weren't _250_ percent. Corporate environments optimize
for responsiveness, not productivity.

People talk about programmers being "overpaid", but I think we're underpaid,
at least at the top end, and I think we suffer for it in more ways than the
obvious one. We work under conditions where we produce at 10% of what is
possible. That's because a good engineer's _potential_ ABV (abstract business
value) is well into the millions per year, so if we perform at 10 cents on the
dollar, we still make a profit for our employers. If our salaries went up 3x,
there'd be fewer of us, but we'd probably have a lot more autonomy and better
working conditions, because it just wouldn't be economically feasible to put
us in noisy offices, give us crappy tools, and have 90 percent of our time get
eaten up by maintenance, meetings, bureaucracy, and distraction.

~~~
jeremyjh
Most businesses are incapable of getting millions of dollars of value from a
programmer because of the work that they assign them to do. As Paul points
out, the biggest potential variation is in deciding what to work on.

~~~
michaelochurch
Right, and this is my fundamental issue with the software industry. If we were
paid 2 or 3 times as much, we'd be assigned to do higher-impact work. The
reason 90% of software engineers are assigned to bullshit is that our
compensation is so _low_ that it can make economic sense to put us on the sort
of low-impact stuff that companies never have the sense to drop in favor of
more ambitious, more interesting projects.

Since the 1960s, we've been approaching (but waveringly, with backward motion
from 1973 to 2008) what some call the "Singularity", but it's actually a more
prosaic shift: a movement from the late industrial era (3-6%/year economic
growth) to a technological one where 10%/year (or better) growth is not out of
the question. The first sign of it is what I call the _convexity switch_. The
input-output curve of a worker used to be concave, with the A-players
producing 120, your B's producing 110, your C's at 100, your D's at 60 and
your F's (slackers) at 0. Intimidation-based management and closed allocation
(which are performance-middling, bringing down the best and up the worst) made
sense in a time where one slacker cancelled out 2-5 A players (relative to the
C standard). But we're moving into a different era where that curve is convex:
your A's produce 1000, B's produce 250, C's produce 50, and the D's and F's
produce virtually nothing. The traditional, mediocrity-oriented management
model used by MBA programs, McKinsey, and typical software management doesn't
work anymore, and no one (except, perhaps, the leaders of Valve and Github)
has any clue what to do.

The issue for us is the expectancy-variance trade-off. The effect of "lean"
management post-1975 was to make individual managers (and workers) more
accountable for local performance, the result being that no one was paying
attention to global, company-wide concerns. Everyone started becoming a lot
more careerist, job tenures decreased, et cetera. People optimized for local
performance and especially for low variance, because underperformance is
punished more severely (firing) than high performance is rewarded (usually,
small bonuses, if the high performance is noticed at all). Bosses no longer
worked for "the company" or were rewarded for abstract contributions that make
the whole firm a better place, but instead were measured by _their_ bosses,
and on a tight timeframe. It became more about "individual accountability" and
less about actual value creation. The results favor low-variance work. In a
concave world, this actually works very well, because low variance is observed
at the top of the output curve. This means the work is reliable and meets
expectations, and the interchangeable parts fit together well with no
surprises. But in a convex world, the top of the output curve is more _highly_
variable, so the result of low-variance management strategies is abysmally low
bulk output. It doesn't _look_ abysmally low-- software engineers are still
contributing $200-400k per year of business value-- but it's terrible in
comparison to what would be possible if the allowance for variance were
higher.

~~~
theorique
Are there even that many high-leverage problems available though?

~~~
SatvikBeri
At most places I've worked, if my assigned work contributed $x to the bottom
line, the side problems I chose to work on contributed $10x-$20x. There are so
many high-leverage problems out there that it's frankly ridiculous.

~~~
tmorton
It sounds like your real contribution isn't solving high-leverage problems,
it's identifying high-leverage problems. This is a rare skill, no matter how
obvious they seem to you.

~~~
michaelochurch
Implement open allocation and it becomes not-so-rare.

~~~
theorique
Isn't that how Valve does it? I seem to recall some articles here about
that...

~~~
SatvikBeri
Valve, Github, and Gore & Associates all use open allocation or something very
similar. Gore & Associates is particularly interesting because they are a
large company and have basically proven that this model can work at scale
(~9000 employees).

------
chmike
A very refreshing reading to which I fully agree and recognize my self as a
hacker now such in a shit job for years. I don't know if I can recover from
that since I'm getting 50. I'd love to try working on interesting and
challenging problems again.

At 15 I built my own computer, at 17 implemented a disassembler for 6502
processor with pokes, and at 19 the symbolic assembler still with pokes. These
where saved with tape recorders at the time. At that time I bought a book
containing the raw disassembled listing of the ORIC Atmos Basic 'OS'. I spent
my free time finding out what each function did and documented it, as fun. It
felt like what decoding ADN and genes might feel today I guess. Pure hacking.
etc.

The reason I "failed" is the lack of entrepreneurial culture in my family and
educational context, or meeting a lucky opportunity. There was no Internet at
the time which would facilitate meeting other hackers.

My advise based on my experience, is if you feel like matching the hacker
description of Paul Graham in this essay, go run to find and join other
hackers, ASAP !!! Start with open source projects for instance which didn't
existed in my time.

If you don't do that you'll suffocate and get crunched under the pressure of
"mediocracy". It's a concept I had plenty of time to develop based on the
analysis of my working context. Maybe one day I'll write an essay about it.

~~~
japhyr
I can relate to this perspective. My parents encouraged me to try a number of
things when I was young. They encouraged me to read a lot, to get outside, to
challenge myself. But every time I started to get really good at something,
they encouraged me to back off, often in very subtle ways. I think they were
afraid of real success, or afraid of a big failure on my part. It took a long
time to recognize this, and a long time to fully break away from this.

My father was a software engineer from the 70's-90's, and he passed away last
year. It was really sad to go through his computer, and see the project which
he'd been working on in his retirement, knowing it would never see the light
of day. He never learned the "release early, release often" concept.

The positive side of this is the new motivation I have to make sure I finish
projects. I do not want to watch my technical skills go to waste. This is
especially important to me, because my day job is teaching, not programming.
So all of my programming consists of side projects, the easiest things to
leave unfinished. It also inspires me to not fear my son's failures, in fact I
want to teach him that you have to fail in order to succeed significantly.

Some of my heroes in life are the programmers who have remained relevant
throughout their entire lives. It's interesting growing older. I am just as
impressed by technology as I was when I was a kid, but I am much more focused
on what we do with that technology.

------
peter_l_downs
> The mere prospect of being interrupted is enough to prevent > hackers from
> working on hard problems. If you want to get > real work done in an office
> with cubicles, you have two options: > work at home, or come in early or
> late or on a weekend, when > no one else is there.

> They get new technology by buying the startups that created it > \-- where
> presumably the hackers did have somewhere quiet to work.

It's funny -- all the startups I know have embraced open floor plans, and the
culture of coming in late and on the weekends. My sample size is pretty small,
though (n=2); what are your offices like?

~~~
capisce
Open office plans seem to be considered "hip" these days. The fact that it's
cheaper probably also makes it easier for the founders to ignore the lessons
from Peopleware.

~~~
michaelochurch
Open office plans are "hip" because they show that you're in access to the
anti-anxiety drugs you need in order to survive one.

------
whelps
Thank you olalonde for posting this. It comes at a perfect time for me as I am
in the process of evaluating my own career and this article hits the nail on
the head in so many ways. I work for a non-technical CEO at a small startup
and perhaps I am not a great hacker (as Paul says, 'I don't know'), but I do
know that the non-tech CEO - hacker relationship is one fraught with peril
regardless of how good "friends" the two people are outside of work.

------
throwaway467
I wish people/mods would add dates to PG's articles - I can never tell whether
it's a new one or just something from the archives. Still interesting though.

------
grantph
Okay... 2004 and now it's 8 years later. I'm curious to know what PG thinks of
great hackers after 500 startups and plenty of exposure to would be hackers.
Surely his thoughts have matured?

Paul Graham, care to oblige us?

------
jeremiep
While the article is excellent, it is wrong on one point. Edison didn't invent
anything at all; Tesla is responsible for most inventions credited to Edison
today. The world could definitely do with as little Edisons as possible, what
the world really needs are more Teslas.

~~~
s_henry_paulson
While I appreciate Tesla as much as the next person, the statement that he's
responsible for "most" of Edison's inventions is wholeheartedly not true.

Edison is still seen as being largely responsible for things like the
phonograph and kinetoscope, the pre-cursors to modern music and television, as
well as hundreds of other inventions in other areas that Tesla never touched.

~~~
JoeAltmaier
Yes; Edison invented some toys. Tesla invented the modern industrial power
complex, almost wholly from his own head. You almost have to think he was a
time traveler or alien or something, to get thousands of details exactly right
to propel a civilization into the electric age.

------
melc
>Though, frankly, the fact that good hackers prefer Python to Java should tell
you something about the relative merits of those languages.

Not realy just that the good hackers you mention decided Python fitted better
to their specific needs.

------
pootch
Dude,

That was one of the greatest things I have ever read.

~~~
huhtenberg
<http://paulgraham.com/articles.html>

You are welcome, dude.

------
jasongaya
benjaminwootton agree with your opinion what do you think for new start-up?

