Lessons from an Ambitious Young Developer

It all starts with a new Jira. You are given an assignment in a component you have never worked with, but you are a good developer and you estimate that you can finish the work in under a week. You are confident and ambitious and are looking for ways to show this to your team lead. As you start sketching out your dev plan, you realize the component you are working with is unnecessarily complex and you say to yourself “Hey, I could spend a couple days refactoring this code. It will be more work, but once I am done, the component will be a lot simpler and easier to work with!”. Even though no one asked you to do this, it will show great initiative, and it will make the component better for whoever has to work on it next. You decide that you are going to walk the extra mile and entirely refactor the code.

A couple of weeks later you get a support call at 7:30 am on a Sunday. Your code was just released to PROD so you know what’s going on. You pulled long hours this past week and even though you made the deadlines, clearly something has gone amiss.

The following paragraphs are my “Lessons Learned” from a very similar experience. I am putting them here in other to help other ambitiously naive developers avoid the mistakes I made.

Regression Testing is Important. No code should ever be refactored without a proper framework for regression testing. JUnit tests are not enough. A true regression test should cover most of your component and run through all the edge cases you can possibly imagine. It should also be easy to run and self-contained.

The component I worked on did not have a proper regression testing framework. This made things a lot more complex once I started testing in QA/UAT. We had to go back to earlier versions of the code and add a testing mechanism in order to have something to compare (thanks Mac). From now on, every component I design will have regression testing as part of its required functionality.

Refactor Small Chunks at a Time. Do not aim to refactor everything at once. Go small and test things as you go. Doing very large refactoring might be easier, but if you start finding bugs you are going to hate yourself for the decisions you've made.

Because of the complexity of the code, and because it was hard to test if my changes had broken anything, I did most of my refactor in a hand full of commits. Debugging was a pain.

Keep an Open Dialog with Your Team Lead. Your team lead is more experienced than you and he can probably save you from your own demise. Team leads are also busy and have more things going on in their heads than the rest of us. It is your responsibility to make sure you are getting constant code reviews and to communicate issues as they arise. They key here is to understand what upward management is. If you don’t know, you should google it.

Know When to Ask For Help. On this occasion, I had chosen to do this extra work on my own and I believed that it was my responsibility to make it happen. I was wrong. If I screwed up, I would look bad, but more importantly, my team would look bad as well. There is a reason we work in teams and not individually. This does not mean you can slack off and have others patch your mistakes. The responsibility is still yours, even if you don't have the time or the experience necessary to solve the issue. It took me longer than I would like to accept, but if I had not asked for help I would not have finished the work. Not even close.