loading...
Cover image for What Makes You a Great Programmer on The Team?

What Makes You a Great Programmer on The Team?

Ilona Dee 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...
pic
Editor guide
Collapse
sandordargo profile image
Sandor Dargo

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.

Collapse
sebbdk profile image
Sebastian Vargr

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.

Collapse
v6 profile image
πŸ¦„N BπŸ›‘

I've had the good fortune to meet 2 such men at my current job.

Made a toast to them when we met in person for drinks in Guadalajara.

Collapse
workingwebsites profile image
Lisa Armstrong

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

Words to live by!

Collapse
perigk profile image
Periklis Gkolias

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

Collapse
elasticrash profile image
Stefanos Kouroupis

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.

Collapse
carlillo profile image
Carlos Caballero

Hi Ilona,

Thanks for these interesting tips!

Collapse
yogeswaran79 profile image
Yogeswaran

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

Collapse
v6 profile image
πŸ¦„N BπŸ›‘

Modeling, I guess.

If I may paraphrase the Oracle of Omaha, some of the best code is the code you decide not to write.

But maybe I'm just making excuses for my own lack of productivity.

Collapse
carlosds profile image
Karel De Smet

Warren Buffett said that? Geez, this guy is full of surprises...

Collapse
v6 profile image
πŸ¦„N BπŸ›‘

Yes those were his exact words.

Collapse
stereobooster profile image
stereobooster

No one can learn everything.

main argument against fallacy of 10x engineers

Collapse
rotimi__o profile image
Rotimi Olatunbosun

A great read. Reminds me of the book 'Good to Great' by Jim Collins

Is it possible to highlight text in an article on dev.to?

Collapse
jaygcoder2020 profile image
Jay G

Great insights, thank you. Would def. appreciate if you're starting out and you have a great developer having your back.

Collapse
djaballah_mi profile image
Djaballah

Insightful tips,
thanks

Collapse
prahladyeri profile image
Prahlad Yeri

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.

Collapse
stereobooster profile image
stereobooster

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 Β―\_(ツ)_/Β―

Collapse
prahladyeri profile image
Prahlad Yeri

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.

Thread Thread
stereobooster profile image
stereobooster

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.