Programmers’ emotions(blog.sidebits.tech)
blog.sidebits.tech
Programmers’ emotions
https://blog.sidebits.tech/programmers-emotions/
33 comments
This spoke to me. Thank you for the check on my own imposter syndrome.
> The number one thing that got me to senior engineer, and will get me to staff as I improve (though staff has more of a relationship management component)
I love the little rat race we’ve created for ourselves. When did staff engineer become a thing? I’ve just noticed it but feel like it’s probably been around for a few years.
Next question when you get to staff engineer what next? Do you become a lead engineer or staff engineer II?
Jokes aside
> Not getting angry when the codebase is not architected well or is hard to understand.
This is the most important job hack for a software engineer of any artificial title. Even more important when your title starts with a C.
I love the little rat race we’ve created for ourselves. When did staff engineer become a thing? I’ve just noticed it but feel like it’s probably been around for a few years.
Next question when you get to staff engineer what next? Do you become a lead engineer or staff engineer II?
Jokes aside
> Not getting angry when the codebase is not architected well or is hard to understand.
This is the most important job hack for a software engineer of any artificial title. Even more important when your title starts with a C.
Usually I see Staff Engineer followed by a title like Architect. Never ever by anything about Lead or Manager because that's the whole point, you should be able to increase your scope so you're making tech decision across the whole org without also becoming a good people manager.
Staff engineer is the name for a “rank” but the rank has existed for a long long time. Staff is the first “leadership” engineering role - roughly equivalent to a manager in scope.
Some places have a manager equivalent of senior engineer but that’s also sometimes a role you’re expected to rapidly leave: either via promotion or back to IC.
Some places have a manager equivalent of senior engineer but that’s also sometimes a role you’re expected to rapidly leave: either via promotion or back to IC.
Pure dread, when you have signed up for a new gig and open an existing code base for the first time. Starring at hundreds of unknown files and folder with no idea what anything is and how it all works. No going back, you're a new maintainer, so better get to it. Usually after a few days you start getting a grasp, and it's not so bad though :)
Even worse is being 1 year into the gig and still having no idea...
A few days is exceptional. On average it takes me 3 months to a year to get to a point where I even kinda sorta feel comfortable in a codebase. There have been exceptions, but normally I find they're just written very expediently.
Feeling the same still after a few months. And dread is not very helpful when someone asks you to implement the new feature "now" (like none of your current tasks are as important as reducing the number of decimal points in that one screen).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Sure there is. You take each programmer’s self-ranked hardest N problems and get the other programmer to try and solve them.
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.
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.
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.
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.
Just because you can contrive a pairing that’s less efficient to compare doesn’t mean it’s a bad test for colleagues.
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?
Have a crack at the problem yourself.
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.
It happens all the time... unfortunately.
You can also blame things that were actually your fault on systemic problems. People will believe you.
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.
Yes. Thank you for putting this so succintly. I've been looking for the words to describe it.
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.
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.
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.
> 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.
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.
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.
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.
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.
It doesn't help to change company, when the same fads sooner or later starts getting pushed down there as well.
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.
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
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
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.)
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.)
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
> 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.
If anything that's more a cliche than something controversial.
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
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
Add a product designer or project manager that actually do things and all the empathy/making software for people becomes optional.
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.
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 :)
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 :)
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.
> 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.
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.
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.
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.
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.
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.
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.
This is so odd to me. There seems to be some sort of obsession with making sure everybody knows that programmers “Aren’t Normal People.” It’s just a job, doing it well doesn’t make you some Superhuman Logic Machine.
I’d love to see a post like this that includes “Pathologically Obsessive Need For Self Aggrandizement” as one of these ~Coder Feelings~ that only the Chosen Folks can experience.
I’d love to see a post like this that includes “Pathologically Obsessive Need For Self Aggrandizement” as one of these ~Coder Feelings~ that only the Chosen Folks can experience.
Right; Agreed 100%!
Other than requiring little more than average persistence and curiosity, there is nothing "superior" about it. Anybody can learn "Programming". We are natural born problem solvers and the only thing there is to learn is how to instruct a machine to do the same in a structured manner.
Other than requiring little more than average persistence and curiosity, there is nothing "superior" about it. Anybody can learn "Programming". We are natural born problem solvers and the only thing there is to learn is how to instruct a machine to do the same in a structured manner.
I agree in spirit, but I no longer believe that anyone can necessarily learn programming, maybe because some of those other elements are missing. That's just based on witnessing people who don't seem to be able reason though even the smallest unit of logic expressed in visual form. I believe that most people probably can though to some extent
"Programming" as a technique of problem solving can be taught and learnt by anybody just like Mathematics. Now whether they will become good at it depends on various other characteristics like Interest, Aptitude, Effort and Persistence. There is no inherent limiting factor since it is a function of "General Intelligence" which all of us "Normal" folks are imbued with.
> Relief. When I solved a problem I had been struggling with for a long time.
I like to call this an 'Aha! Moment'. They happen rarely enough though, so the dopamine hit is not enough to really enjoy programming.
Also: programming for me needs ergonomics and accessibility. My setup is really opinionated and catered to me only. Others can't so easily jump into my setup and start coding away. They'd feel really uncomfortable in my chair and have to understand all the keyboard shortcuts I have burned into memory, as-well as a bunch of macros.
I like to call this an 'Aha! Moment'. They happen rarely enough though, so the dopamine hit is not enough to really enjoy programming.
Also: programming for me needs ergonomics and accessibility. My setup is really opinionated and catered to me only. Others can't so easily jump into my setup and start coding away. They'd feel really uncomfortable in my chair and have to understand all the keyboard shortcuts I have burned into memory, as-well as a bunch of macros.
The sooner you realize that everyone on God's green earth is acting from an emotional place, the sooner that human interactions make sense.
How something makes people feel - or how they think doing something will make them feel - dictates the vast majority of human behavior.
How something makes people feel - or how they think doing something will make them feel - dictates the vast majority of human behavior.
Yes I quite like the metaphor that our rational mind acts largely as the press secretary for our emotions.
I have never heard that metaphor before but I like it very much.
I think it's Jonathan Haidt who popularised that phrasing.
The first part of his book "The Righteous Mind" discusses this aspect.
The first part of his book "The Righteous Mind" discusses this aspect.
I think it is also illumiating, if somewhat obvious, that people tend to have well thought out reasons for doing something.
So if you see someone doing something obviously stupid, you are probably not seeing the whole picture. It is extremely worth it to try figuring out why they do that. And in figuring that out it is important not to dismiss the other person's ideas out of hand.
people tend to have well thought out reasons for doing something. So if you see someone doing something obviously stupid, you are probably not seeing the whole picture
I used to think this, until I read more about advertising and how it's designed to trigger an emotional response. More and more, I think it's really emotions that motivate most behavior. There are many people, when asked "Why did you make that decision?", will respond with some variant of "I don't know, I just felt like it."
It implies to me that most people don't really know what they feel, or why they feel that way. The corrolary to that, which I find fascinating (and a bit sad), is that it means most people really have no understanding of why they do what they do. This as true of actions as trivial as picking a brand of gum or selecting a parking spot, to choices as monumental as deciding to get married or have children.
I used to think this, until I read more about advertising and how it's designed to trigger an emotional response. More and more, I think it's really emotions that motivate most behavior. There are many people, when asked "Why did you make that decision?", will respond with some variant of "I don't know, I just felt like it."
It implies to me that most people don't really know what they feel, or why they feel that way. The corrolary to that, which I find fascinating (and a bit sad), is that it means most people really have no understanding of why they do what they do. This as true of actions as trivial as picking a brand of gum or selecting a parking spot, to choices as monumental as deciding to get married or have children.
Emotions can be good reasons!
Addiction. From the endless edit-compile-test cycles.
Dopamine circuits go completely berserk.
Dopamine circuits go completely berserk.
I recently changed over to management after being a principal engineer. I miss my regular dopamine hits. Now feedback can take weeks, months, or longer. It is a change for sure.
Really enjoyed this piece. Many of my developper colleagues like to boast that emotions have no place in our field. However this is going against human nature and is in my opinion futile.
And this is why programming is a horrible job. Once you lose the satisfaction, which happens pretty quickly all that is left is irritation and confusion and anger. Its absolutely miserable work. But I'm completely stuck in it.
I still feel the satisfaction. Not as often as at the beginning, but I still feel it sometimes, even after 35 years.
I need a wankerless environment to feel the satisfaction… otherwise I never do.
I don't know if confusion should be considered an emotion. Depending on the situation you can be confused and feel fear, or you can be confused and be excited.
Same applies to "silliness" and "hesitation".
Same applies to "silliness" and "hesitation".
I don't know if shell scripts should be considered a programming language.
What a snarky reply. Don't know if you get off on things like that, but I hope it increased your mood.
You can be happy and feel fear, or be happy and excited.
Well, happy and excited seems to be almost the same thing. While happy and fear - I don't think I ever felt that way in my life.
I wanted to see more about this distinction and found a relevant Wiki page about emotions [1].
"Confusion" appears to be added as a separate emotion in some classifications, while missing from others. When it's added it is added as a neutral emotion (having 0 emotional "tone").
Personally, don't think I experience confusion as an emotion. It's just a mental picture of my state and emotions arise according to how I interpret that picture. Same as "I am lost" or "I am missing a finger" are not emotions, thou they would cause emotions to arise.
[1]: https://en.wikipedia.org/wiki/Emotion_classification
I wanted to see more about this distinction and found a relevant Wiki page about emotions [1].
"Confusion" appears to be added as a separate emotion in some classifications, while missing from others. When it's added it is added as a neutral emotion (having 0 emotional "tone").
Personally, don't think I experience confusion as an emotion. It's just a mental picture of my state and emotions arise according to how I interpret that picture. Same as "I am lost" or "I am missing a finger" are not emotions, thou they would cause emotions to arise.
[1]: https://en.wikipedia.org/wiki/Emotion_classification
I agree with you that my categorization is questionable, and subjective. The comments here make it clear to me that different people process things differently, and even give different names to similar feelings.
Couple more for me
Surprised, when something non trivial worked the first time around. How could this be? This can't be right?
Floored, when I see the quality and quantity that some developers are able to contribute or create.
Surprised, when something non trivial worked the first time around. How could this be? This can't be right?
Floored, when I see the quality and quantity that some developers are able to contribute or create.
What is it about programmers that makes them (in general) not expressive, effusive, gregarious, ...
I have a deadpan face most of the time, people complain about not being able to read me. When I was younger, I rationalized that I don't want emotions to cloud the logic of a conversation. But I ultimately realized that I was deadpan all the time, whether in work/reasoning discussions or personal interractions. Regardless, my lack of reaction frequently confuses others and gets me into trouble.
I have a deadpan face most of the time, people complain about not being able to read me. When I was younger, I rationalized that I don't want emotions to cloud the logic of a conversation. But I ultimately realized that I was deadpan all the time, whether in work/reasoning discussions or personal interractions. Regardless, my lack of reaction frequently confuses others and gets me into trouble.
Yes, I can relate. I realize now that fun conversation is highly illogical, emotion based. I view my desire for control and logic actually gets in the way of emotions, which makes conversations less enjoyable.
Me too. I feel that the key insight is that rational mind is almost always too slow to keep flow of the conversation interesting. It inevitably destroys timing and rhythm.
You can observe this clearly in stand-up performances - rationality of the bit is only minor part, the delivery is almost everything.
I don’t fully understand, but I have the same issue.
I’ll have a full day of coding work and I’ll have the full range of emotions - joy when t worked, fury when the underlying UI framework is lower quality than my expectations for my work output and I spend days or hours making awful workarounds. Cough cough UWP. Cough cough Xamarin.Forms.
And then I try to go out for drinks after and it’s like I’m an actual robot. Text generation seems to work OK, but emotional processing just isn’t there. I can’t access the part of my brain that does all of the socially-expected facial expressions, speech tone, and cadence.
When I was much younger, I was criticized for a constant monotone delivery and I’ve since worked on fixing that with great success. But if I spend more than an hour or two coding - or if I get anywhere near a state of productivity- I end up with a less convincing reproduction of human emotion than Alexa.
It makes dating after work, or getting coffee with someone mid-day, a serious challenge. I’m not opposed to hearing solutions in the reply.
I’ll have a full day of coding work and I’ll have the full range of emotions - joy when t worked, fury when the underlying UI framework is lower quality than my expectations for my work output and I spend days or hours making awful workarounds. Cough cough UWP. Cough cough Xamarin.Forms.
And then I try to go out for drinks after and it’s like I’m an actual robot. Text generation seems to work OK, but emotional processing just isn’t there. I can’t access the part of my brain that does all of the socially-expected facial expressions, speech tone, and cadence.
When I was much younger, I was criticized for a constant monotone delivery and I’ve since worked on fixing that with great success. But if I spend more than an hour or two coding - or if I get anywhere near a state of productivity- I end up with a less convincing reproduction of human emotion than Alexa.
It makes dating after work, or getting coffee with someone mid-day, a serious challenge. I’m not opposed to hearing solutions in the reply.
None of this is well-researched or strongly evidenced, but a few things that have helped me with similar problems:
* Reading Nonviolent Communication, by Marshall Rosenberg. I have very low native empathy, and the techniques in that book have helped me learn to understand and interact better with more emotionally-responsive people. It also helped me learn to recognize my own emotions better.
* Therapy. Finding a good therapist is hard and they are definitely not all good, but it can help a lot when you do.
* 2.5 grams of daily fish oil seems to have actually increased my emotional response significantly. Totally anecdotal, and not why I started taking it, but after about a month of that dosage I started to notice a difference. There's some evidence I may be on the autism spectrum (high-functioning, once known as Asperger's), so this could relate to that.
* Consciously taking breaks throughout the workday to pause, stretch, and think about what emotions I'm feeling and why.
I hope some of that helps you.
* Reading Nonviolent Communication, by Marshall Rosenberg. I have very low native empathy, and the techniques in that book have helped me learn to understand and interact better with more emotionally-responsive people. It also helped me learn to recognize my own emotions better.
* Therapy. Finding a good therapist is hard and they are definitely not all good, but it can help a lot when you do.
* 2.5 grams of daily fish oil seems to have actually increased my emotional response significantly. Totally anecdotal, and not why I started taking it, but after about a month of that dosage I started to notice a difference. There's some evidence I may be on the autism spectrum (high-functioning, once known as Asperger's), so this could relate to that.
* Consciously taking breaks throughout the workday to pause, stretch, and think about what emotions I'm feeling and why.
I hope some of that helps you.
> Consciously taking breaks throughout the workday to pause, stretch, and think about what emotions I'm feeling and why.
+1 on this. If I'm not careful, my default mode is to get in the zone for hours, and then eventually realise my body is tired and hungry and cold (or whatever) and I have to do some big intervention like collapsing into a vegetative state for a while. Expanding your awareness, learning to maintain a general sense of how your body is doing while you're absorbed in the actual fun stuff, is a chore; but it's one which pays off when you can notice you're hungry after an hour and fix it quickly (rather than after four hours, at which point the problem is much worse and you might lose an extra hour just recovering from having no energy). And the easiest way to get to a constant gentle awareness of your physical state is to practice by consciously interrupting yourself every so often to do the checks, until the habit gradually fades into your background processing.
+1 on this. If I'm not careful, my default mode is to get in the zone for hours, and then eventually realise my body is tired and hungry and cold (or whatever) and I have to do some big intervention like collapsing into a vegetative state for a while. Expanding your awareness, learning to maintain a general sense of how your body is doing while you're absorbed in the actual fun stuff, is a chore; but it's one which pays off when you can notice you're hungry after an hour and fix it quickly (rather than after four hours, at which point the problem is much worse and you might lose an extra hour just recovering from having no energy). And the easiest way to get to a constant gentle awareness of your physical state is to practice by consciously interrupting yourself every so often to do the checks, until the habit gradually fades into your background processing.
I think programming appeals to people who don't natively do a lot of emotional display or read emotions well.
Emotional responses and awareness have very little relevance for the acts of writing and testing instructions for computers. Machines don't know or care how you feel.
Thus, people to whom those things seem less relevant often drift towards software development, IMO.
Emotional responses and awareness have very little relevance for the acts of writing and testing instructions for computers. Machines don't know or care how you feel.
Thus, people to whom those things seem less relevant often drift towards software development, IMO.
Personally I was overly expressive as a kid and it irked me that people could so plainly read me, so over time I learned to tone down my outward emotions. Might have gone a little too far on that. Whoops.
Take no notice of the people who complain.
Why do they need to read you? Unless it’s a close friend, family or relationship in which case they need to understand how you communicate.
I had a manager who said I need to get better at presenting etc. and for the first time I though meh… whatever. I’ll only do that once I find intrinsic motivation I won’t do that because it’s expected for a job (I’m not in sales and I rarely present other than internal demos)
Why do they need to read you? Unless it’s a close friend, family or relationship in which case they need to understand how you communicate.
I had a manager who said I need to get better at presenting etc. and for the first time I though meh… whatever. I’ll only do that once I find intrinsic motivation I won’t do that because it’s expected for a job (I’m not in sales and I rarely present other than internal demos)
I think a highly conscientious developer might feel all these emotions. However, I am sure we have all worked with the developer that is absolutely shameless.
Shame is not really constructive though, if you know what you are capable off, accept that you will always have to learn more and do your best each day. There is no need for shame. Even if your PR comes back with 20 issue even though you didn't see any.
I don't think that's what shameless means in this context.
Shameless means being as unconscientious about all work as possible in a consciously cynical way.
Shameless means being as unconscientious about all work as possible in a consciously cynical way.
Missing: frustration.
The main one, frustration sometimes kill the whole day. At the end the work is done in 30 minutes.
Also missing: blind fury
I occasionally find myself feeling like this after frustration builds to a crescendo, and I've spent hours trying to get something to work that should have taken no time at all!
I occasionally find myself feeling like this after frustration builds to a crescendo, and I've spent hours trying to get something to work that should have taken no time at all!
For the past 6 months or so I've asked myself if this is all so hard... because from looking at how long it takes me to do stuff and how often others fail at it, or the questions they ask me, it MUST BE HARD, because no one around me is all that good at it, and it takes us ALL way too long to do stuff that looks like it should be simple and easy.
I think that acknowledging that something is hard gives you some power over it. Like if we acknowledged that writing documentation was hard, maybe we would apply more resources to writing documentation.
I think that acknowledging that something is hard gives you some power over it. Like if we acknowledged that writing documentation was hard, maybe we would apply more resources to writing documentation.
That is when I truly hate technology and how bad all UX is.
That was also a glaring omission to my eyes. It's the emotion I associate the most with programming, although I guess it's a mix of some of the ones mentioned in the article.
FDD - Fear Driven Development. When you are afraid of 1. Looking incompetent, or 2. Missing the constant deadlines.
Irritation: when the documentation is incorrect or missing and I have to figure out how the API works by guess work or hit and trial.
Anger: when there is unnecessary red tape to get access to an API while my competitors have the access.
Tired: when applying Nth money patch to use a broken API
PS: I work with external APIs a lot
Anger: when there is unnecessary red tape to get access to an API while my competitors have the access.
Tired: when applying Nth money patch to use a broken API
PS: I work with external APIs a lot
I feel a lot of these, including the good emotions, are driven by ego. My solution to some of this has been a mix of confidence and humility. Try to be confident in your choices, but be quick to admit you are wrong and quick to change direction when needed. It is not confidence to hold onto a bad solution.
One of my major problems is being too conservative. A few times I have been skeptical of a new technology or solution to a fault. When we started to use that technology it turned out it worked! My answer to this has been to try and be more open to suggestions. Try and talk things through and be patient and understanding.
One of my major problems is being too conservative. A few times I have been skeptical of a new technology or solution to a fault. When we started to use that technology it turned out it worked! My answer to this has been to try and be more open to suggestions. Try and talk things through and be patient and understanding.
Looking at the comments, Having emotions is normal, but at work we should try stay professional. In the article there is a reference to his own bugs and during code review what he called a nitpick. I found that a bit immature, should we wait until its a bug in production?
I think the industrie would benefit if we all abide by egoless programming.
https://blog.codinghorror.com/the-ten-commandments-of-egoles...
I think the industrie would benefit if we all abide by egoless programming.
https://blog.codinghorror.com/the-ten-commandments-of-egoles...
Are you saying everything brought up during a code review is relevant, i.e. that nitpicks just don't exist at all? Because I feel that's a rather extremist point of view.
Note that a bug isn't a nitpick. A nitpick would be something like "that variable name is a bit long" - it may be, but is it really relevant in a business sense? Should either reviewer or programmer be spending time on something like this? Should it hold up an important commit?
Protesting that isn't 'immature', it indicates he understands there is a trade-off between differing priorities. It's something that is surprisingly uncommon among programmers, unfortunately.
Note that a bug isn't a nitpick. A nitpick would be something like "that variable name is a bit long" - it may be, but is it really relevant in a business sense? Should either reviewer or programmer be spending time on something like this? Should it hold up an important commit?
Protesting that isn't 'immature', it indicates he understands there is a trade-off between differing priorities. It's something that is surprisingly uncommon among programmers, unfortunately.
Awe. It happens very, very rarely, but when it does, it's unforgettable. For me, it happened when I was learning Haskell.
(As for the Lisp enlightenment, I havent yet learned Lisp deep enough to feel it, and maybe I'll never will; but I certainly appreciate Lisp's "idea efficiency". It's amazing how much Lisps can do with basically a single piece of syntax).
(As for the Lisp enlightenment, I havent yet learned Lisp deep enough to feel it, and maybe I'll never will; but I certainly appreciate Lisp's "idea efficiency". It's amazing how much Lisps can do with basically a single piece of syntax).
I just completed a work package that was bugging me for a while causing a lot of frustration.
There is a lot of happiness in getting stuff done.
Imposter Syndrome: Not an emotion per se.
It’s a belief. That everyone else is smarter than you.
Opposite of dunning-kruger, where you think you’re smarter than everyone else.
Opposite of dunning-kruger, where you think you’re smarter than everyone else.
Not an opposite. Dunning-Kruger works both ways:
> The Dunning–Kruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their own ability, and that people with high ability at a task underestimate their own ability.
(From Wikipedia: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect, emphasis mine)
> The Dunning–Kruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their own ability, and that people with high ability at a task underestimate their own ability.
(From Wikipedia: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect, emphasis mine)
There are two things in life that bring me joy like no other, and they're basically the same: completing a physical fabrication project and successfully implementing something in code.
The elation I get when it comes out exactly the way I imagined is unrivaled.
The elation I get when it comes out exactly the way I imagined is unrivaled.
I don't see rage listed. It should be. Sometimes it's almost Homeric.
> From the outside, programmers seem to resemble the machines they program – cold, emotionless, unmoved.
Nothing grabs you in an article like the person saying everybody in your field has no external personality.
Nothing grabs you in an article like the person saying everybody in your field has no external personality.
>missing bitterness
ah, so he’s a junior dev
ah, so he’s a junior dev
Programming work is emotional, and the technical interviews that may get you there even more so.
I'm surprised to see "frustration" and "rage" did not make the cut.
> Anxiety, inadequacy, and shame are just not helpful. It is good to reduce them if we can.
Uhm, not really. All emotions have evolved because they are useful. The ones listed here could keep you from doing something stupid, dangerous, or potentially deadly. They are also likely to make you notice something wrong earlier than others.
Are those emotions not helpful in some cases? Absolutely. Sometimes they are not justified. But that's true of any emotion. Even positive emotions can make you reckless and take too much unwarranted risk.
One might argue that for a programmer those statements are more accurate, but I'm not so sure. Blow some deadlines because of too little anxiety and too many positive emotions and you'll take a hit for sure.
Uhm, not really. All emotions have evolved because they are useful. The ones listed here could keep you from doing something stupid, dangerous, or potentially deadly. They are also likely to make you notice something wrong earlier than others.
Are those emotions not helpful in some cases? Absolutely. Sometimes they are not justified. But that's true of any emotion. Even positive emotions can make you reckless and take too much unwarranted risk.
One might argue that for a programmer those statements are more accurate, but I'm not so sure. Blow some deadlines because of too little anxiety and too many positive emotions and you'll take a hit for sure.
On a societal and evolutionary level they're necessary feelings, on an individual level they're just burdensome. You can reason your way to the same results.
Yeah this is a lesson I learned during the NBA playoffs sometime in the mid 00's - I was supporting the Cavs, and the whole series was hanging on a 3 foul shots by Lebron James. I was watching in a bar, and was super agitated along with everyone in the bar, and everyone in the arena as we could see on TV. But I noticed that James him self was completely stone-faced and calm. And I realized in that moment, that all this agitation wasn't actually useful, and would not affect the outcome. And even if I were the one in position to affect the outcome, that kind of agitation would actually make things worse.
That said, I've had colleagues who could probably do with a bit more shame. Confidence and self-assuredness is great for self-promotion, but if you can continuously produce shitty output with a smile on your face I don't want to work with you.
That said, I've had colleagues who could probably do with a bit more shame. Confidence and self-assuredness is great for self-promotion, but if you can continuously produce shitty output with a smile on your face I don't want to work with you.
Can you? A lot of psychological literature shows that we are far from being masters of ourselves.
Depresses people cannot reason themselves to any result at all. Addicted people cannot reason themselves out of addiction. You can fix many things with therapy, but that's far from just "reasoning" and takes a lot of time and work.
Emotions come from a much older part of your brain than the one for your reasoning skills, and thus have a far stronger pull on your actions. That's not to say we are completely at the mercy of our emotions. But controlling them is a matter of practice and reinforcement, not pure logic.
Depresses people cannot reason themselves to any result at all. Addicted people cannot reason themselves out of addiction. You can fix many things with therapy, but that's far from just "reasoning" and takes a lot of time and work.
Emotions come from a much older part of your brain than the one for your reasoning skills, and thus have a far stronger pull on your actions. That's not to say we are completely at the mercy of our emotions. But controlling them is a matter of practice and reinforcement, not pure logic.
I edited this sentence to make it clear that I mean only it in the programming context.
I believe that we could use positive or neutral emotions instead of negative ones, at least in most cases. Curiousness instead of inadequacy as the drive for learning; humbleness instead of shame; desire to make something great on time instead of anxiety.
Of course, the more difficult question is how to do that.
Your personality largely determines your emotions and you can't generate them at will.
"Twin studies and other research have shown that about half of the variation between individuals results from their genetic inheritance and half from their environment. Researchers have found conscientiousness, extraversion, openness to experience, and neuroticism to be relatively stable from middle age through old age" [1]
What if you don't feel any curiousness? Or you feel it for something that is counterproductive at the moment?
What if your desire of making something great clashes with your boss order to make some more boring CRUD software because that's what the client wants?
In these cases, anxiety and inadequacy could be the very emotions that recenter you on what you should to do.
[1] https://en.wikipedia.org/wiki/Big_Five_personality_traits
"Twin studies and other research have shown that about half of the variation between individuals results from their genetic inheritance and half from their environment. Researchers have found conscientiousness, extraversion, openness to experience, and neuroticism to be relatively stable from middle age through old age" [1]
What if you don't feel any curiousness? Or you feel it for something that is counterproductive at the moment?
What if your desire of making something great clashes with your boss order to make some more boring CRUD software because that's what the client wants?
In these cases, anxiety and inadequacy could be the very emotions that recenter you on what you should to do.
[1] https://en.wikipedia.org/wiki/Big_Five_personality_traits
I think this is a good point why it would be good if we, as an industry, accommodate these emotions rather than force them away or pretend they don't occur.
At the same time, it doesn't have to mean that one cannot improve things independently. We can't change personality, but we can change beliefs, which also affects what we feel.
Consider this: I used to feel really bad about having my pull requests getting reviewed, because other programmers would leave insensitive comments full of criticism. At one point, I just realized that they are not motivated by shaming me, but that they just care about the codebase's quality (and are not very good at conveying emotions in written comments). This change in perception literally changed how I feel about it.
At the same time, it doesn't have to mean that one cannot improve things independently. We can't change personality, but we can change beliefs, which also affects what we feel.
Consider this: I used to feel really bad about having my pull requests getting reviewed, because other programmers would leave insensitive comments full of criticism. At one point, I just realized that they are not motivated by shaming me, but that they just care about the codebase's quality (and are not very good at conveying emotions in written comments). This change in perception literally changed how I feel about it.
I think you cannot control how you are made, but you can control what you do with it. It's up to you to figure out how to put yourself in situations where your personality will be an asset rather than an obstacle.
As far as emotions like inadequacy and anxiety, I think mindfulness is a useful tool in terms of differentiating between having those emotions and dwelling in them.
For instance, recognizing one's sense of inadequacy, and from a sober state of mind being able to decide whether that is a signal to reenforce one's skills in some area, or to remind oneself why that reaction is inappropriate in this case is a healthy response. Just walking around feeling bad all day due to imposter syndrome is not a healthy response.
As far as emotions like inadequacy and anxiety, I think mindfulness is a useful tool in terms of differentiating between having those emotions and dwelling in them.
For instance, recognizing one's sense of inadequacy, and from a sober state of mind being able to decide whether that is a signal to reenforce one's skills in some area, or to remind oneself why that reaction is inappropriate in this case is a healthy response. Just walking around feeling bad all day due to imposter syndrome is not a healthy response.
I watched a Robert Sapolsky lecture which made a lot of sense on this topic. His point was that our psychological reactions to things evolved because they were useful to our ancestors, but not necessarily because they are useful to us.
The classic example would be the stress response. It's perfectly useful to go into a flight-or-fight mode if you need your body to be ready to escape an imminent threat like a lion you spot in the long grass 100m away. But when you have the same physiological reaction for weeks at a time due to a looming work deadline, this is not something our minds and bodies evolved to tolerate.
The classic example would be the stress response. It's perfectly useful to go into a flight-or-fight mode if you need your body to be ready to escape an imminent threat like a lion you spot in the long grass 100m away. But when you have the same physiological reaction for weeks at a time due to a looming work deadline, this is not something our minds and bodies evolved to tolerate.
"All emotions are useful" is wrong, they just were useful at some point. Anxiety in particular has very little utility today and big downsides for health. It's a fight/flight response thing that temporarily switches off important systems like digestion while heightening our senses and making us feel worried and alert. In the 21st century it creates far more problems than it solves.
I'm honestly not sure how you can make it past say 10 years in the industry without having the mental skills of a Buddhist Monk.
Coding isn't too bad for the most part, but on top of that it's like you have to manage the product owners / managers, coach your team mates, and put up with company politic dribble.
While you're doing all that people are constantly changing their minds, making you task switch to jump on fires the previous devs set up, and of course you're having to learn how to get around some libraries undocumented "peculiarities" or learn WTF it is that some legacy code is doing.
OH and you have to be full stack with knowledge in a,b,c,d,e,f,g.
"Coding" is draining because for the most part it's not coding...
After going through all the BS you just end up questioning why you're at Company Z in the first place. You then come to the conclusion that helping sell more ads isn't how you want to look back on your life or that you're helping prop up a dying product/industry, and you move on to the next shit show.
I'm honestly questioning whether I want to remain in the industry or whether I should take up something like Acting. Interested to hear if anyone's made a similar career move.
Coding isn't too bad for the most part, but on top of that it's like you have to manage the product owners / managers, coach your team mates, and put up with company politic dribble.
While you're doing all that people are constantly changing their minds, making you task switch to jump on fires the previous devs set up, and of course you're having to learn how to get around some libraries undocumented "peculiarities" or learn WTF it is that some legacy code is doing.
OH and you have to be full stack with knowledge in a,b,c,d,e,f,g.
"Coding" is draining because for the most part it's not coding...
After going through all the BS you just end up questioning why you're at Company Z in the first place. You then come to the conclusion that helping sell more ads isn't how you want to look back on your life or that you're helping prop up a dying product/industry, and you move on to the next shit show.
I'm honestly questioning whether I want to remain in the industry or whether I should take up something like Acting. Interested to hear if anyone's made a similar career move.
The grass always seems greener. Dev jobs are objectively very comfortable. Problems exist in all industries/occupations, who's to say they aren't equally frustrating.
I've done a variety of different jobs in my time, and standard dev work (in a corporate environment with managers and pretend-agile and JIRA etc) is by miles the most stressful, confusing, complicated, bullshit-ridden job I've ever had in terms of day-to-day experience. It's also the most well paid – that's what evens it out. It's not that all jobs/industries are equally frustrating (which is obviously untrue, to anyone who has worked in more than one industry).
The 'objective comforts' you get at some places, if you mean stuff like pingpong and free beers and lunchtime yoga, are sticking plasters that don't actually get much take-up. The only real 'objective comfort' is the high pay, which makes the rest of your life more comfortable, but doesn't make the day-to-day experience of the job any less frustrating, hence developers 'burning out' so often.
The 'objective comforts' you get at some places, if you mean stuff like pingpong and free beers and lunchtime yoga, are sticking plasters that don't actually get much take-up. The only real 'objective comfort' is the high pay, which makes the rest of your life more comfortable, but doesn't make the day-to-day experience of the job any less frustrating, hence developers 'burning out' so often.
This. I have also felt very burned out and frustrated with our industry, but with a little therapy I've found that most of my unhappiness comes from within, and once resolving those issues I've realized that being a developer is one of the most comfortable, privileged position one can be in. I can literally change a job in a matter of weeks, I have ridiculous salary, and most of my job I actually even love! Not so much the case with a ton of other jobs.
> Dev jobs are objectively very comfortable.
Who’s to say dev jobs are objectively very comfortable?
> Problems exist in all industries/occupations, who's to say they aren't equally frustrating.
The claim that the problems that exist in all industries are equally frustrating, is obviously absurd.
Who’s to say dev jobs are objectively very comfortable?
> Problems exist in all industries/occupations, who's to say they aren't equally frustrating.
The claim that the problems that exist in all industries are equally frustrating, is obviously absurd.
See a therapist. Get in touch with your values. They won't tell you what to do but will help you understand what you want.
Woodworking. That's the dream.
> After going through all the BS you just end up questioning why you're at Company Z in the first place
I honestly think this is a natural path, and we should be question a lot more why we work for company Z.
The answer can seem obvious, but even if it’s something like “best money I can get”, having it explicit helps a lot with dealing with the compromises we’re making. And sometimes it’s only after putting it in words that we realize the answer doesn’t make sense.
> make it past 10 years
On one hand I think programmer is not an exception, film industry for instance must be worse 1000 times. On the other hand, that’s probably one of the reason we see people in their forties do startups. Moving on to something else can be a coping mechanism.
I honestly think this is a natural path, and we should be question a lot more why we work for company Z.
The answer can seem obvious, but even if it’s something like “best money I can get”, having it explicit helps a lot with dealing with the compromises we’re making. And sometimes it’s only after putting it in words that we realize the answer doesn’t make sense.
> make it past 10 years
On one hand I think programmer is not an exception, film industry for instance must be worse 1000 times. On the other hand, that’s probably one of the reason we see people in their forties do startups. Moving on to something else can be a coping mechanism.
"You then come to the conclusion that helping sell more ads isn't how you want to look back on your life ..."
Software has been commoditised. The number of people making a career out of "selling software" continues to decline.
The Fortune 500 uses free software.1 Software quality is not correlated to price.
People work for (computer) "tech" companies and are ostensibly paid to write software, but fewer and fewer are trying to sell it. The companies are only sustained through sales of advertising services. None can survive by selling the work of programmers.
1. Meanwhile, companies increasingly overpay for web hosting and use of third party data centers.
Software has been commoditised. The number of people making a career out of "selling software" continues to decline.
The Fortune 500 uses free software.1 Software quality is not correlated to price.
People work for (computer) "tech" companies and are ostensibly paid to write software, but fewer and fewer are trying to sell it. The companies are only sustained through sales of advertising services. None can survive by selling the work of programmers.
1. Meanwhile, companies increasingly overpay for web hosting and use of third party data centers.
I stopped feeling shame for my code after a couple years in business. Every line out there is someone’s little piece of shit. We are just little shit machines producing ever more shit. Sometimes we even use shit to patch up the gaps in existing shit. We are also known to get bold sometimes and start fresh shit piles usually because we have realized flashier shit gets you promoted.
All code is shit.
All code is shit.
This explains well why it's so satisfying to delete code.
The key is talking to people. Too many people on here complain about meetings, 1x1's, and that they hate interacting with people who don't understand what they're asking for, like management. The real reason is cause many people (especially new grads) think all their job centers around is code. It absolutely does not. Having fun actually interacting with people around the abhorrent minutia of everyday life is not only part of life, but shows you also are not a said "robot."
Too many interns I've worked with at my comment are just monotone unimaginative, unemotional, unfeeling drains. Any time they'd talk during a zoom call it was like "God I'm only asking you how your day was so you don't feel left out. When they had nothing to share I was so excited cause we got to skip over them because they were just so damn uninteresting to listen to.
But I feel like I'm one of the few that knows this, hence why I enjoy doing these things. One of my Comp Sci instructors was this way as well and he was very enthusiastic about everything. It's why everybody liked him. Unfortunately since Comp Sci is a legitimate hard science, especially being centered around math, it drives out a lot of the perky speakers who don't like to think. I do think it's good because it keeps out the people who think this is all just an easy paycheck, but in reality, I think Comp Sci majors should almost be required to be far more social with others.
Too many interns I've worked with at my comment are just monotone unimaginative, unemotional, unfeeling drains. Any time they'd talk during a zoom call it was like "God I'm only asking you how your day was so you don't feel left out. When they had nothing to share I was so excited cause we got to skip over them because they were just so damn uninteresting to listen to.
But I feel like I'm one of the few that knows this, hence why I enjoy doing these things. One of my Comp Sci instructors was this way as well and he was very enthusiastic about everything. It's why everybody liked him. Unfortunately since Comp Sci is a legitimate hard science, especially being centered around math, it drives out a lot of the perky speakers who don't like to think. I do think it's good because it keeps out the people who think this is all just an easy paycheck, but in reality, I think Comp Sci majors should almost be required to be far more social with others.
From my perspective if I have nothing to enjoy sharing then I would prefer to be left alone.
What you are describing seems forced, like when there are several good-ol pals on a call with a new grad, waiting for him to entertain them with a story.
Talking about oneself and sharing comes with trust which comes with time (working together) and being open with co-workers, this is my experience.
What you are describing seems forced, like when there are several good-ol pals on a call with a new grad, waiting for him to entertain them with a story.
Talking about oneself and sharing comes with trust which comes with time (working together) and being open with co-workers, this is my experience.
I prefer the company of fellow robots. Being expected to remember the minutia of the lives of others is annoying and unproductive for both of us.
And this is the exact mentality that is antithetical to team based work that is ever so growing nowadays! This is why people who know how to talk and engage are getting jobs and the anti socials are still having trouble getting meaningful employment.
Staying in a long debugging session without ragequitting and getting to the fix.
Pushing through when I feel really dumb for not knowing how a react hook works or how to test a particular feature.
Not getting bored (or recognising it and pushing through) when fixing a bug that is "trivial" but complicated.
Not getting angry when the codebase is not architected well or is hard to understand.
In every one of these situations, better emotional management has made me more productive, calmer, and I had a better outlook of the situation in the end, so my suggestions to external stakeholders about what to do next were more accurate.
And I'm still learning! I get bored and take 3x too long all the time.
This is maybe an exaggeration, but after you learn about for loops and functions, the rest of the job is emotional management.
Ok, maybe EQ becomes important a little bit after for loops, but way earlier than you think. Maybe after 1 year of experience.