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!
Oldest comments (61)
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 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.
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.
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.
Yes, curiosity++!
Well said. Excellent write-up.
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!
If you are only that, and you lack non-tech skills, well if you're happy with that that's great!
What I strive for is to be that PLUS have the qualities mentioned in the article. That way you're also a great mentor for other developers.
This was a fantastic post!!!! Thank you for elegantly articulating each of these non-technical skills.
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.
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.
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.
Hey Ali,
great notes,
thanks a lot.
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 really loved your article. I am totally agree that these skills are very important for anyone to become a successful team player. I hope job interviewers do focus on these skills rather than routine core language questions which I believe does not guarantee being a good programmer.
This was educational. Thanks.
This article is truly outstanding. Gratitude :D
The thing missing from your list is meritocracy. I'm a firm believer in technical merits. A team of developers who have all the empathy, confidence et cetera, but none of the technical profession, will happily embrace and welcome any friendly people - with no progress in their actual project.
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. ;)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.