Advice That Changed The Way I Look At Code
After attending the Hashnode Bootcamp session by Anna McDougall, she changed the way I look at writing. It took me back to a time when I was a junior developer, and something my team lead told me changed the way I look at code.
I am sure we all had those moments where we were scared of starting from a blank file, but I think there was an even more intimidating scenario than that. That is working on a high value existing solution. As a junior developer, when we identified poorly written code, we always steered away from changing it because it was "working just fine".
Indeed "working just fine" was good enough, and so we set on growing as we code, avoiding large portions of code or worst yet avoiding to prioritise specific feature requests.
That is not the quintessential path for a junior developer to walk as we learn bad habits and shy away from challenges. It's surprising that in some teams it is encouraged not to change certain parts of the solution due to the intricacies of them. My one team lead had a different opinion that changed the way I look at code!
My team lead back in 2015 looked at me and said that our generation has access to soo much information that we could overcome any coding problem if we searched and tried hard enough. The power is at our fingertips, and collaboration has never been easier. He then said this, which changed the way I look at code.
He said: "At the end of the day, its just code! You should not be afraid to break it or better yet, try to find a better way of doing things. It is a trait of a good programmer to be courageous and "leave the code cleaner than you found it.". It may lead to working a few more hours, but you will learn soo much."
The phrase "Leave the code cleaner than you found it." is a famous phrase that Uncle Bob uses in his book clean code which comes from the boy scouts rule which is is: "Always leave the campground cleaner than you found it". When you find a mess on the ground, clean it, doesn't matter who did it. Your job is always to leave the ground cleaner for the next campers.
I changed my approach when working on existing solutions; however, it was clear that I would first break everything and feel overwhelmed. My team lead affirmed that its okay to break the code if we are trying to find a better way of doing things and that asking for help to improve our solution will not be frowned upon. He also assured me that because we use source control (version control for our code), we can easily just revert to the last working version.
It was after that conversation did I truly grow some confidence when coding, knowing that there are many ways to get unstuck after breaking the codebase.
AFTER ALL... ITS JUST CODE!