5 ms·

I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding

I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.

jiggy2011 14y ago
I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code because their idea of re-use is copy-pasting the same bit of code they found online into every place they think it will fit and changing it around in various ways in different places so it becomes very hard to abstract later. They also like to stick with the same set of now deprecated APIs they learned 10+ years ago which means that it becomes hard to take advantage of newer libraries which were not built with these in mind, meaning that you will do a lot of wheel re-invention or shimming. They tend to think of economizing on effort and brain usage right now rather than economizing on technical debt in the long run. There is also sometimes a trade off between saving time for the programmer and saving time for others. For example a manager might want a feature that saves them 10 minutes of time once a month when they want to produce a particular report but may cost programmers several hours a month just keeping this feature up to date. In this case it comes down to who's time is more valuable. The best way to explain this to people is in terms of "tax" (since everyone hates that). I was once asked by a management type "I used to get all my changes turned around same day, now I seem to wait weeks or even months. What's going on?" Of course the simple answer to this question is that a year ago the program was about 10Kloc , now it's more like 200Kloc. It's also much more "mission critical" than it was. A year ago the program was small enough that I could easily imagine all the consequences of making a change in my brain so I could do basic testing and push to production, now a small change can have many consequences so it has to be thoroughly tested first. So the analogy to make would be the government building infrastructure for say the road network. The upfront cost of building is $x , but when doing that you commit to $y spending per year (in terms of cost+time) to keeping that going. Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing. It's also partly a political issue, I've spent months adding features to codebases that I know for a fact are not required because somebody with enough influence simply insists that it will be important. There is only a certain level of argument you can get into before you get to "do as you are told", that level will of course depend on many non-technical factors. Another interesting point is that I find sometimes people will request feature X because they are perusing a line of though that will eventually lead them to conclude that they actually need feature Y. In many cases feature Y may be easier to implement (or maintain) than feature X but they simply haven't reasoned that far ahead yet so will insist that they want feature X now but acknowledge that they may change to feature Y a few months down the line.
- hcarvalhoalves 14y ago
  "I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code (...)" No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. "Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing." If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce. In fact, I can only feel sorry for any business which depends fundamentally on software and doesn't have a developer as the main stakeholder.
  - jiggy2011 14y ago
    No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too. If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all. If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run. After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers. I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers. If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce. Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing. It's an interesting point about automation and how much stake a developer should have in a business. Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere. Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made? This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?
noonespecial 14y ago
Not to be a pedant, but I think you meant "yak-shaving"(1) not "bike-shedding"(2). Shaving yaks is fun. A little too much fun. Bike-shedding is always misery. (1) http://en.wiktionary.org/wiki/yak_shaving* http://en.wiktionary.org/wiki/yak_shaving* (2) http://en.wiktionary.org/wiki/bikeshedding* http://en.wiktionary.org/wiki/bikeshedding*
- hcarvalhoalves 14y ago
  Thanks, but I really meant bikeshedding - that is, people who "love" coding tend to also "love" wasting time in the details instead of focusing in the big picture.
  - yock 14y ago
    For what it's worth, I don't agree with you at all. It's like you're saying that the best chefs are those who hate cooking the most. It's a ridiculous notion that betrays a misunderstanding of the relationship between what we do and what is produced by it.
    - hcarvalhoalves 14y ago
      The irony is that the parallel you made with chefs just proves my point. E.g.: chefs care about delicious dishes, great presentations, evoking emotions, not keeping customers waiting, etc. On the other hand, go ask a chef if he loves chopping vegetables ;) In fact, they couldn't care less about this kind of minutae and develop techniques to do it fast and not waste time. Analogously, coding is the chopping of software development.
vibrunazo 14y ago
Thanks for posting that. I thought I was the only one around here to thought like that :) I write code every day, but I hate programming. What I really enjoy is building things and it just so happens that in software you have to write code to build things. Programming is a means and not an end. Way too many people think programming is the end. If I could build awesome stuff without having to write code, I would. Unfortunately, I still have to write code today. That's why my current project is about writing lots of code now, so others don't have to write code later :) As the article points out, that's where current tools are heading. Hopefully in the future we'll have better abstraction so everyone needs to code less to get more done.
Peaker 14y ago
People who hate programming don't program a lot. Programming is immensely about experience. I have not seen a programmer who hated programming and wrote good code.
FuzzyDunlop 14y ago
To be a good developer you have to know what you're doing. That is, to know when it's a good idea to write more code, and to know when it's an even better idea to challenge the rationale for writing it in the first place. I don't think the assertion that raw, passionate emotion (ie. hate) drives a good developer is an ideal, or a correct one.
anthonyb 14y ago
Good programmers hate programming? That's an over generalisation if ever I've heard one. To be a good programmer, among other things, you need to love good code, and hate bad code. Good code is short, neat and to the point, is well tested and well used, and helps you get things built faster.
- hcarvalhoalves 14y ago
  Not only good programmers hate programming, they also try to make it suck less. That's when they come up with new languages, frameworks and abstractions ;)

jiggy2011 14y ago

I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code because their idea of re-use is copy-pasting the same bit of code they found online into every place they think it will fit and changing it around in various ways in different places so it becomes very hard to abstract later. They also like to stick with the same set of now deprecated APIs they learned 10+ years ago which means that it becomes hard to take advantage of newer libraries which were not built with these in mind, meaning that you will do a lot of wheel re-invention or shimming. They tend to think of economizing on effort and brain usage right now rather than economizing on technical debt in the long run. There is also sometimes a trade off between saving time for the programmer and saving time for others. For example a manager might want a feature that saves them 10 minutes of time once a month when they want to produce a particular report but may cost programmers several hours a month just keeping this feature up to date. In this case it comes down to who's time is more valuable. The best way to explain this to people is in terms of "tax" (since everyone hates that). I was once asked by a management type "I used to get all my changes turned around same day, now I seem to wait weeks or even months. What's going on?" Of course the simple answer to this question is that a year ago the program was about 10Kloc , now it's more like 200Kloc. It's also much more "mission critical" than it was. A year ago the program was small enough that I could easily imagine all the consequences of making a change in my brain so I could do basic testing and push to production, now a small change can have many consequences so it has to be thoroughly tested first. So the analogy to make would be the government building infrastructure for say the road network. The upfront cost of building is $x , but when doing that you commit to $y spending per year (in terms of cost+time) to keeping that going. Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing. It's also partly a political issue, I've spent months adding features to codebases that I know for a fact are not required because somebody with enough influence simply insists that it will be important. There is only a certain level of argument you can get into before you get to "do as you are told", that level will of course depend on many non-technical factors. Another interesting point is that I find sometimes people will request feature X because they are perusing a line of though that will eventually lead them to conclude that they actually need feature Y. In many cases feature Y may be easier to implement (or maintain) than feature X but they simply haven't reasoned that far ahead yet so will insist that they want feature X now but acknowledge that they may change to feature Y a few months down the line.

hcarvalhoalves 14y ago
"I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code (...)" No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. "Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing." If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce. In fact, I can only feel sorry for any business which depends fundamentally on software and doesn't have a developer as the main stakeholder.
- jiggy2011 14y ago
  No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too. If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all. If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run. After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers. I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers. If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce. Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing. It's an interesting point about automation and how much stake a developer should have in a business. Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere. Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made? This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?

noonespecial 14y ago

Not to be a pedant, but I think you meant "yak-shaving"(1) not "bike-shedding"(2). Shaving yaks is fun. A little too much fun. Bike-shedding is always misery. (1) http://en.wiktionary.org/wiki/yak_shaving* http://en.wiktionary.org/wiki/yak_shaving* (2) http://en.wiktionary.org/wiki/bikeshedding* http://en.wiktionary.org/wiki/bikeshedding*

hcarvalhoalves 14y ago
Thanks, but I really meant bikeshedding - that is, people who "love" coding tend to also "love" wasting time in the details instead of focusing in the big picture.
- yock 14y ago
  For what it's worth, I don't agree with you at all. It's like you're saying that the best chefs are those who hate cooking the most. It's a ridiculous notion that betrays a misunderstanding of the relationship between what we do and what is produced by it.
  - hcarvalhoalves 14y ago
    The irony is that the parallel you made with chefs just proves my point. E.g.: chefs care about delicious dishes, great presentations, evoking emotions, not keeping customers waiting, etc. On the other hand, go ask a chef if he loves chopping vegetables ;) In fact, they couldn't care less about this kind of minutae and develop techniques to do it fast and not waste time. Analogously, coding is the chopping of software development.

vibrunazo 14y ago

Thanks for posting that. I thought I was the only one around here to thought like that :) I write code every day, but I hate programming. What I really enjoy is building things and it just so happens that in software you have to write code to build things. Programming is a means and not an end. Way too many people think programming is the end. If I could build awesome stuff without having to write code, I would. Unfortunately, I still have to write code today. That's why my current project is about writing lots of code now, so others don't have to write code later :) As the article points out, that's where current tools are heading. Hopefully in the future we'll have better abstraction so everyone needs to code less to get more done.

Peaker 14y ago

People who hate programming don't program a lot. Programming is immensely about experience. I have not seen a programmer who hated programming and wrote good code.

FuzzyDunlop 14y ago

To be a good developer you have to know what you're doing. That is, to know when it's a good idea to write more code, and to know when it's an even better idea to challenge the rationale for writing it in the first place. I don't think the assertion that raw, passionate emotion (ie. hate) drives a good developer is an ideal, or a correct one.

anthonyb 14y ago

Good programmers hate programming? That's an over generalisation if ever I've heard one. To be a good programmer, among other things, you need to love good code, and hate bad code. Good code is short, neat and to the point, is well tested and well used, and helps you get things built faster.

hcarvalhoalves 14y ago
Not only good programmers hate programming, they also try to make it suck less. That's when they come up with new languages, frameworks and abstractions ;)