3 ms·
I take issue with #3. The clean code is for you. Future you. You will be substantially more productive if your code is clean. You will end up being the "roc
by redleggedfrog 3y ago
I take issue with #3. The clean code is for you. Future you. You will be substantially more productive if your code is clean. You will end up being the "rockstar" (groan) because you can implement 2, 3, 5, 10(!) times faster on your clean code than your peers. I am living proof of this. And then when your managers and company realize you're the cash cow you can ask for absurd raises and get them. You are going to be hard pressed to do this with crappy code bases.
- sanderjd 3y agoNot just future-you, future-everyone-on-the-team. And in my experience it isn't true that nobody in leadership appreciates this. I think it's easy to make the case that it is worth investing today to make it less burdensome for a team in the future, which may or may not contain the current team members, to evolve the software being written in the moment. This makes sense to everyone in a business, because the same is true of any business process. "Clean code" is not the only way to accomplish this; processes and documentation are other things you can do. But I also think it's easy to make the case that writing comprehensible code actually has the best lifetime return on investment. It isn't hard to do - indeed, it's often easier to ship working features with well-structured code, and it requires less future toil than documenting a process that requires working around poorly structured code. But of course often times there is a tipping point where further tinkering with making code "clean" is no longer net positive. But I think codenames that tend toward I dunno, maybe 95% cleanliness provide good value to an organization.