3 ms·
In our world of Ship It/Get Shit Done/Move Fast Break Things, code readability doesn't stand a chance. I find there's little allowance for time spent thinking
by izolate 7y ago
In our world of Ship It/Get Shit Done/Move Fast Break Things, code readability doesn't stand a chance.
I find there's little allowance for time spent thinking about the poor sucker who has to read my code, lest the sprint burndown chart suffers.
That's why code linters and formatters are so important. When applied correctly, it's the closest we can come to having the entire codebase looking like it was written by one person. A single standard you can learn once. Go and Dart are good at this.
- caymanjim 7y agoThis might be true at some shops, but if so, they're doing it wrong. You can move fast and still maintain code readibility. No matter how fast you're moving, code shouldn't be accepted into a shared repository unless it meets minimum standards. A well-functioning agile team cuts corners by not over-engineering, by not waiting for elusive completion, by releasing minimally-viable products that provide user value to get feedback and drive further development. Even breaking things is ok, but sloppiness is not. When you push out crap code to meet an arbitrary velocity target, you're just digging an inescapable hole of tech debt. If you're not thinking about the poor sucker who has to read your code, you're doing it wrong.