In addition to the fact that I write garbage code, this is one of the most important skills I'm still acquiring.
If you're a developer and have the same attitude as I do, you view your coding endeavors as pieces of art. With every new package, library, or application you create, you invest a lot of thought and effort into writing good code. It's something you give a great deal of thought to, something you respect and take into account.
I've always seen things from that perspective, and I'm working to change that thinking.
It appears a little absurd that someone would want to cease creating Great CodeTM with such care and effort. Shouldn't we follow the advice, hints, and "best practices" that the greatest developers of all time have proffered? Well, maybe in a few ways. The same perspectives, however, have also prevented me from moving forward.
The "web is your oyster" if you want to learn top-notch language-agnostic software design or how to write effectively in any language. The community that surrounds those teachings enables you to quickly determine what material is bullshit and what is gold, just by the masses curating the knowledge for you through likes and shares. The mentors in the industry have made it very easy to freely obtain the knowledge to write software masterpieces.
It is admirable to aim towards flawless and error-free code, and by following the best practices, avoiding common mistakes, and avoiding the worst industry practices, you'll probably achieve this Nirvana. Nirvana is difficult to achieve, though, if you become overly devoted to the concept of it.
You probably develop stuff for a firm, unless you're really lucky. It doesn't really matter if that business is your own or not. What matters is that businesses are obligated to these things we term "customers." If you can image it, clients also like to return their purchases and wish to do it swiftly. No customers means no money. No revenue, no business. Neither a corporation nor developers. You won't exist without coders. From the buyer all the way to your source of income, you may create a straight path.
I bring this up because it drives home a very important point: if you're creating something that your client wants to work, ignore the rules. Notice that I did not say toss it out but rather toss it aside for a while.
I've fallen into countless rabbit holes when trying to overplan and make my first edit just so. It's referred to logically as "premature optimization." I'm doing my clients and myself a disservice by placing too much emphasis on "best practices" when the feature I'm working on doesn't even operate.
Here’s where the “garbage” part comes in.
Even though it pains me to say it, the code I create will probably be removed, changed, or at the very least significantly refactored. Perhaps the features I create will be extensively used and end up being essential to the program. In that case, it will probably be refactored rather soon after the release into something lovely and finally adhere to "best practices." However, it's possible that the feature never gets utilized (you might be laughing, but it's happened to me more often than I'd like to confess). No need for restructuring; striving for perfection would be pointless.
The challenging aspect of anything is that, once I discover the "correct" method to do things, doing it any other way damages my ego and undermines my excessively perfectionism way of life. To get around this, though, I've been employing a cute little technique. I merely have to remind myself that finishing projects quickly exceeds the benefits of meticulousness and that I have focused all of my mental energy on finishing projects rather than making my string of characters resemble the Mona Lisa() to some fairy tale DiVinci who will never see her in person.
Just keep in mind that the new feature just needs to work, and the code you use to make that happen will likely be indistinguishable the next time you see it, if you ever do. Apply a bit of that excellence you hold so passionately if you do come across it again.
Make stuff perfect once you get shit done.
Want to thank me 😅, buy me a coffee ☕️ here
Top comments (8)
For side, throwaway, projects I agree... it's "garbage code".
For actual projects, I prefer to call it "first draft code".
I blame content creators that make it seem simple and logical to make "perfect" code from the get go.... nobody codes like that. (I do, however, understand why they do it.)
Do you mind sharing your pint of view
No one do perfect code from start to finish.
Each new feature I do is a whole disgusting mess... but it works.
Then I refactor it until I make it right (or at least "good enough").
And every time I go through that file to add stuff, I improve on it.
First draft? Yeah, that's ugly. But with refactor iterations it gets good.
And if it's a throwaway piece of code, then it just doesn't matter how ugly it is as long as it's working. But that's mostly because it's a piece of code you're not gonna iterate over and over.
That is great 👍
Just make it work pragmatism reminds me of Sandi Metz' talk Go ahead, make a mess! It's okay to make things work and not to strive for perfectionism or even clean code in all parts of your work. Sandi presented a technique of allowing yourself messy code at least in contained parts of your work and rather containing the "mess" (or "garbage" as you call it) instead of trying to fabricate or refactor everything to 100% of clean code perfection. Also backed by the concept of YAGNI (you ain't gonna need it).
Thanks for your post!
Sandi Metz ideas about hiding the mess behind non-messy interfaces is a pillar of my approach to software in general.
Good, tested interface means the innards can definitely be messy 😅
😂😂
Glad I could help 🙏🏽 You can buy me a coffee here