IntroEver wondered why my employer is shelling out money to pay me?Do my colleagues enjoy delving into my code? Do I aim to ensure the happiness of my future self?Why bother writing tests when I have QAs?Conclusion
Intro
I really enjoy making super complex stuff to challenge myself. I'm always thinking ahead and solving problems that haven't even shown up yet. That's what keeps things interesting for me. Once I've got this awesome code ready, testing it or tweaking it myself just doesn't appeal to me. I'd rather have someone else test it and let me know if anything's off. But today, I want to convince myself why I should start writing my own tests. Get ready to see me being pretty tough on myself. Ready to dive in?
Ever wondered why my employer is shelling out money to pay me?
Well, it's not just out of generosity; they're essentially compensating me to produce code, even if it gets a bit messy, and to indulge myself a bit. If only they were mind readers, right? Unfortunately, businesses operate on the fundamental principle of profitability. So, my coding endeavors should either create or maintain business value. Now, let's be honest with ourselves, can you really survive without a paycheck? I highly doubt it. But hold on, not everything has to directly contribute to business value, right? Well, great! Seems like you're up for more.
Now, let's talk about the connection between creating value and writing tests. Manual verifications take up more time compared to automated test suites. So, by diligently writing tests, you're actually setting the stage to churn out more business value within a given timeframe.
The ability to deliver more value hinges on having robust automated test suites. Consider code as a living entity. It evolves and expands. With proper attention, it grows positively, but neglect can lead to undesirable outcomes.
In the realm of software development, you've probably noticed that, over time, you end up reading more code than you actually write. This underscores the importance of crafting readable code, something that not only pleases your current self but also ensures satisfaction for your colleagues and your future self.
Do my colleagues enjoy delving into my code?
Well, the optimistic answer is yes! Why wouldn't they? But let's be real for a moment. If I'm being honest, I have a soft spot for reading my own code more than others'. There's a subtle bias at play here. It's just easier to understand something you've written yourself. I sense a bit of self-bias; it's easy because you're the one who crafted it, remember?
Reading someone else's work, on the other hand, often leaves me scratching my head, trying to decipher their problem-solving approach. The only time I can grasp a colleague's code effortlessly is if it's related to a task I've tackled before. Otherwise, it's left for the QAs to catch any issues.
Here's the reality check. Nobody really wants to read others' codes unless absolutely necessary. And sorry, dearest ego, the same goes for your code. People are generally reluctant to dive into your code unless compelled.
Now, you might wonder how this relates to writing our own tests. Well, software development is an enduring journey. It begins with understanding the problem, identifying familiar patterns, and gradually typing out lines of code. But here's the catch, once I think I've nailed the solution, I hesitate to touch the code again. That's the root cause of code deterioration. It's a reluctance to test it anew.
So, you're probably thinking, "If I write tests, can I refactor my code?" Bingo! That's absolutely true. By covering all the corners with tests, you gain the confidence to safely refactor your code, making it more readable. The tests act as a safety net, immediately flagging any issues that may arise during the refactoring process.
Do I aim to ensure the happiness of my future self?
Dealing with badly written code that's a pain to change is no fun. We've all been there, right? How many times have you been slowed down by code that just won't cooperate? You wish it were easier to tweak. I've definitely been in that boat, and, guess what, most of the time, I'm the one who wrote that tricky code.
So, here's the fix: start writing your own tests. But hold up, you might be thinking, "I'm down, but I don't really know how to write good tests." No worries, we'll tackle that in another post. For now, just know that practicing writing tests while you're coding is key. Here's a quick tip: focus on how your code behaves, not just how many lines you cover. Kick off with edge cases, invalid inputs, and those less-than-ideal situations. Save the happy cases for later.
Once tests are there, make your code easy to read. It's super important to avoid future headaches. Best way to check? Get a friend to read your code and give you some feedback. It's a simple move, but it ensures your code isn't just friendly to you now, but to your future self too.
Why bother writing tests when I have QAs?
Ever wondered why bother writing tests when we've got QAs to handle it? Well, here's the deal, if your code is a messy puzzle that's hard to keep up with, it's going to slow you down sooner or later. Trust me, it's not a matter of “if” but “when”. Your once manageable code will turn into this clunky mess, and every little change or new release will just add more weight to the testing load. Suddenly, you're stuck needing more people and more time for testing. And guess what? The team might even decide to start from scratch and rewrite everything.
But, hold on! Writing tests is like your secret weapon. It lets you make changes to your code without breaking into a sweat. You get the confidence to push those changes live without worrying about everything falling apart.
Think of writing tests as your team's superhero move – it saves you all from the disaster of shouting, "Let's redo this whole software." It's like a safety net, keeping things smooth and preventing unnecessary chaos in the long run.
Conclusion
While writing tests isn't the sole factor contributing to maintainable software, I strongly believe it's a necessity. Crafting meaningful tests might take some time to get the hang of, but if you haven't mastered it yet, seek guidance – it's worth the effort.
Why write meaningful tests, you ask? Well, it's the key to making your software a breeze to maintain. It grants you the freedom to fearlessly refactor or tweak the code without worrying about everything falling apart.
And here's another perk – writing good tests reduces the stress when it comes to pushing your code to production. Less stress means a boost in motivation, making your work environment much more enjoyable.
When you apply tests correctly, you end up with code that's not only readable but also maintainable. It's like giving your code a solid foundation for the long run.
All these advantages add up, making you not just content but genuinely happy to stick around at the company. It becomes an opportunity to learn more and tackle a variety of challenges, making your experience there both enriching and satisfying.
If you enjoy reading this, please follow me on LinkedIn