Testing

Testing testing testing, it’s one of those things that as a graduate you don’t put a tonne of thought into. You’ve had lectures and senior developers tell you it’s important but do you listen? No of course not, you know better, besides you can’t create new functionality if your testing the old stuff. You can’t move onto the next card if your stuck testing the old one. You don’t feel productive if your not adding new features or fixing bugs. Yet the longer you go without testing the worse it becomes. I went into my first job thinking I should test every single line of code, just like my lectures had taught me and the books I had read had preached. Yet after a few months of doing some very terrible tests that lets be honest didn’t actually test much, other than the language itself. I kind of gave up on testing, using the age old excuse of: “I don’t have time” or “I’ll get to it later”, of course as we all know, you don’t get to it later and yes you do save time in the short term, but you add twice as much if not more in the long term when you have to revisit your code because it’s complete crap and doesn’t work as it should. Yet I would still not test, till one day after fixing similar crud functionality for the fourth time, I said “Fuck it, I guess I’ll write a test, so I don’t have to fix this shit again”. So I did, I got serious about testing my code, I wrote a test that tested a successful instance. There is way more to testing than a successful outcome, so I tested a few failure conditions, some weird data being put in, and a few different user roles. In the end I had written 20 test, I was feeling pretty good about myself. What was even better is that I haven’t had to go back and fix anything because it works, as intended! I learnt a very valuable lesson, one that lets be honest I should already know, but like many things in life you won't learn the lesson till you go through the pain. It’s exactly like when your mum told you not to do something but you did it anyway because your a kid and kids don't listen to anything their parents say. So you go out and do that thing your parents told you not to do and you hurt yourself, you had to learn the lesson the hard way and once you did you didn’t forget it. As my dad always said “It’s times like this I wish I had listened to what my mother used to say. What did she say? I don’t know, I didn’t listen”

You have to learn things the hard way. I can tell you all about how I didn’t write tests and it came back to bite me in the ass but until you go through the process of not writing tests, your code has bugs in it and you have to go back and fix it multiple times. These are the things you just have to learn for yourself and you will, your first year is going to be one big learning experience. Going from the theory based world of university, where you have all these lectures who deal with theory, yet don’t seem to have any experience with anything from the real world. Furthermore, you get the lectures that have worked so long on the C++ kernel that they have no idea how to actually teach a subject and just think their way is the only way, better yet it’s the best way. Then on the other hand you have the self taught programmer who will spend a majority of their time learning from books and youtube, maybe a few code camps. This type of developer has a very different approach than the university student, yet both are more or less the same: inexperienced, eager and full of mistakes. It’s only when you spend time around better, more experienced developers that you realise you don’t know anything. Testing is one of those areas where you really find out how important it is and how much of an art form it is, the other is code reviews.

Code reviews

Code reviews are one of those things that is quite scary when you submit your first pull request and lets be honest it's scary for good reason. I remember when I submitted a PR, not my first one, but definitely an early one. I got over 100 comments, tearing it apart, in a nice way of course, but it was three very experienced developers questioning every bit of my code. Saying why did you write it like this? You don’t need that? That's just going to create more bugs. Now they were all very nice, and they assured me that it’s nothing personal. I won’t lie I felt pretty shit afterwards, but after I digested the “attack” on my code, I realised that it wasn’t anything personal and they were just trying to improve my code, trying to make me a better developer and help the team as a whole. Since then I’ve gotten a lot less comments on my PRs, I still get comments, what developer doesn’t. It’s good to have people critique your code, they see what you can’t. They see your code from a different perspective, you might have spent days on this problem and completely missed something, yet in seconds they can ask: “Have you thought of this?”. These alternate perspectives make your code better, it teaches you things, improves you each time. It’s just like a sculptor going over their masterpiece, refining it slowly and over time. It takes iterations to improve your code, to make it more secure, run faster and just look cleaner. That’s why it’s so important to have code reviews, I know places that don’t review code at all and these developers struggle, they don’t improve and their skills never improve because they’re constantly thinking their code is the best thing ever. Although your first dozen reviews might be brutal and if your part of a respectful team it won’t be personal. You have to take the comments on board, fix what you can and ask for help on what you can’t fix.

If being selfish and wanting to become the best developer you can isn’t a reason to have a code review, you might want to think about some of these. Code reviews allow you to check that the requirements are met for the problem you’re trying to solve, there will be fewer bugs, and one of the biggest ones is the cost to fix defects. Fixing defects as early as possible in the life cycle of a software project is very important. An ugly bug that raises its head at the end of the project can be devastating, but the same one found early on can be fixed easily. There will most likely be less code written on top of it, less code that relies on it and more time to actually fix the problem. Checking that you’ve met all the requirements for a ticket allows you to properly close it off, to say yes it’s done and not have to go back to it. Having others inspect your code reduces the number of defects that happen, more eyes on the solution, finds the holes in the sail that is your code. Code reviews are a very cheap way to fix issues before they become bigger issues. They allow your senior developers to mentor the juniors, improving the team as a whole. As the saying goes a chain is only as strong as its weakest link and a team can’t succeed if the weakest link is constantly introducing bugs.  

Code reviews and testing are all part of improving the quality of your code, they are simple yet effective techniques. Code quality, consistency and readability are all vitally important to the success of a project and the less time you spend fixing bugs the more time you will have to produce more features and the happier the client will be. The client expects zero bugs and although that's impossible, you can go a long way in reducing the number you actually do create. The more time you spend on writing unit tests, integration tests, whatever tests you can think of, the more time you save future self and others. The more time you spend code review the faster the team grows as a whole and the less bugs you produce. It also gives you a chance to see the problem solved, creating a discussion before it gets merged in and forgotten about for awhile. It gives you the chance to discuss if that's really the way to solve it, if that's really a problem and if more problems arise because of this. Don’t be like me, test your code and don’t complain when it gets torn apart by people with much more experience and knowledge.