Kindness and Code

It is very easy to think of software development as being an entirely technical activity, where humans don’t really matter and everything is about the computer. However, the opposite is actually true.

Software engineering is fundamentally a human discipline.

Many of the mistakes made over the years in trying to fix software development have been made by focusing purely on the technical aspects of the system without thinking about the fact that it is human beings who write the code. When you see somebody who cares about optimization more than readability of code, when you see somebody who won’t write a comment but will spend all day tweaking their shell scripts to be fewer lines, when you have somebody who can’t communicate but worships small binaries, you’re seeing various symptoms of this problem.

In reality, software systems are written by people. They are read by people, modified by people, understood or not by people. They represent the mind of the developers that wrote them. They are the closest thing to a raw representation of thought that we have on Earth. They are not themselves human, alive, intelligent, emotional, evil, or good. It’s people that have those qualities. Software is used entirely and only to serve people. They are the product of people, and they are usually the product of a group of those people who had to work together, communicate, understand each other, and collaborate effectively. As such, there’s an important point to be made about working with a group of software engineers:

There is no value to being cruel to other people in the development community.

It doesn’t help to be rude to the people that you work with. It doesn’t help to angrily tell them that they are wrong and that they shouldn’t be doing what they are doing. It does help to make sure that the laws of software design are applied, and that people follow a good path in terms of making systems that can be easily read, understood, and maintained. It doesn’t require that you be cruel to do this, though. Sometimes you do have to tell people that they haven’t done the right thing. But you can just be matter of fact about it—you don’t have to get up in their face or attack them personally for it.

For example, let’s say somebody has written a bad piece of code. You have two ways you could comment on this:

“I can’t believe you think this is a good idea. Have you ever read a book on software design? Obviously you don’t do this.”

That’s the rude way—it’s an attack on the person themselves. Another way you could tell them what’s wrong is this:

“This line of code is hard to understand, and this looks like code duplication. Can you refactor this so that it’s clearer?”

In some ways, the key point here is that you’re commenting on the code, and not on the developer. But also, the key point is that you’re not being a jerk. I mean, come on. The first response is obviously rude. Does it make the person want to work with you, want to contribute more code, or want to get better? No. The second response, on the other hand, lets the person know that they’re taking a bad path and that you’re not going to let that bad code into the codebase.

The whole reason that you’re preventing that programmer from submitting bad code has to do with people in the first place. Either it’s about your users or it’s about the other developers who will have to read the system. Usually, it’s about both, since making a more maintainable system is done entirely so that you can keep on helping users effectively. But one way or another, your work as a software engineer has to do with people.

Yes, a lot of people are going to read the code and use the program, and the person whose code you’re reviewing is just one person. So it’s possible to think that you can sacrifice some kindness in the name of making this system good for everybody. Maybe you’re right. But why be rude or cruel when you don’t have to be? Why create that environment on your team that makes people scared of doing the wrong thing, instead of making them happy for doing the right thing?

This extends beyond just code reviews, too. Other software engineers have things to say. You should listen to them, whether you agree or not. Acknowledge their statements politely. Communicate your ideas to them in some constructive fashion.

And look, sometimes people get angry. Be understanding. Sometimes you’re going to get angry too, and you’d probably like your teammates to be understanding when you do.

This might all sound kind of airy-fairy, like some sort of unimportant psychobabble BS. But look. I’m not saying, “Everybody is always right! You should agree with everybody all the time! Don’t ever tell anybody that they are wrong! Nobody ever does anything bad!” No, people are frequently wrong and there are many bad things in the world and in software engineering that you have to say no to. The world is not a good place, always. It’s full of stupid people. Some of those stupid people are your co-workers. But even so, you’re not going to be doing anything effective by being rude to those stupid people. They don’t need your hatred—they need your compassion and your assistance. And most of your co-workers are probably not stupid people. They are probably intelligent, well-meaning individuals who sometimes make mistakes, just like you do. Give them the benefit of the doubt. Work with them, be kind, and make better software as a result.

-Max

19 Comments

  1. There is an obvious flaw in your reasoning.
    You meet somebody in the elevator, you are polite and kind.
    This person steps on your foot once, you are polite and kind.
    What happens the third time this person steps on your foot?
    The fifth time?
    Case a. you are a saint and you die polite and kind, case b. you are just human and at some point you stop being polite and kind.
    Because you know, there aren’t many reason why somebody keeps stepping on your foot, just two actually, the guy is stupid or bad, in both cases he is dangerous.
    Yes, you could also have abnormally long feet so the guy can’t move without stepping on one.
    I guess in this case you can’t be in the elevator with anybody so again the reasoning doesn’t apply.

    • No. This comment here seems to be missing the point.

      First off, your fellow developers aren’t stepping on your feet. They aren’t causing you physical pain or even attacking you. There’s no reason you would react to bad code or a difficult technical discussion like you would react to a person who is actually physically attacking you.

      Secondly, read the last few paragraphs again and realize that I said that you _should_ stop people from doing bad things. I don’t know what you’re proposing you would do here that would actually solve the problem besides like, call the police on the guy at some point? I don’t see how any of this is a justification for being rude to your co-workers.

      -Max

      • I have worked with many “fellow” developers who stepped on my foot. In my experience that happens because on top of all the common issues people have, developers on average tend to have serious difficulties in relating with others and twisted personalities.

        There are countless examples.
        The relatively funny ones like you demonstrate a new product to clients, you activate some feature and you get the classical “demo-catastrophic-error” but instead of seeing the “lorem ipsum” text you are showing on the big screen a nice sequence of profanities. The really bad ones like a client is calling on the phone because the server is down o the software crashed somehow and you aren’t at your desk, your “fellow” developer is there playing solitaire or watching porn and does not pick up. Or you must coordinate to work on different parts of the same software and your “fellow” developer refuses deliberately to agree on how to do things and instead he make efforts to make your own part as harder as possible, to the point the whole projet fails, just for the enjoyment of it. To not mention your “fellow” developers stealing stuff from the company that employs both of you, telling lies all the time, faking analysis, trying to steal your work or trying to get credit for your own achievements and so on.

        Besides, it is not just about work, when you take a look at the whole “open source” ecosystem, Linux and stuff, you can easily see people step on each other feet all the time and for no other reason than the fact that many are either stupid or bad (you can be both and still be able to code).

        Dude, you live in la-la land.

        • I got everything you’re saying, Nemo.

          It sounds like you’re just saying that people are often bad. Perhaps that’s true. But it doesn’t require being rude to fix it. You don’t even have to be rude when you’re firing somebody or writing a report on their behavior to HR and management.

          Note that it sounds like you’ve been in an environment where people keep on being bad, so perhaps what you’ve been doing about it so far isn’t actually working. Have you considered that possibility?

          -Max

      • Max – your thinking resonates with me and has always been my mantra in software development. Reading the comments though it’s clear that not everyone agrees. My views have come around to the “enlightened self-interest” view, that it’s in your own best interest to be kind to others and not do damage to them intentionally. There are so many ways that we do damage unintentionally, like making simple mistakes that others have to spend hours to fix. Mindfulness about our actions, empathy for those in our coding universe and just plain giving a shit about what we do – matters – and comes back to us in kind.

    • I think the point the author is trying to make is that your reaction to bad/negative events should steer the interaction/environment in a positive direction. If somebody steps on your foot, a positive reaction would be like “Excuse me, but your stepping on my foot hurts, and I’m not sure what purpose it serves, could you explain?”.

      I’ve worked with difficult developers as well, and I used to have this “I’m not being negative, I’m being honest” attitude. But that’s still negative, and I eventually learned that if I ever wanted other people to change their attitude, all I can do is be a positive influence, period.

      Trust me, I’ve had juniors make some serious mistakes that cost a company money. It’s very frustrating, especially after you’ve explained how to avoid those mistakes beforehand. But calling people out triggers a negative response, always, even if they don’t show it immediately.

      You seem to be focusing on the negative side of things, without offering any kind of solution. That was exactly the reason the junior dev I mentioned was hard to work with as a Senior Dev. Once I reacted with an open dialogue, rather than pointing fingers, I began to see a change in his reaction, we started discussions instead of arguments.

      I think that’s the authors point here, positive change in a toxic environment has to start with a positive (or at least constructive) dialogue. Pointing out failure without offering a solution accomplishes nothing. If anything it has a negative effect, making the initial problem worse.

    • To stay within your example/analogy, you don’t have to treat him rudely in order to prevent him from stepping on your foot. Period.

      In fact, treating him rudely will *not* prevent him or dissuade him from stepping on your foot. This is the error made by “punishment-drive psychologists”: if you stamp on his foot really, really hard, it will “teach” him that bad things come when he steps on your foot and then he won’t do it anymore. Or if you scream in his face that he’s an a-hole because he stepped on your foot, then he will “learn” by punishment and never again step on your foot. The theory doesn’t work. (If you don’t believe me, you can try it out next time someone jostles you or steps on your foot. Scream at them enough and you might get a fist in the teeth.)

      Instead, exactly as described in the last paragraph of this post, you might speak up (calmly) and say, “Hey man, could you please look a little bit more closely where you’re walking? You just stepped on my foot.” This is much more likely to be effective than rudeness.

      You set up a totally false dichotomy in stating that either the person is stupid or bad. Has it occurred to you that when you treat other people with that belief, they will naturally react to you badly? And their irritated or resentful behavior toward you can then be interpreted by you as proof that they are stupid or bad: a self-confirming hypothesis. Try to treat others as you would want them to treat you and you may find their behavior toward you improving also.

  2. I believe the last statement of the post “Work with them, be kind, and make better software as a result.” is the one of the most important statements here.
    At the end of the day you want your team to succeed, you want your product/service to succeed, and you want to spend your time doing impactful things and not refactoring/redesigning old code only because it is now too complex to add more functionality to it.
    If you see one of your peers needs correction during code reviews, whether its design-wise, readability or anything else, the more you react sensibly and logically (and not emotionally) the better the chances your peers will accept your review quicker.
    In addition, sometimes the other person has more context than you do. So even though something might appear off, it’s actually the right thing to do. By being rude you might make a fool out of yourself later. Try to understand if there is a good reason why the other person wrote the code that way.
    Anyway, thanks for the good post.

  3. Thanks for the article, I appreciate it a lot! Frankly, I would like to live in a world where articles about keeping to some cultural standards would not get any popularity as something pretty much obvious. Unfortunately, we are not; I cannot think about any kind of explanation of being simply rude toward other people. Anyhow, the tendency happens to change, also due to voices like yours – and I am glad to witness that.

  4. I Agree too, Team members always should be helpful and kind to each other, help other developer, let other help you. it makes success more easier to achieve 😉

  5. Fully agree.

    It’s important to be diplomatic, supportive and open. Software Engineering can be a demanding profession and supportive colleagues aid resilience. This is a two way street.

    A lot of it I think comes down to the attitude and emotional / self-support skills of each person involved. Not a simple personality measure – I’ve met over time several of the stereotypical introvert, logician, system thinker types and they come in all flavors, like everyone does.

    Trends I’ve noticed that lead to ‘cruelty’ situations can include over-inflated false confidence (see the dunning-krueger effect), poor responses to impediments or mistakes, high self-chastisement with mistakes, strong ego-defending (saving face is an example), ‘passive-advantage’ effects whereby other developers get used to a higher performer pulling through a higher workload and resist changes sought by the impacted colleague (a form of boundary crossing), poor interpersonal maturity and skills including crossing boundaries, bringing unprofessional habits into the workplace, and more.

    People can choose professions because of what they avoid as much as what they offer. The stereotype of spending your time in a backroom with only machines is still present to a degree, and unfortunately for the foreseeable time the profession will still attract, and allow in, people who only want to do that and avoid human relations, or even people who are technically brilliant but have no measure of people soft skills.

    One thing I would add is that people have limits, and sometimes the reserves are emptied by stress or demand of the profession. Courteousness is still important especially with the customer, but otherwise a little understanding and forgiveness goes a long way with over-stressed team members. To that end companies do better with good employee enhancement, support and retention programs. Apparently some existing companies still believe to not be their responsibility.

    • To be frank, if you had not begun your comment with “fully agree” I would have no idea what your position was on the topic of this article, though I’ve read your comment four times. It seems the sprinkling of psychological terminology is not aiding the effective relay of understanding or information to your audience.

      Personally, I prefer clear-cut engineering style statements with precise and particular meanings, even when discussing subjects that relate to the human rather than the technical side of our profession. For example, the author’s statement: “There is no value to being cruel to other people in the development community.” This is a statement with an exact meaning, requiring nothing but an understanding of the plain sense of the English words used. (And note I am *not* a proponent of the notion that all statements must be reducible to numerical meaning as in mathematics in order to have logical validity. Symbolic logic is a far weaker tool than well-written English for expressing precise ideas without losing nuance.) His is also a statement I believe is literally true and quite meaningful.

      Having read your comment three times further, it seems its intent would be preserved, enhanced and clarified (much like program code when Code Simplicity principles are applied) if one were to refactor it to simply state, “Kindness is among the most important qualities to preserve in oneself, despite the many difficulties and discouragements one may encounter in trying to do so.”

      This also avoids the rat’s nest of undefined “psychobabble BS” which so often hinders effective communication about the human side of our profession—and which actively *turns away* those technical people who prefer their data in a more orderly format. 😉

Leave a Reply