If you had to narrow it down to the most important aspect of a developers personality... what would that be?
What quality could an interview candidate have that would make you extra interested in hiring them?
If you had to narrow it down to the most important aspect of a developers personality... what would that be?
What quality could an interview candidate have that would make you extra interested in hiring them?
For further actions, you may consider blocking this person and/or reporting abuse
Steve Sewell -
Harold Defree -
Kai Röder -
Muhammad Essa -
Top comments (32)
For me, the best quality is "humility" and a love of "not knowing."
As I mention in this article:
Why I was wrong about Scrum + “Hard Goals”
Cubicle Buddha ・ Aug 21 '19 ・ 4 min read
Another huge aspect of humility I personally struggle with is delegating. The world isn't going to end because I didn't write that module in some super fancy functional programming chained statement that lets me show off I know what a monad is.
I have been through a lot of abusive/dangerous/traumatic situations in life and it is hard for me to trust people, so sometimes I have to catch myself doubting my own teammates can get the job done and I have to recollect and possibly get out of the office for the rest of the day.
That definitely hits home for me. I often find myself judging other people's code most harshly when I'm feeling my own feelings of inferiority. Ain't it funny how that works?
Sometimes I find that if I tell myself "you are a good developer who doesn't need to be ashamed of his skill level" I will suddenly feel less judgemental to others. If I can heal "the inner child" then I'm not as concerned with what other people are doing. And it also reminds me that they're on their own journey too. They might end up in my "fancy functional programming chained statement" world eventually (I do love FP btw), or they might not. But either way, they are probably dealing with their own inferiority. So thank you for reminding me of that. :)
Btw, you also gave a great solution too:
Sometimes a little bit of distance is all you need. :)
Great thoughts @ssimontis .
I'm open to argue about "humility", although we may understand different things here. One has to have some self-confidence and even a bit of arrogance - being too humble isn't good for you. Being over-confident is bad too - no argue about that of course.
Can't you be confident without being arrogant? I define humility as being confident while being willing to be wrong.
I also like this quote:
And this one kind of touches on the empiricism aspects I was talking about in my article:
Curiosity and a willingness to accept the demonstrated expertise of others, especially those of a different background, personality type, skin color, gender, etc from you.
Enthusiasm is so important. If I'm enthusiastic, I can suck at something new for a long time before I feel like giving up (and I won't). With the right team, it's contagious! Here's a comment from QA on our recent retrospective:
I wanna hire that QA engineer!
You can't have her, she's with us! hehehe
That's right, but I'm not convinced you can just "muster" Enthusiasm.
There's boring projects I dread doing and fun ones I would spend 20 hours a day coding.
The ability to communicate effectivly with your team mates. I experienced it makes a huge difference on team productivity if one can effectively share ideas, progress in a project or feedback in code review.
Would rather hire someone with great communication skills and less good at coding than a senior who is unable to work with others.
I had people ghosting the team after a disagreement, a bad mentor who only ever gave negative feedback and was got personal in discusions, people not contributing to projects because they did not know what they should do and manager starting to micromanaging and extending the daily stand up to 1h because team communication wasn't working.
That burns some much time for nothing and makes working together a pain...
I wrote a bunch of stuff related to this question in an article called 50 Things I Wish I'd Known at My First Developer Job, but boiling down to one is hard.
Personally, I'd have trouble picking between curiosity, communication skills, and humility.
Empathy, Curiosity, Persistence, and Humility
I like that you called out empathy. Frances Frei's TED Talk on trust has stuck with me for a long time. She advocates that trust has three components: authenticity, logic and - as you called out - empathy.
When I hire, I look for someone that will fit well with the team in question, and someone who is untrustworthy will never be a good fit.
You can only pick one! Just kidding, these are all great answers. :)
Empathy? Still speaking for software developers? Since when dealing with other people helps us create programs for computers? If you have a good specs may not even need to talk or chat to anyone
Great software are made by great teams. :)
A balance is required, but empaty isn't the first thing that comes to mind, when talking about software development, engineering or construction.
Okay :)
Judging from your use of the word “specs,” it seems to me that your experience with software development has mostly been with waterfall processes (or some variant where specs are created up front and the developer has little to say about the requirements for the feature). Or perhaps you worked with people who use the word “Agile” but don’t embody Agile’s iterative learning approach.
But for some developers, the ideal situation is where you accept the fact that we can’t know what the user wants— and when you can’t know, you don’t write specs. So you follow an iterative (I.e. Agile) process so you can develop -> learn -> develop -> learn.
And learning about your users involves being able to empathize with your uses needs so you can properly listen to what they really want you to build. And sometimes they don’t know until they’ve tried your software. That’s why in my opinion specs don’t work.
Samsara: 5 Agile Techniques to End Suffering And Increase Learning
Cubicle Buddha ・ Apr 7 ・ 6 min read
Discipline to endure the boring parts of the job
Great point. What techniques have helped you deal with the boring parts of the job?
I'm terrible at focusing, but i found out putting soundscapes on my headphones helps me get less distracted.
mynoise.net/ has great selections.
I'm a huge fan of the Japanese Garden one.
Ability to improvise, because you will have to figure out complex issues without help from anyone, understand and fix undocumented (or even worse - poorly documented) code, APIs and databases.
And because one day you will reach a level, where none of your questions will be already answered on stackoverflow.
Quite possible that he may not the answer at that instant but surely figures out a way to solve it
To be able to deliver consistently on estimates?
(I know, sounds boring compared to what others say.. but..)
Is that a skill that you think developers can actually develop?
I'm the wrong guy to ask..
But I suppose they could.. I'm not sure how though.
I know a few people that can do this.
They say.. It will take me 2 weeks to finish that. And they always meet or beat their own estimate.
There are techniques for this of course. One is to break down the features to tiny tasks in your head and then be able to be sincere with your own abilities (that's the hard part for me).