7 ms·
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 peopl
by csours 5y ago
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.
- burlesona 5y agoI 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.
- tomxor 5y agoYou 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.
- stackbutterflow 5y agoRegarding 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 5y agoProgrammers 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.
- taneq 5y agoSure there is. You take each programmer’s self-ranked hardest N problems and get the other programmer to try and solve them.
- NateEag 5y agoPeople 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 5y agoThat’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 5y agoAnd 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.
- daniel-cussen 5y agoPlot 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?
- iamdbtoo 5y agoYes. Thank you for putting this so succintly. I've been looking for the words to describe it.
- Jensson 5y agoWhen 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 5y agoI 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 5y agoRight, 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.
- open-source-ux 5y agoLack 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 5y agoWhat 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.
- dudeman13 5y agoAdd a product designer or project manager that actually do things and all the empathy/making software for people becomes optional.
- Jensson 5y agoOnly 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 5y agoAh, 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 5y agoI 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.
- austincheney 5y ago> 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.
- rectang 5y agoCollaborating 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.
- ehnto 5y agoA 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.
- unphased 5y agoAnd 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.