This is my brutally honest advice to anyone starting a career in software engineering. I wasted years figuring out what truly matters, but if you want to skip the trial and error, then this is the advice that I wish I had from day one.

1. Code is the Easy Part

This took me years to learn. I used to think that writing code was the hardest part of being a software engineer. It’s a rare and valuable skill that many of us work really hard to develop. Because it was so difficult, it’s easy to tie our worth to our ability to write code, to think that the only thing that matters is technical ability.

The truth is, unless you’re writing an operating system or a database, there’s a baseline level of proficiency required to be an effective software engineer. Once you reach that, the challenge shifts to solving problems. And that can be much harder.

We spend so much time learning how to write code, which is a technical and solitary activity, and suddenly we have to operate as part of a team, work with non-technical people, and support users. The most successful teams I’ve been on had engineers who could communicate effectively with stakeholders, non-technical people, and each other.

For every lone wolf with amazing technical ability but minimal social skills, there are many more successful communicators. Even when it comes to code, you’ll have to communicate your ideas to other developers.

I now believe that the best way to progress as a software engineer is to first develop a foundation of technical ability, then dedicate time to mastering the soft skills associated with our work. Once you’ve built strong communication and teamwork skills, you can return to deepening your technical expertise, and continue this cycle indefinitely.

2. Burnout is not a Badge of Honour

I used to jump on every production issue and last minute request. Now, especially since remote work has become more common, there’s pressure to be available 24/7.

Early in my career, I thought working late nights and sacrificing weekends made me a dedicated engineer. I saw others do it and thought it was a necessary step to prove my worth. But burning out doesn’t make you a hero, it makes you ineffective. When you’re exhausted, you make more mistakes, become less productive, and feel miserable.

I’ve personally quit otherwise great jobs solely due to burnout. The best engineers I work with know how to pace themselves. They take breaks, set boundaries, and prioritise their health without guilt. This actually increases their stamina, energy, and productivity.

Pushing yourself to the limit is a tool you can apply for short term wins, but for long term success, you need sustainable work habits. Set boundaries, prioritise rest, and know when to say no. If you want a long, fulfilling career in software, don’t glorify burnout - focus on sustainable growth and balance.

3. Learn to Love the Boring Stuff

Your approach to documentation, testing, and version control separates junior developers from senior engineers. It’s not glamorous, and to be honest, I still don’t like doing it - but it keeps systems running smoothly.

Documentation is for future you (and everyone else). I developed the habit of writing documentation for myself years ago, and it has paid off repeatedly. I also write little scripts to automate repetitive tasks. I once dreaded restoring a database backup until I found a script I had written years ago that automated the entire process.

Automated testing is another thing that saves you time and effort in the long run. No, it’s not fun to write tests, but it’s essential.

Taking the time to learn how to use version control properly will save you a lot of pain. Git isn’t just a tool to email code to your colleagues. Learn proper branching and rebasing strategies, and you’ll be able to manage simultaneous features, bug fixes, and releases without breaking things.

I once lost half a day’s work because I didn’t understand how rebasing worked. Don’t put yourself in that position. Learn the boring stuff. It saves you more pain than it causes.

4. If No One Can Use It, It’s Worthless

Learning this lesson completely transformed how I thought about my work. A feature that technically works but frustrates the user is still broken. Bad UX kills good code.

You can write the most elegant, efficient, and technically sophisticated software in the world, but if users can’t figure out how to use it, then it’s technically useless. A confusing API, a misleading error message, or an interface that requires a PhD to navigate causes friction and turns potential users and collaborators away.

Developers make UX decisions all day, every day. As the people actually implementing the code and specifications, we make the final decision about how things should work. You might not be designing user interfaces, but every function name, API endpoint, and error message you write affects how intuitive your work is for others.

Code that’s clear and predictable makes life easier, not just for your future self but also for your users and your colleagues. The best engineers think like users before writing a single line of code. They ask: What’s the simplest way to make this work? and What would make this effortless for the user? The user could be an end user of the application or another developer. Writing good code isn’t enough. It has to be intuitive.

I’ve invested time in learning how to design user interfaces and spend time thinking about how to make my code as easy to understand as possible. It’s actually a very rewarding way to work. Nothing feels better than seeing your work in the hands of others and knowing that you’ve made their lives a little bit easier.

5. Everyone Feels Lost

If you feel like you don’t know enough: congratulations, you’re doing it right.

I used to believe that one day I’d wake up and finally feel like I belonged in this industry, but that day never came.

No matter how experienced you are, doubt never fully goes away. The best engineers don’t wait to feel confident, they just trust that they’ll figure it out. The trick isn’t to eliminate doubt, it’s to move forward despite it.

Even now, years into my career, I have moments, sometimes entire days, where I doubt whether I’m moving fast enough, doing enough good work, or making a difference at all. I track my progress, see the impact of my work, and get positive feedback, yet I still find myself wondering: Was today a waste? Did I really accomplish anything?

You can know intellectually that you’re making progress, but how you feel is a different story. And I know I’m not alone in this.

If you’re just starting out, the worst thing you can do is compare your first chapter to someone else’s tenth. The people you look up to have been in the trenches longer, made more mistakes, and spent years refining their instincts. You’re not behind; you’re just at a different stage.

Document your progress so you can see how far you’ve come. Focus on learning rather than proving yourself. Get comfortable with discomfort - it’s a sign that you’re growing.

Imposter syndrome isn’t a sign of failure, it’s proof that you’re stretching yourself beyond what’s easy and growing into the kind of engineer you’re becoming. If anything, it shows that you’re on the right track.