The First Thing To Do As A Software Engineer
After my first 5 years as a software engineer, I moved from South Florida up to the Tampa Bay area and started working at a biometric security software startup. Since I was the most senior C# developer in the office and had management experience from the military, I was tasked with managing the .Net team in the office and another in Mexico.
I had to strategize and work toward my success. I was hired into a position I wasn’t sure I was ready for, but I wasn’t going to back down.
The First Thing
I had to get up to speed quickly to start making progress on two of their products. I started reading the code for one of the products. I followed the flow from the login screen down through the layers to the database and did the same for each screen. I took notes, drew diagrams, and wrote down questions. I was done in a week with one product, had a lot of questions, and had a notebook full of notes.
I immediately learned that this one thing would be what I would always do with new companies.
Why Read The Code?
A lot of developers dive right into the code when they get hired and figure out where they need to go to make changes, add a new service, or which stored procedures to update. I had been reading the code for each new company I started at and it had helped me tremendously, but I wanted to see how long it would take if I didn’t.
I skipped reading the code at one company to test how long it would take me to get up to speed. I struggled for weeks trying to understand how the code worked and where I needed to go to make simple changes. I made mistakes and had to rework some of the changes I made; not a good look.
Eventually, I spent some time reading some of the code and got a better understanding.
Reading the code helps in various ways:
- It shortens the time you need to get up to speed. Spending a week or two reading the code is time well invested versus trying to get by attempting to figure out where the file for a specific web controller or a DTO is and having to ask another developer each time. You will be and look more competent when you invest that time upfront.
- It helps you to understand the architecture of the code. Is it an MVC pattern, are they using IoC (inversion of control), and what is the standard practice among the other developers?
- You get to understand the business objectives and get to play with the product/service as the customers would. Without getting properly trained, you start to see what the customer sees (customers often never get proper training) and have to figure out how to use the product. Is the interface somewhat intuitive and are you finding any bugs?
- You get to write down all of the questions about the product and the code. Why is the business implementing this feature like this, why hasn’t the business implemented this feature, why did the developers use one pattern versus another, and what’s the roadmap look like for new features? Your questions become more informed and thought-provoking.
Make It A Habit
Reading the code has been my go-to for a long time and I encourage new and seasoned developers to invest that time before writing a single line of code. Consider this as the first code review you will have with the code. Managers and company execs understand why I make that request and welcome it as they’re paying a lot for experienced developers to take their vision further.
When you’re the one hiring a new developer and giving them the time to read the code, you spend less time explaining how the code works, and why the code is written a certain way, and spend less time answering simple questions and focusing on the deeper questions.
Final Words
After reading the code, the next best thing would be to understand the business. I’ll talk about this in another article.
Do you read the code at each new company you work at? What’s the first thing you do?