4 ms·
It can be really unappealing to deal with an existing codebase which contains whimsical choices, and ideally a team should have a turnover low enough to ensure
by southpawgirl 13y ago
It can be really unappealing to deal with an existing codebase which contains whimsical choices, and ideally a team should have a turnover low enough to ensure continuity and consistency of coding style. And to overwork people it's hardly a good strategy to keep people sticking around. The problem you mention might be connected with the issue of overworking more than it seems, imho.
- Edmond 13y agoYou are right, working with someone else' code can be quite a task sometimes but it comes with the territory. It almost always happens that a programmer attempts to redo work and end up creating the same problems that the original developer already solved. I think it really comes down to perspective, once you learn to view programming as a means to an end, not an end in itself, I think you become more tolerant of what looks like shabby code.
- UK-AL 13y agoUntil the shabby code starts making even the simplest changes, take days to complete. Keeping code in good condition, delivers a large amount of business value over the long term. Shabby code delivers business value short term, but reduce it long term.
- Edmond 13y agoshort term benefit vs long term value is certainly something to consider... Going back to my earlier point, the important thing is for managers to know how to recognize when a developer's effort is aligned with business interest as opposed to simply allowing developers do what serves their own ideology. I think once you do that, it becomes easy to discuss/address things like technical debt.