What really genius-level things has Fog Creek done? I remember demoing FogBugz, and it was marginally better than its competitors, but it was far from a complete game-changer. Trello is ok, but it's only marginally better than a whiteboard with post-it notes. None of these reinvent an industry, or provide something so outstanding that people rush toward it.
Don't get me wrong; I think Joel has a lot of good ideas in general, and Stack Exchange is indeed a game-changer. But as someone who continually talks about hiring "rock star programmers", I simply don't see a result that I'd consider "rock star" equivalent. But, maybe I'm missing something?
Edit: More than that, I don't even consider myself a rock star developer, just a normal developer who loves learning new things and getting a lot of stuff done. I'd be thrilled to work for a Google or Microsoft, but what would attract "rock star developers" to Fog Creek? Basically, are fancy chairs enough? Isn't the most attractive thing a super interesting problem domain?
There's plenty of rock star coding out there, of course. But it tends to be either hidden inside companies due to secrecy concerns (Google's scaling architecture or the NVIDIA driver stack, say) or exposed in the open source community instead of the startup world (Fabrice Bellard is a great example here).
Startups all say they want rock stars, but then they put them to work doing "better versions" of the same boring stuff we all recognize. Which, if you think about it, is sort of what startups are supposed to do.
I sort of snicker when I see startups post jobs looking for "rock star" coders [1]. What self respecting person would call him or herself a "rock star", let alone apply for such a position? Maybe it's just a gimmick to get mediocre developers to get to work on boilerplate web work..
[1] I also saw a job posting recently where they were looking for a coder "to work on hard problems and blow a hole through the universe"... Why not have them blow bullshit of their face while they're at it? Is this just HR trying to sound too cool, or what?
A huge class of such systems that are waiting to be created are crowd labor systems. How do you create leaderless organizations that produce what google or boeing or walmart produces and that compensates individuals for performance.
The answer today is a messy unorganized market system. Proper information systems that better organize that would create a lot of value. The analogy would be this site. Thousands of people communicating, without the organizing software it would be much worse (thousands of people standing around talking to each other, the good ideas spoken would not easily reach the top as it does in this organized software system).
tldr; the biggest value opportunities lie in CRUD apps, not the low level code
That might be a bit contradicting to what Joel is explaining. From what I've experienced first hand, there's programmers that can produce similar code/software in a week that takes 5 mediocre programmers to produce in a month. Those are extreme cases though.
There's not enough "rock star programmers" to go around, so not everyone can have a piece of that cake. Much of this is also very domain specific, it's not a given that a "rock star" game programmer is going to be a orders-of-magnitude better at developing business support systems. Finally, this is not that specific to programming. Not everyone's Einstein, Feynman or Michelangelo.
This idea that a single programmer is somehow so much better or superior may have its merits, but it's harmful to your overall business if you put all your weight on that single support.
You have to accept that above a certain number, your employees will fall on a bell-curve of ability, and you should support the efficiency and productiveness of the entire system, not depend on a few "rock stars" to drag it up with you.
Here are words I associate with Rock Star: driven (sure), but myopic, single-minded, selfish, unbalanced, and unfaithful. I say we strike it from the vocab.
In the rock star analogy, it'd be like getting the Beatles to write music for Justin Bieber fans, or getting Metallica to switch to the "easy listening" genre. That's not what you do with rock stars.
Made himself independently wealthy. Repeatedly (IE: Not luck).
Not that I disagree with you. But that is worthy of respect in itself. Also, there is an art to the very difficult task of making the difficult look simple and easy.
All success is based on luck to some extent. It's silly to argue otherwise. Of course there is skill involved as well.
To quote The Spolsk himself: "This paper is the ultimate rebuttal to those grumpy people who email me, barely able to conceal their disgust, saying, 'why do you need to hire such smart people to work on bug tracking software?'"
"Don't get me wrong; I think Joel has a lot of good ideas in general"
The saying that comes to mind is perhaps the following. "Those who can, do, those who can't teach." I'm guessing that Joel, by his writings, is a combination of the two and as a result his output is not "rockstar" quality.
Another example might be Steve Blank. Who no doubt achieved more fame as a teacher then he ever did creating anything.
There is obviously quite a value in people who can do both in varying degrees.
When I think of a rock star, I think of someone who not only produces stuff of quality, but actually changes the landscape of the industry. If FogBugs hires 40 rock star developers, I'd expect to see a lot more come out of them than products all in crowded spaces. While they are all quality products, they aren't changing the landscape of the industries involved.
And you know what? It's all about the same. It comes down to things like being respected, challenged, engaged, and working with people you like being around.
If Spolsky were to go slumming it and open an office in my town, I would be first in line to apply to work on FogBugz, and I don't care about the fancy chairs.
- god this is long. Isn't it ironic that a superstar programmer would have been bored by now and stopped reading.
- momentarily after that, I guess I just admitted that I'm not s superstar programmer.
- momentarily after that, I wonder if there are writers who can transmit ten times as much information using one tenth of the words.
- just now, I imagine magazines don't want superstar writers. That would diminish the amount of ad space they could sell.
I tend to do this somewhat subconsciously when I start to realize the content is sparse.
I'm reading it right now and, if nothing else, can totally relate to "I can't concentrate on things very well anymore" feeling.
I like how Carr's own sentiment mirror the sentiment of people who thought books will stop people from remembering things. And he wants us to return to books?
For example Paul Graham's essays are often very insightful, but they are frustratingly long. The core idea, which is the only reason why I am reading the essay, can be summarized into 1 - 3 sentences. The rest is just a boring extrapolation and repetition of that.
First time PG has been denounced for verbosity?
This suggests to me that the biggest influences on productivity for the organisation as a whole are probably to do with collaboration, culture and environment rather than extraordinary individual skill.
Maybe the very best programmers aren’t extraordinary just because they can solve the most difficult problems, but also because they are better at presenting their solutions in ways that are more accessible to other developers. That would have the twin benefits of improving productivity in its own right and of implicitly teaching by example so less experienced developers in the organisation would tend to develop the same skills themselves over time.
If you had a seed of programmers on that level and a culture that promoted mentoring, pair programming, code reviews or similar collaborative exercises, it’s not hard to imagine that such an organisation would develop significantly higher collective performance over time than another organisation without those benefits, even if most people joining each organisation were of a similar level of skill and experience to start with.
Not a complete understanding, just a basic idea.
This is why mediocre programmers are what they are---they lack this ability and end up "flailing around", looking at somewhat random issues, bouncing back and forth, unable to see the pattern, and so end up spending more time writing code that eventually has to get rewritten.
A great programmer will systematically take a problem apart so that even if they don't solve a problem in one minute, they've at least narrowed down the window of options for the future.
This is also why great programmers are always great debuggers.
For me, there are days of brilliance and days of complete distraction. I won't call myself a 10xer but I think much of my success has come because I truly love what I do.
EDIT - I couldn't find a reference to the study I was remembering, but Steve McConnell of "Code Complete" fame has written a blog post describing how flawed the studies he's reviewed have been - http://forums.construx.com/blogs/stevemcc/archive/2011/01/09.... There are links to a lot of interesting sources and he clearly isn't arguing against the idea of dramatic differences in programmer ability ... just sayin'.
Can I pay attention to the details without losing sight of the big picture?
Can I do a good job technically, but keep within any other project constraints like budgets and timescales?
Can I write code that is good enough to ship tomorrow, but maintainable enough to work on again next year?
My best work tends to get done when I figure out the right balances. If I let one aspect become too dominant and neglect something else as a result, that’s usually when the problems start.
This requires a high level of aptitude and experience (which comes with practice).
However, I feel the ability to write quality code quickly is just one facet of a great programmer's skillset.
Often overlooked is the ability to communicate and collaborate with others effectively--which is just as important.
With complex projects, I oftentimes find that the solution to my problems has already been solved. Sometimes the best code is no code at all.
I would argue that this presents several sub-skills:
Being able to do this quickly b/c you don't have to spend the time learning
Being able to do this effectively -- by not painting yourself into a corner b/c you well versed in best practices and anti-patterns with using said 3rd party technology
Being able to do this smartly -- because you are well-versed in a lot of the different options, you can effectively way their pros/cons, and make smart decisions on which 3rd party stuff to use, and when to build vs. buy
I think these skills are more effective (towards your end goal) than simply being able to quickly code some brilliant labyrinth of an algorithm in less SLOC than a 1 or 2-xer. I feel like the emphasis is always put on the latter, and these skills are overlooked.
Combine these with effective communication, and then you are talking about someone who can get things done.
That type of agility is hugely helpful in an organization.
(Still, working is more important than talking about it.)
Some people have objected to the "10x" label, making an argument like "We had a super programmer on our team once. He was so obnoxious he alienated the whole team, and overall productivity was actually better without him.
In general, any practical definition of a real 10x programmer has to include the effect the programmer has on the rest of the team. I have known super programmers who were obnoxious. More often, a supposed super programmer with an obnoxious personality was really an average programmer, or worse than average, using an obnoxious personality to hide a lack of performance. The true super programmers I've worked with have generally also been cooperative team players, although of course there are always exceptions."
Taking his blogs at face value, and assuming that my sample size of 1 is enough, here's what I've got:
"Superstars" get things done because they get things done. They may be ADD in their multitude of projects or in their personal lives, but while they're producing, they produce. They don't fuck around on reddit while they're coding. They might screw around interminably at other times - they might work only a few hours a day - but while they work, they're working, and that's it.
They also get things done because they understand what the hell's going on, at least one or two layers of abstraction below the one they're officially working on. Stevey claims that his understanding stops at transistors - transistors are black boxes, but he gets what has to happen at the layers of abstraction above that, from the machine code to the guts of the interpreter.
Particularly delicious? Steve Yegge worked at Geoworks (http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st...), and he attributes their defeat by the likes of Microsoft not to superior marketing, but to the value of abstractions.
http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
10Xer imples 10X some base level. Depending on what base you choose, Yegge can easily fall short.
I "worked" on Wyvern in high school (in that I played a lot of Wyvern and made a few terribly shitty game areas and ended up being an administrator, or "Wizard" in classical MUD parlance).
You know how Dwarf Fortress, that ASCII game, simulates a whole lot of ridiculous detail? Over-the-top, "the goblin's spear strikes the baby dwarf in the back upper left tooth and it really hurts so he cries for mommy"? Wyvern didn't quite have that, but the API implied most of the functionality for it.
You didn't have inventory slots, you had body parts, which brought with them the ability to wear or wield certain other items.
You could've written Wyvern in a much simpler fashion. A bright high schooler could make a game that had all of Wyvern's functionality at the end of its life. It's the mountain of "do a lot of other shit later" that got in the way.
And that's what he's writing about in that blog post - not that he's perfect and Java sucks, but that he was trying to employ industry best practices and make everything perfect without compromises. It's not very hackerish, and sure, it was stupid. But the guy wasn't doing this for his day job and didn't have defined deadlines. He was a programmer, in other words, not a project manager.
And that's where he fell down. Project management, not programming. And if you read back through his massive wall-of-text blog archives, you can see him mature as a programmer and project management.
(Please note that I am an avowed fanboi, if you didn't catch that already, and as such everything I say must be taken with a grain of salt.)
"How strong is the support conferred to the 10x claim by the best-reputed list of references, for a reader persistent enough to follow the chain of citations back to primary sources?
"Based on our close reading of the “10x files”, we can now answer: quite weak.
"Not a single one of the references is to a replication, in the scientific sense of the term, of the original exploratory experiment.
"The empirical data is in general quite old, most if not all of it predating widespread use of the Internet - which we can safely expect to have wrought major changes in programming practice.
"None of the studies address the question of construct validity, that is, how meaningful it is to speak of an individual programmer’s productivity, and if it is meaningful, whether the experimental measurements line up adequately with that meaning."
Don't get me wrong--I've certainly seen 10x (and greater) variations in productivity. But they've been due to factors other than inherent individual capability. They're things like
* technical debt
* familiarity with the codebase and problem domain
* interruptions, distractions, multi-tasking and other office environment issues
* choice of language - but this is a distant fourth compared to other the other three
On top of all this, the Economist article is a thinly-veiled press release for tenXer, which is itself nothing more than an exercise in testerone-fueled egotism. tenXer measures activity, not productivity [2], and I expect the primary result of increasing your tenXer metrics will be less time thinking, more time hacking, and insufferable smugness.
[1] The Leprechauns of Software Engineering explores what science is and how we distinguish between fact and folklore in software engineering. It specifically explores the 10x claim, and determines that it's folklore. http://leanpub.com/leprechauns
[2] Productivity is defined as output over input, and the output of programming is software capability. No one's come up with a good measure of that yet. So any time someone claims they can prove increased productivity, ask them how they measure it. Chances are good you'll get a bogus value that measures activity instead, such as "lines of code." http://martinfowler.com/bliki/CannotMeasureProductivity.html
They found 10x differences in time spent on the average coding war (which was typically a pretty small sample) with those finishing faster typically producing programs that worked better. So by any reasonable measure, at least 10x productivity.
There is your 10x, right? Wrong. They found that the best predictor of programmer performance was the performance of another programmer at the same company. Furthermore they managed to correlate a lot of that performance factor to specific factors, such as having a phone that turned off, a private room, adequate desk space, and so on. There was still something like an unexplained factor of 3 left over, but they didn't know whether it was environment variables they had not looked at (eg training), individual ability (which might be correlated across institutions), etc.
It is true that this research happened in the 80s, before the Internet was widespread. I would love to see it replicated again.
(Note, I'm aware of the existence of many other poorly controlled studies, see http://www.flownet.com/gat/papers/lisp-java.pdf for an example, but what is critical in the Peopleware study is that they acquired information both about productivity and about factors that might cause productivity differences.)
I will jump the shark and speculate that these gel-members tend to be female more often than male, and the gelling-like effect comes from how their presence and patterns of behavior influence the group dynamic. I will further speculate that the dearth of women in development incurs a hidden cost to productivity, since statistically, fewer teams will have women, and consequently, the incidence of gel-members will be lower, and teams more fragmented.
I think there is a business opportunity here somewhere, or maybe it has already been realized in places, but the players have not been eager to trumpet their results.
1) Small.
2) By themselves.
3) Well understood and documented.
4) Doesn't have any threat of changing out from under them.
In the real world, the bottleneck usually isn't writing code, it's writing code that does the right thing and making the right people happy in the right way.
In some ways, trying to apply the lessons from Peopleware in the real world is like using your knowledge of unicorn anatomy to predict the Kentucky Derby.
Most developers suck at programming (and that's actually OK). 90% of the code they write is copy and pasted from elsewhere in the codebase or from the web, and then tweaked until it does something approximately correct. They usually need help when solving a new pattern of problem. What they do often have is domain knowledge not related to programming, and produce just about acceptable results out of the machine in a labour-intensive way that doesn't really scale over time or problem size, but they muddle through with determination.
I don't know about a 10x productivity differences though. I'm not really arguing in favour of that hypothesis. Rather, if anything, I've seen step differences in potential; that is, there are developers that can do things other developers can never do, not in 10x the time, not in 1000x the time.
I don't entirely disagree with you, but watch out for the Fundamental Attribution Error: http://en.wikipedia.org/wiki/Fundamental_attribution_error
I think the 10-50x observed increase in productivity is task specific. But, people also deal with a finite list of specific problems so what if bob is 2x as productive on random tasks if there is 10 years worth of work where he can be 10x as productive he is worth a lot more than the average programmer.
I haven't read the ebook you're advertising, but a book with an identical pitch, Robert Glass' Facts and Fallacies of Software Engineering, is an example. The difference between his facts and fallacies is that the "facts" tend to have one poorly controlled, never replicated study (usually from 1978) to their name. Better than nothing (maybe), but close to nothing.
My point is that at this stage in history, it's all still folklore. Even you, immediately after playing the science card, followed with mushy folklore of your own ("I've certainly seen...").
Edit: come to think of it, your quotes make it sound like there is empirical evidence for the 10x claim, just that it's old and wasn't replicated. The "old" criticism is weird; it's not at all obvious that the internet invalidated the data. So the critique seems to boil down to: there was a study, but it wasn't bullet-proof and it wasn't properly replicated. What studies of software development isn't that true of?
I'll admit to being guilty of using anecdotes to describe my experiences with software development. (That's not quite the same as folklore, but whatever.) You won't find me claiming that my anecdotes prove anything, though, and I try to be clear that my perspective is based on experiences, not objective truth.
[1] For example, this comment three years ago on reddit: http://www.reddit.com/r/programming/comments/7dkjx/rescuing_...
I'm immediately suspicious of the statement you quoted: "Not a single one of the references is to a replication, in the scientific sense of the term." Strict replication is not and never has been a requirement to good science. As a trivial example, how do you replicate a supernova observation? You can't. But you can make models and test the models against the observed data and against future supernovas, and you estimate the reasonableness of the model effectiveness.
If that quote is indicative of Bossavit's views, then he is a poor judge of what's good evidence.
Going on with more quotes you gave, "which we can safely expect to have wrought major changes in programming practice." That is a conjecture, not a statement of fact. It seems like he's saying that once upon a time there was 10x difference, but the Internet makes everything different now there isn't. However, without evidence to back it up, I don't know why I should believe it.
What tests has Bossavit carried out to show that this is the case?
To the contrary, L. Prechelt "An empirical comparison of C, C++, Java ..." was both carried out during the internet era, was done with good rigor, and shows a large spread in the overall time to complete the project. That's a small project, granted, but it's another data point in the overall trends.
(If you don't like the small project size, another example, given by McConnell, is the large productivity difference between the Excel and Lotus 1-2-3 teams, which produced roughly comparable spreadsheet programs but with about an order of magnitude productivity difference across several different metrics.)
Multiple independently determined data points which all trend in the same direction strengthen the likelihood that the ~10x hypothesis is a useful model. That's what scientific evidence looks like.
McConnell even has a section in his chapter on "how meaningful it is to speak of an individual programmer's productivity", along with all of the caveats and cautions that everyone here is bringing up (some programmers produce negative lines of code, the best programmers tend to get the hardest problems, the effect of teams, etc.), and concludes "So while I see the value in measuring individual performance in research settings, I think it's difficult to find cases in which the measurement effort is justified on real projects."
Edit: I see that Bossavit wrote in response to McConnell's chapter. McConnel's reply to Bossavit is at http://forums.construx.com/blogs/stevemcc/archive/2011/01/09... .
Rather than try to defend someone else's words, though, I'll just direct you to the book. You're going into a lot of detail critiquing quotes from an end-of-chapter summary, which isn't fair to Bossavit's work. I hope you'll read the book, because I'd like to hear your critique of the full work.
"Within individual firms, the difference in performance was only 20% or so."
Is this because good developers congregate together, as suggested, or because having at least one good developer raises the productivity of those around him or her? They can certainly influence an organization through their choice of platforms and tools, aiding the productivity of everyone on the team.
Also, taking advantage of existing software makes a huge difference in 'productivity' at least as far as business people can measure. And someone who does that without acknowledging that they are doing it may appear to be a 'superstar' to management.
For example, someone may just consider all of the source code they have ever written, regardless of the circumstances they wrote it in, to be a code library they can copy and paste in whatever company they currently work at. And not even acknowledge that they are reusing code they wrote years ago.
So that sort of dishonesty irritates me, but generally I think taking advantage of existing software is the right thing to do and is the number one factor in what non-technical people would perceive as productivity. There is a huge difference in the time required to build a system using an easily configurable base like WordPress with plugins or components or by integrating open source software or libraries versus building various parts or all of the system from scratch.
That's where you will see orders of magnitude difference in productivity where one person or group is reinventing a bunch of wheels that another group is not. And again there are many different ways of avoiding reinventing wheels, from using Google to basing software on existing open source programs to selecting more practical application programming languages/tools (like ones with things like garbage collection or more straightforward syntax or support for interactively configurable graphical components/plugins), or for example doing test driven development or in general having any type of automated QA rather than relying on a manual QA process entirely.
Whoa. Either I'm a worst programmer or this is clueless.
http://plus.google.com/110440139189906861022/posts/84784VhCm...
"An outfit in San Francisco called 'tenXer' has begun testing a service that aims to help people boost their mental accomplishments by up to tenfold—hence its name. . . . "
. . . .
"For those wishing to have a go, tenXer
in San Francisco is currently offering a beta version of its tracking software to help people analyse their own performance, set goals for themselves and improve their lot. At present, the tracking software works only for programmers. But down the road, the same techniques could just as readily be applied to other occupations. . . . "
The great thing about this is that many of us on Hacker News can put the claim to the test. Commenting on the claims of tenXer, which is what the writer for The Economist and several of the commenters here on Hacker News are doing, is interesting, and trying this out and seeing whether or not it works might be even more interesting. It's still unclear how much most individual human beings can improve themselves if they apply effort to self-improvement. It might be a good opportunity for career development for many HN participants to try this out.
For the record I've worked with EPOC-32, Windows, NextStep, Linux, VxWorks, and Nucleus - none of them was as painful as PC/GEOS (although EPOC-32 sometimes came close...)
In any case, superprogrammers != super marketplace conquerors, and IMO should not be judged as (un)impressive on that metric.
So much for moving up in the world.
i'd argue that individual contribution to any given project of substance is greatly overestimated, while contribution of the team (organization/culture/whatever) is unfairly underestimated.
even in professional sports, superstar a winning team does not make.
Another study in the book "Imagine" by Lehrer Jonah implies that creativity depends on the Q factor, inside a group. Here is a quote: "Uzzi’s data clearly demonstrates that the best Broadway shows were produced with intermediate levels of social intimacy. A musical produced at the ideal level of Q (2.6) was two and a half times more likely to be a commercial success than a musical produced with a low Q (<1.4) or a high Q (>3.2). It was also three times more likely to be lauded by the critics."
I can see how hiring only rockstars which probably knew each other would increase the Q beyond the ideal level.
