3 ms·

Wow, I'm amazed how few people seem to be reacting the blog post the way I read it. Did the text change? His argument isn't about good or bad programmers, it's

by neilk 16y ago

Wow, I'm amazed how few people seem to be reacting the blog post the way I read it. Did the text change? His argument isn't about good or bad programmers, it's an observation about programming: the annoying stuff can't be automated. Good programmers automate whenever they can. Therefore, the author believes, annoying stuff will eventually dominate their whole day. Maybe your Ruby on Rails, or Scala on Snowshoes, or whatever, framework makes it trivial to create a functional site from twelve keystrokes. That just means most of your day is spent in customer meetings, gathering specs, and fixing obscure bugs. There's some truth to this, but I also enjoy designing and communicating, which are also non-automatable. Perhaps the author doesn't like that stuff, but if so, that's sad. And there are always ways to automate more and more; you may have to leap to a different paradigm to capture the essence of truly thorny problems, but this should be fun for a good programmer.

aamar 16y ago
Good point; I think this is the right response. The author is making a good observation, but I'd suggest tweaking the statement of the paradox: "An increase in programmer skill will increase the fraction of programming time spent doing work that he or she hates, using tools and technologies that he or she also hates." This version reduces the suggestion that the paradox is a definition of a good programmer. Both my statement and the original accept at face value that programming skill leads to automating more successfully. In my experience, this paradox is frequently, but not always, true depending on the programmer's temperament and situation. This 2x2 illustrates: | Automatable | Not automatable | Pleasurable | Game/"Sudoku" | Deep problems | Unpleasant | Busywork | Frustration An increase in programmer skill means shifting time from column 1 to column 2, while not necessarily keeping it in the same row. That means a happy decrease of busywork but also the loss of what I think of as Sudoku-work, the technical work that feels sort of fun and pleasant mental exercise, but work that can be easily automated or obviated given a decent language/working-environment. Sudoku-work is technically productive, in a way, but certainly not optimally valuable. The paradox is based on the theory that Sudoku-work time is lost and turned into frustration time. But there is a way out, one that seems partially fixable via programmer mindset: deconstruct frustrating work into busywork (and automate it) and deep problems -- the latter including deep technical problems as well as gaining insight into clients/users, design, and so on. edit: minor clarification, punctuation fix
- neilk 16y ago
  Whoa, excellent insights. This could be an essay on its own. The ability to enjoy Sudoku-work is something of a defining characteristic for programmers, too. There's a certain overlap here with the theory of "Flow": http://en.wikipedia.org/wiki/File:Challenge_vs_skill.svg http://en.wikipedia.org/wiki/File:Challenge_vs_skill.svg http://en.wikipedia.org/wiki/Flow_%28psychology%29 http://en.wikipedia.org/wiki/Flow_%28psychology%29 It seems to me that programming is special, because repeated tasks tend to be automated away. If you ever achieve Flow doing one task, you'll never achieve Flow there again because you won't need to.
Periodic 16y ago
For me, the fun part is in getting something to work! I love seeing an elegant solution come together. I love seeing all my tests pass. I love looking at two problems, seeing they are the same, and factoring out the common parts. I hate busywork and boilerplate because they make it take longer for me to get to the stuff I love. They require effort in addition to what is actually required to express my solution to a problem. I don't love coding, I love making things with code. The faster I can do that, the better. The more efficient my tools get, the happier I am.
Lennie 16y ago
Sounds like what Edsger W. Dijkstra said about higher level languages, something along these lines: higher level languages are supposed to make things easier, instead they make it more difficult. You can automate all the mundane tasks away, all that is left are the complicated parts.

by neilk 16y ago

aamar 16y ago

Good point; I think this is the right response. The author is making a good observation, but I'd suggest tweaking the statement of the paradox: "An increase in programmer skill will increase the fraction of programming time spent doing work that he or she hates, using tools and technologies that he or she also hates." This version reduces the suggestion that the paradox is a definition of a good programmer. Both my statement and the original accept at face value that programming skill leads to automating more successfully. In my experience, this paradox is frequently, but not always, true depending on the programmer's temperament and situation. This 2x2 illustrates: | Automatable | Not automatable | Pleasurable | Game/"Sudoku" | Deep problems | Unpleasant | Busywork | Frustration An increase in programmer skill means shifting time from column 1 to column 2, while not necessarily keeping it in the same row. That means a happy decrease of busywork but also the loss of what I think of as Sudoku-work, the technical work that feels sort of fun and pleasant mental exercise, but work that can be easily automated or obviated given a decent language/working-environment. Sudoku-work is technically productive, in a way, but certainly not optimally valuable. The paradox is based on the theory that Sudoku-work time is lost and turned into frustration time. But there is a way out, one that seems partially fixable via programmer mindset: deconstruct frustrating work into busywork (and automate it) and deep problems -- the latter including deep technical problems as well as gaining insight into clients/users, design, and so on. edit: minor clarification, punctuation fix

neilk 16y ago
Whoa, excellent insights. This could be an essay on its own. The ability to enjoy Sudoku-work is something of a defining characteristic for programmers, too. There's a certain overlap here with the theory of "Flow": http://en.wikipedia.org/wiki/File:Challenge_vs_skill.svg http://en.wikipedia.org/wiki/File:Challenge_vs_skill.svg http://en.wikipedia.org/wiki/Flow_%28psychology%29 http://en.wikipedia.org/wiki/Flow_%28psychology%29 It seems to me that programming is special, because repeated tasks tend to be automated away. If you ever achieve Flow doing one task, you'll never achieve Flow there again because you won't need to.

Periodic 16y ago

For me, the fun part is in getting something to work! I love seeing an elegant solution come together. I love seeing all my tests pass. I love looking at two problems, seeing they are the same, and factoring out the common parts. I hate busywork and boilerplate because they make it take longer for me to get to the stuff I love. They require effort in addition to what is actually required to express my solution to a problem. I don't love coding, I love making things with code. The faster I can do that, the better. The more efficient my tools get, the happier I am.

Lennie 16y ago

Sounds like what Edsger W. Dijkstra said about higher level languages, something along these lines: higher level languages are supposed to make things easier, instead they make it more difficult. You can automate all the mundane tasks away, all that is left are the complicated parts.