“The craft of programming begins with empathy, not formatting or languages or tools or algorithms or data | structures.” - Kent Beck
We found this quote on Twitter and have no context to it. In our show (nearer the end) we try to determine what it might mean, and whether we agree with it.
Is Beck referring to empathy for users, other developers, or something else? What do you think? Do you agree with it?
My opinion in the end is that I agree there must be an understanding of users expectations, but that "empathy" is the wrong word.
Top comments (29)
Regardless of verbiage, I'd say that the answer is an emphatic yes. I'm not sure where empathy ends and other associated traits start, but in general yes.
However............
Having "empathy" doesn't make up for lack of experience, discipline, and other problem-solving skills. Software development requires a lot of different skills.
I'd also add that this discussion is usually framed as a counter to a, perhaps, stereotypical idea that programming is "purely logical" or something like that. Emphasizing empathy as a valuable software skill helps attract folks who might not self-identify with other skill sets. There are many paths towards software excellence and it's easier to venture the path if you think you belong.
I can tell you this, it's a lot easier to express your own empathy if you have a mastery of the tools you are using. I don't really have any experience in operating systems development. All the empathy in the world probably wouldn't help me before learning the lower level tech. Different story on the web. I have the initial skill sets where an empathy for the user/developer goes far.
I wonder, if when it comes to technical concepts like OS design, whether empathy would imply being able to understand an OS designer? This is the part that I'm unsure about the word empathy. If you're dealing with logical and rigid structures, does empathy imply you understand them as well? Without that, you won't be able to get inside the mind of the person coding it.
Definitely though, empathy is certainly not enough to be a good developer. It cannot make up for a lack of other skills.
I worked on RTOS and driver code in college for a robotics competition. In the 3 or 4 years I did that, I noticed one of the biggest driver for how long your code survives in the organization is how easily other people can use it. "Use" has a lot of different meanings depending on the organization, and for my robotics team, it meant "compile", "test", "extend", "modify", "understand", and "maintain" in various proportions to different people. Any combination of the above would require some exploring into other people's heads. How will the way the API is structured drive people to use the code? How will the way the documentation is written drive people's understanding of the code? How will the implementation drive people to maintain the code? So it's just like any other software, except an OS developer's user base is a very specific group of people. Things like well written documentation and consistent, understandable style are just as important as in any other software project.
I believe empathy is really subjective but correct at the same time. Let me elaborate:
Programming in my opinion is first a way of expression of how us as humans think about a subject and second as a piece of technology that enables us to solve problems, craft new tools for specific purposes and much more. So when I start coding I do it with the mindset of delivering my best solution in the time I'm given but also thinking of the next programmer that, in the future, will be touching my code. Will he understand what I meant with this function? (I know, that's what comments documentation generators are for but nothing beats a good'ol naming convention of variables, functions and classes) Is my solution readable enough so it can almost be read like a book's paragraph but concise enough to be called clean code? In short I'm always thinking of ways to help future developers working with my code.
This empathy also considers our users, be it other devs or the clients. When coding always think about your user, specially If you develop UI. A menu suddenly vanishing by a misplaced button or excess of animation can scare future users and clients off your product so guiding them the best possible way through your UI could also be called a form of empathy.
Programming will always be about humans helping other humans.
Best regards!
I think when I hear the word "empathy" I think about feelings. I realize this isn't the sole definition of the word, which is more broad to consider the though process and experiences as a whole of another person. In that sense I think you're right on both counts -- we want to write code that a future programmer will understand, and create an application that does what a user wants.
Though, I am uncertain about the future programmer. "require" is a strong word. Is empathy really required, or would following a strong set of clean coding rules and logic be sufficient?
(I have no doubt about the user. If you don't have empathy with them, your app will suck. And given the state of current UI's, I have to assume this lesson is lost on most UX designers.)
Gosh, that's a question that makes you think.
I had to look up empathy to figure out if I agree. The definition I found was "the ability to share someone else's feelings or experiences by imagining what it would be like to be in that person's situation".
If he is saying that being able to imagine what a situation would feel like, and so having a strong reason for 'why' write the code is as important as knowing 'how' you want to write the code. I'm sort of comfortable with that.
Part of what makes this site and some projects rewarding is that there are people who are good at empathy. I'd like to be better at it myself because when I find myself seeing the world from someone else's perspective I feel I learn things.
But I'm personally a bit cautious or skeptical of any statement that says that anything is the best or right way of doing something.
Considering what Kent Beck is generally known for, I'd say Google's Project Aristotle is a relevant mention.
Edit: Here is a video with a brief description of the study.
The causality argument here would likely need to be investigated. How did these teams end up structured this way? Was it because their members were empathic, or did they rigidly choose to take this approach as they knew it would work?
I'm assuming the good teams arose from many members with strong social skills -- but that's just an assumption.
The details are in the study. But I believe standard hiring practices were used, primarily based on technical merit and critical thinking. (You know, those weird Google interview questions.) The point of the study was to try to determine what made some Google teams successful and others not. And in fact they could not find any commonality among successful teams at first. They initially examined things like age, diversity, education, skill level, etc. and came up with no correlations. That's when they started trying to find other factors and discovered the connection between success and the "emotional intelligence" of the team.
You didn't say this, but I wanted to point out. I do not think you have to be extroverted to have emotional intelligence. I am introverted and tend to have some. Rather I think emotional intelligence means really listening to and processing what other teammates are saying. It is all too easy to rely on our old mental models of people and situations and ignore new (especially contrary) information. It is pretty noticeable when someone on the team chronically "doesn't listen" or "does their own thing". That can lead others on the team to decide they no longer have to put in the effort to listen either. This video is pretty relevant to that aspect. She is describing the results of a different study, and you can back up to get the overview of that study. And in fact, I'm pretty sure I heard of Project Aristotle from another Sandi Metz video. Both links should be at the relevant section of the video.
Really interesting!
This looks to be the original tweet by Kent Beck ( twitter.com/kentbeck/status/566255... ):
Judging by another comment he makes further down in the discussion,
I get the impression that he is at least in part referring to the importance, when writing code, of thinking proactively of the people who will be reading that code in the future (which could be the original author of course).
Making the intent and workings of the code as clear as possible does seem valuable to me, given that modern code is being updated all the time. Personally, empathy seems to me like one of many qualities that are valuable though. Here Kent Beck seems to elevate it to a special status above other important qualities, like motivation, dedication, problem solving, etc. I'm not sure I go along with that.
I do think it's usually worthwhile for us to consider how people who have to work with our code later on will feel about it, and to try to make that experience as easy as possible. However, I think there are programmers out there who would work hard to make their code clean and readable, but they might not look at it from the point of view of empathy. They might see it as just taking pride in their craftsmanship. The result would still be the same though.
The comment sounds like it might be somewhat reactionary. If you're working in an environment where people repeatedly make similar mistakes, and continually work for themself, you'll start prizing the attribute you think everybody is missing.
No, but success in life does. You can build anything with or without love, but I know which house I'd rather live in, which meal I'd rather eat.
There is such a thing as a spiteful genius, though. Kind of person you'd like to hear their sonatas but wouldn't want to share a drink with... or let near your kids...
I don't think empathy implies love. It's possible to understand how others feel without having any attachment to them. I think this was researched in regards to psychopaths, who may actually have a strong empathy ability, but can emotionally distance themself.
So you're saying we should optimize CS curriculum to ethical psychopaths ;)
Jokes aside, I think that's fair.
Programming?
No.
Software Engineering?
Yes. Because that's a team job. Even if you are working back-end, far away from nit-picky users, you still need to write APIs, and empathise for fellow engineers who are going use your APIs.
I don't distinguish these terms. I distinguish "coding" from "programming/engineering" though. I consider programming to be a lot of things.
Even in relation to coding though, it seems there is an opinion here, that we must be empathic for the future coders reading our code. Do you agree?
Definitely agree.
A bit of an romantic here, where I think that software is a kind of literature that is meant to be shared and read by other people to learn. It written in a way should be readable to human.
I distinguish "programming" from "engineering" probably the same way you distinguish "coding" from "programming/engineering". When I'm designing formulas for spreadsheets, I feel like I'm programming, but I hardly feel like I'm engineering. Personally I feel that engineering is a level up from programming and requires another set of brain muscle to think about not just creating a solution to a problem, but also creating a robust yet malleable solution that lasts. I'd even imagine how the software might need to evolve over time as requirements change, years later, and the person who's updating the code is probably not going to be me, and what if it's a junior developer? I need to plan the architecture, design the APIs, and document the system in a way that's easy for anyone to contribute.
The answer is no if your software has no users and you are developing by yourself...
Coding is a craft not an art. Craftsmanship require skills, you need to be good at it.
Can you be a good dev if no one is using your code?
Basically, do we exists only through others eyes?
I have no idea.
Empathy is a skill/value we can only learn by interacting with others.
If a tree falls in a forest and no one is around, does it make a sound?
Unfortunately, I only have more questions.. Do we write code to communicate with the machine or with other humans who will read it? I am not even sure whether programming is a craft or an art or a science. There are definitely subsets of all 3 involved.
We have to separate the end and the mean. You write code to machine for other human. I can't think of any useful program that no one use (correct me if I missed it).
In my opinion, science bring craft which bring art (science -> craft -> art). Any can stand for itself and not feed the next, breaking the chain.
Obviously, Code is based on Computer Science and can produce art.
I'm getting away from the point, but if code is a craft it serve a purpose. Therefore, you need the least bit of empathy to understand your user problem and build what he/she need.
ps: concerning your link to the "tree falling phylo", I love this answer :
Code without user is just thin air.
It's only no if you are guaranteed to never ever read your code again in the future.
In all other cases, then you also need to have some empathy with your future self.
I think this is a fair response. Unless somebody shows how empathy is required, there's no reason to say it doesn't. As the question is phrased the same as "Does programming require telekinesis?" To which "no" is also a valid answer.
Yes.
Code is communication with humans not machines.