Perfect code is the enemy of becoming a good developer
I am a perfectionist. I always want my code to be flawless and bug-free. Right from deciding the variable name to the commit message in Git, I will aim for perfection. Sometimes I have spent minutes deciding a branch name in Git. There you go I said it, I accepted it.
But, one of the things I've learnt so far from my developer journey is trying to be a perfectionist comes in the way of becoming a good developer. Yes, every developer wants their code to be perfect. But little they know is that no code is perfect, it's only ever good enough.
You want your code to be as perfect as a flawless diamond. But I tell you, almost every diamond on earth has some flaw in it. That flaw shows the uniqueness of the diamond and it's even used to identify the diamond.
Better a diamond with a flaw than a pebble without.
No code is perfect than "no code"
The perfect code does(not) exist. And the only way to achieve perfection is to not to write any code. If you take Linux operating system which powers 99% of the internet's servers around the world, it has so many issues as of even today.
If the contributors behind the Linux waited for a perfect moment to ship their code, I am sure they wouldn't have come this far. Also, that doesn't mean that they are writing bad code. They are writing the code which is good enough to ship.
If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose.
– Kent Beck
Process should not slow down the progress
I love following the best practices for all my work. The first thing I do after learning the syntax and semantics of a programming language is to know how to design the code with the language-specific best practices. But allow me to play the devil's advocate here.
Make it work, make it right, make it fast.
– Kent Beck
Yes, we all know every developer should follow best engineering practices. It's how you can eventually become a good developer. But at the same time, one should not allow the process and the practices to come in the way of shipping the software release.
Let's take an example. You're building a web app to show the trending news in software. The final product should be able to pull news from different sources and display in a nice web page. You will start the project with the initial version in mind, it is going to be a simple web app that pulls software related news from a single source like TechCrunch.
The first thing you should do is, make it work. The initial version has to pull the news from TechCrunch. Now you have to write the boilerplate code for establishing connections with TC's API endpoint, see how their API is designed and how can you implement search queries using that API.
Then, you can simply display the results on a webpage. Now you have something to show for your initial version. Next, you have to make it right. Now you will clean up the code a little bit. Remove all hardcoded values, structure your projects, abstract your modules and write few tests.
Let's say, you have implemented OAuth to communicate with TechCrunch APIs. You will be abstracting it as a separate module so that you can reuse it when you add APIs for another news source.
Now comes the last part, you can make it fast. Since you've already implemented a working version and cleaned up the code. You can easily identify which part of the code is taking more time and fix them by doing simple benchmarking.
Remember, good developers follow best practices. Good developers also show progress. If you notice you already have started showing the progress in first step itself.
It's okay to have tech debts
According to Wikipedia, tech debt is something that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Technical debts are same as any other debt. When you're in shortage of something, you lend it and pay it back when you can. There are two things to keep in mind while you decide to get into a debt.
First, the payback is going to incur some interests, which is the tradeoff you are willing to make later, to get something done today. Second, not paying off the debt at right time is going to cause you problems.
Remember as any other debts, technical debts accumulates interest over time and not paying them off will cause you troubles.
But it's not a bad thing to have technical debts. If you have to develop an MVP, you have to be okay with the incurred debts to prove your hypothesis. Also while releasing a version of your software, you have to cut off nice to have things that doesn't go with the current release plan.
Then again, you should build your code base in such a way that you can pay back the debt in future. Code with tech debts is not bad code. Code which won't allow you to pay back the tech debts is the bad code.
Engineering is all about the trade offs you make on nice-to-have features to have must-have features
So, Don't wait for the perfect moment to start a project. Don't wait for your code to grow flawless to ship a release. The perfect moment is now, the perfect code is the working version you have now. Stop perfecting and start shipping.🛳️🛳️🛳️