Everyone needs to start somewhere. Becoming a trusted Software Engineer takes time, effort, resilience and determination.
There is no magic sauce that you can drizzle on your dinner that will automatically help you blossom into the Software Engineer you’ve always dreamed of becoming, but there are some things you can do to help you along the way.
I’m actually on this journey right now — I started in Data Science fresh out of university, which was mostly creating machine learning models and not much software development, but I then transitioned over to software engineering around 1 year ago. Here are a few things that have helped me in my first year as an engineer.
1. Push for Challenges
This has been the most important point for me. It’s obvious to say, but I’ve found that I learn a lot more in a particular area by putting myself forward for a task that I very well know is out of my depth. Maybe it’s a certain design pattern or particular testing library I’ve never used, or a service I have never seen.
If you only push for doing tasks that you know you can do, or tasks that are in a domain that you already know a lot about, you aren’t giving yourself the opportunity to learn a new skill and therefore increase your knowledge base.
Taking on challenges will be hard work, but the benefits that come from it afterwards are worth it. Your expertise will most certainly improve, and by persevering through a tough challenge, you will find it easier to deal with difficult situations and to handle your emotions.
2. Be Inquisitive
Let’s say you’re tasked with fixing a bug in a service that you’ve never seen before. It’s a relatively easy fix, it seems — you’ve seen that someone else made a similar fix in the code, but you don’t really understand why. Hey, if it fixes the bug, that’s all that matters, right?
Incorrect.
Sure, it will mean you’ve fixed the bug in record time and you can now move onto another task if you want, but how have you helped yourself? Have you learnt anything from it? Do you understand what the fix was so that if you had to, you could re-write the code in a more efficient way to therefore avoid bugs?
This is incredibly important when growing as an engineer. The more code you understand (even the most spaghetti-like code you’ve ever seen), the better you will become at understanding loops, design patterns, data structures, callbacks… The whole lot!
If you can’t work out what the code is doing by yourself through debugging and researching… Ask.
The knowledge and wisdom of other engineers can be your greatest resource, not necessarily the internet. This is especially the case when the code in question was written years ago, and there had to be a certain explanation for why the code was written so weirdly. This brings me nicely onto my next point.
3. Embrace Pair Programming
Pair programming is the practice of developing a piece of code or a feature with a colleague — one person writes the code (known as driving) and the other will discuss, support and suggest next steps.
Before I tried it, I wasn’t sure I would necessarily enjoy it. Would I be judged for going wrong? What if I didn’t know how to do something?
I’m happy to say that I have been proven wrong in any case of pair programming. Pairing is not about proving your intelligence, or judging the other person for mistakes. Pairing is for helping each other learn and sharing knowledge, finding a solution quicker and writing more efficient code with two pairs of eyes, and improving your communication and ability to listen.
I would say that most especially at the start of your career, pairing can help you understand certain principles that would take much longer to find by yourself, and it can give you the support you need to take on new challenges that would take much more effort to understand on your own.
4. Believe In Your Effort
Of course, there will be times you’re faced with a problem that you just can’t seem to solve, either by yourself or in a pair. It’s getting to the point where you’re going around in circles, with 20 different search tabs open and you just can’t see the way through.
Your biggest strength at this very moment is your perseverance and belief. You may be working on something that’s out of your depth, but you’ve most likely been trusted to take on such a task because of your hard work in the past with working through similarly tough problems.
Nothing in life comes easy, but what’s most important to remember is that your effort and hard work are what got you to where you are. Learning the foundations of software engineering itself probably took a lot of effort, even if you didn’t realise at the time. That doesn’t mean that everything else will now come easily.
Push through, believe in your work ethic, and stay positive. It always helps!
5. Do More Than Code!
Of course, as a software engineer, you’ll spend the majority of your time writing code. At the end of the day, that’s why you chose this career.
But there’s more to being a software engineer than just writing software. You also need to have a number of soft skills to help you become more well-rounded, and you can find you’ll become a better software engineer by doing things that aren’t just coding.
For example, maybe your team will be a doing a few brainstorming sessions on some upcoming tasks. Instead of just being one of the contributors to the meeting (and risk losing focus for a moment), why not offer to lead the session and take the notes? This will help your communication and listening skills, as well as actually help you to understand the problem much deeper. When leading the meeting and writing up the notes, you will need to understand what you’re writing about. You will therefore inadvertently ask the important questions that others may miss.
Another example — perhaps you’ve just finished up a great feature? Present your architecture and prototype to the rest of the team. By practicing the art of explaining certain processes, methods and key results, you can improve a bunch of skills all at once. Firstly, you’ll improve your general presentation and speaking skills, always useful as an engineer. Secondly, by actually explaining ideas and thought processes to other people, you will understand the whole architecture much more clearly just by running through the explanation. What Robert Heinlein said was true:
“When one teaches, two learn”.
These are just a few things that I’ve been practicing every day to help myself grow as an engineer. I find that it’s important every now and again to check in with myself and make sure I’m still paying attention to these points.
As long as you continue pushing yourself, learning, collaborating, persevering and trying new things, you will always end the day as a better engineer than the day before.
