3 ms·

I'm super skeptical of these articles about programmers with superhuman powers.

steego 7y ago
Maybe they're not superhuman? Maybe they applied their time, practice and attention to developing skills that have yielded very big returns?
jshaqaw 7y ago
I suggest reading the J interpreter Whitney wrote in a weekend and reconsidering! https://code.jsoftware.com/wiki/Essays/Incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum
- kuroguro 7y ago
  Writing in that style is not that hard, I do something similar if I need to make a prototype of something. The short variable and function names really save time as long as you remember what is what. Reading or debugging it even a week later is torture tho. Writing the interpreter in an afternoon is impressive but most likely he had done something similar before and had most of the algorithm in his head before he even began. You don't need to be superhuman to do that.
beagle3 7y ago
"Superhuman" hyperbole aside, some people are demonstrably orders of magnitude more productive than others, and that's true for almost any field of work (depending on your metric, of course - but that's true for some of the metrics that actually matter to most people), and programming is no different. Arthur Whitney, Fabrice Bellard, Linus Torvalds, Mike Pall are well known examples. It obviously requires a lot of skill, and I agree with [0] that it also requires the skill to be selective - some problems require a lot of work for which there are no "better ways". E.g. Mike Pall, alone and in short time, produced a JIT that runs way faster than V8 (which probably already had 100x more man-months[1] of really really smart people at that point). This amazing feat is a result of Pall's amazing talent - but it was only possible (IIRC, he said so himself), because Lua, although it is essentially as dynamic as JavaScript, made a few choices that made it much more amenable to effective JITting. [0] https://yosefk.com/blog/10x-more-selective.html https://yosefk.com/blog/10x-more-selective.html [1] I use it properly here as a unit of effort/cost, not as a unit of productivity.

Maybe they're not superhuman? Maybe they applied their time, practice and attention to developing skills that have yielded very big returns?

jshaqaw 7y ago

I suggest reading the J interpreter Whitney wrote in a weekend and reconsidering! https://code.jsoftware.com/wiki/Essays/Incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum

kuroguro 7y ago
Writing in that style is not that hard, I do something similar if I need to make a prototype of something. The short variable and function names really save time as long as you remember what is what. Reading or debugging it even a week later is torture tho. Writing the interpreter in an afternoon is impressive but most likely he had done something similar before and had most of the algorithm in his head before he even began. You don't need to be superhuman to do that.

beagle3 7y ago

"Superhuman" hyperbole aside, some people are demonstrably orders of magnitude more productive than others, and that's true for almost any field of work (depending on your metric, of course - but that's true for some of the metrics that actually matter to most people), and programming is no different. Arthur Whitney, Fabrice Bellard, Linus Torvalds, Mike Pall are well known examples. It obviously requires a lot of skill, and I agree with [0] that it also requires the skill to be selective - some problems require a lot of work for which there are no "better ways". E.g. Mike Pall, alone and in short time, produced a JIT that runs way faster than V8 (which probably already had 100x more man-months[1] of really really smart people at that point). This amazing feat is a result of Pall's amazing talent - but it was only possible (IIRC, he said so himself), because Lua, although it is essentially as dynamic as JavaScript, made a few choices that made it much more amenable to effective JITting. [0] https://yosefk.com/blog/10x-more-selective.html https://yosefk.com/blog/10x-more-selective.html [1] I use it properly here as a unit of effort/cost, not as a unit of productivity.