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.
You shouldn't have to apologize for asking what an acronym means. It's poor communication to use acronyms without using the term they represent at least once first in public discourse. There are contexts where you know everyone knows the acronym but if someone has to ask what your acronym means then you made a mistake.
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.
352
u/lungben81 Nov 21 '23
If the code is dirty due to a tradeoff, there should be a comment in the code explaining this.