3 ms·

What I've seen mostly is developers bringing complexity, then cutting corners after that because they don't want to deal with it. In Coders at work, Douglas Cro

What I've seen mostly is developers bringing complexity, then cutting corners after that because they don't want to deal with it. In Coders at work, Douglas Crockford said to spend the sixth cycle - whatever the cycle is - on refactoring. It's a sound advice if you care about technical debt as an engineer. Spend some time to revisit the code architecture to see if it still fits the problem you're solving. Instead of spending three cycles on something that could have been done in one because of how fragile everything is. Or having a long list that is tied to the same root cause. Sometimes it means redo your React marketing website in Node and EJS (or the equivalent) instead of trying to make it SSR too.

jack_h 3y ago
> In Coders at work, Douglas Crockford said to spend the sixth cycle - whatever the cycle is - on refactoring. It's a sound advice if you care about technical debt as an engineer. My point is that very often it's not up to engineers. If a company doesn't incentivize this refactoring and engineers have to - as some sibling comments suggest - inflate their estimates then the code base will deteriorate over time. Even if your team sets up a policy of doing refactoring ~15% of the time this will be overridden by business interests more often than not. This is essentially a corollary of Conway's Law. You should not expect code bases to be better than the business incentivizes it to be. I'm speaking from personal experience here; this is burnout territory. Keep in mind these are very general observations and every company is different. In some companies what you and Crockford suggest is possible. I'd wager it's the exception rather than the rule though.