From Programmer to Software Developer – The Skills That Make the Difference

Programmer and developer are often used interchangeably, but there is an important distinction between them: the developer’s broader perspective and focus beyond just code. In this article, we will step back from coding to highlight the skills that define what skills a successful developer should have.

In This Article

• Architectural Skills
  • Best Practices and Anti-Patterns
  • Design Patterns
• Communication
• Eliminating Dependencies
• Build a Team
• Build a Network
• Who Should Do the Work?
  • What Does Responsibility Mean?
  • Don't Do the Work For Others
  • To Delegate or Not
  • Don't Ask What to Do
  • Learn by Teaching
• Personal Traits
  • What are Traits?
  • Is Extreme Better than Being Average?

Programmer vs Software Developer

Most people know these two terms as synonyms, and they indeed are. However, if you search on Google, you'll notice there is a distinction. The difference isn't about how they work with code, but rather their perspective on work and software development.

The table above shows different perspectives that a programmer and a full-fledged developer can have. A programmer's view is narrow and focuses on code and its immediate environment: writing clean code with proper architecture, testing it thoroughly, and delivering it to the next department or pushing it directly to production.

A software developer, however, has a much wider view on development. It isn't just about writing code; it's about collaboratively building a product that solves customer problems. This rarely involves just a single team, but rather many teams across the full DevOps lifecycle, from the planning phase all the way to monitoring the deployed product.

DevOps lifecycle

This doesn't necessarily mean that a developer is working on the entire DevOps chain. The important part is that the developer understands and are involved in the full lifecycle and actively tries to improve and optimize the process. It's also about being available when other teams need assistance, so the organization as a whole can deliver a quality product.

Looking at the whole product solution is essential

Architectural Skills

Let's start with the most obvious skill a software developer needs to have - one that even programmers should possess: architecting. Though this may seem obvious, it's worth emphasizing due to its importance and the fact that many people neglect it.

A common role in software development is that of the architect. An easy mistake is believing that the team architect is solely responsible for the architecture of all applications owned by the team, which simply isn't true. Every developer should contribute to improving code architecture and must therefore know and practice it. While architects work at a higher and broader level, all developers share the responsibility of keeping the code clean.

Best Practices and Anti-Patterns

There are best practices and anti-patterns for all languages and frameworks. They differ somewhat and change over time. For example, my article about do's and don'ts in React from last year is still highly relevant, but with the new compiler in React 19, several of those 17 rules will become outdated.

What's important to remember is to always research best practices and anti-patterns when starting with a new language or framework. Those hours of reading saves significant time that would otherwise be spent on debugging and refactoring. In extreme cases, we're talking about months or even years of development time saved.

Design Patterns

Design patterns play a big role in architecting. The difference between good and bad code often lies in the usage of design patterns. Most design patterns are language-agnostic, meaning you can use them regardless of what language or framework you're using. Additionally, each framework has its own set of design patterns and is built on patterns that consumers should follow.

One of the most well-known general design patterns is SOLID. It's a universal design pattern that works with most frameworks. Some frameworks are already based on it, and users of these frameworks will automatically follow the pattern. Other frameworks can benefit from it, even though it isn't always obvious how to adapt to it. For example, React doesn't automatically follow SOLID principles, but if you understand how SOLID principles work, you can apply them to React as well.

React also serves as a good example for framework-specific design patterns, where you have patterns like Render Props, Custom Hook Pattern, and Higher Order Components.

The key point is twofold: take time to learn about design patterns in general, and make sure to look up framework-specific design patterns when starting with a new framework.

In general, design patterns make code more:

• readable
• testable
• modular
• robust
• DRY (Don't Repeat Yourself)

These aspects are necessary for writing reusable code and collaborating with co-workers. Design patterns also help prevent bugs.

Design patterns are not completely bug-proof

Communication

As a developer, you're most often building part of a larger system. Without proper communication with other teams to ensure your software works with the rest of the system, your part becomes useless. And without communication within your own team, you won't even finish your component on time.

Communication is vital in every project. Unfortunately, it's very challenging. I could write numerous articles about communication difficulties and how to communicate effectively, but that's not my focus today.

For now, just remember that communication is a important part of a developer's job, and it's just as important as being proficient at coding. If you'd like to learn more, I do have additional tips on how to communicate effectively in large organizations.

Eliminating Dependencies

In my early days, when I struggled with communication with certain individuals and teams, my initial reaction was often to provide super clear instructions and closely follow up on processes to ensure tasks were completed by others. When that didn't work, I would finally give up and do the work myself just to get it done.

That's when I realized that the best type of communication is when it isn't needed at all. If there's nothing that needs to be communicated, there cannot be any communication issues.

An important detail here: I'm not suggesting that you should skip communication and do other people's work yourself. Rather, I'm saying that work should be divided into different areas in a way that minimizes the need for communication.

When building teams, people usually talk about cross-functional teams - teams that have all the competencies needed to develop, deploy, and monitor their product without dependencies on other teams.

Cross-functional teams often refers to having the knowledge and skills to be self-organized, which means they have all the necessary expertise to manage their dependencies.

Once again, there's a lot to cover in this article, so I won't deep dive into this topic. If you're interested, you can read more about eliminating dependencies in my other article, which also covers similar tips for team collaboration and communication.

An important part of communication is to know when not to communicate

Build a Team

Team building is a term most often associated with fun activities and occasional after-work gatherings. While these are definitely important aspects of team building, they're far from the whole picture.

Does your team have common goals? Have you agreed on how to handle code reviews? Do you know why your team never answers questions in the team's Slack channel? If the answers to these questions are no, you haven't fully built a team yet.

Team building should be about discussing ideas, resolving conflicts and disagreements, and finding a common way of working that the entire team agrees to. It's about sharing knowledge and experiences so all teammates are comfortable working with the team and facing upcoming features and bugs. It's about helping teammates work both independently and collaboratively.

The way to accomplish this often involves meetings. These don't have to be formal meetings with strict agendas, but there must be occasions where the team gathers to communicate. Some discussions might require a full hour, while other topics can be addressed during small sync meetings.

For instance, a good time to discuss expectations for code reviews is during the actual code reviews! Instead of just talking about how to change the code, make sure to discuss why you think the changes are needed. Why do you think it's important, and what do your teammates think about it?

One final note - team building is for the entire team. While certain roles such as Scrum Master and team leader come with the responsibility of building a team, they aren't the only ones who should strive to improve it. Building a team is teamwork, not a task for a single person.

Even superheroes need a team

Build a Network

Have you ever been stuck on a problem? A time when you've sought help but no one had time to assist? Have you felt that no one was listening to what you were saying, even though you later turned out to be correct? Why does this happen?

People are commonly busy, and it isn't possible to always consider everyone's opinion. What you need to do is make your voice heard. Too often, the way to do so is to speak loudly and confidently state that your solution or problem is what needs to be considered.

However, not everyone is comfortable doing that. Fortunately, there's another way to make your voice heard - by finding someone who listens to you even when you whisper.

Who are the people most likely to help you when you're in need? It's family, friends, and acquaintances. It's very rare for people to help strangers, especially when it means taking on additional work.

By building a network and making friends, you'll find yourself getting help more often and much faster. People prioritize helping friends, both because it's someone they like and because it's more difficult to say no to a friend.

The ease of making friends varies from person to person, but everyone gets opportunities. Simply say a brief comment or ask a question to someone while standing in line for coffee, or make a point to talk to the designer about something you're wondering about in the Figma designs instead of guessing or sending a Slack message. Whatever you do, don't ask other people to talk to someone for you, then you are missing out on a new friend.

In the end, you don't need to be best friends with everyone for them to help you. Just talking with someone for five minutes can be enough for them to consider you as someone they know and someone they want to be respectful and polite to.

The more the merrier

Who Should Do the Work?

Everyone knows about the famous "someone". It's always "someone's" fault as soon as something doesn't work out. "Someone" was supposed to handle it.

But who is this someone? Unfortunately, it's often difficult to identify them, which is why there's a need to talk about responsibilities and who should do the work. The interesting thing is that it's more often than not true that the responsible person should do the work.

What Does Responsibility Mean?

What does it really mean to be responsible? Being responsible doesn't actually mean you must do the work yourself, it means that the expecations on you is to get the work done. It's fully possible for you to delegate the whole task to someone else, giving them the responsibility.

True responsibility involves a commitment to ensure success, but it also calls for encouraging others to contribute toward that goal. A CEO of a tech company has a lot of responsibilities, but in the end, it will be a whole organization of developers, managers, and other people who do the actual work to develop a product.

Similarly, an architect in a team is responsible for ensuring that the team has and follows architectural guidelines when writing code. However, this doesn't mean it's the architect's job to write all the code or even to define every aspect of the architecture. The entire development team should collaborate to enhance code quality and adhere to agreed-upon patterns and practices.

An interesting thing about responsibility is that it often can be delegated to others. However, when that is done, the accountability usually stays with the person who delegated the responsibility; it's only the responsibility of handling the work which is transferred. Meaning, if something goes wrong and the project fails or gets delayed, then it's the accountable person who will have to take the blame.

Sometimes it's actually everyone's responsibility

Don't Do the Work For Others

Doesn't everybody love that person at work who amazingly manages to fix all the problems for everyone? Well, I do too, but I know it isn't optimal behavior.

Taking on other people's work only creates a cycle where people rely on others to complete their tasks. The day that amazing employee quits, the whole team or even multiple teams will find themselves in a tricky situation.

Instead of doing the work for others, invest the time to guide them on how to handle it themselves. Though it may take longer initially, once they're self-sufficient, you'll save significant time and effort.

To Delegate or Not

While you shouldn't do others' work for them, this doesn't mean you should avoid tasks outside your direct responsibilities. Remember, work shouldn't fall solely on the person responsible, that person can delegate tasks so everyone can contribute to getting them done.

There are different types of tasks, however. If you are responsible for something, it's likely there is more work than one person can manage alone. In that case, delegation is essential, but deciding what to delegate depends on the nature of the task. If it's a small, one-time task, avoid delegating it since it may take longer to explain than to complete it yourself.

For tasks that are time-consuming or recurring, consider them candidates for delegation. Here, you should weigh the implications of delegating: if a task is critical, you might choose to handle it personally, even if assigning it would save significant time.

Don't Ask What to Do

Asking for permission and double-checking that what you do is appreciated is nice to do once in a while, so you don't spend a month doing something completely unnecessary. But on a daily basis, quit it.

Just as a team should be self-organized, you as a developer must be able to take care of yourself. You cannot have a manager or team lead who is always supposed to tell you what you should do for the day or how to solve each problem.

What you should do is figure that out yourself. This doesn't mean you cannot talk to anyone. Remember, communication is an important part of development. If you are uncertain or if you are working with bigger tasks, discuss it with your development team to see what they think about it. Make sure to describe the problem clearly and suggest some potential solutions you have thought of.

Do you see the difference here? The difference is that you are working together with your development team; you are all collectively responsible for developing your product. If you are an eight-person team, you have eight brains which can be part of making a good decision. If you instead go to a team lead to ask what to do, you are basically neglecting your own willingness to make decisions and putting all the responsibility on a single brain. That's not a good approach for solving problems.

Sure, you will make mistakes. Live with that. That's the way to grow in life. It's not just a saying that what doesn't kill you makes you stronger.

Learn by Teaching

If you read the article I linked to in the communication chapter, you should have seen the learning pyramid. You may then have noticed that the retention rate of what you learn when you teach others was as high as 90%, compared to only 10% of what you read.

According to the learning pyramid, you remember 90% of what you teach others

Surprisingly, this pyramid tells you that you are the one who is learning the most when your intention is to teach others. And next after that, you will learn the most by practicing doing something.

Note how this aligns with other topics we have discussed here, about being involved in solving problems, building a team, and stopping asking others for instructions of what to do. The foundation of all those has been to take action and actively work on improving the team and coming up with solutions to problems. These are actions which involve group discussions, practicing problem solving, and teaching others, all of which are at the bottom of the learning pyramid.

In contrast, if you only take orders from others, only listen to what they say, and read about how they solved an issue or write code they have told you to write, then you work purely at the top of the pyramid, which means you are learning very ineffectively by reading, hearing, and watching demonstrations.

As a bonus of teaching others, you will get to face the most tricky questions. You might tear your hair out or feel embarrassed when not knowing the answer to a question someone asks you, but in a few years, you will be the one who knows it all.

Personal Traits

We have now talked about some technical skills a developer needs, and some soft skills for how to handle communication and interact with others - the kind of skills that are important when it comes to how you interact with other people.

What we haven't talked about yet is who you are as a person - your personal traits which define who you are. These might be difficult to change, but you might not need to. As we will see, the most important part is learning when there is a need to adjust them.

What are Traits?

When speaking about personalities, traits are characteristics of a personality. There are plenty of models trying to model human personalities, where DISC, MBTI (Myers-Briggs Type Indicator), and Big Five are the most well-known ones.

The DISC model is a very simple model, it divides people into four different personalities, which we won't dive deeper into in this article.

DISC personality model

MBTI takes it a step further and divides people into 16 groups. It's a very popular and researched personality model, but it's not scientifically accepted.

MBTI personality model

The scientific world generally prefers the Big Five theory. Big Five is similar to MBTI, it includes extroversion vs introversion together with four other traits.

The Big Five personality model

MBTI and The Big Five are two fairly similar models, and the reason why Big Five is accepted scientifically is not because Big Five has better traits in it; it's because it defines people on a scale.

The Big Five doesn't categorize people, it claims that humans are more complex than 16 personalities and that each trait has a scale. This means a person is not necessarily extroverted or introverted; they can be somewhere in between on the scale, which is called ambivert.

The Big Five represents personal traits on scales

Is Extreme Better than Being Average?

If we follow the idea of having a scale for each trait a human has, we can start judging whether specific traits are good or bad. Let's take perfectionism for example.

There are many types of perfectionists: self-oriented, other-oriented, socially prescribed, etc. Most of these types would, according to the Big Five theory, be quite neurotic and conscientious persons who aren't very open to criticism. Doesn't sound very attractive, does it?

Personally, I see loads of problems with perfectionism. Frankly, I have been one myself but worked hard to get rid of it. Nevertheless, I cannot claim it is a bad thing that should be avoided. In fact, it is sometimes very beneficial; for instance, when being a high-level architect for a big corporation with hundreds or thousands of developers, then it is somewhat necessary to be a perfectionist.

The thing here is that there are no consistently good or bad traits. Each trait has its own advantages and disadvantages. It depends on the situation you are in if a trait is good or not.

For instance, take the architect as an example. I claimed perfectionism is a good trait for a high-level architect in a big corporation. In a startup company, however, it's undesirable to be a perfectionist, for real. Startup companies are all about speed and agility. You need to quickly iterate with customers to find out what they need, and you need to do it quicker than your competitors and before your money runs out.

Dependent on your role, you might need to focus on quality or being fast

Generally, being an extremist in any area is rarely beneficial. Whether it involves levels of extraversion or introversion, religious beliefs, or political views, being at the far end of any spectrum can lead to challenges. To complicate it a bit, it's neither beneficial to be strictly average. Unique skills are often essential to accomplish things in life.

The truth is, an ideal person cannot be pinpointed on a fixed scale; rather, they have the ability to exist anywhere along it. Such a person is fully aware of their behavior and can adapt it to suit the situation at hand. This adaptability depends not only on the task but also on the characteristics of those they interact with - remember, effective communication with others is essential.

Even within the same role, you might need to act differently dependent on tasks

Think about Peter Parker for a while. How would you describe his personality? Would you describe it the same way as you described Spiderman's?

There're times when you have to be someone else (yes, that's supposed to be Peter Parker)