6 Things I Wish I Told Myself When I Started as a Software Engineer
Advice from someone who's been there
tldr; read the stack traces, lean in when you are uncomfortable, and think deeper about what you are doing
Back in 2014, I graduated from college with a degree in chemical engineering. I quickly realized that field was not for me. I ended up teaching myself computer science and got my first job as a software engineer at Refinery29. It’s normal and natural to make mistakes, but plenty of them are avoidable. After some reflection, I’ve narrowed it down to 6 things I wish I did differently when I started programming.
Advice
Read the Stack Traces
I cannot tell you the number of times I would ask stupid questions because I couldn’t figure out what was wrong with my code. I would get stuck and I’d ask the senior engineer on my team for help. More often than not, he would roll over to my desk, look at the stack trace, and read me the answer right off of it…not a good look.
It was so hard for me to read that block of red text. It was intimidating and I just never wanted to do it. To no ones surprise but my own, reading the stack trace almost always gives you actionable information on what is wrong with your code. If you just take the time to read it, you can save yourself and your team a lot of frustration. Sometimes I'll even read the stack trace outloud to prevent myself from skimming it.
Identify Where you are Uncomfortable and Lean into it
It took me two months to open a JSON file. I didn’t know anything about them and every time they came up at work I would avoid being involved in the conversation. I had a mental block that came up every time I heard someone say “check the JSON” file. It wasn’t until I accidentally opened one that I realized how simple they were. I can’t believe it took me that long to even try to learn what they were.
The real lesson here is that avoiding a topic because it makes you uncomfortable can hinder your progression. The sooner you lean into what makes you uncomfortable, the faster you will grow as a software engineer. As they say at Replit: “seek pain”.
Think About the System
As a junior engineer, I only really thought about the specific files that I was working on. The system was all broken up into disjointed pieces in my mind, and I never took the time to understand how everything came together.
What really allowed me to level up was thinking about the entire system as a whole. I made sure to actually think about how my changes were going to impact the system, not just the function I was writing.
Understanding the system will allow you to write better code and avoid bugs. You’ll also become a better communicator with your team and make smarter decisions. If you haven’t already, try creating a system design doc and checking with a senior engineer to see if you got everything right!
Avoid Unnecessary Refactors
It’s easy to justify your own inefficiency early on to non-technical stakeholders by saying things like “this codebase is a mess!”. There will be a natural urge to refactor code that you didn’t write. You should fight this urge unless you really need to. A good rule of thumb is that you should always have a measurable metric you plan to improve with every major refactor. One time, my team spent months working on a complete API rewrite to “clean the codebase”. When we finished, although the code was “cleaner”, nothing measurable had really changed. Management was confused as to why the entire team just spent months rewriting everything to have 0 measurable impacts on the business.
Do not Undervalue Communication
When I was studying for programming interviews, I learned how important it is to be able to talk about your code. It contributed to me getting offers at Facebook & Google and to my ability to talk through the work I was doing. It is helpful also as you grow to be able to communicate your ideas. As a junior engineer, you tend to write the code you are assigned. But, as you work your way up to a senior, where you are designing systems and delegating tasks, communication becomes increasingly more important.
Understand the Metric for your Team and Department
Once I understood the goals of my team and what we were working towards, it helped to improve my decisions and my code. I of course always knew the goals of my team, but it takes just a second longer to actually think about the actual metric and apply them.
If you are someone that is consistently making decisions around the team’s metric, it will build trust with your teammates, manager, and department.
Conclusion
Overall, just think a little bit deeper about what you are doing when you start your career. It all contributes to the bigger picture. Don’t be afraid to ask questions and be confident. Also, remember not to be too hard on yourself when you are starting out. You are going to make mistakes but as you continue to learn from them you will grow and evolve as an engineer.
Feel free to hit me up if you have any similar stories or want to add any advice. The more we can share with future developers the better!
Join the Community
Hackpack is the most active community of engineers studying for programming interviews. We hold each other accountable, provide support, and fight burnout to study more efficiently and get the job faster.
If you are in need of a study partner - apply here: hackpack.io
I tweet interview tips here
Programming Interview Prep Events (Upcoming: Q&A w Senior Meta Engineer)