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%.
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.
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.
My point is really that there is a huge mismatch between the value of problems and how people's time is allocated, and right now many people can benefit from learning how to identify the best problems.
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.
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.
> 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?
I like the idea of private offices that are shared among 2-3 people, as long as there is also ample lounging/social space. If the latter is not available, then open floor plan with headphones is preferable.
That changes around 10 employees. Once it becomes obvious that not everyone is going to be a real member of the team, people start spending more attention on their relative status within the company than the absolute success of it, and the hypervigilant bullshit that people typically associate with "work" begins.
Paul Graham, care to oblige us?
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.
Not realy just that the good hackers you mention decided Python fitted better to their specific needs.
That was one of the greatest things I have ever read.
You are welcome, dude.