3 ms·
> This is very sage advice. I mean in real life (when you don't have Guido to do it for you), if people are writing code you can't understand then you need to
by Alex3917 7y ago
> This is very sage advice.
I mean in real life (when you don't have Guido to do it for you), if people are writing code you can't understand then you need to tell them to fix it. And many people don't like being told they need to rewrite their code because you can't understand it, so it leads to conflict and eventually you often need to fire people.
So yes, it's good advice, but by cleaning up engineering debt you're often going to take on a lot of team debt.
- Aperocky 7y agoThere's a delicate balance that often lies in hiring process. There are people who simply refuse to understand generics and/or stream APIs. Which are to (most) programmers more readable then the same logic being drawn out in a loop. Meanwhile some other programmer would just write code golf and brag about it. At the end of the day, it should be about enforcing a coding style that defines what you can or can't do. Adding final to all variable that can be final for instance is a great start.
- trilinearnz 7y agoWe have reached a middle ground in our organisation (not a tech company, so there is less code and a slower pace). We don't require rewrites, but simply recommend that next time the code be written in a more lenient style. The education aspect is a good lens through which to view the issue also, sometimes resistance to an unfamiliar style is due to a fixed mindset around a known set of language functionality. It could be an opportunity to learn something new which is genuinely useful.
- deleted 7y ago[deleted]