Over-engineering; which is somewhat of an anti-pattern to KISS, Keep It Simple Stupid, is something that engineers eventually do when they actually want to learn something. If only I got a penny for making a to-do application in every framework that I've tried 🙂. But that's the beauty of overengineering! You don't seem to understand the "where-s" and "how-s" of infrastructure in production codebases unless you actually get your hands dirty! So why is it still an anti-pattern?
Documentation can only take you so far.
One cannot stress the importance of documentation. There's nothing more satisfying than looking at some clean documentation. But having said that, you give only as good as you get, so how much do you actually get from the documentation? Documentation is best for when you have this crazy bug or reached the depths of StackOverflow.
Learn-by-doing, yeah we've heard that too. We've all seen people with a billion projects on their Github Repos. Things could get quite intimidating indeed. WhatsApp Clone, Facebook Clone, Twitter Clone etc. It's about time people made a WhatsApp Clone Clone, if that even makes sense, but again how is this different from over-engineering?
Making a case for over-engineering.
Over-engineering isn't about making the next WhatsApp, it doesn't have to stick out on your resume and it's most certainly not about becoming an entrepreneur. It's about design principles and solving actual "engineering" problems. It's about best practices and it's probably your best shot at giving your system design interview. It's about high-level understanding (okay now I'm selling it sorry 🥱). It's for the OCD maniacs, it's not about making things work, it's about making them right.
Okay, let me cut to the chase, What do I mean by over-engineering? To build/ understand infrastructure. As simple as that. Drop the business use case, that's for your workday. It's no longer about what you are building, it's about how you are building. And getting passionate about the next fun thing to mess around with.
Common Mistakes:
You have a great idea, you've mastered the middle-out algorithm, and you're on your way to becoming the CEO of Pied Piper, yay no one stopping you congrats! This isn't about that. You have a great idea go ahead. This is all about learning a tech stack, the correct way, your WhatsApp clone works, good for you also (check out my WhatsApp Clone) but it's more than that, it's about writing clean code, getting the things that make it work/ scale right, it's about security, it's about infra.
Screw the "business-use-case"
It's the only time it's okay to get lost in your world of perfection.
Focus on best practices and design principles.
Don't forget security and scalability. Not that anyone is going to hack your to-do application, but you get the idea.
Play with the infra, no-code is actually fun.
It's not to make a step-by-step guide, it's about abstracting a high-level concept.
And we love diagrams.
Finally, I'm planning to write about Overengineering practices here, also a shameless plug-in of this website/ blog that I've just hosted. It's in development. It's a pretty simple app which lets you upload articles about over-engineered projects in simple markdown. So in short I'll be discussing design practices here, while I upload the implementations/ ideations on my website, which clearly has been over-engineered/ being over-engineered. This is a try at open-source as well so wish me luck.
Having said that, I will post the ideation of my website on both Hashnode and T.O.P.'s website, because Hashnode is ♥. I hope this rather introductory article on overengineering was more than just a rant and I hope to be consistent with writing here and on my website.
You might be wondering what T.O.P. is well it's The. Overengineering. Project. 🚀