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.
Damn, I was wrong… ;)
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?).
Correct, I was trying to give a why, directly from someone often perceived as an arrogant asshole senior dev.
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).
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).