5 ms·

Honestly, I would get bored working at a place where everything is "easy". I actually enjoy the challenge of working on awful code-bases, and trying to improve

by whack 10y ago

Honestly, I would get bored working at a place where everything is "easy". I actually enjoy the challenge of working on awful code-bases, and trying to improve upon it, while still preserving the functionality and not breaking anything. That said, if I had to work with awful code and I wasn't allowed to touch it or make it better, I would definitely leave in a heartbeat.

OpenDrapery 10y ago
I used to enjoy the thrill of the refactor, especially on applications where there weren't a lot of users or the product didn't generate much revenue. Or better yet, refactoring before the product has even been released. When the stakes are low, you can be much more fearless, and it is fun to rearchitect and introduce new patterns, etc. But when the stakes are higher, the risk/reward ratio just isn't there. You can refactor the code to make it more sensible or pleasing to your eye. Two problems with this: 1) Someone else may disagree and refactor it again. 2) When it blows up or has unintended consequences, and you are now on the hot seat, you find yourself working on Saturday asking yourself if it was worth it at all. Thus the fear sets in.
collyw 10y ago
I took that attitude with my new job, but the more I get to know the codebase, the more I dislike it, and there just isn't the time to rewrite everything.
Obi_Juan_Kenobi 10y ago
Is it really that different to put that energy into new features? I guess you lack the 'archaeological' aspect of deciphering old code, but there are still plenty of challenges. I think it's also implied that, in a situation where technical debt isn't appreciated, it's unlikely that resources would be given to pay it down. Instead, it sits there making all work more frustrating, whereas a shop with minimal technical debt spends more time creating new, more robust, code.

by whack 10y ago

OpenDrapery 10y ago

I used to enjoy the thrill of the refactor, especially on applications where there weren't a lot of users or the product didn't generate much revenue. Or better yet, refactoring before the product has even been released. When the stakes are low, you can be much more fearless, and it is fun to rearchitect and introduce new patterns, etc. But when the stakes are higher, the risk/reward ratio just isn't there. You can refactor the code to make it more sensible or pleasing to your eye. Two problems with this: 1) Someone else may disagree and refactor it again. 2) When it blows up or has unintended consequences, and you are now on the hot seat, you find yourself working on Saturday asking yourself if it was worth it at all. Thus the fear sets in.

collyw 10y ago

I took that attitude with my new job, but the more I get to know the codebase, the more I dislike it, and there just isn't the time to rewrite everything.

Obi_Juan_Kenobi 10y ago

Is it really that different to put that energy into new features? I guess you lack the 'archaeological' aspect of deciphering old code, but there are still plenty of challenges. I think it's also implied that, in a situation where technical debt isn't appreciated, it's unlikely that resources would be given to pay it down. Instead, it sits there making all work more frustrating, whereas a shop with minimal technical debt spends more time creating new, more robust, code.