[csours]

I've been thinking about this A LOT over the last year. Knowledge work is Emotional work.

Software developers make software for PEOPLE. Making things for people requires empathy to be successful or else a whole lot of luck.

Having empathy means putting myself out there. It means asking questions that sound ignorant.

It means going from feeling like I had a great idea to seeing all the flaws and shortcomings of that idea, and being willing to accept the shortcomings of that idea and change my mind.

It means doing all of this and being 100% technically perfect. One extra space - computer says no. Number in the wrong place - computer says no. Off by one - computer says no. Tyop - computer says no.

[Jensson]

When people say you need soft skills to succeed they mean you need to have empathy for your manager and make your manager happy, nobody cares about the user. You see software riddled with bugs everywhere etc that would get fixed easily if anyone related to that project actually cared, but hey if the manager doesn't notice the problem then the problem doesn't exist so better not bring it up!

What you'll find is that many of those said to have bad soft skills actually just cared way more about the users than their coworkers. Steve Jobs or Linus Torvalds for example, if you sacrifice the user experience then this kind of people will get angry at you. If you are the top of the company it works, but if you want to climb the corporate hierarchy it doesn't matter you just need empathy for your boss, so you will get nothing for getting upset when your manager and your peers sacrifice user experience for no reason.

[dasil003]

I hear you, but you're conflating two things and drawing an overly reductive conclusion:

> if you want to climb the corporate hierarchy it doesn't matter you just need empathy for your boss, so you will get nothing for getting upset when your manager and your peers sacrifice user experience for no reason.

The second half of this sentence is true for any concern not just UX: if you get emotional about your manager and peers doing [anything they consistently do as a group] under the assumption they are doing it for no reason then you have already failed to understand the culture and marginalized yourself and your growth opportunities in that environment.

The first half is a false conclusion born out of the bitterness of passion tempered by misunderstanding. It may be true that in some nepotistic hierarchies that empathy for your boss would be sufficient, but as an engineer who has made a successful career by caring deeply about UX I can assure you it's no way to live. In healthy corporate cultures promotion to higher levels depends more on broad cross-functional empathy and the ability to collaborate and have good judgement with limited depth of information.

[Jensson]

Right, if your manager cares deeply about UX you should too. That doesn't refute anything I said, it is still the manager that is important.

[dasil003]

My goal was not to refute you, it was to offer a broader perspective based on decades of experience caring about the same things you seem to care about.

The words I used were "overly reductive". Yes, what your manager thinks is important, but so is the broader company culture and what you believe to be right. If the entire company doesn't value something and you do then you're fighting a losing battle and you should get out before your internal motivation is replaced by cynical survivalism. On the other hand, if the company does but your boss doesn't, then the trick is to keep your boss happy and work on the stuff that matters to you with the people that do care.

Keep in mind that managers come and go, if you subvert your own values and judgement simply to align with your manager, you may get a better performance review in the short-term, but in the long term you lose yourself and won't gain the kinds of leadership skills that are key to long-term success.

[_y5hn]

Often there are many times more concerns than just UX. Some of them real, other concerns manufactured. However, when the decision process is kept opaque, respect is kind of lost in that kind of environment. From experience, the people will never change either, but things can change when their start to die, retire or relocate.

It doesn't help to change company, when the same fads sooner or later starts getting pushed down there as well.

[bitwize]

Lack of empathy is commonly cited by Hackernews as the reason why some Linux app doesn't work exactly the way its macOS equivalent does.

[asiachick]

plug in a keyboard with an END key, oh ... like this one

https://www.apple.com/shop/product/MK2C3LL/A/magic-keyboard-...

and then tell me again that apple cars about the user or that HN wishes it was like MacOS :p

[stackbutterflow]

Regarding your last sentence, I think technical jobs, and especially people who write code as part of their job, are forced to develop a special kind of humility. Engineers, scientists, technicians, deal with the law of physics everyday. As a developer particularly you get immediate feedback dozens if not hundred of times a day. You can't bullshit your way out of a bug. The computer is cold, rational and executes the piece of code you wrote. You can't convince it to run your program with pretty words.

This is in contrast to other jobs, for example marketing specialist. As a marketing specialist you spend weeks or months on a well crafted marketing campaign, then you launch and the results are not bad but yet not great either. There could be millions of reasons for your campaign to have failed. You could job-hop thinking you did a great job and blame the lukewarm success on external factors.

There are people who spends their whole career failing at what they do who would never know otherwise because their job lacks this sort of cold instant feedback.

[whatshisface]

Programmers also suffer from the problem of no objective performance measure - there is no way to tell the difference between good programmer + hard problem and average programmer + easy problem.

[Jensson]

Which is why many programmers don't want to make good UI's. It is a ton of technical work to get all those features working, and at the end people praise the UX designers for doing a good job creating such a good UI and not the people who coded it all together, except if it breaks then it is the programmers fault. People say the code is the easy part, but seemingly not a single big company can actually manage to get the code right, and it gets even worse at most smaller companies, so from my perspective we lack programmers who knows what they are doing way more than we lack programmers who has empathy.

No amount of empathy matters if the programmer ultimately fails to code up a working system, you'd rather have a programmer who can code up a working system with all the fancy parts needed for good UX when given proper requirements.

[taneq]

Sure there is. You take each programmer’s self-ranked hardest N problems and get the other programmer to try and solve them.

[NateEag]

People are not actually fungible.

Each of us has different skills, insights, strengths, weaknesses, and life experience.

What caused one of us months of misery might be the next person's perfect problem, what they were born to solve flawlessly.

[taneq]

That’s why you average across several questions. If one is too hard just leave it. You’ll pretty soon get an idea who’s good at what.

[whatshisface]

And if one person has had a career of spending 1 year on each research problem while the other person has had a career of spending ten minutes on each UI micro-bug? You swap the problems, and person A spends 20 minutes, person B spends half a year, and you think person A is better even though they're actually 4x worse.

[taneq]

Just because you can contrive a pairing that’s less efficient to compare doesn’t mean it’s a bad test for colleagues.

[daniel-cussen]

Plot hole. Why did he spend 1 year on each research problem? After a year, what? A paper incorrectly proving the goal was impossible because that's what PhD's in industry say (I've seen this) so they're boss gets off their case?

[daniel-cussen]

Have a crack at the problem yourself.

[Findecanor]

Sure, you can bullshit your way out of a bug. It is called making a "kludge", also known as "technical debt".

It happens all the time... unfortunately.

[DangitBobby]

You can also blame things that were actually your fault on systemic problems. People will believe you.

[psfried]

I get the gist of what you're saying, and broadly agree that seasoned programmers tend to develop a strong sense of professional humility. I have to say that I think the analogy goes a bit too far, though. Even very poor programmers can get things to compile and tests to pass. The things that make a programmer very successful are still very nebulous and difficult to measure, just like in creative professions.

[rectang]

Collaborating with a computer requires a weird kind of empathy, too.

I've often observed that the best programmers are excellent at giving directions to people: anticipating places where confusion might occur, simplifying language, choosing slightly longer but easier to understand routes, and so on. There seems to be overlap between understanding the failure modes of a human following your instructions and understanding the failure modes of a computer following your instructions.

The machine takes you completely literally: if you tell it to delete the production database, it will. It will not stop to ask you, "uh, do you think that's a good idea?", unless you've told it to do that too. It has no common sense on its own. And yet, because it is natural for humans to do so, programmers anthropomorphize the machine.

So programmers empathize (if you will) with our machine collaborators, which is similar in a way to empathizing with users. But anthropomorphized computers and actual human users aren't the same, and eliding them brings sorrow.

[tomxor]

You also need to be careful with your empathy, it can get burned if you are exposed to the wrong users too much. It's good to stand back a bit before trying to relate to a user issue and ask "does this person deserve my attention"... that might not sound fair, but if you don't you will start to not care at all.

[ehnto]

A lot of software gets made at a disconnect from the user or client as well, which is very demoralizing in itself. You never get the opportunity to truly empathise with them to get their needs explained correctly, and you also never get the opportunity to explain yourself if you happened to misunderstand the vague instructions given. Everyone has a bad time, and the results are bad to boot.

Even when software I write is used by thousands, if I never meet any users it may as well be as real as conversation with a GPT chat bot. The text on the screen says things are going well, the text is happy. I am pleased to help the text.

[open-source-ux]

Lack of empathy abounds among programmers writing user-facing software. I am increasingly convinced lack of empathy is over-represented among developers. It's a controversial thought, and feel free to shoot it down.

But why the lack of empathy? Is it because developers are more comfortable with computers than with people? This is a common stereotype about programmers. Perhaps it has more than a hint of truth to it?

Examples of abrasive behaviour in developer circles are too numerous to list (from real life and online).

It's not just a lack of empathy towards fellow developers, lack of empathy is even more marked when applied to "non-technical" users who are often patronisingly viewed as clueless idiots (and a source of irritation for developers).

So many UIs (visual and non-visual) and interactions are badly designed by developers who show no empathy toward users struggling to complete tasks. If you can't use the software you're considered a clueless and annoying 'newbie'. (How dare you suggest I 'dumb down' the interface to accommodate your cluelessness).

RTFM? (Read The Fucking Manual) Even this patronising acronym speaks volumes about the sneering attitude among many developers towards other developers and users. (Never mind the fact that in most cases the manual doesn't exist or is so poorly written as to be useless.)

[SomeCallMeTim]

What you describe is orthogonal to whether a developer has empathy, though.

1. UX design is a trained skill that most developers don't have. It's not a lack of empathy if you have no idea how to create a better user experience.

2. Many developers are in it only for the paycheck. They do exactly what they have to in order to keep being paid, and not a minute more of effort goes into their work product. They may be an excellent people-person, and in fact may be able to talk themselves into raises and promotions at work due to their excellent empathy skills. But if they really don't care about the end user or the work product, that's not a lack of empathy as much as a lack of pride in work.

3. RTFM may be misplaced if there really is no good manual, but a significant fraction of the time I've seen it employed (or more polite variants) was because there was a manual that had the exact answer the developer asking the question was looking for, and the questioner just didn't bother to look. I spent an entire year and a half on a project answering questions to the same developer with links to the documentation where he could find the answers he was seeking. I swear he would ask me something at least weekly, and I always could just point him to exactly where I'd already answered that question. It's not a lack of empathy to just start saying RTFM. It's a failure of PATIENCE with someone for asking the same question you've already answered a hundred times because they're too lazy to look up the answer themself.

And telling an end user to RTFM goes back to point #1 above: If the user feels the need to ask how to use a product, then that's a failure of UX. See Don Norman's many books on the topic: He's fond of saying that an ideal user interface shouldn't require instructions. An as in point #1, if you needed instructions to begin with, that implies bad UX, which isn't the fault of a programmer, but rather of a UX designer. Most programmers also shouldn't be front-line on helping end users anyway because of the patience issue I mentioned.

There are developers out there who just lack any form of empathy. Granted. Anyone with the skill to code can likely find work, regardless of their shortcomings; demand is such that they will be hired even if they're generally jerks. But I don't accept that programmers are in general less empathic than an average person. It's just that empathy isn't a job requirement.

[Karrot_Kream]

It probably started out as a character trait among early programmers, but these days I'm convinced it's mostly a cultural thing. It's not actually about the software as much as these folks want to say it is by saying things like "RTFM"; it's selecting for people with similar emotional reactions to themselves. Consequently, you're also going to see more abrasiveness in very online programmers. Devs that don't want to deal with the abrasive gatekeeping and bikeshedding online and just want to get shit done either work on projects and share them in private circles or quietly write cool software for industry. I know folks working on microkernel stuff and capability-security that just don't want to get into online language flamewars or complexity flamewars, so they just don't publish their stuff on the big link aggregators.

Entire online software communities (suckless, PL enthusiasts, etc) have been created around cultures of rewarding gatekeepers; things like "our software sucks because we're forced to write it for _normies_" (suckless) or "oh those capitalist, Fordian idiots causing us to use sad programming languages that aren't Haskell/Ocaml/Lisp/etc" (PL enthusiasts). It's sad because it holds these developers back from understanding why people don't buy into their philosophies. But for a lot of these folks, I don't think writing and sharing software is the end goal. They want to form a community and a culture with other people where they can shit on the normies or Fordians because it offers them pleasure in some form.

[JoelMcCracken]

The last time I remember seeing someone say "RTFM" is probably something like 2006? in the freenode bash IRC room. Where are you frequenting that you see such things?

I don't know any haskellers who I would think say or think the things you say. Most of them realize that they're into a niche thing. I think most of them want the good things of haskell to be shared to the larger community, but we just don't know how to get there from here.

Well, I take that back. There is one person I know of who is what I would consider gatekeeper-y, and I really generally disagree with him on almost everything, except I too like Haskell.

But this is one person out of the many many haskellers I know.

[Karrot_Kream]

> The last time I remember seeing someone say "RTFM" is probably something like 2006? in the freenode bash IRC room. Where are you frequenting that you see such things?

Just a cursory search, nothing specific:

https://news.ycombinator.com/item?id=28831243

https://lobste.rs/s/yjvmlh/go_ing_insane_part_one_endless_er...

https://lobste.rs/s/yjvmlh/go_ing_insane_part_one_endless_er...

https://lobste.rs/s/yjvmlh/go_ing_insane_part_one_endless_er...

https://lobste.rs/s/d1tk0e/overhead_returning_optional_value...

https://lobste.rs/s/cpfajx/java_16_gets_records_jep_395#c_dr...

https://news.ycombinator.com/item?id=29006854

I can definitely find more but this is what 5 minutes of searching turned up, and while many of them come from the same thread, I can find way more where that came from. There's legitimately a vocal contingent online that wants to gatekeep around PL usage. Note the language there: "inferior language and ecosystems", "Rob Pike doesn't trust programmers to be good", "The entire attitude is an apology for the bare fact that Go doesn’t have error-handling syntax", "perhaps we care a little too much about ordinary users?" These aren't solidarity-building statements. They're about flaming, expressing intransigent opinions, and gatekeeping.

> I don't know any haskellers who I would think say or think the things you say. Most of them realize that they're into a niche thing. I think most of them want the good things of haskell to be shared to the larger community, but we just don't know how to get there from here.

When I said "PL enthusiasts" or "suckless", I don't necessarily mean to say every, or even most, PL enthusiasts fall into that bucket. Likewise devs interested in simple architectures aren't all in the "suckless" camp. Like I said, there's plenty of folks doing great work exploring things like ML-based functional programming or simple, composable designs. What there also is though is a vocal community, probably a minority, of folks who _do_ create a tribe of gatekeepers. As I was saying in my last post, these folks are usually the Very Online type as most folks trying to actually get things done spend less time inciting flamewars and more time actually writing code.

But my post is more about this strain of very (online) visible toxicity in programming. Taking opinionated, intransigent positions is disturbingly common in programming and I largely think it's a practice holding the state of the art back.

[JoelMcCracken]

I see. When I read your statement, I interpreted it as statement about a majority of devs in such communities.

I actually came into the haskell community expecting MORE of such behavior, becuase I think common wisdom is that Haskell is full of gatekeeprs. I've been quite surprised by how little of it there actually are.

I'm not sure I totally grok your point re: golang. Just go read Rob pike's statement. That doesn't mean much about golang per se; he may have been attempting to make something suitable primarily for beginners, and hit upon some kind of impossibly powerful design (i'm thinking like scheme or something). But I hear about how bad golang code has to be, and well it makes me very sad.

Of course, golang does solve actual very real problems, and failing to acknowledge this is holding back the industry 100%. It also meets people where they are, not where the language author is, which is of course something we really need to come to terms with as a group of people who want to push the industry forward.

[Karrot_Kream]

> I see. When I read your statement, I interpreted it as statement about a majority of devs in such communities.

> I actually came into the haskell community expecting MORE of such behavior, becuase I think common wisdom is that Haskell is full of gatekeeprs. I've been quite surprised by how little of it there actually are.

Yeah I don't mean to imply that this is something specific to the Haskell or PL community. More that there is a strain of vocal gatekeeping in the field of software dev as a whole, and it finds most purchase in niche communities like PL enthusiasts or simplicity enthusiasts, probably often because small communities don't always have the time/manpower to create consistent messaging and guidelines.

> I'm not sure I totally grok your point re: golang. Just go read Rob pike's statement. That doesn't mean much about golang per se; he may have been attempting to make something suitable primarily for beginners, and hit upon some kind of impossibly powerful design (i'm thinking like scheme or something). But I hear about how bad golang code has to be, and well it makes me very sad.

I just linked those posts from a thread I found, it's not really a point I'm trying to make myself, though hating on Go is a common sport for folks who write in niche languages. (So P(niche language writer | hater) is high, not that P(hater | niche language writer) is high.)

> Of course, golang does solve actual very real problems, and failing to acknowledge this is holding back the industry 100%. It also meets people where they are, not where the language author is, which is of course something we really need to come to terms with as a group of people who want to push the industry forward.

Right and that's all I mean. I firmly believe that choosing a PL is often a complicated decision and is often driven more by the problem domain than anything else. But the toxic gatekeeping around the dialogue ends up making everyone defensive and has people take increasingly intransigent positions, which leads to silly divides instead of folks working together to advance SOTA.

[varjag]

If anything that's more a cliche than something controversial.

[throwaway2331]

I don't think it's that programmers are, on average, less empathetic than "non-programmers/techies/whater."

In my experience, it's always been that people who are technically-minded, usually don't have the soft skills to make it look like they care -- without really getting emotionally involved at all.

Most people are just trying to go about their day and deal with their problems as they come up. Whether they be financial, emotional, inter-rational, mental, or what have you; everyone is primarily focused on themselves.

Most people will feign empathy and side-step such things with some tact, because their livelihoods and current level of comfort relies on other people liking (or atleast tolerating) them. Whereas programmers have a little bit more insulation -- a moat if you will -- for being tactless jackasses, because other people will still tolerate them (for the moment), so long as they ship that code and stay in their caves, away from real people.

The same is true about many BB IBankers: what's the point in being a decent human being? You're getting paid fat stacks to brown-nose. The best, most soul-less brown-nosers get rewarded by making MD/VP. Whether or not you have empathy is irrelevant to your compensation, i.e. your comfort and livelihood, i.e. your goals.

t. someone who used to be a virulent jackass thinking meritocracy was the be-all, end-all

[burlesona]

I don’t know if it was intentional, but IMO your last sentence is perfect.

I agree with you about the emotional aspect, and I think it’s one of those blind spots that a lot of engineers have. In my experience, the best software engineering is done by the engineers who _care_ the most about the end user experience and the work their software is doing. And the people who care most aren’t always the most brilliant computer scientists or analytical minds.

[austincheney]

> Software developers make software for PEOPLE. Making things for people requires empathy to be successful or else a whole lot of luck.

I have spent my entire career watching people say this and simultaneously doing the opposite out of either convenience or insecurity. This illustrates either a complete misunderstanding of empathy or some immature self-loving platitude.

[dudeman13]

Add a product designer or project manager that actually do things and all the empathy/making software for people becomes optional.

[Jensson]

Only works of the product designer or project manager actually has empathy to the users, which seems to be just as rare as developers having it. They are hired to manage and track user complaints and keep it below a certain level at minimal costs to the company, not to empathize with users. Or maybe that is what you meant, if you have dedicated people for that role then nobody has to empathize with the user, the product can churn along anyway.

[dudeman13]

Ah, I meant for the programmer to empathize with the user.

If you have people dedicated to those roles, they should be the ones that decide what to do by default. As such, programmers don't really need to care about the user at all (although they can)

Specs come in, software comes out :)

[saynay]

I feel like you need a balance there. If your programmers cannot put themselves in the shoes of the users at all, you need really really good specs. If they can, your specs don't need to be as... specific, as you can rely more on the programmers to make reasonable design decisions.

[unphased]

And to add on to that, you're lucky if your computer just tells you no. Often you get a yes and something blows up much later with precious little for you to follow and you've got to put your Sherlock hat on.

[iamdbtoo]

Yes. Thank you for putting this so succintly. I've been looking for the words to describe it.