Today it has been a year since I started my fulltime job as a DevOps Engineer at TRES. After studying four years for my bachelor’s degree in software engineering and traveling around SEA for five months I returned the 22nd of February to my old internship. The only difference now was that I was not an intern anymore, but a full-time employee.
I have always believed that it is a good thing to look back in the past at your own actions and think about certain moments or conversations when you learned something from somebody else or when important decisions were made. That is why I am writing this blogpost where I will look back at some of the things I have done and learned over the last year and what will be up for me the upcoming year.
Inform people
Most of us have regular sessions with our managers or team leads, typically focusing on project updates, milestone discussions, or resolving issues. However, it is crucial to recognize that these sessions are just a snapshot of our work. Our managers, busy with their responsibilities, might not be fully aware of our day-to-day activities – and that is normal.
In my experience, they should not have to ask us every day for updates. Instead, we should take the initiative to keep them informed. This approach helps them identify areas where they might offer support or resources that could advance our work. In the end that is part of their job.
Proactive communication is key. It is not about spamming them with constant updates, but rather about strategically sharing valuable information that highlights the impact and progress of your work. For instance, a brief conversation about a challenge you overcame yesterday or a milestone you reached can be incredibly insightful for them.
It shifts the dynamic from them having to probe for updates to being in the loop effortlessly. This not only ensures that the impact of your work is recognized but also demonstrates your capacity for self-direction and awareness of the bigger picture. By regularly volunteering this information, you position yourself as a proactive and engaged member of the team, which is invaluable in any engineering role.
Sharing knowledge and ideas
As an engineer, you have, in my opinion, the most amazing job of all. You can translate your knowledge and ideas into both commercial and non-commercial solutions. During our trip to Southeast Asia, my girlfriend and I spent a few weeks at an NGO in a rural village in Cambodia. There, we transferred our gained knowledge by teaching English and assisting the owner of the NGO with IT-related tasks.
Before this experience, I worked for companies focused on providing services and goods to make a profit. However, my time in Cambodia opened my eyes to the possibility of applying my software engineering skills in an entirely new context for the greater good. This experience not only gave me new insights into what makes me happy but also showed me the broad spectrum of opportunities available for engineers like us.
Another thing I was made aware of is the almost moral duty we, as engineers, have to share our skills and knowledge in specific subjects with other like-minded individuals. This realization is precisely why I strongly focus on knowledge transfer within my company and through various channels, including this blog. It is not just about applying our skills; it is about multiplying their impact by educating and inspiring others
Take your time to think
As a freshly graduated engineer there is a big chance you want one thing, and one thing only, building solutions by writing code. When I look back at the past year, I can identify a few instances whereby I started to soon with building the actual solution for a problem I thought we had. The entire process both for me and the actual solution would have really benefited if I had set a timer for 10 to 15 minutes and allowed myself to do some actual research before, I let my engineering like mind take over and start hacking something together.
Now I have learned it really helps if you give yourself those precious few minutes to think about a subject, do some small google searches about it and write some stuff down. Currently I really like the approach whereby I actually timebox the time to do some research. I set a timer and force myself to actually research a subject for a fixed amount of time before starting to think about a possible solution.
So, my tip. Set a timer for 10 to 15 minutes and give yourself that time window to first start to look for solutions online.
Get to understand the business and its legacy solutions
Something they do not really teach you in university is the entire concept of having to deal with legacy. This can be both from a technical perspective as well as some business processes that date back long before your arrival.
9 out of 10 businesses have to deal with some form of legacy one way or another. You as a freshly graduated engineer who has worked with the newest and most modern technologies might not understand why we would still develop or support that legacy code base. But you need to understand why that legacy solution is still there.
Perhaps that piece of legacy made the company a good fortune in the past and is not something we can just say goodbye to. What helped me was getting to know the business side of that legacy. Perhaps there is already an EOL procedure in place to gradually phase out that piece of software.
Knowing those things also gives you insights on how your new modern solution might be treated in the future. Whatever you are writing today might already be legacy in a year or two. Which is also normal and something you can’t really avoid. It’s part of the solutions lifecycle.
One thing you can do today is to make sure your decisions are well thought out and backed up by knowledge and insights. You should not want to rewrite your application every year just because some new modern framework came out.
Learn to appreciate some form of legacy and understand why it is still there. In the end businesses are there to turn a profit and that can only be done by having legacy.
Get stuff done
I’ve realized the immense value of becoming that go-to person in your team or company, someone whose hands are capable and trusted. When a task is assigned to you, your goal should not only be completing it but ensuring that the quality of your work reassures your team or your manager. They need to feel confident that entrusting you with a task is not only safe but beneficial.
This confidence is key; it is what separates a task being handed to you as a growth opportunity from it being perceived as a potential risk. If your colleagues believe they are better off doing the task themselves for fear of an unfavorable outcome, it is a signal to step up your game.
Keep your team updated. Do not wait for them to check in on your progress. Regular updates, even small ones, can go a long way in building confidence in your abilities. It shows you are on top of things and aware of how your work ties into the larger project.