4 ms·

> He is a terrible, terrible coder. I've had an idea brewing in my head for quite some time, and while I still don't quite have the words to express it complet

> He is a terrible, terrible coder. I've had an idea brewing in my head for quite some time, and while I still don't quite have the words to express it completely, it more or less boils down to this: There isn't necessarily a correlation between being a good programmer and shipping a successful product. Now of course we can argue over the definition of "good programmer" and "successful product". I started as a hobby programmer in my childhood and teens, then went to college, and since then have written code for various companies. For several of the earlier years (including college), I had this wide-eyed fantasy of the brilliant, beautiful code that I would work on once I became a "Real Programmer" (whatever that means). My hopes and ambitions shattered once I got into the workplace and discovered some of the slop that I had to maintain. Then for a few years I was on a crusade to banish all ugly code from whatever project I happened to be working on at the time. Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. I don't really know much about the internals of minecraft, but I do know that nearly half of the teenagers in my neighbourhood spend hours and hours playing minecraft. I have to admit that I'm still an idealist at heart, and of course the best situation would be to have a project that is both externally successful and well-designed (making it simple to fix bugs and add new features and such), but I'm constantly having to remind myself to stop trying to get everything perfect and just write code.

colechristensen 13y ago
The great is the enemy of the good.
- seanmcdirmid 13y ago
  Aka "worse is better," aka "New Jersey style"
vorg 13y ago
> Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. It depends on the use case and business model of your software. If you want to ship a single version of something then don't worry about code quality. If you're market testing and will get resources for a rewrite if the product takes off then again speed to market is more important than code shape. But if you want to enhance the software or tune its performance then you need good code structure.
- willismichael 13y ago
  Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a bad thing. Like you say, the amount of sloppy code that you can get away with depends on what you are doing. There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.
  - romaniv 13y ago
    Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.
    - willismichael 13y ago
      I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
      - romaniv 13y ago
        Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
    - corresation 13y ago
deleted 13y ago
[deleted]
tete 13y ago
To me the real question is not about shipping products vs good programmers. There is is a much more important question when it comes to writing ugly or pretty code: Does it work and will you maintain it? In my experience I often had to often fix dozens of critical bugs of "getting things done" programmers. I often hear "I will fix this later", "I will refactor it later", "but it works", "we can write tests later", "I will comment/document later", "I will clean up later" from these people giving it to maintenance programmers who rewrite the stuff, cause it is too ugly to deal with. That's a big problem. People write code and other people have to fix this "but it works" code. Great, when you have a node.js application only running cause there is try catches around things hiding all the errors, killing the logging back end. If you are the only one to read the code than it's fine to do whatever you want with it, as long as it works. But usually code that really works is well-written, well-commented, tested, etc.

colechristensen 13y ago

The great is the enemy of the good.

seanmcdirmid 13y ago
Aka "worse is better," aka "New Jersey style"

vorg 13y ago

> Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. It depends on the use case and business model of your software. If you want to ship a single version of something then don't worry about code quality. If you're market testing and will get resources for a rewrite if the product takes off then again speed to market is more important than code shape. But if you want to enhance the software or tune its performance then you need good code structure.

willismichael 13y ago
Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a bad thing. Like you say, the amount of sloppy code that you can get away with depends on what you are doing. There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.
- romaniv 13y ago
  Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.
  - willismichael 13y ago
    I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
    - romaniv 13y ago
      Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
  - corresation 13y ago

deleted 13y ago

[deleted]

tete 13y ago

To me the real question is not about shipping products vs good programmers. There is is a much more important question when it comes to writing ugly or pretty code: Does it work and will you maintain it? In my experience I often had to often fix dozens of critical bugs of "getting things done" programmers. I often hear "I will fix this later", "I will refactor it later", "but it works", "we can write tests later", "I will comment/document later", "I will clean up later" from these people giving it to maintenance programmers who rewrite the stuff, cause it is too ugly to deal with. That's a big problem. People write code and other people have to fix this "but it works" code. Great, when you have a node.js application only running cause there is try catches around things hiding all the errors, killing the logging back end. If you are the only one to read the code than it's fine to do whatever you want with it, as long as it works. But usually code that really works is well-written, well-commented, tested, etc.