This article proves my thesis about superproductive programmers: that they (i) don't write user interface code and (ii) don't work for non-programmers. A third advantage he has is that he's largely working alone or in small volunteer teams.
A major source of "unproductivity" for applications programmers is rework. A lot of rework comes from poor specifications and from the essential difficulty of creating user interfaces. To get usable user interfaces it's generally necessary to try a number of things that don't work. You certainly can build one prototype, set a stingy budget, and timebox it, but odds aren't good that real people will actually stick with the product.
Another issue in commercial applications development is the NNPP's (Net Negative Productivity Programmers.) You'll have one on your "team" or you'll be maintaining code written by one. Either way, they'll sap your productivity.
Adding up these unproductivity factors you can find 80% of your time disappearing... And that this point it doesn't matter if you're a genius or an NNPP yourself... You're not getting much done.
Of all the programs, only QEmacs has a substantial user interface. And in that case, the user interface was largely specified in advance -- the folks at MIT did a great front-loaded job of user interface design for emacs and we've accumulated a huge amount of experience with emacs-derived.
A lot of programmers are intimidated by math-heavy systems programming, but once you get over the hump, it's easy to be productive. In projects like linmodem you're certainly going to have to deal with BS from hardware vendors, but it's nothing like applications programming.
I was a bit disappointed that the article didn't really say much that you couldn't grok from glancing at his Wikipedia article and reading something like The Mythical Man-Month. I was hoping to learn more about him-- how does he separate his work and personal life? How does he make money? What are his goals? How does he focus?
I'm the author of the article. I, too, was disappointed that Mr. Bellard chose not to answer questions. I could have investigated him more deeply with more interviews of others; I chose, for this time, to respect his modesty and not do that. Perhaps there'll be an occasion in the future for a different treatment.
A major source of "unproductivity" for applications programmers is rework. A lot of rework comes from poor specifications and from the essential difficulty of creating user interfaces. To get usable user interfaces it's generally necessary to try a number of things that don't work. You certainly can build one prototype, set a stingy budget, and timebox it, but odds aren't good that real people will actually stick with the product.
Another issue in commercial applications development is the NNPP's (Net Negative Productivity Programmers.) You'll have one on your "team" or you'll be maintaining code written by one. Either way, they'll sap your productivity.
Adding up these unproductivity factors you can find 80% of your time disappearing... And that this point it doesn't matter if you're a genius or an NNPP yourself... You're not getting much done.
Of all the programs, only QEmacs has a substantial user interface. And in that case, the user interface was largely specified in advance -- the folks at MIT did a great front-loaded job of user interface design for emacs and we've accumulated a huge amount of experience with emacs-derived.
A lot of programmers are intimidated by math-heavy systems programming, but once you get over the hump, it's easy to be productive. In projects like linmodem you're certainly going to have to deal with BS from hardware vendors, but it's nothing like applications programming.