What Really Makes a Succesful Software Engineer
Five skills no course teach you, but matter more than your tech stack.
Hi Friends,
Welcome to the 166th issue of the Polymathic Engineer newsletter.
When you think about becoming a better software engineer, your mind probably goes straight to technical skills. Learning another framework or mastering a programming language, or practicing system design patterns. And yes, these things matter because they are what get you through the interview and into the job.
But here is the thing: technical skills are only half the equation. After almost 20 years in this industry, I have noticed that the engineers who truly excel share a set of skills that have little to do with code. Those are passive skills that work in the background, helping you through your daily routine without you even noticing. However, there are no online courses or bootcamps that teach them. You have to develop them yourself.
Any technical skill can be learned over time by reading documentation or watching a video. But the skills I am about to talk about are the cornerstones on which you grow as a developer. They are what help you through the learning process itself. If you skip them, it is like learning to run before you know how to walk.
The outline is as follows:
Patience
Determination
An eternal student mindset
Accept criticism and learn from it
Know how to communicate
Stop debating architecture in pull requests.
If your team’s pull requests are filled with comments like:
This architecture won’t scale
We should approach this another way
You are suffering from high costs and wasting developers’ time.
Developers often realize what should have been built only after the PR discussion begins, leading to endless back-and-forth and complete rewrites.
Introducing the CodeRabbit Plan that makes planning a first-class workflow before you write a single line of code. CodeRabbit Plan lets teams design how a feature should be built before writing code, so PR reviews serve as validation rather than architecture debates.
Old Way: build > PR > debate
New Way with Plan: plan > align > build
Thanks to the CodeRabbit team for collaborating with me on this newsletter issue.
Patience
Nothing says you are a software engineer like spending three hours debugging a piece of code, only to find the problem was a tiny detail forgotten somewhere in the middle.
If you think this is a sign of being a junior developer or of lacking experience, you are getting it wrong. I go through that same process every now and then, after almost 20 years in this profession. It never fully goes away.
The reality is that almost everything in software development requires time and effort. Understanding someone else’s code or researching how to solve a problem? Time and effort. Same for writing code and getting it actually to work.
Sure, you can take shortcuts. Copying and pasting code from an AI assistant feels like the quick path to a solution. But it only gets you halfway. The rest needs to come from you, and there is a lot of trial and error involved. You try something; it fails. Then you try something else, and it fails again. This is simply the process.
The engineers who burn out fastest are often the ones who expect everything to work on the first try. When it doesn’t, frustration builds up. Debugging for three hours isn’t so bad if you know that being patient is part of the job. It’s just another day at work.
Determination
Determination goes hand in hand with patience. Everyone who has done our job long enough knows it isn't easy, but setting the right expectations is the best way to avoid being discouraged when things go wrong.
The truth is, you will encounter roadblocks in your career. Problems that, once solved, turn into ten new ones. Bugs that take a long time to fix, like weeks or months. In any of these cases, quitting is a possibility.
There have been many occasions in my career when I wanted to quit programming. A lot of developers in our field would like to move to the middle of nowhere, away from technology, and become farmers. However, this is not a sign that something is wrong with software development. It only proves that our job can be frustrating at times.
That's why determination is so important. It is hard to know how determined you are until you face a struggle. But if you are already a determined person who doesn't give up after the first try, you will be a good developer.
The good news is that you can build determination over time. Every bug you fix, every roadblock you overcome, adds a little more to your reserves. You start to trust that you will figure it out eventually, because you have done it before.
A Student Mindset
Growth and learning are inseparable. You can't have one without the other. However, many developers forget this after they get a job or become more senior.
Our field never stops changing. Sometimes it moves forward with concepts that are really new. Other times, it goes back to previous concepts and presents them as the next big thing. Either way, if you don't pay attention, you will fall behind.
This doesn’t mean you need to chase every new framework or learn every trending language. That would be tiring and useless. What that means is that you should be open to the idea that what you know today won't always be relevant. The tools and practices you use now will change, and you will have to adjust to them.
I have seen developers who refuse to accept this. They learn one stack and think it will help them for the rest of their careers. It sometimes works for a few years. But eventually, the industry changes, and they are unable to move forward because they stopped learning too soon.
Technology drives technology. New advancements lead to new areas of research, new ways to work with data, and new ways of building products. When that happens, the tools we use have to adapt. If you adapt with them, you stay relevant. Otherwise, you get left behind. The key is not to learn everything. The key is to never close the door on learning.
Accept Criticism and Use It to Learn
Programming is not a solo activity. Even if you work as a freelancer, you will interact with other developers in one way or another. Giving and receiving feedback is part of that.
A good example is code reviews. It can be uncomfortable when other developers read your code to look for problems, missing standards, or flaws. However, if both sides do it well, code review can be one of the best methods to learn and grow.
The purpose of reviewing is to improve the code, and not to put down the person who wrote it. On the other side, if you are getting feedback, you need to keep in mind that it is not personal. The reviewers are sharing their experiences. Take their opinions to heart, and make sure you know why they were offered. You will learn a lot from this.
But feedback doesn't just show up during code reviews. You get feedback all the time, such as during performance reviews, in comments on open-source projects, or from a coworker pointing out an issue with your work. You should expect some feedback, but some will surprise you.
It is also crucial to make a distinction. Some feedback highlights a flaw in your work, like a bug you introduced. Other feedback is just negative noise: people venting their anger without giving any meaningful information. Learn how to tell them apart. Even a negative critique generally offers little insight. Don't worry about anything else; just focus on that.
If you only see feedback as something bad, you will start to doubt every decision you make. And that goes against the whole goal, which was to help you get better.
Know How to Communicate
This one is tough. Many developers, even experienced ones, struggle to communicate effectively with others. We spend so much of our time learning how to write logic for computers that we forget how to talk to people. Computers don't care about how well you speak or what words you use. They require clear, easy-to-understand instructions. But you also have to work with people, and people are all different.
When you need to ask a colleague for help, explain a problem you are facing, or help someone else with their issue, you have to switch from your machine syntax to your human syntax. This shift is not easy, but getting good at it gives you a big edge. If an interviewer sees that you can communicate well, you have already won half the battle.
How do you get better at this? One way is through writing. When I first started, I was bad at both writing and speaking. I spent hours reviewing emails that I believed were important, adding clarifications, and asking my peers to check that they made sense.
Things didn't change until I started making an effort to write online. Writing posts for my blog made me think of clearer ways to explain things. It didn't happen right away, but eventually something clicked. My oral communication also improved. I learnt how to talk to people better.
Communication is a skill you can practice right now, for free. Start a blog, write about what you are learning, or just explain a concept to a colleague. The more you do it, the better you get.
Conclusion
Getting the job is not the end of the line. It’s just the beginning. There are developers who think that once they get a job, they have made it. But it’s like thinking you’ve won a video game when you reach the highest level. In reality, you have simply unlocked a whole new set of challenges. Technical knowledge can get you through the door. But to get to the top, you need to be patient, determined, open to learning, good at talking to people, and able to take criticism. These are the building blocks for everything else you will learn along the way.