I was hired to solve problems, not to craft beautiful software

By 2025, I've been working in software development for 5 years. I didn't go to university for Computer Science, but I never doubt my technical skills. I'm far from being the most skilled engineer, but I can learn this stuff, it comes natural for me. I love it, too. Writing elegant, well organized, easily extendable, and beautifully formatted code is a joy, even more so if I am to create useful and delightful software. Getting paid for it is the sweet cherry on top. The love for the craft was what got me into Microsoft – the big league.

But that's enough self expression. Recently, I realized it was the same love that held me back in my career. Here are some observations I'm noting for myself so I can experiment and see if I can do better this year.

Sometimes, caring too much about code quality is a bad thing

Because I care about the code, I need the code to be up to my standard. This is only a tiny problem when I'm the one writing it – I am free to do it my way and only need to make sure deadlines are met. It's a bigger problem when I read the codebase or review someone else's PR (not directed toward anyone specific, just a general comment). Sometimes I have that burning desire to refactor the whole thing, or comment on it until it looks prettier to me.

I well understand that good code can look like anything, not just my standard (if it's even good - my arrogant ass think it is), but sometimes you just know a piece of code is unmaintainable when you see it.

This rarely serves me well. Too often, my standard increases friction for my teammates, and friction is not perceived well in teamwork, unless I can convince others that there's a good reason for it. Being convincing is a skill I'm not good at yet.

I firmly believe my good code is easy to change and extend and will result in fewer bugs, but in this case, it is only achieved at the cost of slower progress. The sad truth is, the benefit of well written code is hard to justify but slow progress is very easily understandable.

The team needs me to solve problems

My team has its priorities. Product managers want me to do the dev work, fix bugs, and get releases out of the door. My manager needs me to complete assigned tasks, help others complete theirs, and show growth. My teammates want me to review their work, make it as smooth as possible, and help them when they need it. Ultimately, they needs me to help them achieve their goals and make their lives easier.

Supposing that assumption is true, it is clear I'm focusing on the wrong thing. Code quality should be a given but not the sole focus. The final goal should be solutions to problems, not a beautiful codebase (though highly desirable).

This is a theme I see at Microsoft, but my guess is that it's generally true at Big Tech. Their engineers don't necessarily have stronger technical skills than the average dev out there, but they know how to solve problems, corporately speaking.

I can write beautiful software in my own time

Finally, I think I'd better separate work and hobby when it comes to programming and shouldn't mix them up. I can focus on code all I want in my spare time (let's see if that's a good idea), but at work, for now I will focus on solving problems fast.