Let’s break the rules! When it’s okay to write bad code.
There’s no such thing as ‘perfect’ code.
That’s one of the things I was taught whilst learning programming at a coding bootcamp.
Yet at times in the beginning, I always found myself getting caught up in the pursuit of writing ‘elegant’ and ‘efficient’ code.
You know the kind of code you can be proud of: bug-free, well-structured, refactored, functional, fast - pretty! 🌸
It wasn’t until one day when I got stuck on a task and had to ask for help from a fellow student friend, that I realised I had to change my approach.
We had to make a scoreboard for a Bowling game app, and I was so fixated on getting my scoreboard to look good (the ex-designer in me won’t ever quit 🙈), that I actually couldn’t figure out how to make it functional.
I asked my friend for help and she said:
“Sure you can take a look at my code, I know it looks pretty bad but it works.”
Did her scoreboard look amazing? No.
Was the code well-structured and bug-free? No.
Did it work? Yes.
That’s when I thought wow look at that, maybe sometimes writing bad code can actually be a good thing.
What is “bad” code?
When I say "bad” code, I'm not talking about writing messy or poorly structured code on purpose.
Rather, I mean allowing yourself to write code that may not be perfect, but that can help you learn and grow as a developer.
My friend wasn’t being lazy or nonchalant with her “bad” code, she was simply being a learner. A learner who prioritised experimentation over perfection.
Essentially, writing "bad” code can help you discover new approaches to solving problems and ultimately improve your skills as a programmer.
If I wasn’t so focused on making my scoreboard look pretty, I might have been able to actually get it to work!
When “bad” code pays off
Now my little scoreboard task wasn’t anything special. It wasn’t going get deployed anywhere and no users would ever have to use it.
But what happens when big companies launch with bad code? And when does it actually work well for them?
Let’s look at Twitter for example.
When Twitter first launched, it was plagued by a number of stability issues and frequent downtime. Much of this was due to the "bad” code that the site was built on, which made it difficult to maintain and update.
In particular, Twitter's code was highly redundant, with multiple copies of the same code scattered throughout the site. This made it difficult to make changes to the codebase without breaking other parts of the site.
Additionally, Twitter's code was not well-documented, which made it difficult for new developers to onboard and contribute to the project. This lack of documentation also made it challenging to debug issues when they arose.
Despite these challenges, Twitter was able to grow rapidly and attract millions of users.
The company invested heavily in improving its infrastructure and tools to better manage its codebase and address issues as they arose. This included hiring experienced developers, implementing better testing and deployment processes, and investing in better hardware and software.
Over time, these investments paid off, and Twitter was able to improve the reliability and performance of its site. Today, Twitter is one of the most popular social media platforms in the world, with over 450 million active users.
While the company's initial "bad” code may have caused some challenges in the early days, it ultimately allowed the company to move quickly and iterate rapidly, which helped it achieve success in the long run.
When it's okay to write “bad” code when learning how to code
I’ve discussed how the concept of writing “bad” code helped me and how it helped Twitter, but let’s look at how it can help you when learning how to code.
Here are 5 times when it's okay to write bad code whilst learning how to code:
#1 - Learning through experimentation
When you're first starting out as a programmer, it's important to experiment with different approaches to programming problems. This often means writing code that isn't optimised for performance or efficiency.
However, this process of experimentation allows you to develop a deeper understanding of how programming concepts work and how to apply them effectively in real-world scenarios.
#2 - Building prototypes
When you're developing a new software product or feature, it's often useful to build a prototype to test out your ideas and see how they work in practice. Prototyping often involves writing "throwaway" code that isn't meant to be part of the final product.
While this code may not be optimised for performance or maintainability, it allows you to quickly iterate and make changes to your design.
#3 - Overcoming analysis paralysis
Sometimes, when faced with a complex programming problem, it's easy to get bogged down in analysis and planning. However, writing "bad” code can sometimes be a way to break out of this cycle of overthinking and start making progress.
By writing code that isn't perfect, you can start to see the practical challenges of your project and get a better sense of what needs to be done.
#4 - Discovering edge cases
When you're writing code that needs to handle a wide variety of inputs and conditions, it's often useful to intentionally write code that is "bad" in some way.
By doing so, you can more easily discover edge cases and corner cases that your code needs to handle. Once you've identified these edge cases, you can then refactor your code to handle them more effectively.
#5 - Learning from mistakes
Finally, it's important to recognise that making mistakes is an essential part of the learning process. When you're learning to code, you will inevitably write "bad” code at some point.
However, once this happens, you can gain a deeper understanding of what not to do and how to avoid common pitfalls in the future. This process of learning from mistakes is an important part of becoming a better programmer.
Conclusion
In conclusion, writing "bad” code is not always a bad thing. In fact, in certain situations, writing code that isn't perfect can be beneficial for learning, experimentation, and iteration.
While it's important to strive for good code in the long run, there are times when it's okay to prioritise progress over perfection. By embracing the idea of "bad” code as a tool for learning and growth, you can become more agile, innovative, and effective in your work and elevate your learning journey.
Now go write some “bad”ass code! 🔥
From your fellow ever-growing dev,
Cherlock Code
💙 If you liked this article...
I publish a weekly newsletter to a community of ever-growing developers, seeking to improve programming skills, increase productivity and share knowledge within the exciting sectors of Tech, AI and Web3.
Get more articles like this straight to your inbox.
And stay in touch on 🐦 @evergrowingdev
Top comments (0)