Fog Creek

Soft Skills for Hardcore Developers – Interview with Ed Finkler

Looking for audio only? Listen on and subscribe


Up Next
From Talmudic Maxims to Software Engineering Excellence

In this interview with Ed Finkler, Lead Developer and Head of Developer Culture at Graph Story, we discuss soft skills that are important for developers. We dive into how things like humility and empathy impact your effectiveness as a developer and the quality of products you produce, as well as ways to ensure you’re always learning and how you can give back to the community.

Ed is co-host of the /dev/hell podcast, and writes about software development and raising mental health awareness in the tech community on his blog.

Content and Timings

  • Introduction (0:00)
  • The Importance of Empathy (2:33)
  • How to be Humble (6:41)
  • Always Be Learning (7:46)
  • Avoiding Tribalism (9:32)
  • Bettering the Community (11:42)
  • Recommended Resources (15:27)

Transcript

Introduction

Derrick:
Ed Finkler is an experienced software developer who is currently Lead Developer and Head of Developer Culture at Graph Story. He’s co-presenter of the /dev/hell podcast and speaks frequently at conferences, including the talk, ‘How to Be a Great Developer’. Ed, thank you so much for taking time to join us today. Do you have any more to share about yourself?

Ed:
I’ve been doing primarily web development, I guess, for coming on 20 years now. I always tell people that I started doing web stuff before browsers had frames.

Derrick:
In your talk you say that tech skills are overrated and instead think we should put more focus on 5 key soft skills: empathy, humility, always learning, avoiding tribalism, bettering the community. In what way do you think tech skills are overrated?

Ed:
I think that a lot of people put emphasis on technical know-how as sort of the primary metric to measure the efficacy and how good a developer is, how you grade a developer. It is not as if those things are unimportant. I think we all agree that it’s important that you know what you’re doing and that you’re always trying to get better at that. It is certainly not to say that tech skills are unimportant, but simply that they are one aspect of being good at what you do.

I’ve seen anecdotally a lot of evidence that you can be a very, very good developer from a technical standpoint and be a very, very poor developer, period. The reason why I say that is because there are so many other skills that go into being a good developer. Really, you can extend a lot of it to being, are you an effective teammate? how well do you communicate with people? all these kinds of things that are aspects that oftentimes we joke about. We have this sort of stereotype of a socially awkward developer who is some sort of savant at certain things and has very poor social skills, or very poor communication skills, and things like that. I would assert that I would rather have somebody who is not as technically accomplished, but is very good at these other skills.


“The only thing that you should be loyal to is people. I think that everything else should be a pragmatic choice”


The Importance of Empathy

Derrick:
Let’s talk about one skill in particular. You say that empathy is the most important skill you can practice. Why do you think it’s so important?

Ed:
I think it’s important because it touches so many things. It touches all of the interactions that you have. I think we’re well past the point where you have many cases where you have lone developers, just like one person doing everything. There’s lots of specialization, and typically you’re working on teams. At a very base level, I think that it is much easier to communicate and to understand where people are coming from when people are practicing empathy, and that’s a difficult thing.

There’s an assumption that your experience is universal, but that is typically not true. I think that’s also particularly a problem with developers, because the things that we make in general, they’re tools for other people to use. It is often the case, not always, that the tools that we make are not for people who have similar life experiences to us, who are, say, developers who have the same types of expertise, and backgrounds, and things like that.

Because of that, I think there’s a tendency for developers to often miss the mark in terms of producing products or tools that people are going to use that are effective for the people who are going to use them. The two most practical areas where you’re practicing that empathy, where you’re learning what it’s like to be this other person and putting yourself in their shoes and trying to understand that, is practicing that empathy for the users of your product, for the audience who’s going to actually work with it.

That’s really essential for creating good products. I think many of us think of ourselves as craftsmen, and so we take pride in the processes and we get interested in the processes; but, at the end of the day, all the things that we do have to serve the end product, and that end product is this tool that gets used, typically by somebody else, who, again, may or may not be like us at all.

The other area where I’d say is that practicing empathy informs so much of how we do things, and a lot of our processes, and a lot of the ways that we interact with people, and the choices that we make in doing our job so that our other team members can effectively do their job as well. That gets into things like how important it is to document code, and put comments in, explain things, stuff like that, or make code that’s clear and easy to understand.

At the end of the day, the reason why you do that stuff isn’t for you right at this moment. It’s for the person who’s touching your code who’s not you, oftentimes 2, 3, 4, 5 months down the road, or a year down the road, or 5 years down the road. Even for yourself, I think it’s really important that you take the practices into account and make things comprehensible and as easy as possible to understand.

It’s that empathy for the team, when you think about, like, “Am I going to follow effective procedures that other people can look back and understand what happened? Am I going to do a good code review, or am I going to gloss this over and skip through things?” I think all of those things, if you practice empathy before the other people who have to work with the stuff that you do and are impacted by what you do, I think that all of those things sort of get informed by the empathy, and that’s what drives you to do a better job in there.

How to be Humble

Derrick:
Another skill is humility. How does humility make you a better developer?

Ed:
Understanding that you’re probably wrong about a lot of stuff and that you’re constantly going to be improving. You do the best job that you can, but you don’t necessarily hold onto your practices as if they are some sort of catechism handed down that this is the one true religion. It’s really important that you are in an environment that allows people to say, “I don’t know how this works. Can you explain this to me? I don’t really understand this. Can you help me out with that?” Without fear, without saying, “Oh, man, maybe that’s a sign this person doesn’t know what they’re talking about.”

I think a lot of times the reason why we don’t have humility about stuff is because we try to steel ourselves from being wrong and we’re afraid of being wrong. So, it’s really important that you’re in an environment where that’s okay. You can be wrong about stuff and you just do the best you can.


“Be really liberal about what you learn about… be very conservative about what you actually end up using”


Always Be Learning

Derrick:
You say that we should always be learning. How do you go about ensuring that you’re always learning? What other things can we try?

Ed:
I think the best way you can do that is to really seek out mentors, for lack of a better word. I really treat that informally. I don’t say, necessarily, “Well, you have to ask someone specifically and apply for some mentorship thing,” or stuff like that, but I do think that you view other people as possible mentors in lots of different ways. If I don’t understand something, I ask one of the teammates that I have at Graph Story. I say, “I don’t really understand how that works. Can you explain that to me?” That happens a lot.

There’s a few different curated newsletters, like PHP Weekly, Python Weekly, Javascript Weekly. I think I subscribe to all of those. Ninety-five percent of what I see there I don’t pursue in any way, but oftentimes I’ll look through it and say, “Oh, that looks kind of interesting,” or I might make a note of it. It’s like, “Oh, this mentions a library that might be useful sometime down the road.” I bookmark it and keep track of that stuff.

If I have time to do side projects, those are really good opportunities to test out different technologies I want to learn about and I think might be interesting, but I want to get a feel for them and then maybe see sort of what the nuts and bolts are like. Those are usually really good opportunities for me are those side projects. I tend to view that you should be really liberal about what you learn about and what you play around as side projects, but you should be very conservative about what you actually end up using in, what I’d say, your production stuff.

Avoiding Tribalism

Derrick:
Why do you think we’re so prone to tribalism as developers, and how can we avoid it?

Ed:
There are much smarter people than me who study anthropology and stuff like that. Essentially I think that we want to belong to groups because we feel safer in groups. I think the thing that’s dangerous, though, is when that tendency overrides our ability to think practically about different solutions and overrides our empathy. We have to keep strongly in mind that something that works well for me may not work well for another person for any number of reasons. It could be the project. It could be the people that they have working there. It could be a ton of different things. There’s lots of things that go into technology choices for different situations.

So often I see people ask a question that says, “Hey, how do I do X with Y? How do I accomplish this task with this, say, framework?” Then oftentimes the response that I’ll see from other developers is, “You shouldn’t be using that framework,” or “You shouldn’t be using that tool.” It is unlikely that you’re in a position to understand why that is, unless you want to sit down and have a good discussion about, how did this project come about? What’s the history of it? There’s a reason why they’re asking that. So, that kind of goes back a little bit to humility oftentimes.

That’s a good example of why developers oftentimes don’t practice humility, don’t practice empathy, because they assume that their experiences are similar to everybody else’s: “I don’t like X tools, so that’s why it is inappropriate for anything ever,” and that’s kind of a ridiculous notion. All that stuff, you start seeing people who get loyal to technologies, or loyal to brands, or companies, and I strongly feel that that is a mistake. I think the only thing that you should be loyal to is people. I think that everything else should be a pragmatic choice.

Derrick:
Yeah. You’re really combining all of these things together. Empathy and humility will help you know if you’re starting to get into the tribalism. What are some actual ways that we can better our community as developers?


“Understand that you’re probably wrong about a lot of stuff and that you’re constantly going to be improving”


Bettering the Community

Ed:
There’s the communities that we participate in as developers, within our, maybe, the tools that we use, the choices that we make, the processes that we have. In that community I think sharing what you know and that collaborative learning process is really exciting, really cool, and I think those are really good ways to better your community, is sharing what you know and encouraging others to do the same, and helping organize ways to do that.

It doesn’t mean that you need to be the person who necessarily is on point and takes a huge leadership role and to organize things, to say, like, “Here’s opportunities for us to go share knowledge,” and “Hey, once a month we’re going to have a Google Hangout or something like that. Somebody’s going to present on something so we can all learn from them.” You can do lots of things like that. You can do that in your job. You can do that informally as parts of user groups and things like that. All those things are great, and you can help out in a lot of ways, not just be the point person on that kind of stuff. Do you know what I mean?

I think that the second thing is actively trying to mentor people. That’s a part of that one-on-one exchange of information and passing on the knowledge that you have to somebody else. That is really valuable and oftentimes a much faster and more effective way for people to learn than to, say, go off and just do it themselves.

The other thing that I would say with communities is, really, the community you live in. I think oftentimes we as developers, because of our experience, we spend a lot of time on the internet. We oftentimes work remotely. We sort of have insular lives in a lot of ways and oftentimes we’re really not that engaged with the community around us. That community is not just people like you. It is the people who live near you. There are a lot of people, and a lot of groups, and a lot of folks like that who live in your community who would greatly benefit from skills that you have, but it is very likely that they don’t have the money or they don’t have the time to try to find people who are as good as you are at it.

I would give a couple of examples that I’ve personally done. The school that my son goes to is a public charter school. It’s operated locally; it’s a non-profit. The first things I started doing is I volunteered on the tech committee, because they don’t have enough money to have any on-staff tech people. I’ve been doing that for 6 or 7 years now, just trying to help out.

Sometimes that means helping them build a better website, which is kind of my bread and butter. Sometimes that means going around and installing software updates on computers, things like that, or trying to make their processes better, things of that nature, going in and fixing a printer, because a lot of times they don’t have time to do that and they don’t have the expertise in-house necessarily, or the manpower, even if they had the expertise, to do those things. It dramatically helps them do better work; so, even something as basic as that makes a huge different.

Recommended Resources

Derrick:
Really, the final question that I have for you, Ed, is can you recommend any resources for those waning to learn more about these soft skills, especially for developers?

Ed:
There’s a couple things that I can think of that I would at least encourage people to explore. There’s a conference in Kalamazoo, Michigan every year called Kalamazoo X. It specifically is a conference for, I kind of hate this term, ‘soft skills’ for developers and people in tech. That’s what they do. It’s a pretty small conference. It doesn’t get a lot of play, but I heard about it from a friend of mine. She loves this conference and goes every year.

Specific resources are kind of tough; but, I think, in general, thinking about these kinds of things and valuing these kinds of things, I think that leads you in the right direction, if you keep those things in mind and value the things that we’re talking about here.

Derrick:
Thank you for your time today. We really appreciate it.

Ed:
Thanks for having me.