by Bruce Flow

Don’t be the software developer you can’t stand working with

I have more than 10 years of industry experience as a software developer. I am working at one of the largest tech companies. I have also worked as a Scrum Master in multiple projects.

By no stretch of the imagination am I the most experienced developer out there. Yet, I have worked with enough software developers to recognize that I enjoy working with some developers much more than others.

The developers that I enjoy working with are the ones that collaborate well with me. They are professional yet pleasant. Their friendly competition pushes me to be a better developer every day.

And there are developers that annoy the heck out of me.

I did a breakdown of the characteristics of these difficult developers. It is not a list of rants. I made the list to learn from it for my own personal development. I also use the list to check myself from time to time as a means of professional self-reflection.

The following is a list of annoying things software developers do. For every characteristic, I also provide suggestions of what we can do instead.

Having sloppy craftsmanship

You know that developer. That developer that names variables, has typos in function names, and leaves remnants of old comments in the code. That developer that can’t bother to run the code formatter despite being told 5 times. The developer that ignores lint issues even when the IDE screams at them.

Having sloppy craftsmanship annoys other developers. It also slows the development process down. In code reviews, other developers have to waste time commenting on glaring issues that should have been fixed during coding. In other cases, other developers have to fix these problems themselves.

Even worse, the lackadaisical attitude increases the chances of having bugs in the software. Bugs cost money and time to fix down the line.

I get frustrated with sloppy craftsmanship because it is a question of attitude. That that can only change if that sloppy developer decides to take pride in their work.

As software developers, we have much freedom to choose how we do things.

Using this freedom to hone our skills is hard work. It is easier to just coast. Nevertheless, there are major long-term payoffs.

“Without craftsmanship, inspiration is a mere reed shaken in the wind”

— Johannes Brahms, German pianist and composer

Taking pride in our craftsmanship makes us increasingly better at what we do. It also inadvertently helps us derive more satisfaction from our work. Getting better at what we do opens up more opportunities in the future.

Being disrespectful of others’ time

There’s that developer who comes late to meetings on a constant basis. Everyone is late once in a while. Yet, coming in late all the time is choice.

Depending on the importance of that developer in that meeting, two things could happen. The team will either have to wait for the developer or have to spend time bringing them up to speed on what they have missed.

Habitually coming in late to meetings is a blatant disrespect to others. It might not seem like a big deal if you come in a few minutes late, but here’s my rough formula to calculate the time wasted:

Total time waste = n x (t1 + t2)

n = number of people

t1 = time late to meeting

t2 = time wasted bring the developer up to speed

Example scenario:

A team has six developers. One developer shows up 10 minutes late. The team takes five minutes to bring them up to speed. The total time loss would be 6x(10+5) minutes. That would be a total of 90 minutes wasted.

Coming late to meetings disrupts the flow of the meeting. Other colleagues might be having a productive discussion when the late developer interrupts.

Punctuality is an attitude.

Having the attitude of punctuality saves everyone’s time and nerves. Besides, it also gives the positive impression of reliability. Showing up at every meeting on time means we give a damn. It means the chances are higher that we give a damn about delivering our work on time, too.

Disregarding non-code aspects of work

There are times that I hear a developer say “The UI I built is ugly because I am not a designer”. This makes me want to get into Hulk mode and flip my standing desk.

Coding is just one of the responsibilities of the developer.

To be good at software development means that we adopt a holistic approach to our work. We should also consider aspects like user experience, architecture, and business strategy.

To think that software development is merely about coding is like saying you can drive because you know how to step on the gas pedal.

Ignoring the big picture will make the software hard to use, expensive to maintain, and inconsistent with the other components.

It is our responsibility as software developers to educate ourselves in all aspects. Granted, we cannot be experts in all fields. The important thing is to have adequate awareness. We can always request the help of experts when needed.

Having a holistic view of things will also allow us to understand other roles better.

When I engage in discussions with designers, I make it a habit to learn how design decisions are made. I do it by asking questions. This improves my basic understanding of design principles.

Learning to see the bigger picture better is a continuous process. A process driven by curiosity and the commitment to produce good work.

Talking about excuses instead of solutions

Everyone has a bad patch at some point. Sometimes, it takes longer to produce the results we want. This is totally fine. It is not fine when a developer constantly produces excuses instead of results.

Typical excuses include time constraints, inadequate knowledge, or task difficulty.

Producing excuses on a constant basis has zero positive effect on the team. It wastes time at best. In the worst case, it lowers the bar of excellence in the team.

Instead of excuses, I prefer to hear about the specific steps the developer has already taken.

This has many benefits:

• Gives the team a better chance to offer help or solutions
• Allows the team to learn from the problem
• Provides a better picture of the task progress

Talking about solutions is what we do. After all, we are engineers. Engineers solve problems.

Philosophizing about the unknown instead of figuring out the problem

On many occasions, colleagues argue technical topics based on their opinions. Opinions that are not backed by any facts.

Such lengthy discussions can be ended by finding out the facts instead of arguing about it.

“Truth is ever to be found in simplicity, and not in the multiplicity and confusion of things.”

— Isaac Newton, one smart dude

In software development, we deal with both technical and non-technical issues.

With the technical issues, we have the luxury that things are usually black and white. Any disputes can be resolved by trying out code in a sandbox or running a piece of software to check what it does.

Non-technical issues are resolved by reading the documentation, asking subject experts, or googling.

Complaining and having an aura of negativity

Most developers I have worked with are positive and enthusiastic people. Maybe that is why working with negative developers bugs me so much.

Negativity is infectious. If someone complains, it focuses the attention on the negative side of things. Others will be inclined to adopt the same attitude.

“Negativity is the enemy of creativity.”

— David Lynch, film director

Of course, it is not all roses in software development. There are hard times. We do sometimes have to work with legacy code from the dark ages or with tools that have the performance of a sloth.

It is better to ask ourselves what we can control instead of reiterating what we cannot change.

We can allocate resources for code refactoring or write documentation. We can find out if we can tweak the memory settings of slow tools to speed them up.

Rambling on in meetings

In meetings, I see eyes rolling back when “that developer” rambles on and on.

Like any other profession, verbal communication is one of the key soft skills we have to learn.

When communicating, getting straight to the point works wonders. Colleagues will understand us and the situation better.

One communication pet peeve of mine is when a developer talks to non-coders using jargon. Designers sometimes pretend to nod when a developer rambles on about JavaScript intricacies. Anything to get them to stop talking.

Knowing whom you are talking with and speaking in their lingo is common sense. Sometimes, common sense is not common.

Stealing credit for yourself

Once in a while, I will see a developer stealing credit for the work produced by a team effort. They would write an email to management advertising the feature or talk about a task as if they had done it alone.

More often than not, this is communicated in a sneaky non-straightforward way. The credit taking statements are cleverly implied.

Such strategies might produce short-term visibility for that individual.

In the long run, such developers will be alienated. This is done either by choice or subconsciously. Other team members will evolve their communication to highlight their contributions better.

It would make much more sense to give credit to others when it is due. No need to overdo it. But I’m saying give due credit.

There are many ways to give credit. We can mention the colleague’s contributions during Daily Scrum. We can thank the colleague via email and copy their manager.

There are myriad benefits of giving due credit:

• You feel good because you are honest.
• The contributing colleague feels acknowledged.
• Allows the manager to have a more accurate impression of the colleague.
• The team has a better picture of skill sets of individuals.

Thus, let us be aware of when to give or take credit.

Conclusion

The path to becoming a better developer is a never-ending process. Sometimes, it makes sense to take a stop on that path to reflect on how we do things. The art of professional self-reflection helps us correct our course. Becoming better at our trade increases our level of contentment with what we produce.

Let us be the software developer we love to work with.