What Makes You a Great Programmer on The Team?

Ilona Codes on July 20, 2019

Majority of software developers are aspired to be not only a competent professional but also a great one. Nowadays, with accessibility to many cou... [Read Full]
markdown guide
 

Majority of software developers are aspired to be not only a competent professional but also a great one.

I'd definitely argue thus. Most of the people don't want to be great. Most of the developers don't want to be great professionals. They just want to live a decent and safe life without taking too much risk - being great requires taking big risks.

Then even the majority of those who claim they want to be great, they just daydream because they are not willing to put in all the necessary discipline and efforts.


The combination of good time management and being a good team player is an interesting topic. I'm pretty sure that many think it's a sign of greatness if devs who got stuck can always ask for your help. Well, they can always ask, but you should not always be available to them.

If you are, you might foster an environment where everyone can interrupt anyone at any moment.

On the one hand, it's selfish. When you are stuck, it's very important to you. But I bet that most often it's not so important for the one who you are just about to interrupt, even or especially if team goals are most important ones.

On the other hand, it's even counter-productive because an interruption driven way of work can be up to 50% less productive. (I should look for the study later on)

My point with this is to emphasize the importance of time management.

That skill has the utmost importance. You have to be able to block enough time for yourself to work on tasks that are important in the long run and give and communicate to the others how and when they should reach out for help that will not be immediate most of the time. And it's just fine. Most often, we just need another rubber duck. So frequently by the time, my colleague would be available, I solved the problem. Maybe because I wrote it down in the chat or maybe because I took 5 more minutes to think about it.

 

The best programmers IMHO are multipliers, that help their colleagues improve their output.

A good multiplier can cause a group of bad or inexperienced programmers to produce great output, something i have experienced first hand in the beginning of my career.

In 12 years i've meet maybe 2 of these people.

 

I would add one more. A great developer should be able to adapt. We had people in the past joining our team and hated everything about our processes...

The fact was simple...the team worked in a highly efficient way. And he thought that by adapting his ways would greatly improved our efficiency.. he was indeed right in a couple of them...which the team saw merit immediately, but others no one was willing to adapt... He keept trying for a year to change our minds and after a year, he decided we were too unorganized for him and he left. He was a decent developer.

But I think he could make a more than decent dev manager in the future. Still it lacks a lot of experience to do that.

 

Great points Ilona. I would add accountability and no-excuses mentality. Too many people nowadays act the opposite way and I find the it too toxic

 

"A good programmer is intelligent, while a great programmer is wise."

Words to live by!

 

Hey there! I shared your article here t.me/theprogrammersclub and check out the group if you haven't already!

 

No one can learn everything.

main argument against fallacy of 10x engineers

 
 

Everything is correct except this:

They help teammates when they get stuck and take criticism well because they are more interested in team achievement than personal.

Nobody takes criticism well these days, and especially in ITπŸ˜„ In fact, even the faintest of criticism is met with pitchforks, aggressive rebuttals and sometimes even abusive behavior! You need to act in a highly diplomatic and empathetic way in order to get a coder to fix something.

 

Depends on what kind of situation we are talking about. If we talk about online conversation between strangers than yes that would happen (like open source). If we talk about onsite communication in the team, then that would be strange. If there is a person who never accepts critics, especially from different people on the same subject it's time to fire them Β―\_(ツ)_/Β―

 

The open source world is no different than the real world where you live in, its the same kind of humans working in both! While its true that FOSS devs couldn't be fired but being kicked out of a maintainer position in a reputed project could mean a significant loss of street cred.

In onsite communication, devs might pretend to accept criticism and not indulge in rebuttals but they'll still show it in some other manner in the form of passive aggressiveness or some other behavior which might fall within the accepted range of social conduct in workplaces.

People are the same for sure.

  1. Treatment to people who you know and who you don't is different. For people who you know you would assume better intentions first (unless you know this is a bad person). For a stranger you can assume bad or good intentions depending on the mood
  2. Meida (online vs onsite) is different. Online doesn't transmit emotions (or poorly transmit if you use emojis and gifs). Onsite you can read emotions from body and face.

In onsite communication, devs might pretend to accept criticism and not indulge in rebuttals

If somebody hears critics N times and accepts it and changes nothing it's good reason to fire them, isn't it?

the form of passive aggressiveness or some other behavior which might fall within the accepted range of social conduct in workplaces.

this is called sabotage. As soon as this will be discovered everybody on the team doesn't want to work with that person anymore, there will be consequences, like transmitting to different team or firing.

As well somebody who gives critiques can be wrong. If nobody wants to hear their critique, probably something wrong with the way critique delivered or with the reasoning.

code of conduct - report abuse