Do programmers suck?

Introduction

Programmers are people, not aliens. Well maybe not the most social ones, but still people. They carry their own personalities, emotions, culture, and set priorities based on their interests, as everybody else! Why programmers should be the exception? The reason is simple: Programmers work in teams by default, even if it seems otherwise!

They are always part of a team, even if that team is consisted by the sole programmer and the client. Programmers, at least, always need a domain expert who might be a colleague, a supervisor, the client, the product owner of someone else. Of course, those kind of teams are not (always) efficient but sometimes this is all we might get.

The key issue is that programmers are trained to be programmers, but they are not culturally educated to work as team members, nor in universities, nor when in business line. We prefer to work alone, with minimum distractions, we avoid meetings like vampires the garlic, and assembling a team of programmers for a project is not an easy task, at all.

Not everybody want to participate to a team, at least quite actively, and sometimes they might not like their teammates for numerous reasons. So in the end, what we have are programmers as units addressed as a team, and those units only care to make their boss happy, or themselves. Additionally, what happens when we set a team of junior and senior programmers? Without the right principles and processes, that team is going to collapse in no time!

The bad programmer

All the bad programmer types below, that you have read about them again and again, are based on bad attitude, not lack of skills.

  • Don’t just copy paste code. Copy pasting itself is not bad. Not knowing what this code does, and why is bad! If you are not aware of the consequences don’t paste till you are sure.
  • Dirty code. Don’t just write code that works. Write code that is understandable by others, and by yourself after some time. Follow a variables naming guideline, indentation, coding style, avoid fat objects etc (clean code is going to be an article in the future).
  • Don’t avoid testing. Avoid testing is not bad for the project itself, it is mainly bad for your and your colleagues. Testing help us reduce technical debt, fix unpredictable code, remove useless or/and old code if it exists, help us keep things under control.
  • Learn the domain.: Focus and learn the domain you are working on, don’t just develop a feature or fix a bug. Knowing the domain help us write better code, develop the expected, by the clients, behaviour of the system, and utilise this knowledge in the future. Programming without understanding the domain is like shooting in the dark.
  • The rigid programmer. Always learn new languages, new frameworks if needed. Don’t feel side if you have to program using another language. Try leaving your comfort zone, and embrace something new!
  • The super wow solution. Complicates problems ask for simple solutions. Over-engineered and complex code works for a short time and crashes after a while. This adds to the technical debt, and the later the debt it handled, the worse!
  • The not case! How many times we have heard by our colleagues, or even by ourselves the following phrases: “I did’t write this”, “It is not my problem”, “It is not my fault, it is X’s fault ” “I can’t (don’t want to) fix it”. Negative attitude leads to negative responses, so be careful.
  • The wanna be hero. Huge ego is bad for the team. If you are the best and most experienced programmer in the team, do not enforce your personality or ideas to others. On the contrary, teach them, guide them, give them a change to listen and understand you. It’s not your project, it’s the team’s, and the company’s, project. Huge ego is equal to low productivity.
  • Avoiding documentation. Clean code is a must. But sometimes extra comments or documentation are needed. Especially, besides the technical details you have to describe the domain details to add value to the provided solution. Do not forget that one day you might leave the company. What you will leave be behind must be clean, transparent, well described and detailed.

Programmers soft skills

Again, programmers are people as everybody else. And every professional who respect themselves, their colleagues, their bosses, the companies they work for, they must be honest, open minded and modest, they must listen but not speak, share and not keeping to themselves, understanding, supporting and not judging are skills that are needed. Programmers, unfortunately tend to fight like artists. Who is the best artist, whose methodology overrule the others, whose work is most important? No matter if a programmer works as a freelancer, or for a company the concept is the same. You have to play nice, by the rules and with others. Unfortunately, reality is different. Not all programmers have a business culture, nor companies either.

So how do you build a culture? First of all this is perpetual process, and doesn’t complete after a specific period of time. Be honest to yourself and to others and open minded. Read books, watch talks on YouTube. No programmer is perfect, nor in skills, nor in personality.

Always try to work for companies with transparent, crystal clear culture. It’s the best feeling to know since day one what is your role, your responsibilities, your limits, the etiquette, with whom you will work with and why. If things are always blur, or change all the time then quit and find a new job! A long as you allow yourself into a rotten environment, in the end you will rot also.

Conclusions

Unfortunately, a lot of programmers and companies are ignorant and selfish. They think they know something when they don’t, or they have no idea that there is something more to know. This mentality leads to poor project results and in toxic relationships. Many software companies, don’t attempt to improve their employees, their principles, their processes and lot of programmers aren’t willing to improve themselves.

Feeling flexible and taking liberties at work is good, but if the company doesn’t align back you back to the company’s philosophy and principles if you diverge, that both you and the company are not disciplined.

References

[1].  https://www.codesimplicity.com/post/why-programmers-suck/