As a relatively new developer (aka not coding since I could talk) when I step into a new code base that I have had no hand in writing, I try to write new code and solve problems the way the code was already written.
It was such a project that I stepped into with one of the larger projects I picked up when I started my new job. It wasn’t until I hit a massive wall that I realized that I was stuck in the code’s way of thinking, when I should have used recently accrued knowledge to
- give the stakeholder what they want
- update the functionality as per the spec
- get the work done faster, instead of overcoming issue after issue (though every approach has problems to diagnose)
My eureka(!) moment came right at the end of a day that I had spent arguing with the code, getting close, but not quite to what I wanted. I left my desk to wander around the office and let the back of my head work on it while the front of my head dealt with other stuff. Or at least got distracted by the beautiful view out the back of the building.
So often when we are coming into a legacy code base (I use this loosely in reference to the code I was in) we either want to rip it apart or stick to the style at hand. We don’t allow ourselves an in-between. In this case, I had gotten too deep in the stick-to-the-style camp. Being able to get to that moment was pivotal in my growth as a developer and in the momentum of the project.
Within minutes I had it working the way I wanted to, all because I took a step back. Many experienced devs are like, “well, of course!” But I think this is a lesson everyone needs to learn for themselves, and some people (me) need to learn it over and over again.
Don’t get so focused on the trees you forget to look at the forest.
One thought on “Mental Shifts”