My First 5 Years as a Software Engineer

I can't believe I'm already writing my first 5 years in review as a <insert-your-favorite-title-for-developer>, but here we are! A few years of barely writing anything passed by and I could start this post by summing up all the excuses why I stopped investing time in writing, but I’ll spare you the details. What we will do is have a look at a few things that I’ve experienced in the first 5 years of my career. First things first...

Titles!

A title is just a label to define the role of an employee. Some companies might use Software engineers and others might use developers or programmers. "Potayto, potahto". But be aware, whatever the title may be, this doesn't necessarily represent the knowledge or skill level that this person has.

You might be thinking, why is this important? It's not, but that’s the point.

What I’ve learned is that I should consider everyone as equal, whatever the title the person may have, and ask those questions that might sound dumb. In the end, you should treat an intern with the same level of respect as your CEO.

Pick tasks that scare you!

We've all been there... New team, a new way of working, 15 new tools to explore and learn, and a whole new business to get accustomed to. This is pretty scary, certainly when some tasks on the board involve talking to different teams within the organization...

These tasks are the ones that help you learn the most. Don't pick up the tasks to change the color of a button because they look small and easy. Pick the tasks that require you to step out of your comfort zone, even if you need 3 times the estimated time. This doesn't mean that you should blindly pick big and complex tasks but you should try to coordinate with your team in order to pick these types of tickets. If anything, it will give you a great introduction to the organization.

Learn concepts, not syntax

A classic, but such an important lesson that should never be forgotten. In 5 years I've used MongoDB, PostgreSQL, MySQL,... as databases. I've written projects in Spring Boot, Python, Nodejs, and even C#... Used Google Cloud, AWS, and Azure as a cloud platform. This is not bragging or anything that I'm proud of. This will likely happen to you as well when you're working on short-term projects as a consultant and that’s perfectly fine. As long as you stick to learning concepts and not syntax.

Don't get me wrong. I do understand that syntax is important and sometimes you need to focus on specific technologies, but technologies are ever-changing and this won't stop. Most concepts will not change at the pace technologies are changing, which gives you the ability to adapt better to difficult situations. All of these concepts that you learn on the way will potentially help you solve your next big problem.

Before undertaking his craft, the artisan first sharpens his tools

We as engineers are constantly working on our computers, and it's invaluable to know as much as you can about it. This goes from learning a bunch of shortcuts while writing code to getting used to navigating servers via the command line. Every tool that you use on a daily basis should be sharpened before undertaking your craft.

This of course doesn't mean that you can't use tools that you don't know well. I'm just saying that you shouldn’t be cutting 5000 trees with a blunt ax. If you're looking for this specific challenge, don't let my advice stop you from trying!

Adding value

Adding value, as far as I know, is what employers want you to do the most. You should always try to add value to the project that you are working on. Adding value could mean increasing revenue for a product, improving user experience, streamlining processes, you name it. But it will not be easy since it might require you to speak up in tough situations or be silent in others but the outcome should stay the same.

I'm not just sharing this so that your employer is pleased with you, but this can also help you to prove your own value to the company in performance reviews. If you continually add value and improve at what you're doing, it's very difficult for employers to ignore it.

Stick to your values

This might be confusing, but we're talking about different kinds of values here.

I have a few values that are very important to me in my work. I want my work to be challenging, I want to learn new things, and I want to contribute by helping others within or outside of my team.

We all need money to survive, but I try to stick to the values that I think are of most importance to me, and if my job is no longer in line with these values, I should do something about it. I either search for a way to fit my values within my current role, or look for a new role within or outside the organization.

Breathe, Think, Execute

Early on in my career, I used to immediately start executing tasks before creating a blueprint in my brain or on a piece of paper of what the task involves. I would even say that I took the acceptance criteria (if the task had any) and started building on a solution for it, without thinking about the future of this piece of code or solution. Most of the questions came after the "completion" of the task.

A few of my favorite ones were:

• Can we deploy this proof of concept to production tomorrow?
• Will there be any problems if a lot of users are using it?
• Did we add the ability to support French, Dutch, and English interfaces?

You get the drill. Don't over complicate everything you build, but make sure you anticipate the future of your solution in a pragmatic manner. It will reduce the headaches, long hours at the office, and projects that go over budget by a significant amount.

Sidenote: Make sure to try and ask these questions as soon as possible in the process, certainly before making estimates.

Learn to say no

This is something that I struggled with and still do, but it's important to say no to things. Doing 4 extra hours of work a day for an extended period of time can cause tremendous issues to both your mental and physical health. It's great that you want to help the company, but those 4 extra hours (where only one hour is likely to be productive) won't fix the problem when you are out for 6 months due to burnout.

Feedback

One of the things that is often taken for granted is feedback. I'm very quick in giving someone a positive comment about something they did, and that's something I love to do. Positive feedback is great. Everyone loves to hear positive comments about their work every now and then.

Positive feedback is only valuable when there are multiple types of feedback. If you're not receiving constructive feedback, positive feedback is adding less value to you, which often makes it more difficult to process.

This feeling is normal since not all feedback is fair, but get used to receiving feedback by asking for it regularly. If you ask for feedback often, you'll be able to adjust and improve and if you don't, you'll eventually receive feedback that might be much harder to digest if you didn't ask for it yourself.

I could go on and on about the lessons that I learned in only 5 years, and I hope it helps you with navigating your first years as a software engineer (or whatever your title might be 😉).

You might disagree completely with everything that I said here, and that's totally fine but I hope at least one of these points can help you improve your career or serve as an affirmation for you. I think this blog post is also perfectly in line with my values to try and contribute positively to or help others.

Let's see what the next 5 years bring!