This is something I’ve been wondering about for a long time. Programming is an activity that makes you face your own fallibility all the time. You write some code, compile it or run it, and then 80% of the time, it doesn’t work exactly the way you imagined. There’s an error message, or it just behaves incorrectly. Then you need to iterate on it and fix the issues until you get the desired result, and even then it’s subtly wrong, and causes an outage at 3am on Sunday.
I thought this experience would teach programmers to be the humblest people in the world.
I can’t believe how wrong I was. Programmers can be the most arrogant dickheads you will ever meet. Why is that?
In industry, most people do more reading than writing, so you see a lot of other people's mistakes and have to fix them rather than your own. You don't make enough code to feel humbled.
Out of industry, there's often a vacuum. You code one way and make a thing and you're proud of it. You never hear criticism, and you're defensive of your abilities. This could be programmers who are new or just out of college or do it as a side to their main job. You don't share code enough with people to learn better ways and be humbled. Good enough is enough to be proud of.
There's an in between state that can open up the door to humility. Maybe a person who works at a company and thus deals with customers, non-programmers, and a team but still works on open source and in their free time build lots of side-projects and open sources them. You're making enough code and putting it out there enough to really receive good criticism. Those people would be more likely to be humble I suppose
Programming often makes you feel powerful and in control. Humans love that feeling and it’s intoxicating. But I think that feeling of power and control gets easily conflated with being right all the time. If we’re wrong then it’s like we have to admit we’re not in control anymore.
I can’t believe how wrong I was. Programmers can be the most arrogant dickheads you will ever meet. Why is that?
That is a behaviour I commonly see online. Working in scientific programming, my experience has been the opposite. The programmers I interact with aren't afraid to ask for help and will usually recognise their mistakes. Not once have I been mocked for my crappy code, not for a lack of opportunities.
As with any field, the less a person knows the more they boast to know.
I think one of the big problems in software dev is that the 'code doesn't care about your emotions' is just an easy out to not put in the effort to work with other people. We seem to forget that although the nuts and bolts of our work is engineering, the only reason we write any code in the first place is to support human endeavors. Yes one line of code can be provably right or wrong, but absolutely everything else piled on top of that is understanding and emphasizing with other people. I wish more of us would take a step back from the line of code in front of us once in a while and just, you know, look around us.
My thought is this: we often have to deal with people who are absolutely certain about a thing, that's... completely wrong. Disregarding the user's thoughts to fix the user's issue is quite common.
But that wouldn't explain all of it, because anyone in customer service deals with the same stuff, and they usually aren't that bad when they drop the customer service mask.
That may be part of it but I've also observed it among fellow programmers.
You give your opinion about something and your coworker has a smug, arrogant knee-jerk reaction based on some cargo-cult belief without actually thinking about the details of the problem. Then you need to walk them through why what you said is not what they meant step-by-step, and while it may be wrong it is still a valid opinion. If you succeed, they completely change and become cooperative, and you can have an actually useful discussion. But you have to be super patient, like when taming an irritated feral cat that wants to scratch you. If you're good, the cat becomes cuddly and cute.
This works but I'm extremely tired of having to perform this dance with 60% of the new coders I meet.
I mean, it's a scientific job, you have to prove your arguments... with that said they should help you to do so, if you feel them as arrogant, they are bad at their job....and since programming is a complex job, there are a lot of not so good people
It's the duality of coding. You can feel like the dumbest person on earth and impostor syndrome is a real thing. But compared to other people you can still feel like a technomancer/wizard. What too many coders forget is that many, many jobs can get really complicated once you look past the surface. That's part of where the arrogance comes from. I also often see people who feel companies should just indulge their hobby and they forget that the company pays them to write code for the good of the company and not their own good.
I think that the reason is precisely the difficulty. Someone is asking for help with something that (for others) is not that difficult. Some people think "ha, poor fool, I've solved this, they're dumb and shouldn't be programming", while others go ahead and actually help the person in good faith without being a dick.
TLDR: Some think programming is a competition and they must be the winners, others realize it's a community effort where we step on each other's shoulders to go higher.
Part of it is also "engineer brain", where you see problems in terms of a rigid system of rules and forget that most problems in real life outside of engineering depend on rules and systems but also human beings. Unlike a structural member in a bridge or a piece of code, human beings are weird, proud, scared, emotional and smart enough to get out of following rules when they don't want to.
The dirty secret is that many problems inside of engineering are that way too. There's a million equally valid solutions to any given problem and the one that gets chosen is all human factors.
Like: Greenfield REST CRUD App. What language do you choose?
Sure, you can make a million technical arguments for any given language, but there's no real right choice. I'd choose Elixir because I like Phoenix/Ecto for that particular problem. I'm likely in the minority. The answer for most apps will be more borne of social politics than engineering.
"we should use X, it's obviously the best"
"but nobody here knows how to use X except you"
At which point the terminally engineer-brained will short circuit and throw a tantrum, because they are used to information just flowing from one data structure to another with the right tweaking, but human brains and education don't work that way.
People handle success differently. Some folks recognize how difficult it was and respect others facing challenges while some folks believe it must be easy because they did it and if you can't then you're less skilled.
Programmers can be some of the most condescending people ever and it really bothers me.
So many programmers I feel lack empathy especially when it comes to working with other developers. Pure "logical thinking" is primarily for computers. Writing readable code, good docs, good communication I think really separate an average dev from an exceptional one given the same skill set. All of those require a certain amount of empathy to do well because it's about understanding humans not just computers.
I found for myself that part of the journey in career advancement was looking at code, thinking "wow this really sucks! how could they be so stupid to do this!" and then realize that I wrote it a year or two prior.
Humbleness comes. I've since adopted it as a metric to determine if someone is really a senior or lead or level 60 paladin or whatever.
Ask anyone of the popular reputation of philosophers and it's basically the same as programmers. Socrates would definitely piss a few people off in code review meetings. Programming as a pursuit is very prone to sophistry because it's unclear even how to start defining the problem space, and there are always categories of problem where, when encountered, everyone either solves it with the exact same falsehood, or uses the one dependency that actually solves the problem. And then in the end, the software ends up not being used, so the wrong problem was solved.
TL;DR;
Human emotions don't belong in software development. Code doesn't care about your feelings so neither do senior devs. If you want someone to listen about your feelings, talk to your manager, not other devs while proposing a solution based on feelings. If you can't handle critical criticism of your code/designs/etc, you simply don't belong. If you are pumping shit out that takes down prod at 3am on Sunday, it is exactly that... shit.
It's a problem if you're a junior dev. Junior dev acting like they know everything straight out of college will often just get ignored and pushed sideways in the company (rather than promoting upward).
Junior devs should be properly mentored by a senior dev. Junior devs should never be placed in a position where their code could "cause an outage at 3am on Sunday". If that happens from a junior devs code, that is mentor's fault all the way.
Intermediate devs have more leeway since they have seen some shit and often decide and design based on real industry experience rather than a couple of college courses. However, intermediate devs are often deeply passionate about their projects, especially when they are doing something like "designing specifically so we won't have downtime at 3am on Sunday again because that sucked".
Most humans have an extreme difficult time separating emotion and logic. When intermediate dev above "knows this is right", and passionately debates the topic to no end, even when there is an obvious flaw in the logic, they are often debating based on their feelings and not based on matters of fact. This is a problem, and will come off as arrogance, but most likely is not actual arrogance and they are just caught up in their feelings about how hard they worked on the code/solution and they "feel" (not know) that the solution is correct/best/etc. This is easier than saying "damn, I'm wrong" for most people.
Senior+ devs often have seen shit across multiple softwares and companies allowing for more generic context surrounding issues. Senior+ devs also often depend on who they are conversing with, and often change tact to the situation. Ignore junior devs unless it's their actual job (mentorship). Be a contrarian to intermediate devs, to ensure they are doing real due diligence with their solutions. Heavily debate senior+ devs, as this is often where emergent architecture and design comes from, and all parties come out more knowledgeable. Caveat being: debates must be about the data and facts, with no ad hominem.
There is a major difference in the following statements:
This code is dumb
You are dumb
The former has nothing to do with you, even if you wrote the code. The code would still be dumb if someone else, even me, wrote it. Too many people take criticism of code as personal attacks -- human emotions do not belong in software development, facts and logic do.
I've seen variations of this opinion a lot in tech, but you don't have to sacrifice frank feedback to be a little more polite. Like sure "this code is dumb" is better than "you are dumb", but not as good as "this could be more efficient if we did y instead"
The latter is more helpful and less confrontational. The best devs I've worked with have been excited about code, and that came through in review. When they saw something that was wrong their feedback came across as excited to share rather than affronted by ignorance.
The thing devs don't like to admit is that a ton of stuff we argue about is more taste than science. There's no right answer to the classic performance vs readability thing, or where exactly the line is for effort vs payoff. Couching feedback around things like that a opinion often makes people way more receptive to it. "Hey I'd prefer if we did it this way" often goes a long way, IMO.
I actually welcome constructive criticism, and the brand of arrogance I'm so frustrated with is when people dismiss ideas or arguments without offering valid counterarguments. Or maybe when they take the worst possible interpretation of what someone says (see example above) and argue against that. Maybe my original post wasn't clear enough.
While it's true that separating emotions from the work itself and learning to accept justified criticism is important, even crucial, this fact doesn't give free license to the people giving the criticism to be rude. Your comment seems to imply that what I perceive as arrogance is often justified when "senior devs" are defending their solutions based on their experience. But arrogance != conviction or confidence. Confidence paired with humility allows for open-mindedness, and creates a better environment for everyone involved. It encourages sharing and discussing ideas.
You also state that human emotions don't belong in software development, then proceed to write a long rant that reeks of condescension, dismissiveness, annoyance, frustration and a feeling of superiority. Your comment is by no means neutral and analytical, it just displays emotions you feel are justified, while those felt by others are not. It's hard not to conclude that you are exactly the type of person my original post is about.
I guess I should also clarify (if it wasn't obvious), I am speaking about enterprise software development at large scale, and probably none of this properly applies to single OSS with 4 devs (or similar).
My intent was not "senior devs ok to be arrogant", but more so give my understanding of why a lot of senior devs come off as arrogant (if code is dumb, it is okay to say it is dumb, and is not a personal attack).
Simply saying "this code is dumb" and walking away is arrogant -- agreed.
Commenting in code review "this code is dumb" and nothing else is arrogant -- agreed.
Saying "this code is dumb" and debating the concepts at play in code, is not arrogance, but is often perceived as ad hominem ("well [dev] invested tons of time and energy on writing that code you just called dumb and is offended" -- why is [dev] working in a silo to the point that the code is trashed in code review on pull request?).
It's hard not to conclude that you are exactly the type of person my original post is about.
Correct, I was trying to give a why, directly from someone often perceived as an arrogant asshole senior dev.
You also state that human emotions don't belong in software development
Maybe it is better to say "feelings belong in process, not code". I consider everything I discussed process. Code taking down prod at 3am is not, but more of an indicator of bad process (in whatever form).
it just displays emotions you feel are justified, while those felt by others are not
This is interesting. My comment doesn't reflect my actual feelings on this topic, but rather my current understanding of this phenomenon I (clearly) struggle with, based on my experience in industry.
My actual feelings align more with "I am blunt and don't care about your feelings. This is a business not a personal project, get over it." and acknowledge that is arrogant, shitty, and not helpful (probably the other fancy words you used too) but saves ME hours upon hours weekly, which I then get to work on my code/tickets during, which is what my job actually is, and is the ACTUAL metric by which success is tracked.
If you are looking for design review, ask an architect (not through PR to main, which most often indicates "ready"), that is their job, not developers. If you ask for my review I will give it, and that is the "to be nice part". If I look and want to comment "this code is dumb -- rant", and I am the proper reviewer, I ask my manager to help me navigate the best way to express myself without coming off as an asshole.
I also acknowledge I do not write the checks, and have many times over written "dumb code" when that is what the business wants. Although I do make sure and be clear that it is dumb code (business people dgaf until the downtime happens tho).
I totally disagree with a lot of this and encourage you to rethink how you communicate with peers.
Human emotions don't belong in software development. Code doesn't care about your feelings so neither do senior devs.
There is a major difference in the following statements:
> This code is dumb
> You are dumb
The former has nothing to do with you, even if you wrote the code. The code would still be dumb if someone else, even me, wrote it. Too many people take criticism of code as personal attacks -- human emotions do not belong in software development, facts and logic do.
Calling something someone made dumb is mean. Believe me, I totally get where you're coming from and wish I could separate the emotional aspect from it but it's just not possible. Humans are emotional beings. We make decisions based on emotions and use logic to explain them. You can't just say something that someone made is dumb and expect it to not hurt their feelings because it "would still be dumb if someone else, even [you], wrote it."
It is possible to critique code respectfully without losing anything. I realize you're likely simplifying for the sake of discussion, but consider these examples, which would you rather be told?
This is an amateur mistake, don't do this. It is done properly here.
It is easy to make this mistake, I have made a similar mistake before, here is how to solve it correctly.
These both convey the same message (the code is wrong and how to solve it) but one is polite. The first one is in the gray area and I choose it for that reason. It may very well be true that it is a mistake that amateurs make but saying someone made and "amateur mistake" can be degrading.
People view rude words about their works as rude works about themselves and any appeal to logic will not change that. Just say what you would say but be more polite about it.
This is a social psychology question and the answer doesn't have as much to do with the particulars of what a programmer does as the social environment "programming" lives in.
The easiest concept regarding this phenomenon is self selection bias. Certain groups of people are drawn to, and others are excluded from certain professions. These groups are usually defined by demographics and personality traits. This results in a self-preserving system with its own gatekeeping, leading to a self-preserving subculture.
Obviously this isn't unique to programming. Every human group regardless of how that group is defined have in-group and out-group biases which perpetuates us and them identities in our minds. Everyone has these to varying degrees.
If we want to talk about why programming seems to select for the trait of arrogance, we have to speculate.
I think it could be related to the esoteric nature of professions like electronics engineering and programming. Things these professions work with do not have moving parts. Their internal workings can't be guessed by their physical appearance, nor from their immediate function. This might be creating a feeling of magic, as in any advanced enough technology blah blah... You know what I mean.
Perhaps programmers start to believe in the magic themselves, or to take it seriously when they are called "tech wizards" etc.
In return, non-programmers are probably happy to benefit from the "magic" without going into the nitty gritty of all the frustrating grunt work required to make things work, and they exclude themselves from the profession.
If we knew how hard things were going to be (or how long they would take!), we wouldn't attempt the task. Being a bit deluded about how smart we are is helpful for this.
Plus, there is a lot of autism in IT which sometimes makes people seem like arrogant dickheads even if they aren't.
I don't think it has anything to do with being a programmer or not, it's just about being a human and that's basically how human are in general.
So yeah, I think if a person is 'meant' to be mean and arrogant they will be mean and arrogant no matter the job.
Overall you can make many mistakes in almost any field before mastering it. The only things I can think of that are kind of specific to programming (not exclusive though) are that you don't have to be nice to people(which is kind of a requirement for sales, for example) and access to feeling of accomplishment that you have created something possibly great.
Plus being slightly more disagreeable is generally a good feat for a programmer (depends on the company and position) which also may contribute to the cause.
Yeah, overall I don't think I really felt any correlation between being a programmer and being an asshole.
Edit: On the second thought I think there's a possible correlation between being a programmer and how much of an asshole they could be...
you need to iterate on it and fix the issues until you get the desired result
That's pretty much it right there. To be successful in programming it's more or less required that you're a little headstrong. If you're not kinda stubborn you'll have the morale beaten out of you by a segfault or a missing semi-colon or some other tiny thing and self-select out.
As much as programming enforces the idea that "I've been wrong before and I should be humble" it equally enforces the idea that even experts can make mistakes and that the validity of every statement is independent of the source. Aka everything is up for debate.
On the flip side, holding down a job requires/rewards collaborative skills. I've seen companies make exceptions for "10x" programmers but the majority of us have to at least be able to work as team players.
So in reality I think we actually get a pretty good balance of people. But yeah it is kinda a shock the first time you realize that this practice which is based on empirical truths and logic can harbor some insane dickheads.
Also, I wonder how you're meeting other programmers. I have 15+ software dev friends that I've made in person and only 1 I've made on the internet. Could there be a hidden variable? Maybe it's not all programmers who are dickheads but programmers who post on /r/learnMalbolge or maybe 2nd year programming students who might be a little immature because they're 20 and not because they're programmers.
Best of luck. You'll find your 127.0.0.1 in time ;)
If I didn't have some level of delusion a few years in, continuing might have been very daunting. At some point I believed I was the best but, looking back, I was just starting to get competent at reading documentation and moved away from trial-and-error. It was healthy in that I remained enthusiastic but I think it may have held me back sometimes. I ignored good advice from a very experienced person many times.
Maybe there's some filter there where you kind of have to inflate your opinion of your own work to keep at it? It's better to balance it with some doubt, make sure your opinion is based in reality and continue to learn but, for those I've seen who don't really do that... at least they're still showing up. That's half of it.
Programmers are humans and that's the way humans behave. You'll find plenty of ego everywhere, you just selected yourself into our profession and probably don't meet too many people on a different professional path.
As a programmer, I have tried to remain humble because I have been surrounded by smart people who think they’re above everyone else and are just too smart for the world to handle. In any hobby/job that requires being reasonably smart, there are always going to be those people that have god complexes because they’ve associated their value as a person with their ability to do x or y thing well. If they humble themselves then they’re left with nothing in their eyes. I’m sure this is just one demographic of people out of the larger dickhead programmer population. People are dicks for all sorts of reasons anyways. I’m sure everything everyone has said is true about someone.