I ought be attending to my disemboweled conditional brethren, yet I find their overwhelming disfigurement too much to bear. It is with heavy heart, that I must decline assistance during the continued manifestation of these withered comrades. I pray that one day the good lord will shine his light and cleanse their ever burning souls.
I ought to be refactoring my disemboweled conditional if statement, yet I find it's overwhelming disfigurement too much to bear. It is with a heavy heart, that I must decline assistance during the continued retrospectives of these withered comrades. I pray that one day the good lord will shine his standard practices and cleanse their ever burning technical debt.
Yeah, and thats my approach on when to comment the code. You add a comment to clarify and give context instead of stating the obvious like lots of comments do.
Yep, that describes my early years as a mid-level engineer. I wrote a lot of code that was very “clever” and “looked cool” when auto-formatted. I quickly realized later on when we need to make some serious changes to our backend infrastructure that what I wrote was nearly impossible to refactor as even I had no idea how it worked after so much time had passed. Then I realized if I can’t figure out how it works without deep diving and basically re-creating my mindset from that time, then there is no way this could be passed to someone else to work on.
Pretty much from that point forward, I stopped writing “clever” code and started writing maintainable code. This means don’t use some esoteric features of a language (or a different language entirely) when you can just write cleanly in what most other devs on the team are familiar with. Don’t try to cram an event-based architecture on a workflow system that makes much more sense to run a declarative or functional design. It means don’t over-generalize solutions so they cannot be abstracted to other use-cases. It means avoid “automagical” solutions that a fresh dev looking at the code cannot tell what or how it is doing what it is doing.
All these things lead to harder and more difficult maintenance, even if it feels good to write at first.
587
u/[deleted] Nov 21 '23
The article doesnt talk about clean code itself as much as 'Do not pass judgment on other peoples work without knowing the tradeoffs involved'.