5 Qualities of a Successful Developer
When you see a software developer, what makes you go, “Wow, that’s a successful developer”?
Is it the size of the community around that person? Or maybe the number of open source projects they created? I personally think a successful developer has traits that affect several areas:
- Relationship with peers — Other developers need to trust you implicitly to be considered “successful.” And I don’t mean devs who don’t know you but rather people working with you. Those who see you every day, know what you can do, and trust that you’re always up for the challenge.
- Technically sound — You definitely know your stuff if you’re a successful developer. While you might not be an “expert” on a single piece of technology, you know your way around the technical side of our industry.
- Trusted by your superiors — And by “superiors,” I only mean those who are higher up in your company’s hierarchy. Those you report to. If they trust you implicitly, it means they know you can do whatever they ask of you. Reaching that place takes time and effort, which is a sign of success.
But how do you get there? What are the qualities you need to have to be loved by your peers, prepared to take on any project, and trusted by your bosses?
Let’s take a look.
1. Consistency
The most important aspect of any developer is their consistency. Mind you, this is an important trait in any profession. If you don’t show up every day, you won’t improve over time.
But consistency has extra merit in professions like ours because it can be very challenging at times. Showing up every day has its rewards.
For example, spending days debugging code to find bugs deep within logic that you didn’t write. Some folks could just send the bug to the person who wrote the code hoping they’ll find the time to eventually fix it. But not you. You work on it, debug every instruction, and reverse-engineer the logic until you find the problem. That’s consistency.
What about receiving bad feedback from either your boss or peer? I was told I was a terrible project lead during my first assignment — that I didn’t have what it took to lead a project. I hated that feedback, but I kept showing up for the challenge. Of course, I tried to understand what was wrong and what I could do to improve it, but changing course and dropping my goal wasn’t an option. 15 years later, I’m glad I didn’t listen, and that is the reward you get from consistency: You achieve what you want, even if it takes a long time to get it.
But if you stop showing up because you’re too discouraged to do it or because you start listening to those naysayers, then you can kiss your goals goodbye.
Show up no matter what. You’ll get there eventually.
2. An Open Mind
I hate generalizing because 99.9% of the time, you’re wrong and there is always an exception to the rule. However, if I had to pick one common flaw in all developers, I would go with ego.
Especially at the start of our career, we think we’re better than others — be it other developers or those who work with technologies considered “easier” than ours. Or even non-devs, such as designers or QA testers. We’ve all been there.
But thinking you’re better than others closes your mind to being corrected by them, to learn from other people’s wisdom and experience. And that is a terrible mistake that shows inexperience.
Eventually, of course, we tend to see the light and understand that we can learn from others just as much as others can learn from us.
An open mind also gives us the superpower of admitting we’re wrong at times. Not many developers can do that — especially not if you combine it with “after receiving negative feedback.”
Accepting that a negative piece of feedback about you or your work is right is a hard thing to do, but it’s also one of the only ways to grow. We can’t always rely on ourselves to spot our mistakes. Feedback is essential to our careers, from those around us, from those who lead us, and from those whom we lead or mentor. We need to be kept in check by everyone, and to be successful, we need to know how to receive that feedback and turn it into a lesson. Or put another way: Learn from your mistakes, learn what works, double down on it, learn what doesn’t, and stop doing it.
3. Patience
Coupled with consistency, this is one big quality of a successful developer. There is no way you can keep showing up if you don’t have enough patience to understand that whatever you’re trying to achieve will come. It’s “just” a matter of time and effort.
Giving up after seeing something doesn’t work is going to keep you from learning. But taking the time to understand why that solution doesn’t work will teach you something new about it.
And it is through knowledge and understanding that we can grow. Have you ever fixed a bug “by mistake”? Perhaps you were trying something out, adding debugging lines and some extra if conditions, and suddenly everything started to work. What happens then? Do you call it a day and move on to the next problem? Or do you spend some time figuring out what happened, knowing that it can “unfix” the problem?
An eager developer will call it a day and move on, hoping the next problem will be easier to solve. A patient developer, however, will take the time to understand what exactly fixed the problem. That underlying understanding of the solution will teach you what you need. It’ll both help you to be sure you actually solved the issue at hand and to reproduce the solution in the future.
The lesson here is simple: Understanding comes with time and effort, which is also a way to describe patience. Time + consistency = patience.
If you liked what you’ve read so far, consider subscribing to my FREE newsletter “The rambling of an old developer” and get regular advice about the IT industry directly in your inbox
4. Experience
Duh! Well, it has to be said, but you can’t be successful overnight — not the way I define “success” anyway.
But experience means more than just years. It also means a collection of learnings gathered throughout the years of working on multiple problems.
Essentially, a combination of everything I’ve said so far. You can’t have experience if you’re not consistent and don’t keep showing up over the years.
You can’t gather experience if you’re not open to learning and being corrected by others.
You can’t be experienced if you don’t have the patience to chew at a problem until you finally understand what caused it and what can solve it.
It’s a combination of all factors. I also like to call it “baggage.” I think that word describes it better, to be honest. It’s your history, the collection of your individual failures and successes. They all taught you something, and if you were open to learning from them, then that learning turned into experience.
By pulling from that experience, you can teach others, tackle any problem you face (no matter how alien it might seem at first), and that is also how you give your managers the confidence that you can deal with any project.
5. Communication Skills
Finally, being confident, experienced, and always learning is not enough. You need to show it, prove that you can do anything, mentor others, and ensure that your leaders know what you’re doing.
Fact: You can’t do that if you don’t know how to communicate with people.
While that might come naturally to some developers, others will have a very hard time doing it.
Human-to-human communication is hard. The channel is not always clear and the protocol is sometimes ambiguous and can lead to misinterpretation. That is why most developers struggle with their communication skills — especially early on.
It’s only natural, but it’s also a problem that you need to solve to be successful. And don’t get me wrong here: I’m not saying you need to become a public speaker like those Twitter-famous devs who go from tech conference to tech conference.
All I’m saying is that you need to know how to use words to communicate your ideas. Diagrams and code will only take you so far. Eventually you’ll need to articulate your ideas to others who aren’t as technical as you. That means other developers, but it also means your managers or non-dev colleagues (i.e. designers, testers, business analysts, etc.).
By knowing how to explain your ideas and propose solutions that others can easily understand, you’ll become a great asset to your group and your organization. Someone others can come to for advice, ask questions, and rely on to provide a solution they can understand.
But it takes time, and it usually means breaking out of your comfort zone. Telling computers what to do is easy, and while the problem you’re solving can be hard and challenging, they will never laugh at you or bring you down. I get it. However, the benefits of breaking out and learning how to talk to others are far greater than the cons, so keep on trying. See what I did there? Consistency.
Conclusion
If I were to summarize this whole article into a single sentence, I would define a successful developer like this: A successful developer is always looking to learn from their experience and knows how to use that knowledge to solve problems and help others.
How do you get there? Consistency, patience, an open mind, and decent communication skills.
Am I missing something? What do you think are the qualities of a successful developer?