3 Useful practices to becoming a better Software Engineer
This story begins at Foodstuffs in my first ever role as a software intern. Foodstuffs is New Zealand’s largest retailer helping companies such as Pak n Save, New World, and Four square run their businesses and help keep Kiwis fed all year round. Fresh out of university and excited to start my career, I rushed at every instance I got to work on something new. This was one of the most important parts of my journey because it was where I built my foundations as an engineer. It is very easy for us to talk about our successes but this is all about failures and how they made me into a better engineer.
Just ask
The exciting part about being an engineer is figuring things out. We take pride in our work and it is often difficult for us to ask questions. During my internship at Foodstuffs, I suffered from imposter syndrome. Imposter syndrome is a psychological pattern where an individual doubts their skills despite their education and history of success. My struggles eventually led me to fall back behind deadlines which pushed my entire team behind too. The lesson here is simple. Just ask. There are no stupid questions in the engineering world. There are just questions we have the answers to and ones we do not.
Understanding the problem
After Foodstuffs, I got a job as a graduate engineer at ezyVet, a veterinary software company that provides a cloud-based veterinary management system. In my first few weeks, I had learned the basics of the product and picked up a couple of bug tickets with my mentor at the time. Easy stuff right? Not really. Being overly confident didn’t help either. I picked up my first bug ticket with the training wheels off and what I thought would take me an hour or two took me two whole days. Do you wanna know why? I didn’t truly understand the problem. This point ties in closely with the first. In order to come up with a solution, you must first understand the problem and in order to understand the problem, you need to ask questions. I cannot stress how important this is as an engineer. Whether it is understanding API documentation you are trying to use or a product spec you are currently implementing. Understanding is everything.
Always verify, never assume
A couple of years fast forward and now I’m a full-stack engineer at SpokePhone, a communication platform built on Twilio. Switching from working on a monolithic application into a microservice one was a bit tricky. It was a whole new way of thinking and to be honest, I’m still learning a lot about it. Shortly after joining Spoke, I began working on a feature that would display a new column with some results. For this, I added a return payload type that stored information for that column. I assumed it would automatically work and display the results on the client’s end once added but it did not. This was because it was undefined and I did not verify that was a possibility. This goes without saying but always verify your shit. I know it can be very complicated with many different data sources and services in play but always take the time to make sure what you expect is actually what you get.
Being a software engineer comes with many rewards and opportunities all over the world but it also takes time, practice, and a lot of patience to become better. Remember that there are no stupid questions, understand the problem no matter what it takes, and most of all that you never too experienced enough to not verify your </work>.
