7 ms·

The miserable programmer paradox

154 points by cool-RR 16y ago

swombat 16y ago
I must sadly agree. Woobius is written in Flex (Java-like ActionScript 3) and Rails. Guess which I've spent most time in over the last 3 years?
- merijnv 16y ago
  This is of course a case of the True Scotsman fallacy, because the author can argue (following the posts logic): - Good programmers are stuck spending most of their time on - tools they hate. - You do not spend most time on a tool you hate. Therefore, you must need be a good programmer. And tada, irrefutable argument and a linkbait blog post subject.
Swizec 16y ago
>I wish I could end this essay with some sort of moral, or an idea for solving this problem, but there’s not much. All we can do is try to cut as many bad technologies as possible out of our lives, and just tolerate the rest. The author said they can't extract a good moral, but the moral is really self-evident. Don't distract programmers!
ahoyhere 16y ago
There's a moral, but the author couldn't find it. The moral is not "don't distract programmers" but: Programmers need to grow up. If you program just to program, or "solve problems" as so many put it, then of course, you will be miserable when your pure programming is disrupted. But work on something bigger - something you believe in - which gives you a big-picture outlook, you'll look at programming as the means to your end. And you will suffer a lot less. Even with no technical change. Because the pleasure you experience will be mostly to do with achieving your bigger goal, rather than (just) crafting the most beautiful line of code. So many of the programmers I know set themselves up to be used as tools by people with ideas, because they claim they only care about "solving problems." So they get themselves hired by people with "interesting problems." And then, because they end up miserable, they quit in short order (1 year, 2 years, or less)... and repeat the cycle again. It's not that jobs are inherently terrible, but that the way certain groups of very smart and capable people LOOK at jobs. Granted, lots of people who want to "do a startup" do the same thing. They look for an interesting problem, not a bigger thing they want to achieve in the world. Their work is all about "the problem," and so they get stuck... and work on it for 1 year or 2, before they quit and look for another, more interesting problem.
- cool-RR 16y ago
  "But work on something bigger - something you believe in - which gives you a big-picture outlook" What is this "something bigger" and how is it any better than the goal of "living a nice, comfortable, intellectually-satisfying life"?
  - mechanical_fish 16y ago
    That's something bigger. And if having to (e.g.) constantly code HTML in IE6 interferes with that goal... you need to stop constantly coding HTML in IE6. The underlying fallacy of the original essay is that the life of a programmer consists of a semi-infinite series of programming tasks that only stop when you die. Well, yeah, if you think like an assembly-line worker this is true, but you need not do so. In real-world projects, you do have to deal with HTML, but you don't have to do so to an infinite extent. You only have to write enough HTML to make all the web pages you need to fuel the rest of your comfortable, intellectually-satisfying life. (For some, this is "near zero": PG wrote all the HTML for this site five years ago, probably in less than two hours, and it's working out just fine.) HN has been over this many times. If you don't enjoy ritual grunt work, get out of the piecework business and solve a problem. [1] Nobody really knows how much work, say, the folks behind the scenes at 37signals do. We don't pay them by the hour, or by the line of code. We pay them for their product. If they can produce the product in half the time, they get the other half of the time to invest in other things. They don't have to spend that extra time programming in systems they hate. --- [1] This ties into my Programmer Aging Hypothesis: Old "programmers" are hard to find not because their brains wither and die, or whatever, but because most of them have learned enough to brand their work as something other than "programming".
  - deleted 16y ago
    [deleted]
  - frostbytten 16y ago
    I was a "pure programmer", programming for the sake of programming for a long time. Then I started pushing my boundaries by learning new languages for every new project, not necessarily because it was best suited but because pure programming can become dull if there isn't a real impact behind it. Now, I've moved positions and am programming in one of the first languages I learned (PHP) and although I feel the limitations of the language, the project is something I believe has potential to impact a lot of people in a beneficial way and am sold out behind the idea. It is my "something bigger." And, unfortunately, I don't necessarily have the "nice, comfortable" part of life down.
nostrademons 16y ago
This is the human equivalent of Amdahl's Law. Say that you have a boring task where 90% of it can be automated, and that part can be sped up by a factor of 100. Now, the workload that used to take up 90% of your time takes up only 0.9%. The part that can't be automated remains constant, however, and so you now spend over 90% of your time doing work that can't be automated. The total amount of work you can do increases dramatically, but a much higher fraction of it (by time) will be distasteful. In practice, it doesn't seem quite as bad as the article makes it out to be. I've found that by now, I spend the vast majority of my workday learning things, and the limiting factor in my productivity is how fast my brain can learn. Typing speed ceased to be a bottleneck in high school when I got up around 90 WPM. Thinking speed ceased to be a bottleneck a couple years after I started programming professionally, once I became fluent enough with the syntax and basic libraries of the languages I typically use that I don't have to reach for the docs all the time. The bottleneck is now learning libraries, data sources, requirements, and algorithms that I don't typically use. And while this can be a little annoying - it's mentally exhausting and not great for the ego that my productivity is limited by intrinsic problems with my brain - getting paid to learn things all day is a pretty nice state of affairs.
- Stormbringer 16y ago
  Your math is wrong. 10% (cannot be automated) + 0.9% (can and has been automated) = 10.9% What you do with that extra 89.1% you just liberated is unspecified. You're making an assumption about what happens to that extra time, I think you should be more explicit about it. You say: "The part that can't be automated remains constant, however" You need to back that up somehow. I am unconvinced that this 90:10 ratio is some cosmic law. Also, you are buying into the original authors deeply flawed premise that work that cannot be automated is tedious and distasteful. I respectfully completely disagree. You have it exactly backwards. The tedious and distasteful stuff is first in line for automation, not last. The stuff that cannot be automated is always the most interesting stuff, because it is the bit that requires you to engage your brain. Example: automation can give you really really bad software design, but for good software design nothing comes close to doing it 'by hand' (or rather 'by brain').
jcr 16y ago
The general observation of the author is correct, but his claimed reasons for it are flawed; it has little to do with breaking concentration. I was at a party with a dear friend of mine, Pat Davis, who is an expert PCB layout engineer at Millennium Design (www.millenniumdes.com). When I was healthier, I used to do some occasional PCB and automation work for his company. While the two of us were talking with another mutual friend, I said, "Working with me can be, ummm, interesting. I have zero patience for poorly built machines and programs." And then I asked Pat for affirmation from his own experience working with me. Pat replied, "Sure, you can be tough to work with, but there is a real upside to it; if I never want to do something manually again, I just make Jon do it three times. He'll lose his patience and automate the living snot out of it." As much as I hate to admit it, his answer was completely truthful.
- wccrawford 16y ago
  Put me in the 'automate the crap out of it' category, too. We had a sysadmin that spent most of his time on 2 tasks, 1 was an internal maintenance task, and the other was email. When he quit, those tasks fell to me, the sole programmer at the time. THe internal maintenance task, I did it for about a week before I decided that it needed to go away. So I wrote scripts and an interface for it, tested it for a while, and turned it over to customer service, which was the department that was requesting it anyhow. They were ecstatic because it meant they no longer had to request it and wait... They could just do it instantly. Much better for everyone. The email was easier. We just moved to Google Apps. The remaining tasks that the sysadmin did were now just a tiny fraction of my time. As the company grew, those tasks increased until management realized they needed an actual sysadmin again, and they hired one.
  - jcr 16y ago
    Very much agreed. The real trouble is, the automate-everything mentality is unfortunately very rare due to the simple fact that if successful, you've just made your own job unnecessary. I actually want to work my way out of a job, but most people are far more concerned with keeping their job security.
ZeroMinx 16y ago
I think another point is that programming is generally started as a hobby, because you love it. You might spend years and years doing it for fun - you are in control what you're doing, you do things that you like. Then, it becomes a profession. Suddenly, even if you're doing the same things, it's now something you _have_ to do. All of a sudden it's not that much fun any more.
- thret 16y ago
  True of all hobbies turned professional.
  - ZeroMinx 16y ago
    Very true indeed, but this particular post was about programmers :)
axod 16y ago
I disagree. A bad programmer is the guy that says "I will only use lisp! Everything else is terrible". A good programmer just wants the thing to work and will use whatever is best for the task. The solution is for programmers to learn more technologies and stop being so fanboish with his favorite. Rise above the language/tool. They're nothing to do with real programming, which is solving real world problems. Good programmers don't think about problems in a specific language, they don't read code in a specific language. It's all just code. Languages are just a crappy way for humans to write machine code. That's all.
- cool-RR 16y ago
  Someone who insists too much on perfection is a bad programmer, like in the example you gave. Someone who doesn't insist enough on perfection is also a bad programmer.
  - axod 16y ago
    I don't think that's the case at all. Bad programmers spend years on silly problems that don't matter. No one cares if you as a programmer find a particular language to be beautiful. Language syntax doesn't matter. Having to type out boilerplate doesn't matter. Runtime matters, scalability matters, resource usage etc.
    - eitland 16y ago
      And often, most important: Time to market. A working solution in PHP today may may often be far more valueable than a perfect solution in Java next week, next month or next year.
    - Dn_Ab 16y ago
      But then it does matter. While choice of language is not the end all be all it will affect run time, scalability, resource usage, correctness and time to market. And if you have a choice in language to use then do not forget we are humans with psychological considerations; balance the choice between the one you want while also considering its fit for the problem domain. Going less common has its down but also up sides. Its up to you to decide what is paramount. Some syntax and language features suit different mental types better. This will affect things like motivation hence touching correctness, time to market and similar mental state affectable things.
CrLf 16y ago
The example of going directly to a particular line is not a good one, IMHO. I find myselft often doing stuff that I know that my editor can do faster. Scrolling is one, but there are other examples. This not only doesn't interrupt my train of though, but it also works as "time to think".
k0nad 16y ago
Edison famously quipped : Genius is 1% inspiration and 99% perspiration. What's not so famous is that this was during a live radio debate with Tesla. His response was "If Mr. Edison thought a bit more, he wouldn't have to sweat so much."
JonnieCache 16y ago
Yeah. If nagios were written in ruby/python/javascript I'd be a lot less miserable right now. I demand executable, object oriented configuration files! It is my basic right as part of the pursuit of human happiness, as the OP has now shown conclusively.
edw519 16y ago
A good programmer will spend most of his time doing work that he hates, using tools and technologies that he also hates. Oy, another "good programmer, bad programmer" post. A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None." Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?" To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. To a customer, the programmer who solves their problem quickest is a good programmer. To a business owner, the programmer who makes them the most money is a good programmer. To a PHB, the programmer who makes them look the best is a good programmer. To a journalist, the programmer who tells the best stories is a good programmer. To a junior programmer, the best mentor is the good programmer. To another programmer, the programmer they are most likely to want to go into battle with is a good programmer. To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.
- cool-RR 16y ago
  I understand that many people read my essay as if I was trying to judge who is a good programmer and who isn't. That wasn't my intention-- I just wanted to reflect on a problem that good programmers have.
  - StavrosK 16y ago
    The problem isn't about anything that was in the post, it's simply working on things you don't like. I've never taken a job that wasn't Python (which I love), therefore I never work with technologies I hate. According to you, that makes me a bad programmer. According to me, I can simply afford to turn down jobs I will hate. At this stage in my life, it's simply not worth it to me to work with things I will hate. I'd rather not work at all. You can't even claim I have to work with some technologies I don't like in the stack, because I'm in love with my entire stack. Postgres? I adore it. Python? The love of my life. Redis? I'm amazed whenever I work with it. Varnish? In love with it. AppEngine? Just brilliant. It's great feeling when you hate NOT working because you like what you're doing so much. You need to be careful not to overdo it, but, generally, I love my job. I don't even see it as a job, it's basically a hobby people will pay me for. Disclaimer: This rant may or may not have been relevant to the discussion.
Raphael_Amiard 16y ago
I think that in today's technology world, if you really care about the technologies you are using, they are plenty of positions with reasonably good languages, where tools are not imposed because you're working on a web product. I use python professionnally, but there are a lot of ruby openings to, some scala and clojure now, and even C# is really far from being a bad language. I do hate to program in Java, but there is plenty of room in the tech world to let me not program any line of Java, and let that to people who like it, or simply don't mind. So my question is i guess, if you are indeed a good programmer, and hate your tools, what stops you from learning one of the "bearable" languages that are plenty used in the industry today, and find a job where you can use it ?
- cool-RR 16y ago
  Even in my open-source project, where I make all the decisions, I have to work with technologies that annoy me. If you want to actually ship working software, you have to make some compromises.
Nervetattoo 16y ago
"Ignorance is bliss". The problem is rather universal. Put a good "X professional" to do job Y and a bad X to do the same job, it will be more miserable for he who is good because he has more knowledge and is better able to realize all the reasons why job/task X is a miserable sorry job. On the other side you could argue that a good programmer would be able to abstract away a proportional amount of miserable work to a bad programmer, thus leaving them equally miserable. In the end its your attitude as a person that decides if a task makes you miserable. If your attitude makes everything you do into a job — some piece of tedious labour you do at someone elses whim — then no wonder you are miserable.
PaulHoule 16y ago
When my family sees me working I'm afraid they'd get the impression that I hate my work. It seems like I'm always dealing with something that doesn't quite work right. I had a conversation with the salespeople in my organization that got me thinking about it too; as a developer, I was always talking about what was wrong or missing in my product, not what was right about it. If you're the kind of programmer that the "buck stops with" you'll always be frustrated with what you've got because your whole job is to make it better.
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
waivej 16y ago
A miserable programmer is a miserable person and won't be happy with good tools and technologies. Likewise, a "skillful" programmer could be a like a skillful mechanic that builds a good set of tools. The best mechanics I've known ended up working in jobs where they like the cars they maintain (Honda, Porsche, classic car restoration). The less skillful ones seem "trapped" working with cheap parts or cobbling things together and not doing a great job of it. They tend to have excuses about why the cars or parts are engineered poorly. I've also known very skillful mechanics that are proud of their ability to keep beat up old cars running inexpensively regardless of the brand and making their own tools rather than buying fancy ones. Likewise, a good programmer will know the limits of the systems they are working in and will strive to not do quick fixes that cause problems later. They may also make their own tools and libraries...and they will move to companies with better politics or projects when opportunities arise.
ebiester 16y ago
How much of this discussion would have been easily replaced by "most?" Most programmers above entry-level try to automate away tedious pieces. However, there's an easier explanation for the miserable programmer paradox: most programmers get good at the pieces they enjoy; thus, those pieces take less time. We tend not to get as good at technologies we dislike (Pure human nature -- if you don't like it, you're not going to play around with it as much). Thus, they take longer.
Luyt 16y ago
When I find myself spending time over and over again on repetitive tasks like fighting an inadequate editor or tools, or writing CRUD-like code over and over, I take some time to automate away the nuisance, for example, switching to a more appropriate editor, or refactoring out common code and only describe the differences from there on, or maybe find a better tool for the job. I have experienced coworkers who didn't do this. They figured out how to do certain tasks and keep repeating it into eternity, without giving a thought to how they could work more efficiently.
didip 16y ago
I felt like the post isn't quite finished. He could have gone into greater depth. That said, to me, a great programmer can be measured by how much fun he is having when programming. Not by how much he hate particular tasks. Programming requires constant act of learning, that gets old real fast if you don't love what you do. I admire programmers who can take shitty tools that he hates, cleverly hack it, and make something cool with it.
agavin 16y ago
I would like to add a corollary to this theorem. The best programmers are also willing to work with the annoying technologies -- although they will gripe (healthily) about them. It's all a balancing act. There is a type of programmer who could be great, but is merely good because they refuse to use or deal with annoying techs. Sometimes, you just have no choice, and brute forcing past the annoying is by far the most efficient solution. You all know this type. They are the kind of guy that exclusively used the Next (or Amiga), and ran windows in VM Ware on a bleeding edge Debian install in 2000 -- When the software they were being paid to develop was compiled in Visual Studio! That's the thing. I hate MSFT. I hate Windows. I'll avoid using it. But... if the task requires that a regular PC GUI app be written, I'll use Visual Studio. Although I have been known to ask less PC phobic employees to handle this part of the job :-) Of course, I also decided for an entire series of Playstation 2 games to forego doing the normal thing (using C/C++) and wrote my own Scheme compiler/debugger/environment. And of course, this quickly spiraled into several man years of work (on my part). It did come out pretty well. We did four games, and they sold tens of millions of copies -- dozens of programmers used the system and it was pretty cool. But boy was it stressful. I really should have figured out a way of solving my problems that didn't require so much custom programming to solve a sub-problem of my task. My main task was: Program an absolutely fantastic 3D action game in 2-3 years. I got sidetracked by the theory that "C/C++ sucks for writing highly customized game code" and that the compile/link/run cycle of 10+ minutes made iterative testing (which is the mother of all good gameplay) slow. This is all true, but it's a less focused problem than making a great game. Avoiding this or that technology, or using this or that more fun one is not the same as getting the job done. That being said, programming in Lisp, or Ruby feels like walking on water compared to C/C++'s being wrapped in chains and pushed off the boat. You just don't want to stroll off toward Australia when your gig is in Japan.
techiferous 16y ago
This is similar to what I experienced on a bike tour: even though on hilly terrain the distance you are pedaling uphill equals the distance you are traveling downhill, you are spending 90% of your time going uphill.
rfugger 16y ago
This is why I hate long bike trips: you spend 90% of your time pedaling uphill.

154 points by cool-RR 16y ago

I must sadly agree. Woobius is written in Flex (Java-like ActionScript 3) and Rails. Guess which I've spent most time in over the last 3 years?

merijnv 16y ago
This is of course a case of the True Scotsman fallacy, because the author can argue (following the posts logic): - Good programmers are stuck spending most of their time on - tools they hate. - You do not spend most time on a tool you hate. Therefore, you must need be a good programmer. And tada, irrefutable argument and a linkbait blog post subject.

Swizec 16y ago

>I wish I could end this essay with some sort of moral, or an idea for solving this problem, but there’s not much. All we can do is try to cut as many bad technologies as possible out of our lives, and just tolerate the rest. The author said they can't extract a good moral, but the moral is really self-evident. Don't distract programmers!

ahoyhere 16y ago

There's a moral, but the author couldn't find it. The moral is not "don't distract programmers" but: Programmers need to grow up. If you program just to program, or "solve problems" as so many put it, then of course, you will be miserable when your pure programming is disrupted. But work on something bigger - something you believe in - which gives you a big-picture outlook, you'll look at programming as the means to your end. And you will suffer a lot less. Even with no technical change. Because the pleasure you experience will be mostly to do with achieving your bigger goal, rather than (just) crafting the most beautiful line of code. So many of the programmers I know set themselves up to be used as tools by people with ideas, because they claim they only care about "solving problems." So they get themselves hired by people with "interesting problems." And then, because they end up miserable, they quit in short order (1 year, 2 years, or less)... and repeat the cycle again. It's not that jobs are inherently terrible, but that the way certain groups of very smart and capable people LOOK at jobs. Granted, lots of people who want to "do a startup" do the same thing. They look for an interesting problem, not a bigger thing they want to achieve in the world. Their work is all about "the problem," and so they get stuck... and work on it for 1 year or 2, before they quit and look for another, more interesting problem.

cool-RR 16y ago
"But work on something bigger - something you believe in - which gives you a big-picture outlook" What is this "something bigger" and how is it any better than the goal of "living a nice, comfortable, intellectually-satisfying life"?
- mechanical_fish 16y ago
  That's something bigger. And if having to (e.g.) constantly code HTML in IE6 interferes with that goal... you need to stop constantly coding HTML in IE6. The underlying fallacy of the original essay is that the life of a programmer consists of a semi-infinite series of programming tasks that only stop when you die. Well, yeah, if you think like an assembly-line worker this is true, but you need not do so. In real-world projects, you do have to deal with HTML, but you don't have to do so to an infinite extent. You only have to write enough HTML to make all the web pages you need to fuel the rest of your comfortable, intellectually-satisfying life. (For some, this is "near zero": PG wrote all the HTML for this site five years ago, probably in less than two hours, and it's working out just fine.) HN has been over this many times. If you don't enjoy ritual grunt work, get out of the piecework business and solve a problem. [1] Nobody really knows how much work, say, the folks behind the scenes at 37signals do. We don't pay them by the hour, or by the line of code. We pay them for their product. If they can produce the product in half the time, they get the other half of the time to invest in other things. They don't have to spend that extra time programming in systems they hate. --- [1] This ties into my Programmer Aging Hypothesis: Old "programmers" are hard to find not because their brains wither and die, or whatever, but because most of them have learned enough to brand their work as something other than "programming".
- deleted 16y ago
  [deleted]
- frostbytten 16y ago
  I was a "pure programmer", programming for the sake of programming for a long time. Then I started pushing my boundaries by learning new languages for every new project, not necessarily because it was best suited but because pure programming can become dull if there isn't a real impact behind it. Now, I've moved positions and am programming in one of the first languages I learned (PHP) and although I feel the limitations of the language, the project is something I believe has potential to impact a lot of people in a beneficial way and am sold out behind the idea. It is my "something bigger." And, unfortunately, I don't necessarily have the "nice, comfortable" part of life down.

nostrademons 16y ago

This is the human equivalent of Amdahl's Law. Say that you have a boring task where 90% of it can be automated, and that part can be sped up by a factor of 100. Now, the workload that used to take up 90% of your time takes up only 0.9%. The part that can't be automated remains constant, however, and so you now spend over 90% of your time doing work that can't be automated. The total amount of work you can do increases dramatically, but a much higher fraction of it (by time) will be distasteful. In practice, it doesn't seem quite as bad as the article makes it out to be. I've found that by now, I spend the vast majority of my workday learning things, and the limiting factor in my productivity is how fast my brain can learn. Typing speed ceased to be a bottleneck in high school when I got up around 90 WPM. Thinking speed ceased to be a bottleneck a couple years after I started programming professionally, once I became fluent enough with the syntax and basic libraries of the languages I typically use that I don't have to reach for the docs all the time. The bottleneck is now learning libraries, data sources, requirements, and algorithms that I don't typically use. And while this can be a little annoying - it's mentally exhausting and not great for the ego that my productivity is limited by intrinsic problems with my brain - getting paid to learn things all day is a pretty nice state of affairs.

Stormbringer 16y ago
Your math is wrong. 10% (cannot be automated) + 0.9% (can and has been automated) = 10.9% What you do with that extra 89.1% you just liberated is unspecified. You're making an assumption about what happens to that extra time, I think you should be more explicit about it. You say: "The part that can't be automated remains constant, however" You need to back that up somehow. I am unconvinced that this 90:10 ratio is some cosmic law. Also, you are buying into the original authors deeply flawed premise that work that cannot be automated is tedious and distasteful. I respectfully completely disagree. You have it exactly backwards. The tedious and distasteful stuff is first in line for automation, not last. The stuff that cannot be automated is always the most interesting stuff, because it is the bit that requires you to engage your brain. Example: automation can give you really really bad software design, but for good software design nothing comes close to doing it 'by hand' (or rather 'by brain').

jcr 16y ago

The general observation of the author is correct, but his claimed reasons for it are flawed; it has little to do with breaking concentration. I was at a party with a dear friend of mine, Pat Davis, who is an expert PCB layout engineer at Millennium Design (www.millenniumdes.com). When I was healthier, I used to do some occasional PCB and automation work for his company. While the two of us were talking with another mutual friend, I said, "Working with me can be, ummm, interesting. I have zero patience for poorly built machines and programs." And then I asked Pat for affirmation from his own experience working with me. Pat replied, "Sure, you can be tough to work with, but there is a real upside to it; if I never want to do something manually again, I just make Jon do it three times. He'll lose his patience and automate the living snot out of it." As much as I hate to admit it, his answer was completely truthful.

wccrawford 16y ago
Put me in the 'automate the crap out of it' category, too. We had a sysadmin that spent most of his time on 2 tasks, 1 was an internal maintenance task, and the other was email. When he quit, those tasks fell to me, the sole programmer at the time. THe internal maintenance task, I did it for about a week before I decided that it needed to go away. So I wrote scripts and an interface for it, tested it for a while, and turned it over to customer service, which was the department that was requesting it anyhow. They were ecstatic because it meant they no longer had to request it and wait... They could just do it instantly. Much better for everyone. The email was easier. We just moved to Google Apps. The remaining tasks that the sysadmin did were now just a tiny fraction of my time. As the company grew, those tasks increased until management realized they needed an actual sysadmin again, and they hired one.
- jcr 16y ago
  Very much agreed. The real trouble is, the automate-everything mentality is unfortunately very rare due to the simple fact that if successful, you've just made your own job unnecessary. I actually want to work my way out of a job, but most people are far more concerned with keeping their job security.

ZeroMinx 16y ago

I think another point is that programming is generally started as a hobby, because you love it. You might spend years and years doing it for fun - you are in control what you're doing, you do things that you like. Then, it becomes a profession. Suddenly, even if you're doing the same things, it's now something you _have_ to do. All of a sudden it's not that much fun any more.

thret 16y ago
True of all hobbies turned professional.
- ZeroMinx 16y ago
  Very true indeed, but this particular post was about programmers :)

axod 16y ago

I disagree. A bad programmer is the guy that says "I will only use lisp! Everything else is terrible". A good programmer just wants the thing to work and will use whatever is best for the task. The solution is for programmers to learn more technologies and stop being so fanboish with his favorite. Rise above the language/tool. They're nothing to do with real programming, which is solving real world problems. Good programmers don't think about problems in a specific language, they don't read code in a specific language. It's all just code. Languages are just a crappy way for humans to write machine code. That's all.

cool-RR 16y ago
Someone who insists too much on perfection is a bad programmer, like in the example you gave. Someone who doesn't insist enough on perfection is also a bad programmer.
- axod 16y ago
  I don't think that's the case at all. Bad programmers spend years on silly problems that don't matter. No one cares if you as a programmer find a particular language to be beautiful. Language syntax doesn't matter. Having to type out boilerplate doesn't matter. Runtime matters, scalability matters, resource usage etc.
  - eitland 16y ago
    And often, most important: Time to market. A working solution in PHP today may may often be far more valueable than a perfect solution in Java next week, next month or next year.
  - Dn_Ab 16y ago
    But then it does matter. While choice of language is not the end all be all it will affect run time, scalability, resource usage, correctness and time to market. And if you have a choice in language to use then do not forget we are humans with psychological considerations; balance the choice between the one you want while also considering its fit for the problem domain. Going less common has its down but also up sides. Its up to you to decide what is paramount. Some syntax and language features suit different mental types better. This will affect things like motivation hence touching correctness, time to market and similar mental state affectable things.

CrLf 16y ago

The example of going directly to a particular line is not a good one, IMHO. I find myselft often doing stuff that I know that my editor can do faster. Scrolling is one, but there are other examples. This not only doesn't interrupt my train of though, but it also works as "time to think".

k0nad 16y ago

Edison famously quipped : Genius is 1% inspiration and 99% perspiration. What's not so famous is that this was during a live radio debate with Tesla. His response was "If Mr. Edison thought a bit more, he wouldn't have to sweat so much."

JonnieCache 16y ago

Yeah. If nagios were written in ruby/python/javascript I'd be a lot less miserable right now. I demand executable, object oriented configuration files! It is my basic right as part of the pursuit of human happiness, as the OP has now shown conclusively.

edw519 16y ago

A good programmer will spend most of his time doing work that he hates, using tools and technologies that he also hates. Oy, another "good programmer, bad programmer" post. A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None." Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?" To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. To a customer, the programmer who solves their problem quickest is a good programmer. To a business owner, the programmer who makes them the most money is a good programmer. To a PHB, the programmer who makes them look the best is a good programmer. To a journalist, the programmer who tells the best stories is a good programmer. To a junior programmer, the best mentor is the good programmer. To another programmer, the programmer they are most likely to want to go into battle with is a good programmer. To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.

cool-RR 16y ago
I understand that many people read my essay as if I was trying to judge who is a good programmer and who isn't. That wasn't my intention-- I just wanted to reflect on a problem that good programmers have.
- StavrosK 16y ago
  The problem isn't about anything that was in the post, it's simply working on things you don't like. I've never taken a job that wasn't Python (which I love), therefore I never work with technologies I hate. According to you, that makes me a bad programmer. According to me, I can simply afford to turn down jobs I will hate. At this stage in my life, it's simply not worth it to me to work with things I will hate. I'd rather not work at all. You can't even claim I have to work with some technologies I don't like in the stack, because I'm in love with my entire stack. Postgres? I adore it. Python? The love of my life. Redis? I'm amazed whenever I work with it. Varnish? In love with it. AppEngine? Just brilliant. It's great feeling when you hate NOT working because you like what you're doing so much. You need to be careful not to overdo it, but, generally, I love my job. I don't even see it as a job, it's basically a hobby people will pay me for. Disclaimer: This rant may or may not have been relevant to the discussion.

Raphael_Amiard 16y ago

I think that in today's technology world, if you really care about the technologies you are using, they are plenty of positions with reasonably good languages, where tools are not imposed because you're working on a web product. I use python professionnally, but there are a lot of ruby openings to, some scala and clojure now, and even C# is really far from being a bad language. I do hate to program in Java, but there is plenty of room in the tech world to let me not program any line of Java, and let that to people who like it, or simply don't mind. So my question is i guess, if you are indeed a good programmer, and hate your tools, what stops you from learning one of the "bearable" languages that are plenty used in the industry today, and find a job where you can use it ?

cool-RR 16y ago
Even in my open-source project, where I make all the decisions, I have to work with technologies that annoy me. If you want to actually ship working software, you have to make some compromises.

Nervetattoo 16y ago

"Ignorance is bliss". The problem is rather universal. Put a good "X professional" to do job Y and a bad X to do the same job, it will be more miserable for he who is good because he has more knowledge and is better able to realize all the reasons why job/task X is a miserable sorry job. On the other side you could argue that a good programmer would be able to abstract away a proportional amount of miserable work to a bad programmer, thus leaving them equally miserable. In the end its your attitude as a person that decides if a task makes you miserable. If your attitude makes everything you do into a job — some piece of tedious labour you do at someone elses whim — then no wonder you are miserable.

PaulHoule 16y ago

When my family sees me working I'm afraid they'd get the impression that I hate my work. It seems like I'm always dealing with something that doesn't quite work right. I had a conversation with the salespeople in my organization that got me thinking about it too; as a developer, I was always talking about what was wrong or missing in my product, not what was right about it. If you're the kind of programmer that the "buck stops with" you'll always be frustrated with what you've got because your whole job is to make it better.

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

waivej 16y ago

A miserable programmer is a miserable person and won't be happy with good tools and technologies. Likewise, a "skillful" programmer could be a like a skillful mechanic that builds a good set of tools. The best mechanics I've known ended up working in jobs where they like the cars they maintain (Honda, Porsche, classic car restoration). The less skillful ones seem "trapped" working with cheap parts or cobbling things together and not doing a great job of it. They tend to have excuses about why the cars or parts are engineered poorly. I've also known very skillful mechanics that are proud of their ability to keep beat up old cars running inexpensively regardless of the brand and making their own tools rather than buying fancy ones. Likewise, a good programmer will know the limits of the systems they are working in and will strive to not do quick fixes that cause problems later. They may also make their own tools and libraries...and they will move to companies with better politics or projects when opportunities arise.

ebiester 16y ago

How much of this discussion would have been easily replaced by "most?" Most programmers above entry-level try to automate away tedious pieces. However, there's an easier explanation for the miserable programmer paradox: most programmers get good at the pieces they enjoy; thus, those pieces take less time. We tend not to get as good at technologies we dislike (Pure human nature -- if you don't like it, you're not going to play around with it as much). Thus, they take longer.

Luyt 16y ago

When I find myself spending time over and over again on repetitive tasks like fighting an inadequate editor or tools, or writing CRUD-like code over and over, I take some time to automate away the nuisance, for example, switching to a more appropriate editor, or refactoring out common code and only describe the differences from there on, or maybe find a better tool for the job. I have experienced coworkers who didn't do this. They figured out how to do certain tasks and keep repeating it into eternity, without giving a thought to how they could work more efficiently.

didip 16y ago

I felt like the post isn't quite finished. He could have gone into greater depth. That said, to me, a great programmer can be measured by how much fun he is having when programming. Not by how much he hate particular tasks. Programming requires constant act of learning, that gets old real fast if you don't love what you do. I admire programmers who can take shitty tools that he hates, cleverly hack it, and make something cool with it.

agavin 16y ago

I would like to add a corollary to this theorem. The best programmers are also willing to work with the annoying technologies -- although they will gripe (healthily) about them. It's all a balancing act. There is a type of programmer who could be great, but is merely good because they refuse to use or deal with annoying techs. Sometimes, you just have no choice, and brute forcing past the annoying is by far the most efficient solution. You all know this type. They are the kind of guy that exclusively used the Next (or Amiga), and ran windows in VM Ware on a bleeding edge Debian install in 2000 -- When the software they were being paid to develop was compiled in Visual Studio! That's the thing. I hate MSFT. I hate Windows. I'll avoid using it. But... if the task requires that a regular PC GUI app be written, I'll use Visual Studio. Although I have been known to ask less PC phobic employees to handle this part of the job :-) Of course, I also decided for an entire series of Playstation 2 games to forego doing the normal thing (using C/C++) and wrote my own Scheme compiler/debugger/environment. And of course, this quickly spiraled into several man years of work (on my part). It did come out pretty well. We did four games, and they sold tens of millions of copies -- dozens of programmers used the system and it was pretty cool. But boy was it stressful. I really should have figured out a way of solving my problems that didn't require so much custom programming to solve a sub-problem of my task. My main task was: Program an absolutely fantastic 3D action game in 2-3 years. I got sidetracked by the theory that "C/C++ sucks for writing highly customized game code" and that the compile/link/run cycle of 10+ minutes made iterative testing (which is the mother of all good gameplay) slow. This is all true, but it's a less focused problem than making a great game. Avoiding this or that technology, or using this or that more fun one is not the same as getting the job done. That being said, programming in Lisp, or Ruby feels like walking on water compared to C/C++'s being wrapped in chains and pushed off the boat. You just don't want to stroll off toward Australia when your gig is in Japan.

techiferous 16y ago

This is similar to what I experienced on a bike tour: even though on hilly terrain the distance you are pedaling uphill equals the distance you are traveling downhill, you are spending 90% of your time going uphill.

rfugger 16y ago

This is why I hate long bike trips: you spend 90% of your time pedaling uphill.