Majority of software developers are aspired to be not only a competent professional but also a great one.
Nowadays, with accessibility to many cou...
For further actions, you may consider blocking this person and/or reporting abuse
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'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.
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!
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.
Hi Ilona,
Thanks for these interesting tips!
main argument against fallacy of 10x engineers
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.
Warren Buffett said that? Geez, this guy is full of surprises...
Yes those were his exact words.
Hey there! I shared your article here t.me/theprogrammersclub and check out the group if you haven't already!
Great insights, thank you. Would def. appreciate if you're starting out and you have a great developer having your back.
Insightful tips,
thanks
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?