When I think about who I would like to work with as a programmer, I think so much more about non-technical skills than technical skills that make somebody a good co-worker. In fact, all of the skills that are in this post contribute to writing good code that improves technical projects. Most of them are really helpful for careers outside of programming too, but I'm going to focus on why they're useful for programmers specifically.
Empathy
To build a great product, you must put yourself in the shoes of your users. How will they be using your product? What features will be helpful for them? How can your program help them or improve their lives? And -- conversely -- how could it harm them or negatively impact their lives? What are the ethical implications of your application?
Empathy is essential for so many pieces of your programs -- if they aren't secure then your user's information could be used negatively by a third party. If they aren't accessible, then you are limiting the number of people that can use your project. If they run slowly or need huge amounts of bandwidth to run, then users will leave and people in areas with slow internet or mobile users won't be able to run them. It seems like every day an article comes out with some harmful algorithm a company has implemented, like the YouTube algorithm radicalizing the alt-right, Amazon creating a sexist hiring algorithm (which they didn't end up using), or AI misgendering black women. Think about everybody when you are writing your code!
Also, empathy is helpful for being a team member and a mentor. Put yourself in your manager or another developer's shoes. Why are they making their decisions? What can you do to help them? Having empathy will definitely improve your ability to be an effective teammate. If you're an employer, you can retain your employees for longer, and they will be more effective workers if you display empathy (src).
Have patience for other programmers, especially ones that are learning new things. Remind yourself of something that was really hard for you to learn and how that felt. They probably feel similarly. Being rude to them, diminishing their progress, or being pedantic will only be harmful and make that process harder for them.
Your words and actions have real consequences -- you can use that to enact positive change or hurt somebody. That doesn't end with in-person communication -- online communication counts too. You may think you're being funny or just letting off steam, but you may actually causing a very negative impact on someone's life. It's up to you to decide how to act, and how to apologize if you hurt someone to undo some of that harm.
Problem Solving
When I teach people to code, I see a lot more people struggling with problem-solving than the code itself. The ability to break a problem into smaller ones and then solve all of those smaller problems takes a lot of practice. Getting good at problem-solving can help you become a much stronger programmer.
Also, for most problems, there will be more than one solution. A large part of our jobs as software developers is to think through those different solutions and choose the one that is best. Is one faster to implement? Or does it run more efficiently? Or will it be less expensive? All of these are important questions, and picking the correct solution is a challenging but important part of software development.
Collaboration
Chances are very high that you will work with other people as a programmer. You will have to work with other developers, business people, managers, open source contributors, stakeholders, and countless other people even if you are a freelancer or entrepreneur. Learning how to work well with different people and their personalities is critical.
There are so many things that contribute to good collaboration. The first is knowing that one person can't do everything, or at least do everything well. Different people have different skills, points of view, and life experiences that are more powerful in combination than isolation. Don't feel like you always need to "put the team on your back" or be everything to everybody. You can be a lot better if you allow other people to contribute too.
Ask other people for help, and be willing to help people in return. You don't need to be an expert in everything, and different people will be experts in different things. Rely on other people, and if you are stuck on something make sure to ask for help so that you don't stay stuck for too long. When somebody asks you for help, be willing to help them. You can learn a lot by explaining things well, and you will be able to reinforce your knowledge of the topic. If you're in a management position, make sure to give people time for mentorship and effective collaboration!
Along the same lines, don't talk over people or immediately dismiss their viewpoints. They will probably be much less likely to contribute in the future if their opinions aren't valued or taken into account. Actively listen when people share their ideas -- instead of thinking about your response or why your idea is better while they are talking, try to think about why their approach is also good or how it could be implemented.
Then, once you implement their awesome ideas, give them credit for those ideas. Nothing has made me less effective as an employee as being on a team where my ideas were dismissed, under-valued, and un-credited by other people on my team.
Communication
When you are working with other people, whether those people are co-workers, clients, the people who use your projects, managers, or people you manage, good communication is crucial. Give honest updates on how things are going, where projects currently stand, and your opinions on things honestly but kindly. People will be less receptive to feedback if you are rude or unconstructive. But, if you are dishonest or sugar-coat the truth, then you may not see a positive change. There's definitely a fine line here.
One real life example from my life: I had somebody who read one of my blog posts write a very long letter about how dumb I sound because of the tone I take. I usually use a lot of exclamation points and try to sound exciting in my posts -- and that's very intentional to try and make topics that can be intimidating or boring more fun. The person got pretty sexist in this email and said some pretty hurtful things. That being said, I probably could scale back on the exclamation points and still get people excited about programming. I would have been a lot more receptive to that point if the person had framed the criticism more constructively.
If things are not going well, make sure to say so. Be honest about needing a deadline pushed back, or how something isn't going well at work. You will have a much better chance at changing it and making the environment better for yourself if you speak up.
Inclusiveness
I used to work as a rock climbing instructor and counselor at a summer camp, and the age group I worked with most were middle school girls. They were some of my favorite people I've ever worked with, but, that being said, middle schoolers aren't usually the most accepting of difference or that clique-adverse. We used to run a game where we started out in one large circle, and then one counselor would tell people they were "out of the circle", and they would have to leave the game based on some characteristic that they weren't informed of and couldn't control. The people still inside the circle would play a game, and the people outside of the circle were excluded and just had to watch from afar.
This activity was super effective in showing these girls what it was like to be left out for reasons outside of your control, and I still think back on it a lot. As adults, we still leave people out of the circle and exclude them based on certain characteristics outside their control, but if we let them back into the circle and allow them to contribute then our products draw on more diverse experiences and are better. There's a lot of research on more diverse teams performing better, but from an individual perspective, think about what it feels like to be left out of the circle and try to make your circle larger, not smaller. Chances are, a lot of your users may be people that have traditionally been left out of the circle in tech. I can tell you from my own experience, that it's really difficult to be the only person like you on a team as someone who's been on a team with another woman for ~5% of my programming career.
This also links into empathy -- make sure that you are making your programs for a wide variety of users. Not just the able-bodied or those with cutting-edge internet or technologies. You will be able to reach more people.
Patience
The first person that you need to have patience with when you are programming is yourself. Programming is hard and sometimes you will have bugs or difficult problems to overcome. If it's always easy, then you aren't challenging yourself, and you aren't growing as a programmer. Have the tenacity to keep working through a problem and not give up when it gets hard. But, also, know that you can take a break and come back to the problem in a little while. Maybe taking a break will help you solve the problem more efficiently or to see it differently when you come back to it.
Also, be patient with other people. Things can take a while to learn and people are not perfect. Making mistakes and failing can be some of the most important experiences in the learning process, so allow for that instead of creating an environment where it isn't safe to take risks or grow. Understand that different things click more easily for different people, and know that learning can take a while.
Creativity
My favorite thing about being a programmer is that I get to use my creative energy to build things that other people can then benefit from. You get to think outside of the box to create really cool things.
Having creative ideas is important for coming up with new features, interfaces, and applications. I had somebody buy a license for a product that I built for a company in large part because of the creative interface, and my portfolio site has gotten traction because of its creativity.
In addition to that, a lot of problems require creativity to solve. There is more than one solution to almost every programming problem, and coming up with creative approaches to solving them can often lead to an optimized solution.
Humility
You can learn so much from other programmers -- one person cannot know everything or anything close to it in the world of code. Be receptive to constructive criticism instead of defensive. You can improve your code and yourself from feedback, and being stuck in your ways doesn't lead to growth. You aren't always right, and you should be receptive to other people's ideas.
Confidence
On the flip side, also be confident. I'll admit that this is probably the most difficult one for me as someone with a lot of imposter's syndrome, and it has been my #1 thing to improve on every performance review I've had in my career. I can (and probably will) write an entire blog post on this topic alone, but believing in yourself and being confident in your abilities is really important.
First, have confidence that you can take projects on. Don't relegate yourself to easier projects or doubt yourself when you are assigned something difficult. Try to solve as much of it as you can, and then ask for help to get through the hardest parts.
Also, don't feel the need to research everything as a first resort. Trust yourself to try a couple things before Googling the answer. Or Google part of the problem instead of the whole thing. You are hurting nothing by trying a couple things out in development and seeing if they work. You may be surprised by how much you know.
Another thing that I do is keep track of my wins. I have a document on my computer with cool things that I've done, and really nice things people have said about me. When I'm having a tough day or doubting myself, I'll come back to it and usually feel more confident in what I'm doing.
Adaptability
Programming is still a new world, and it is evolving super fast. Being able to adapt when things change is critical. When a new framework, library, or language comes out that takes over, it's important to be able to learn it (within reason of course). Our industry would look dramatically different if we were all still writing code in Fortran; we need to be able to evolve and adapt when things change.
Also, the goal posts and features for projects will often change, especially with client work. When that happens, we have to adapt and incorporate those requests (again, within reason).
Community Participation
The community is so important for programming -- conferences, blog posts, social media, and meetups are important for learning and growing. Also, open source software and the communities that surround them are the lifeblood of this industry. Being able to network and make connections with people is so important for education, relating your experiences, and finding new opportunities.
Even if you are an introvert or don't love in-person socializing, there are a ton of awesome online communities that you can learn a lot from. And, even inside of companies, having a team with a strong bond will help people work better together.
Conclusion
These skills are often referred to as "soft skills", but I feel like that's reductive. These skills help so much with both writing code and being a good co-worker. They are so much more important than knowing a specific language, library, or framework and they go far even outside of tech.
All of these skills are really important to work on as programmers and as people. That being said -- nobody is perfect, and everyone has room to grow. So keep growing, and trying to make small steps to be better at these non-programming skills and I will too!
Top comments (60)
I think the one thing missing from your list is curiosity. For me, it's really important my teammate is curious about our work and is proactive in contributing to the team's overall proficiency. Other than that you've pretty much hit every criteria that goes through my head when evaluating a potential teammate.
I feel the same way. I believe that interest and perseverance are the two most important things to becoming good at anything. As long as you are interested, you can continue to learn, and not just go through the motions while learning. It provides an attitude to always challenge yourself and continually become better and better as you learn. It's what keeps it on your mind when you're AFK.
Oh, I really really like that one -- it's so important to just try things and keep growing as a developer.
Thank you so much for this awesome article.. I'm with stephen on this,curiosity is part of this list.
As an immigrant software engineer, i saw that team members suffer the most from the lack of communication skills,especially when it comes to a foreign developers dealing with each others.
Yes, curiosity++!
Great write-up, I was just thinking about this this morning. There's all this push for technical chops, but that can only take you so far. These soft skills help you as a developer, but they also set you apart from others if you do them well. That's how you move beyond just being the geek-with-most-tech-skills.
Thank you so much. Totally agree!
Not necessarily. When I was more junior I had a few people try to mentor me and with good intention. They tried. But it's really hard when they don't have the good communication skills to explain things and it can make the mentee feel stupid if they don't understand their way of speaking.
I disagree that pure technical skill and willingness to share knowledge makes someone a great mentor alone. I truly do feel, as both a mentor and mentee, that having at least adequate empathy, patience, creativity, and other soft skills mentioned in the article make for a better mentor.
Mentor/mentee is a relationship where both parties can adapt and grow to be better.
Some people are generalists, others are specialists. But no one reaches seniority in everything — so you need teams to build meaningful products. Social skills are the glue, the major prerequisite for flourishing in a team. Even as a solo dev you'll eventually need to build relations with customers or investors.
In my eyes the people with merit are those that have both technical skills and non-technical skills. In fact, technical skills are more easily taught. There's no mystery to them. That's why the definition of what makes a good developer is changing -- because you can have the most awesome technical skills and be awesome at the skills listed in the article. That is true merit.
And how is "technical merits" missing from the list of "most important non-programming skills"? This article is literally written to cover the non-technical aspects of being a successful developer. ;)
What a great list! I'm lucky enough to work for a company that hires for empathy. And if you stay in the coding game long enough, you're going to have to become humble, or very, very frustrated!
One thing that complements and perhaps even summarises the above is Emotional Intelligence. Having an awareness of your own emotional state, that of others, and the subtle interactions between each. It's a total game changer, and for many of us, learnable!
Thanks for the read :)
It doesn't make an attack. It goes through an empathy exercise, talks about the research of diverse teams, and overall talks about the humanness of empathy.
Before tone policing Ali, who I believe already did a very good job writing very empathetically about touchy issues, I think you should double check why you feel this way. She never made blanket statements about anyone, instead used an empathy exercise to demonstrate how it feels to be left out.
Historically the tech industry has left a lot of people "outside of the circle", I think everybody can contribute to making it more inclusive.
That being said, implicit bias is something that everyone possesses, and it causes us to usually favor people like ourselves. Being aware of that and trying to overcome it is something that can definitely help us be better people and programmers.
I read every word of this wonderful master piece. Thank you!
You are right about that referencing these skills like "soft skills" seems that it minimizes their value and impact. But the truth is that these skills are really important and essential to grow in your life and work.
Awesome, thank you so much!
I agree with most of what you say here and I really liked the section about Inclusiveness.
The game you describe is fantastic, I think I'll use it! maybe with a final reconciliation phase where people out are permitted to go back in the circle, because without trust in a possible forgive, fear can beat any will to include.
There are other sections and considerations that I liked (the last paragraph on Collaboration shows scars that I know very well ;-) and others that I've found a little... cliché, but overall the article is good.
I have however a couple of serious objections.
On the "soft skill" naming
I don't think you got why people call these as "soft" skills for programmers.
There are two main reasons:
On "Empathy"
Seen from an Italian, the focus on "Empathy" in IT both naive and very US-centric.
For example, if you were Italian, I could comment here "Balle." (which is a Italian equivalent to "Bullshit."), without being accused to be harsh, un-emphatic or sexist.
These days US developers seem very focused to impose everybody certain workspace-like "Code of Conducts" that are designed to help managers in their work of controlling the workers, but they don't consider how their mindset might clash with the rest of the world.
The world is huge, and what an Italian feels like empathic might looks as intrusive to an American. OTOH what an American feels like empathic would be felt as hypocrite by an Italian.
So much that when I read a tirade about empathy in IT, my first reaction is to ask myself: "What the author is trying to cover?"
In this case, many of the things you think should be addressed through empathy are instead Ethical issues.
That is: we always follow an Ethics in our work.
Often (especially in the Silicon Valley) it is the Ethics of Capitalism, completely focused on making money (and please the Government, whoever it represent), but people following it prefer to argue that Ethics is not relevant to programming at all (except when talking about the need of delegating Ethics to AI).
Other people follow different Ethics.
But the problem with Ethics is that it drives Politics, and people are scared by the complexity of Politics (which require caring about the Polis, about a lot of other people lives, and thus optimizing for multidimensional goals instead of simply maximizing profit).
Thus they resort to surrogates (such as empathy) to solve the problems that the lack of a richer Ethics and a serious responsibility of developers for the Political effects of their software would pose.
On Community Participation
You state:
Now, I agree that community (that is from Common, which derives from the latin cum - munis, co-obliged, mutually bound) is very important to our species. Aristotle used to say that humans are "social animals" for a reason.
BUT what you are talking about is not really community, but marketing.
It's not by chance that you talk in term of Open Source instead of Free Software!
Hackers' communities don't do much conferences and workshops, we don't care about "social media" (that we often dismiss for their anti-social behaviours on a scale, see the lack of Ethics discussed above), because we don't give a shit about our perception from outside: we just follow our Curiosity.
In conclusion
Thanks for sharing your perspective, I really appreciated it.
That's why, as a hacker and a European, I felt obliged to share a different one that might help you understand why some people are not conforming to your expectations.
The world outside the States is huge, varied and wonderful! ;-)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.