6 Essential Skills for Ambitious Developers Besides Coding

10 min readNov 14, 2020

Becoming a good software developer is hard.

It takes years of dedicated learning to really get a grasp on all the paradigms that you need to know about. You have to dive deep into your programming language to fully understand how certain features work and get ahead of the game. In addition to that, there are design patterns, tools, algorithms, etc., that we should have working experience with.

Really, it is hard to become an expert in software development.

Even worse, it’s not like you are done after the initial learning phase. We are in a fast-paced environment where new tools, paradigms, programming languages, and fancy libraries come up every month or so.

With all that to learn and master, we often forget to realize that ultimately we work with people. And in order to work with people, you need to master a completely different skillset.

Those abilities may not necessarily improve the quality of your code. However, they will have a tremendous impact on your career and be beneficial in every single project you work in.

I wouldn't say these skills are more important than your technical knowledge. But in order to become a true professional and an expert in your field, it takes more than a solid coding background.

Today, I want to give you a set of the most important abilities (at least in my opinion) besides coding.

The art of communication

I know, stereotypically we tend to be nerdy and sit in front of our desks the whole day. Others neither hear nor see us and we are the magicians that just get insanely complex stuff done.

However, it is important that you learn how to communicate with others. I’m not saying you have to change the core of your being. If you are an introvert (and I am, too) that’s more than okay and probably made you the developer you are today. But you should be able to communicate effectively, efficiently (don’t overdo this!), virtual as well as in-person.

Becoming good at communicating with your team, boss, clients, and other members of your organization is not just crucial for the next step in the career ladder. It is also important to connect with them. How can they trust in you, if they don’t know you and vice-versa? How can you work efficiently when you don’t have trust in your team and vice-versa?

Again, it doesn’t take much here, but I give you a list of a few things that you should be able to do through communication:

Small-talk

I got it, many people don’t like to speak just for the sake of starting a 5-minute talk that barely scratches the surface. However, it doesn’t hurt asking a colleague that you meet in the kitchen how they are or what they’ve spent their weekend on. On the contrary, it can have a huge impact and make others like you which is never a bad thing.

Saying no

Okay, that sounds pretty negative, doesn’t it? But it is incredibly important to learn this one skill!

You don’t want to do other people's jobs just because you never learned how to draw boundaries.

You can’t finish a feature in-time? Then you have to tell your project manager/product owner. They will try to negotiate with you if you can make it work somehow. But you know you can’t. Don’t try, that’s really unprofessional. They can only take action and change plans if you make clear that it won’t be finished as they’ve planned.

Never say I’ll try!

Note: Sure, you should always give your best and try to make it work. But don’t give commitments where you don’t completely believe in.

Communication with non-tech people

We work a lot with other developers. They often share the same interests with us and it is really easy to talk to them just because they are like-minded. Nevertheless, on a daily basis, we work with designers, project managers, product owners, scrum masters, clients, etc. You need to communicate with them as well, so you should definitely strengthen this skill.

If you try to explain something to a non-tech person and you see an idle glance in their big eyes, you know you have to improve in this area.

Bonus tip

Never talk bad about others behind their back. It doesn't matter if they really messed up. You don’t know why they did something in that way and humans do mistakes all the time. Remember, even if you are a top-notch programmer, you are also a human being and you will fail. So if they did something wrong, talk with them about it (avoid blaming) and try to help.

Seeing the bigger picture

The next two points really belong to each other, but let’s start with seeing the bigger picture. This is a wish of project managers, I’ve consistently heard in most of my projects as a contractor. Developers (including myself) don’t see what they are programming for.

I know in our day-to-day work we have to handle complex problems. We also try to do things according to the best practices and it’s easy to just lose sight of the business case, our clients, and the setting in which we operate.

Maybe there is another team that later needs to maintain the code, so it may not be the best idea to use the ‘new kid on the block’ tool to create the application. The other developers potentially don’t know it and have a harder time doing their job.

Your implemented error notifications are really great for you as a developer but are they also that great for your customer base which doesn’t have a technical background?

Always remember, who your users are and what their level of expertise is. Think about, what role does this feature play in the business context and for your company. Never get lost in the daily chaos and lose the long-term goals and intentions out of sight.

Bonus tip: You can much easier prioritize and make better decisions when you keep the bigger picture in your mind. That helps also to improve your code as the best code is the one you don’t need to write.

Gain domain expertise

Let me tell you a story. I worked for a subsidiary of a big German car manufacturer. I was just starting as a working student and had a talk with some of my junior dev colleagues. I asked them if they specifically tried to gain knowledge in the car industry. They said, that they are more focused on the programming industry and they told me of a guy working for the company who knew nearly every detail about every car the company produced and he was pretty familiar with how the different parts of a car work together. He told them:

“How can you work for this company when you don’t know the products or how they work?!?”

We had a laugh. Oh lord, were we naïve!

He was completely right and he was behaving like a professional while we were amateurs.

Yes, you are a software developer but ultimately you are a problem solver.

How can you solve problems when you don’t know what they are about? How can you detect falsy requirements for a story when you have no clue about the domain you’re working in?

You can’t.

You don’t have to become the most knowledgeable person in this field. After all, you have to maintain your rock-solid technical knowledge. But you should be able to talk easily about the industry and the context in which your company is operating, and find errors in requirements most of the time.

You can easily get started by reading a book or two about your industry. Try to read articles about it quite regularly. Additionally, speak to domain experts during lunch at least once a month.

Believe me, this is a highly underrated skill that can really make the difference between a good and a great developer. It also helps in seeing the bigger picture which we already looked at.

Negotiation

Okay, that one seems obvious. You need to be able to negotiate to earn more money. Well, that is true, but not the end of the story.

You try to make deals almost every day. During your sprint planning, you have to discuss how many story points a user story gets estimated to. How about deadlines and what features you can provide up to this point? Again there is negotiation needed. Other important things are architectures, design patterns, or guidelines you and your team have to agree on.

For all of these situations, you need negotiation.

Let me examine one case more thoroughly. I already told you, that you have to learn to say no.

I still think that this is one of the most important skills. But even more important afterward is to find ways to say yes.

You maybe cannot commit to delivering the full user interface for the iOS application until the end of the week. But maybe you can find a way to make it work. Here is an example of you talking to your project manager (Tom in this case):

Tom: Hi, we really need to finish the whole user interface and fill it with dummy data until Friday!
You: Hi Tom, sorry that is definitely not possible. I’ve made my estimations and that will at least take two more weeks.
Tom: That is way too long! I have a meeting with the management on Monday where I have to show how the final product will look like. This could easily get us into trouble, our budget cut, and our project canceled.
You: Is it an option to just show the initial screen and the screens we navigate from there. We could then simply omit the detail screens and with some overtime that should be feasible.
Tom: No, they really want to see the whole process with all the detail screens. They need something to click through to show the final product to our clients. It doesn’t have to contain nice code. It should just work for that day. We can make it in a proper way later.
You: We don’t have the time to make it in a proper way afterward as I know our estimation for the project. But from what you‘ve been saying, I would assume that a click-dummy without self-written code would be enough.
Tom: Well, yeah, when I can deploy that to an iPhone and show it to them by clicking through. Could you create something like that for the end of the week?
You: Sure, I can create something for you in a day or two, and then we have even enough time to test it and you can show it to our management and our clients as well.
Tom: Sounds great! Let’s do it! Thank you, very much!

That’s exactly how you should behave in such situations. You should try to give a yes, but never commit to something or say you’ll try when you can’t assure that you will make it in time. At the end of the discussion (negotiation), both parties were happy and had the problem solved in a good way.

Ownership

I first discovered the topic by reading the book ‘Extreme Ownership’ by Jocko Willink and I was hooked. In a nutshell, it says, that you take full responsibility for the project, the people in there, your actions, and theirs.

Oftentimes, I’ve ended up blaming others for errors that occurred. It’s a strange tendency that most of us have to first look for flaws in others. Recently, I’ve had to write more than 80 unit tests for an application that wasn’t tested at all! A few years ago, my reaction would have been to start finger-pointing and really getting angry at the developer who created that mess.

Nowadays, I think differently. I know that he wasn’t that secure with Jasmine unit tests. I also know that he had a lot of time and in the end, I was the one who approved his pull request. It was my responsibility and, therefore, my fault that no unit tests were in place. I did my homework and wrote even an article about that topic to remind myself that you never should allow sloppy code to go into production.

There are other examples, was it the fault of the junior developer that he implemented the feature in the wrong way, or did you do a bad job at helping him out and questioning his understanding. Maybe the acceptance criteria weren’t that clear written and you should have noticed as you have by far more knowledge in the area.

There is no point in searching for mistakes in others. Even if it was their fault, you gain nothing from that. But you can use it as a chance to take responsibility, grow as a developer, and try to avoid these problems in the future.

Conclusion

Software development is hard and it’s not just the technical part that requires our continuous improvement.

In this post, I showed you 5 areas you need to work on outside of coding. These are:

The art of communication
Seeing the bigger picture
Gain domain expertise
Negotiation
Ownership

The list is obviously not complete. There are other topics like teaching less experienced developers or self-organization to get more out of your time. However, I feel that the list above gives you a good start and sets the stage for developing a mindset that you must grow as a developer by growing as a person.

I want to end this post with a great quote:

“What you get by achieving your goals is not as important as what you become by achieving your goals.”
- Henry David Thoreau