The Most Important Non-Programming Skills for Programmers

Ali Spittel - Oct 15 '18 - - Dev Community

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!

Keep in Touch

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .