Just as a disclaimer, I am going to try to post my weekly blog with a unique title as opposed to “Weekly Newsletter – May 25, 2020” for example. I didn’t want my feed to be just filled with a bunch of weekly newsletter titles where the reader doesn’t have a good idea which posts may be of interest to them.
There was a funny Tweet I read a while back that said something along the lines of, “once it is committed to master and pushed to production it is then considered legacy code“. Some may laugh thinking that this is entirely inaccurate, but let’s take for example the case of soon after you are onboarding a new junior developer.
To that junior dev it doesn’t matter much if they’re looking at code written five years ago or written yesterday. They are likely given tasks by you or someone else to make changes based on client or customer feedback and that feedback may involve changing something written just yesterday. Working with these types of tasks offers the junior developer a learning opportunity because they have to review the “legacy code”.
I have done this many times. This allows me to learn and understand why something was written a certain way and also better understand the system as a whole. Many times the change I have been asked to make is made easier because I can reuse the data structure previously written and just make the changes necessary to accomplish the request.
There is no need for me to reinvent the wheel because I am learning from those who came before. The reason I knew I could reuse that code is because I took the time to truly understand what actions the methods were performing and I asked questions when I needed to understand better.
In a formal computer science education system I may be taught Dijkstra’s Algorithm but no one will teach me how to properly update the version of Guzzle being used to support ReCaptcha V3 and handle all the potential errors that may come back so that those errors don’t get posted to the CRM. But the legacy code performed what was necessary before with ReCaptcha V2 and the previous version of Guzzle, so it seems that that is the best place for me to learn.
Don’t get me wrong, some of those computer science data structures will come in handy, but while you’re still learning the ropes the problems you will be working with have probably already been solved by someone on your team.
This is intentional. This is what builds that backbone of your knowledge so when one day you are a Senior Developer you know all the “gotchas”. Cookie-cutter problems allow for a safe environment where the stakes are low to medium if you make an error and the code can always be reverted to the previous working state.
People will notice once you start to solve these problems with ease and begin to give you new problems that fall slightly outside of the cookie-cutter. These problems are more abstract and require you to do the research and consider what may be the pros and cons of various solutions. That time will come.
But while you are still working with these cookie-cutter problems, remember why you probably became a developer.
At the end of the day you are a crafts-person (junior devs too, just not a master-crafts-person). A good crafts-person can build you a brand new violin but a great one can also mend or fix one.
The problems of fixing and building are, in my eyes, equally important. Imagine what some great software or web applications would be without maintenance. They would likely be filled with bugs and experience code rot.
If you’re like me you came to this profession because you love to solve problems and you never want to stop learning.