Programmers’ emotions
blog.sidebits.tech
blog.sidebits.tech
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.
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.
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.
This should be split into:
Pride. When I made something neat
Suspicious. When something worked on the first attempt
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 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.
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.
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.
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.
It happens all the time... unfortunately.
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.
> 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.
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.
It doesn't help to change company, when the same fads sooner or later starts getting pushed down there as well.
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
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.)
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.
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
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.
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.
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 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.
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 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 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'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.
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.
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.
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 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.
How something makes people feel - or how they think doing something will make them feel - dictates the vast majority of human behavior.
The first part of his book "The Righteous Mind" discusses this aspect.
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.
Dopamine circuits go completely berserk.
But, it seems that winning in life is figuring out how to get healthy addictions (to work, exercising, good diet, helping other people).
Same applies to "silliness" and "hesitation".
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.
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.
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’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.
* 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.
+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.
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.
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)
Shameless means being as unconscientious about all work as possible in a consciously cynical way.
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 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.
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
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.
I think the industrie would benefit if we all abide by egoless programming.
https://blog.codinghorror.com/the-ten-commandments-of-egoles...
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.
(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).
Opposite of dunning-kruger, where you think you’re smarter than everyone else.
> 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 elation I get when it comes out exactly the way I imagined is unrivaled.
Nothing grabs you in an article like the person saying everybody in your field has no external personality.
ah, so he’s a junior dev
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.
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.
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.
"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
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.
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.
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.
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.
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.
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.
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.
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.
All code is shit.
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.
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.