Don’t Rush
The worst code I ever wrote was when I was rushing. As a junior I did a lot of stupid things, I wrote some horrible code, I didn’t test database migrations properly which ultimately broke a production database, I produced security holes, you name it I probably did it. I distinctly remember one time when I was creating a migration, it worked fine locally when it migrated, but what I didn’t account for was the change in name of some fields. In Elixir and it's amazing library Ecto it can handle a lot of the migration and rollbacks for you. However, months prior I had named two fields incorrectly something like fields_one and fields_two and it should have been field_one and field_two. Now in the migration, it changes them no problems, but Ecto can automatically rollback a lot of changes, it's very smart that way, but it's not God. It can’t rollback everything, especially when you change the name of a field. Of course, locally I would migrate but never test the rollback. I also didn’t try the migration on the production dataset, why? I was rushing of course. In production it did the migration, it failed and then the rollback also failed. Fuck, I call the senior developer at the time, freaking out of course as production is now completely down. We spent the next few hours trying to fix the production database and get it all back in shape. The hours I had waisted fixing production, as well as the hours of the senior developer, could all have been avoided if I hadn’t rushed. If I had just taken a few minutes to test what would happen if I rolled back. Now the solution was pretty easy but to undo the mess that this created was hard and it took a while, so why didn’t I just take the time in the first place to do it properly? Well, I’m a junior so I make mistakes and for some reason, I had it in my head that if I’m not blowing everyone away with how much code I can write and how many tickets I can complete then I’m a failure. My goal was to produce as much code as possible, to complete X amount of tickets a day and if I got stuck or if I took to long on a ticket then people were judging me, thinking that I wasn’t good enough for the job. This, of course, resulted in me rushing through tickets, rushing through my code, not testing properly, not thinking of the consequences of my code. Some might argue that my code should never have gotten to production, someone should have picked up on it. Well we were a small team, a team of only 3 developers and yes we had peer reviews but the senior developer can’t pick up on everything and still do their job. This meant things fell through the cracks, issues arose but now I had the tools to deal with them. Although I completely fucked the production database which should never happen, I did learn how to fix it. I also learnt a very valuable lesson on how not rushing.
I would like to say that I was completely absolved of my rushing habit, well I wasn’t but I really improved. I wrote better unit tests, I wrote better integration tests, I even wrote better migrations and rollbacks. I spent more time on each ticket and I tried my best to get rid of the issues I had with constantly needing to produce X amount of code, otherwise, I was a failure. It takes time and I’m still working on it now but it's gotten a lot better.
It was a very humbling lesson that I learnt the hard way. I had a client typing at the speed of light as to why production was down and no clue how to fix it. Once I calmed down, consulted a senior and fixed the problem with his guidance it was alright. Although it's probably not the greatest way to learn this lesson, I wouldn’t have it any other way. I learnt that you need to spend more time on what you produce. That it’s okay to spend longer on a ticket, there will always be more tickets, rushing through this one will only reward you with another. If you took one look at our trello board you would see that we had a lifetimes supply of tickets to complete. No matter how many hours you devote to the project there will always be more bugs to fix, more text to change, new features to add and complaints to address. You could have a million developers on the project and the number of tickets would just grow. What's more important is producing something of quality, not introducing more bugs down the road, or creating tech debt larger than humanly conceivable. Testing your code properly and in a way that will catch the most paths possible. Taking the time to write your code properly the first time will save you so much time in the future. It reminds me of a time when of course I rushed through a ticket and it went into production, it had some bugs so the appropriate tickets were raised. Now my next task was to fix them, well I did, tested it, pushed it into production. Wow, that was quick already fixed, well more issues were found that I didn’t think about, possible flows that I didn’t think of that resulted in more bugs of course. More tickets were raised, more bugs were fixed. Of course, I rushed those too! If I remember correctly this one ticket consequently raised about 4 sub-tickets of bugs that if I had spent 10 minutes I would have realised that it was going to be an issue and I could have fixed it. Yet as the silly junior I was I rushed through it, determined to get the ticket completed as fast as possible and it resulted in many more hours of work, much more than if I had just done it in the first place.
It doesn’t matter what level you are, you need to take the time to complete work properly, it doesn’t need to be perfect, because it won’t. It does need to be properly tested, thought out, planned and peer-reviewed. The need to rush out my code was entirely created by myself, no one said “You’re to slow”, nothing like that, it was entirely my own doing. I’m not sure where it came from, but when I got rid of it, I produced much better code and began to get a lot more respect.
I’m always learning something new and with Pluralsight I can have unlimited access to all things programming. But hold on, it’s not just programming. There’s photoshop, visual communication, manufacturing and design. There's a whole bunch! Sign up today and get a free 10-day trial!