5 ms·
The code is elegant AND it works, so it'll beat the one that just works every time. This kind of post is always the same, but any decent developer knows when y
by Draiken 13y ago
The code is elegant AND it works, so it'll beat the one that just works every time.
This kind of post is always the same, but any decent developer knows when you have to just "get it done" and when you should take time to make it the right way. And of course, that dirty code will be refactored later on.
Always using the "f*ing works" strategy just means you're mediocre at writing code. Either because you led the management team to think anything can magically be built in a "hackathon" or you just don't care about what you build.
- otterley 13y ago> And of course, that dirty code will be refactored later on. In my experience, the same product development lifecycles and business priorities that led to the dirty code in the first place will cause it to live forever. Code that works doesn't tend to get refactored unless it needs to be revisited for some other business purpose.
- Draiken 13y agoI partially agree... normally this is a symptom of someone selling it as being something super simple to do for the managers. Personally I make it clear to them that if they need something impossibly fast, I'll need to come back for it later or it will cost us in the long run. When you do that, it's their choice to leave crappy code there, and later on you can point that out, when you need double the time to change that crappy little piece of code. But I've seen managers (that should know better) that just take the fastest path always and just don't care, unfortunately it happens :(