3 ms·
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 i
by 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 agoWhoa, 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.