I think #1 and #6 go hand in hand, and usually results in #2. If you disregard your team, and you're arrogant, your code will likely be sloppy as hell. In my opinion that makes you the worst member of the team.
I spoke with a coworker about this and we agreed that you just need to be humble as a software developer: we all are going to screw up, we don't all know all the answers, and we don't know why others in our teams say / know specific things, but we should not take their advise lightly it might of been a painful lesson for them to begin with!
My girlfriend being a developer also we end up having this kind of conversation very often and we agreed to say the developers we enjoy the most to work with are knowledgeable but yet humble persons.
In my opinions personality traits are often disregarded over technical skills during interviews.
Individuals often have little control over these things, and they are indicative of deeper cultural incentives. Without transgressing some, nothing will get done in many orgs. I see it a lot in big money VC backed startups, much less so in bootstrapped businesses. It’s important to be non-judgmental of people doing these things and simply leave or master Machiavellian moves to clear a path to promotion as other players are, eg. via optics or rallying support to oust “toxic” rivals for the good of the team.
Game theory suggests this is true. Dog eat dog. But do you think this is because incentives are misaligned, or do you think that even successful bootstrapped businesses, if around long enough, will fall victim to this culture?
I agree if we decouple optics from genuine promotion in which an employee "manages upward" their true successes. I know that people are more nuanced than this and it's not black and white. So this will become quite tautological.
I agree. The system in place is to blame, and those people rose because they are just playing the game that is dealt to them.
I'm not so good at the Machievellian political aspect, so I personally opt to leave when I notice behaviors like this are rewarded in the current system. I also wonder if I was able to rise in an organization that functions like this, if I would b the type of person to actually root out that toxicity in the first place.
9. Refuse to do any maintenance and only work on new projects.
10. Hide your actual productivity. IE: get done with your coding tasks in half the time, leaving other devs have to fix all the bugs that QA kick back. (This is probably a managerial issue, actually, but perpetuated by devs who do # 9.)
We haven’t done enough of the latter. I’d love to automate and improve a lot of stuff but our project manager is pretty much always client visible first.
#9 might be a symptom of a structural problem. If developers routinely encounter problems arising from technical debt, and are continually asked to fix those problems, but are somehow never afforded the opportunity to retire the technical debt, that creates an aversion to the maintenance work.
"If it ain't broke, don't fix it; if it is broke, just use duct tape."
A lot of places have infinite budget for fixing things an a patchwork fashion, yet zero budget for planning ahead for the maintenance phase, or for scheduling preventative maintenance. It's the equivalent of never going to the doctor for a checkup, and only going to the Emergency Department at the nearest hospital when an organ explodes. Nobody wants to be in a long-term relationship with an exploding-organ person, and it's the same for code.
---
#10 is an organizational issue. If a dev has "ownership" of a particular domain, they will naturally work very hard in the short run at setting it up so that they may be as lazy as possible in the long run. But if they are continually kicked off their catbird seat of smoothly-running machinery in order to clean up other people's messes, then there is some incentive to exaggerate the effort it takes to clean up their own mess. Or to make it appear as though they have a mess to clean up.
Even worse, if no one has ownership over anything, there is incentive to always drag heels on the current thankless and tedious task just to delay assignment of the next thankless and tedious task. Do the minimum amount of work to fix the current issue, and let the next guy deal with the fallout, even if the next guy is also you. Because if you bust your ass to fix it right, the next guy won't thank you, because there is no next guy. You can only work on the stuff that is broken, and if there's not enough work to do, people get laid off.
And that is the equivalent of under-staffing the POS cashiers, so that none of them are ever idle. That strategy results in fewer customer transactions, because when cashiers are never idle, that also means that there is always a wait for customers to check out, no matter what size the order, and the cashiers have zero individual incentive to complete an order quickly. Monitoring scan rates only covers the problem, which is that employees are implicitly punished for doing their job too well. Go to Wal-Mart, and all the cashiers are always busy, but also always dragging ass, and all the check-out lines are three customers deep. Go to Publix, and cashiers with empty lanes cheerfully offer to check you out the instant you have found everything you need, and will direct you to the correct aisle if you haven't. Idleness is not just doing nothing, but is also customer responsiveness.
When other devs do this, your best tactic is probably just to follow their lead, and possibly collude with each another against management for your own benefit. The org is broken, and you won't be allowed to fix it.
> #9 might be a symptom of a structural problem. If developers routinely encounter problems arising from technical debt, and are continually asked to fix those problems, but are somehow never afforded the opportunity to retire the technical debt, that creates an aversion to the maintenance work.
I've seen a couple fresh grads come in with that attitude and get away with it. I think it is more personality type than anything. What I saw usually happen was they were allowed to work on a new feature as kind of a treat for joining, but after when tasked to start fixing issues from legacy, they flat out refused. Even taking it to the head of engineering and making a stink.
The boss can't hire new grads to work on it, because they can smell the manure from a mile away. So as long as you're willing to slap on yet another coat of superficial patches, they'll keep paying you to do it.
That's an equally-bad symptom of the same problem, approaching from the opposite side. The structural problem still doesn't get fixed, because the developers aren't repulsed by it at a visceral level quite enough to kill it with fire or nuke it from orbit. It's just scary enough to scare off the competition.
The technical debt is kept in place, so that people can live off of the technical interest payments. It's not an honorable living, but it is a living.
You're still stuck on "the code is bad and that's why they don't want to touch it." I'm saying, their attitude is bad and feel maintenance is beneath them.
Every, and I mean every, development shop has some amount of tech debt. But even if the code is generally good quality, you have a subset of devs who think maintenance is below them. That's a bad attitude and people don't want to work with that.
It's worse than that. All code instantly becomes technical debt the moment it's deployed. A development shop is almost entirely composed of technical debt, unless it never shipped anything.
The important thing is that you can recognize your own problematic behavior, and actively work on fixing it. Nobody's perfect, but I imagine there's a reason the author put #1 as #1 ;)
Yup, looking at common problematic behavior without reflecting inward, is an issue in and if itself. People often behave this way for a reason. You're liable to for the same reason.
I read the article and thought to myself that there's not a single thing in there that I don't recognize in my coworkers. :) Fwiw, I think articles like there are really bullshit. They just make self-doubting people doubt themselves even more and the real assholes never understands that the advice applies to them.
In my experience people provide excuses because they're being addressed by management in a way that is unnecessarily negative and/or management is wanting to find "guilty people" and not work out which is the best person for the job of fixing things.
That the article is clearly refusing to even mention this casts a big shadow over the rest of its conclusions. Some of the other things are the result of personality (like taking credit or sloppiness) but making excuses is 100% context and a defensive coping strategy literally every time I have seen or done it.
Yup, "no excuses" is a stupid attitude. Say I wanted you alone to get me to Mars tomorrow. It's absurd to say "no excuses" when you fail. It's possible that you're making understandable demands, or they just don't know how to do it faster.
I was just imagining the opposites of these and remembering some of my favorite people I ever worked with. I've only ever worked with 2 developers who I didn't like, and they fit this list almost perfectly.
As mentioned above, either the code works or it doesn’t … but it needs to work in combination with all the code being added to the codebase by your teammates.
That is Linus' job (or one of his trusted lieutenants). Kernel contributors generally do not interact with each other directly. There are simply too many kernel contributors to hold all kinds of "team meetings". The problems that the article mentions, exist mostly in a corporate environment. Virtual, distributed teams generally do not have these problems.
Software engineering is probably the most collaborative work in today’s world.
Yes, but successful software, such as the linux kernel, is not developed in the way he believes it is. What corporate IT typically does, is certainly not a reference.
A manager who doesn’t understand this is a manager who doesn’t understand software engineering.
A manager who does not read, evaluate, and merge pull requests, is not a manager; and does indeed not understand software engineering. The article complains about the side effects of one particular, rather outdated approach to software engineering. You will, for example, not hear the PostgreSQL or the Debian team complain about that kind of issues.
What corporate IT typically does, is certainly not a reference.
The article was in no way specific to "corporate IT".
But, literally by definition -- we're talking about the huge mass of applications that run most of the planet, here -- overall, "corporate IT" is way more representative than the handful of elite open source projects you're referring to.
Common misconception, but that graph does not explain the Dunning-Kruger effect. It's actually more like a linear curve, it's just a little flatter than the graph of y = x.
The Dunning-Kruger effect is that the best people underestimate their relative abilities, and the worst overestimate. So, the worst 10% may estimate they are about average, while the top 10% might estimate they are in the top 20%. These are more realistic figures than the graph used in this article.
People try to shoehorn Dunning-Kruger into situations where it doesn't make much sense.
Dunning-Kruger boils down to something a lot like "people tend to think other people are like themselves". So if you are low-skill at some task, you tend to think other people are low-skill, and as a result you see yourself as roughly average. If you are high-skill at some task you tend to think that other people are also high skill, so you over-estimate the average skill level.
This article is an example of shoehorning it in when it makes little sense, and I argue that they are claiming that Dunning-Kruger says the opposite of what it actually does. Yes, people can be arrogant and incompetent, but they can also be arrogant and highly competent. Dunning-Kruger would imply that someone who is highly competent would not be likely to be arrogant, since they would overestimate other people relative to themselves, and as a result they would give more credence to the ideas of others than is warranted given their relative skill levels. A total incompetent would indeed overestimate their own ability, but they would still see themselves as roughly average, which you wouldn't think is likely to be the trigger for an arrogant attitude.
All people will from time to time feel like the ideas of another person are silly or not worth listening to, but of course it is considered extremely rude to express those feelings. I think arrogance is just the expression of those feelings, which makes it a symptom of poor socialization.
> So if you are low-skill at some task, you tend to think other people are low-skill
Dunning-Kruger effect is not a way of thinking or reasoning about yourself or others, but a cognitive bias. You need to be put into a quick decision making mode where you have to compare your skill to others for it to skew your assessment.
The worst are the "What the hell was I even doing here?!?!? / What does this even mean?" moments.
Like at one point I thought this code was obvious and worked great. I remember feeling that way about it and feeling all accomplished here, but now I don't feel that way and this code seems impenetrable or at least a big hassle now...
I cringe when I look at some code I wrote. Some of it is maintenance nightmare, however, I read a book and found a better way to do some of those things. With each day I get better at writing maintainable code, I do less of duct taping to make things work.
I feel like I'm actually getting good at this software thing, and I'm actually not a total idiot. However, sometimes I look up simple things and I think I'm still an idiot. But when I look at the bigger picture I can see how much I have learned and understand the whole process. Servers, database, software, documentation, good code is great but there is more to software and I love it.
There's no feeling quite like going 'what the hell was the person who wrote this thinking??' and then doing a git blame and making a humbling discovery.
I thunk there's a second "flavor" of arrogance, where a person believes they're the smartest, but not most knowledgeable, in the room. These people will openly admit they can improve and seek training, partly because they believe they're capable of anything. They don't think they're at the top of the mountain, just that their mountain has no peak.
The real problem is they believe "lazy" coworkers will eventually be below them in every subject. They may seek out colleagues' advice some times, but likely will never return because they "get it" now."
They'll act like a "jack and master of all trades." This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand let alone maintain. So experts need to be brought in, anyway.
These people let the quick ascent of "Mount Ignorance" multiple subjects get to their head. No such thing as a Renaissance man anymore.
That take might be overly cynical. People who have a jack-of-all-trades skill set might not necessarily build the best components themselves, but might be able to bring some big-picture insight that more specialized developers don't have the awareness for, leading the team in the right direction.
I'm not suggesting you transition into becoming a PM or Architect or anything like that, just saying that developers like you count, too. If you have a decent work ethic, then you and your unique brand of knowledge-seeking have something to bring to the table.
> "usually leads to components nobody can understand let alone maintain"
As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything.
We were all born without any knowledge. We all learned everything we needed to know to get where we are today. We've put men on the moon. We've sent probes to escape our solar system. We've sent submarines to the bottom of the ocean. Humans have the capability to do anything we put our minds to. You can too. Everything you understand today, you've learned in the short lifespan you've had. Today you will learn more, and tomorrow and the next. Just because you find humility in your place, doesn't mean you're not capable of anything.
Yes, but those slopes are indeterminate from an outside observer because success comes from within. For every person you think you might have pigeon-holed, I'll show you another that broke the mold. You see everyone starts off facing a metaphorical vertical cliff in anything they attempt. It's over time that you learn the passages and tools that make it easier to climb; that lessen the slope. Unless we're talking about physically dunking a basketball, anyone can be a savant in something with enough effort. But again that future effort is not knowable to a 3rd party, they can only base opinions on past observations. People can change and they can change in an instant.
Everyone's mountain has a peak. We have a finite amount of compute power in our heads, and a finite amount of time on the earth. That means we have a fixed amount of complexity we can work through.
That said, fixing someone's shitty microservice code is probably not bottlenecked by our cognitive capacities. It's probably bottlenecked by financial constraints.
At the point where all your practicing is just maintaining your performance, you've reached your peak. You can stay there, or you can go higher if you practice more (or better). But there is a finite amount of practicing you can do each day. (Studies argue that 4 hours is plenty.) So there is an absolute limit per individual.
Are we talking about a physical skill or a personal capacity for knowledge? Because while your argument might have merit when applied to something like sports, it doesn't hold much water when talking about accumulated knowledge. Yes, I might forget how to do a math problem the way I could when studying for a test in college, but I'll never forget that knowledge exists and where to find it if I should need to relearn. The metaphorical peak I'm speaking of relates to a person's ability to index knowledge like a search engine for the internet.
>Yes, I might forget how to do a math problem the way I could when studying for a test in college, but I'll never forget that knowledge exists and where to find it if I should need to relearn. The metaphorical peak I'm speaking of relates to a person's ability to index knowledge like a search engine for the internet.
The answer to your problem is actually and always "the internet". There, you've peaked.
Mental performance needs practice just like physical performance. At some point you max out. And if you don't keep up practicing at level, your performance declines. Knowledge too is bound by those rules. We're constantly forgetting as we learn new stuff.
> I'll never forget that knowledge exists and where to find it if I should need to relearn.
Meaning you'd have to practice to again reach your former performance. Sure you may reach your peak level again and reach it quicker thanks to your old practice. But you do need to practice again. And then again, if you want to keep it.
True, but I just need to stop thinking I can climb every mountain faster than people focusing on a couple. To put it another way, I need to rely more on others' progress. Even better, help them progress.
I keep in mind that I tend toward arrogance and think twice whenever "oh, I can do that" pops in my head. Also, splitting tasks with a team means other people can grab what they do well and I won't overreach.
Arrogance has very little to do with thinking you know a lot, or disagreeing with others, and everything to do with failing to follow social protocol. If you let other people speak, pause long enough that they feel like you are giving their words a fair evaluation, and then don't use words that they must interpret as telling them they are wrong you will not be seen as arrogant. This is true even if you rarely or never agree with anyone.
- let people finish their statement: If you don't let someone finish and you interrupt, they will decide that you are just refusing to hear them out rather than disagreeing. It doesn't matter if you can prove mathematically with extensive sources and footnotes, most of the time they won't be able to accept that you understood their point and showed it to be flawed.
- pause long enough after they speak: Again, if you instantly explain why they are wrong, most of the time other people will not be able to handle this. They will decide you didn't actually consider what they said. It doesn't matter what is actually true, and if you somehow do convince them that you are right they will be doubly resistant since you are making them feel stupid on top of everything else. A huge benefit of this and the previous bullet is that you will often find that at first you misinterpreted what the person was saying, so you were about to disagree for no reason.
- don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts. It may seem silly, but replying 'I don't think that will work because ...' is going to be the source of turmoil, when saying 'Interesting. Previously we did something similar to that but we had a problem where ...' is going to win the other person over instantly most of the time. Later they will see that they were wrong, but you didn't rub their nose in it and force them to grapple with it in a social setting where they are going to have to feel shame.
Failure to do these things is just what people mean whenever they say someone is arrogant.
Point 3 though. At some point how can you be so demure? Sometimes people are just stupid and wrong and need to get checked. Some guy working for a year getting nothing done and pretending like its some other problem than what it actually is needs to be forcefully briefed on their ignorance not 'hrmm well you see we tried it this way'.
If it's actually that bad, you should just fire them or do your best to not work with them because they will drag you down with them.
For milder/more moderate cases, giving someone a way to concede without publicly admitting they're wrong is a often a useful tactic to get said person to do things the right way while building trust in your relationship with them.
> Some guy working for a year getting nothing done and pretending like its some other problem than what it actually is
This is a management issue. In a rational engineering organization this guy's manager would be like "okay, so we know there's a problem with this tool. Now how do we work around the tool so we can move on to another problem?" And if the conversation becomes "workarounds are stupid we need to make them fix their tool" then the manager needs to be all like "I agree with you in a perfect world that's how things would work, but we're engineers being paid to solve people's problems and not to build the perfect software system. So build the workaround so we can solve the problem and we'll circle around and fix the tool when we have time."
This will let you feel superior and get the pleasure of making the dumb person feel terrible, but it really won't accomplish anything productive. What do you hope to gain by doing this? Will they start being smarter? Will they be better at their job?
I'm sorry, doing what you describe is just being a bully. If management isn't dealing with the problem person you should privately make them aware of the issues (in writing if possible). If management is aware of the issues and won't do anything about it, well you did your part and you aren't allowed to fix the problem. Unless it is a life and death or national security situation, either accept that the dummy is going to be around or resign.
If they haven't done any work for a year their manager is useless. You work at a place where managers don't do their job. If you take it upon yourself to set this person straight, you are basically propping up this useless manager. Useless managers hire useless people and chase away good people. Fixing this problem treats the symptom and may let the bad manager last longer than they would have otherwise, which means you are going to have to go set two additional people straight about how useless they are next year.
I agree it's a management problem. However, I've encountered the case where a developer abruptly teleports from "plateau of sustainability" (high confidence, knowledge and experience) instantly to "Mt. Stupid". And every time it was a case of users becoming confused with UI and doing something that caused injury (including data loss). In that case the developer consistently blamed both the user and user advocate.
I do not think it's bullying to give a bully a taste of their own medicine. It may not solve the problem, to be sure, but pushing back on bullies is not wrong. Pointing out their cognitive dissonance, and drawing a line from their stubbornness to being a bad developer is not wrong either. In particular where the manager doesn't care because 90% of the time that developer is delivering the goods, and just doesn't properly assess the ensuing (UI/UX) hostility.
Bad UI will piss off users. It's I completely expect they should express that frustration directly to the responsible developer. If that developer can't handle it, both accepting the criticism and making appropriate design adjustments, get out of the UI/UX development business.
Sounds like they have a bad manager. Yes some people are bad at their job, and that includes developers, but in every case I've encountered it, their manager enabled it. It could be an equally arrogant bad manager, or a milquetoast bad manager. Servility in a manager is a bad attribute. They should be someone who seeks out the demure contrarian and acts as their advocate, should the manager find their position compelling. Not everyone is confrontational, that isn't the problem though. If the manager isn't seeking out contrary opinions, and only acts obsequious to their developers? That's a stool pigeon of a manager. Bad manager and bad developer? Good luck with that combination.
I find situations where I feel someone else "needs to be forcefully briefed on their ignorance" are situations where I likely don't have the rank, influence, or audience to improve the situation anyway.
I don't really subscribe to Kant-style categorical imperative thinking or defeatist attitudes, but in this case I've always made better progress changing an existing bad thing by being "demure" and accommodating. I might have agency to change things, but if an group of others have have agency to keep it the same, failing to cooperate is counterproductive unless I entirely opt-out or leave.
> don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts
I think that an inability to admit a mistake is arrogant and results in a lack of accountability and ownership over individual's work.
If someone makes a mistake they should be proactively owning it and trying to find solutions to avoid similar mistakes in the future.
I doubt you properly understand that other people are full thinking beings equal to yourself since you assume everyone secretly agrees with you about every detail of everything all the time and the only issue is whether they are going to admit it or lie.
> if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts
Your response to my post:
> I doubt you properly understand that other people are full thinking beings equal to yourself since you assume everyone secretly agrees with you about every detail of everything all the time and the only issue is whether they are going to admit it or lie.
To me, you're contradicting your own position.
It also seems to me that you're the one that doesn't "properly understand that other people are full thinking beings equal to yourself" based on the arrogance and condescension of your response.
It has taken me a few years and I still fail sometimes, but I have learned to let people finish and then ask questions instead of telling them they're wrong, even when it's totally obvious to me. "What if that fails in this way?" instead of "that will fail in this way!". It makes the discussion collaborative instead of assuming that it's my job to point out everyone's failures. The punch line in one of my favorite comic stips is "It's not healthy to keep your problems bottled up inside me." It took me a long time to see how that applied to my own interactions.
The thing that gets me is the same thing I hate about politics. You build an elaborate plan on a bad supposition, and people hear the whole plan and forget it’s based on nonsense.
If the ground premise is wrong, and you see where they are going with this silliness, it’s challenging on multiple levels to “let them finish”.
I kind of miss the point where you think about what people said, react to that actual argument and wonder for brief time whether they actually might have a point.
It is failure of this one way more then just lack of pause - especially in long term relationships.
> Just don't settle for being a 'jack', become an expert
Expert in what? There will always be people "more expert" than me in any particular domain (specific tech, hobbies, whatever). At some point, there's diminishing returns in becoming 'expert' in things you don't need to be an expert in, when "competence" is enough.
Sure. Was just pushing back on the "don't settle for jack-of-all-trades - become the expert". Well... that's a never-ending goal. Perhaps I want to be an expert jack-of-all-trades?
I can't be the expert in all things, or even most things I want to be. There's simply not enough time - people with 10 years of experience on me will always be 10 years ahead - and usually that means there's more 'expert' than me on XYZ (not always, time != expertise exactly, but it's often an signal).
The whole point of the arrogance / humility axis is the awareness that there is not a destination to be arrived at named "expert". The DK graph goes up and to the right, to infinity and beyond. We must merely try to do our best, and try again.
The problem with becoming an expert is that you greatly limit your marketability and pigeonhole yourself into a small niche. When that niche loses demand, or you want to move someplace where there's no jobs in that niche, you're screwed. A generalist has a much easier time changing jobs and therefore more job security.
I just read the article and was like “I don’t think I suffer from these much at all” then read this comment. This is very insightful and also something I just realized that I greatly suffer from. Thanks.
I think one of the symptoms is not picking up enough detailed understanding of anything because you keep moving around and don't believe in most external knowledge anyway (eg. don't want to learn [beyond a certain depth] SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up, don't want to learn economics I don't trust those science cargo-culters). But the other reason you don't want to specialize is that it would be to accept a limit on yourself (OK I'm going to get specialize on getting very good at c++, my upper salary cap is 500k and likely cap 200k, career is mapped out).
One of the things that's slowly curing me I think is running into examples of systems that are genuinely very heavy to understand/improve, and examples of people who are just unarguably higher ceiling in different ways than you.
eg. go watch a SGM play 30 second hyperbullet chess, I don't think I have either the memory or raw processing speed to do what they do, ever. If those guys exist a lot of other people have way higher ceilings. Also realize that chess (and by extension must be a lot of other activities) rely on both a crazy cpu, an amazing memory and an insanely built-out internal database of positions and ideas, and since my cpu is good but not unbelievable, my memory is nothing special and my time is limited there must be a lot of activities I'll never really be good at. Also just getting older and staying unsuccessful relative to your ego, you just start to compromise I think.
> SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up
SQL syntax may be ugly, but for once, it's an example of a widely used technology that is based on a very firm and well thought out theoretical framework.
As a developer, it is definitely worth investing time in understanding relational databases and the theory behind them.
I see this in my step mother. My family isn't very high in social standing, but she has a nursing degree and a long well paying career, better than anyone else in my family. Now that I have a CS degree with similar pay, she pays me respect but still tangentially riffs on things she only half understands.
I have been concerned about occupying a similar space myself. The great secret that we all do well to remember is that being humble is simply a matter of practicing being humble. In particular, when I treat other team members as experts in what they do, and trust that they'll value me for whatever it is that I do, I become much more efficient, and feel more relaxed too. Yes, there are still times that I notice myself acting vain, but these days a few slow, grounding breaths goes a long way toward resetting me.
In fact, I wonder if the narcissism you speak of might have more to do with insecurity, deep down. In my experience, when I see myself taking a behavior that I consciously am against, the cause tends to be emotional and the solution tends to be to gently, curiously observe those situations and start questioning how I feel. When I love and take care of my emotional world, it becomes way easier to interact in a way I feel is more optimal on the fly.
This take can cause a pretty unproductive worldview. The trouble is, we've all met different people who fall into broad categories like "jack of all trades". A lot of morons will say this sort of thing. Sometimes it's because they think you think they are dumb, so they want to show you that they are good at other stuff so as to keep their ego happy.
However, generalists are a very useful component of a team. They tend to be able to have a higher level view of all the moving parts, and typically are great for, say, proposing integrations, or high level system design. Also, often specialists will solve a problem in their specialization, fit be damned. They need someone to derail them and say e.g. "this would be much, much easier if we leaned on MySQL to do this".
So, this feels like a baby and bathwater situation to me.
I'm sorry to read so deeply into your anecdote, but there's some interesting stuff to unpack.
> This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand
This describes nearly every company's MVP, so if you're thinking of a person in particular who had to cobble together some dynamic mess, chances are they have great regret for their design. But remember, tech debt is a luxury in these cases - often the alternative is no job or company, as the runway was exhausted, or investors were not impressed.
> A person believes they're the smartest, but not most knowledgeable, in the room.
I think there's no getting around this. In fact, TBH I hope my colleagues feel this way - I want them to advocate for things they think are better, and I don't want them to instead fall prey to their own insecurities.
It's actually kind of a little self-help bullshitty -- the "you can do anything" stuff -- but truly it's actually not awful advice. I guarantee there's someone you work with who has a better way of doing things, but isn't confident enough to endorse it.
I'm the worst for this. I firmly believe that given a totally novel problem in any domain that neither of us are familiar with. I will always solve it before you.
I also believe that whatever domain you're currently in I can outperform you in 5 years MAX.
It's crazy the bullshit we believe that 'feels' right day by day
Thank you for your admission. I too am naturally arrogant. People think I'm being weird if I'm not arrogant. I get weird people saying they don't believe me when I'm being humble. Probably because arrogant is who I am as a person. I feel people like me more when I'm being my arrogant self. Oddly, when I was my least arrogant and most humble I exhibited most of the traits in this article.
I was quite sour over the fact that I felt like during the interview process I was lied to about the position and what it would entail. Naturally, I was a bit salty about it and the fact that people were doing things that I would get criticized for. It ultimately hurt my confidence in myself. This made me exhibit most if not all of these traits during my stay at this company. I was trying to make lemons into lemonade. Ultimately I was able help us get on the right path and I was happy with my contributions to the team even if it did ruffle feathers and those people hated me afterwards. I took their criticism and I still try to use it to be a better person to work with.
Sorry, but real life situation is infinitely more complicated.
Crybullies, manipulative people, people driven by greed to have power over others, hazing the new team member for whatever reason. Some are much more likely and zealous to report colleagues to the supervisors, some less. Some are more likely to be listened by the supervisors, some less.
In unlucky circumstances, couple of rounds of conversations with managers and suddenly you are the asshole nobody wants to work with.
Referencing Dunning-Kruger effect in any topic on software engineering is very arrogant and pretentious on itself. This says more about the author, than other people's stupidity. The article is just bad.
Also, sometimes relentless negativity has some fringe benefits (moderate perfectionism). There's pros and cons. Just don't share that attitude with your coworkers. Hold yourself to a high standard, but be more relaxed with others.
Well, if you use a fictional interpretation of something known as a justification to claim that other people are stupid - you provide nothing of value regarding other people. And the only thing that can be extracted from this is that you feel the need to claim that other people are stupid.
Example of the arrogance mentioned in the first point: I have met folks who have seriously argued to me that their code contained no technical debt because "We wrote it right the first time." The code at the time was something in the range of 50,000 lines (so assuming 30 lines of code per page, 500 pages per textbook, you'd have to read ~3 textbooks on the subject of what their code does to understand it) and contained no test suite... and maybe 5% of the code was comments.
Sloppiness seems to come with enough examples... but I must say that it's not really a direct problem unless you are in a supervisory role and nevertheless insist on modifying the codebase, as that makes it significantly harder to correct you on your sloppiness.
Disrespect of others' time is being directly connected to meetings here -- I sympathize but I do think that the bigger issue is that "deep work" is best done in ~2-hour uninterrupted batches, and so a company culture which encourages actively scheduling those on shared calendars so that we can have "open spaces" for meetings during other parts of the day, would help a lot. Especially, I am growing more confident that meetings which exist should revolve around some decision to be made that needs input from a bunch of people -- in other words, every meeting is a negotiation and if it's just a "progress update" or a "question and answer" session it should be moved to an asynchronous medium like Slack or (to a lesser extent) email. If you insist on daily standups at least have the courtesy to schedule them in the afternoon so that when I come in off of my morning commute having thought, "I am going to do X, then Y, then Z" I am not burdened by "I have only 1 hour to work on X before I have to drop everything for the daily standup..."
I am probably more guilty of the constant negativity, I think a piece of wisdom from Seth Freeman is helpful here: that one wants to separate problems from people and be hard on problems, soft on people. You can be constantly be negative towards a problem and this will be tolerable if you are consistently cheerful towards the people who might have other needs with which they pursue those ends. "I am really worried that without a proper auth strategy we may get hacked, I know that you all strongly value being able to go forward without wasting time on such a frustratingly difficult problem, I fully understand that, but there has got to be some way that we can get a proper auth strategy which doesn't bog us down so that we're also not trivially hackable" is a very negative position but it somehow doesn't carry the same "drag" as "you're so stupid, trying to implement this insecure thing, you're going to be the reason we get hacked."
Greediness is a hard thing, definitely, but I would observe that all of the examples seem to have to do with private communication channels, and I wonder whether that's endemic to the situation. I also wonder how it subdivides with a manager taking credit for the successes of their team -- in some cases this respect is due and in some cases you feel like "we spent more time evading my boss than being led by them!"...
I think the weakest part of the article was "disregard for the team," I feel like that's just a catchall for "doing anything that was annoying to me personally" and it's like "well yeah but that's not helpful." I think any friction can be couched as "disregarding the team" whereas true disregard has something to do with "you went off and made your own decisions and never told any of the rest of us about it and we could have told you that they were not wise decisions because of needs that you would not have been expected to anticipate" -- but the sin there is really just falling out of step with the community and thinking "I can sail this ship entirely on my own!" and I th...
This, so much. It's where review comments like "why don't you just do X?" come from, where "X" is a systematic change. Condescension coming from a place of strength doesn't make it okay.
No, I mean I don't get promoted for trying to hear what other people say, while managers can't say enough nice things about the hipster-ass who breaks everything he touches trying to turn it into GraphQL no matter what.
But I didn't write that very clearly the first time.
>gives cryptic names for variables, or at best not self-explanatory
sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it:
>Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param
>Needlessly reorganizing data structures or renaming variables so that it becomes more difficult to reason about the flow of data
Naming things isn't just the hardest problem in programming, it's also the quickest way to piss off your peers if you're lazy about it.
For me this often happens incrementally. Like they started with "if (FeatureNotDisabled)" and then locally refactored the code until it was "if (!FeatureNotDisabled)". The problem is that they then didn't go back for another pass before commit, and reverse the double-negative by changing the variable name and semantics. This could be due to laziness, ignorance (it works, what's the problem?), fear (it works now, let's not break it), or time mismanagement (it took long enough to get it working, no time to make everything "perfect").
I could understand that evolution, but I have become convinced that this particular developer simply worked with negative logic in his brain. Even the configuration files will have:
Feature1Disabled=False
Feature2Disabled=True
Feature3Disabled=False
Instead of using feature flags to enable a feature, he used feature flags to disable features. He was very consistent and the logic is all correct, simply inverted.
Gah, naming! It feels like a sign of a lack of empathy to not at least give some semi-meaningful name to a variable. "x" is only acceptable if you're literally writing a function to perform algebra.
Another one is giving insanely long names but only changing one little part, instead of taking advantage of the heirarchical nature of programming languages and coming up with a nice nested structure. Example:
class TheRpcThing
{
object TheRpcThingHost
object TheRpcThingHostTimer
class TheRpcThingValidationException
{
object TheRpcThingHostValidationException
object TheRpcThingHostValidationExceptionErrorMessage
object TheRpcThingHostValidationExceptionErrorMessageFormatter
}
}
The cognitive cost of reading a bunch of previously-unseen code, which has an accumulation (the perfect word for this kind of thing) of the above can be so frustrating.
I actually use the number of capital letters in camel-cased variable/method names as a signal that the code might need refactoring.
Generally, every capital letter indicates another hierarchical relationship from left-to-right. Usually these are implementation details that shouldn't be publicly exposed, or at least could be separated out/encapsulated better in a different object/function structure.
Obviously it's a rule-of-thumb and there are exceptions, but I've found this works pretty well.
'Arrogance' is more often than not mostly a matter of perception. Truly arrogant people can seem nice - so we generally don't want to ascribe negative qualities like 'arrogant' to them.
'Real arrogance', and even greed, backstabbing - those can also done by people who seem to be well liked.
'Perceptive arrogance' I think is mostly a matter of posture, demeanour and communication. If you smile, let other people talk, have an easygoing manner, and are agreeable, you will not be perceived as 'arrogant' even though you may have all of the qualities of a truly arrogant person.
I don't think 'perceived arrogance' has anything to do with actually humility or gauge of one's own abilities, or of one's sense of self importance in the group.
If you're terse, blunt, dour or gregarious ... it can be perceived as arrogant.
'Real arrogance' i.e. the notion that one's thoughts and ideals matter more than others etc. I think is not even correlated with posture and communication style.
The most successful people in the corporate world are pure political players, and have never cared about outcomes, doing a good job - anything. All they care about is perception and their careers. But they are actually nice enough, generally charismatic.
Actually caring caring about a product can simply cause contention, and possibly give the perception of arrogance.
I prefer to consider arrogance in terms of measured behaviours, outcomes etc.. Glib political climbers to me are arrogant. Anyone actually trying to 'do a good job' and stepping on toes is just a bad communicator.
> We all know at least one developer who ... will always insist on following “best practices” without understanding why those practices are considered “best” (there is no such thing as best practices that adapt to every team)
For any developers out there recently starting on your path, I cannot stress the importance of taking the time to seek out best practices for new skills and technologies you pick up.
Find all the "best practices" you can, then ignore some of them for a while with some pilot code, then try to follow a combination of the ones that make most sense to you. Compare the two modules for legibility, clarity, maintainability and conciseness.
If, however, your team already has an entrenched way of doing things, don't be that jerk who comes to the party blasting their own music. Follow the existing style guides to a T and only offer advice for improvement after you've spent some time working with them.
Even if you immediately recognize a glaring problem in the way things are done, no one is going to take you seriously and you'll just come across as arrogant unless you already have rapport as a perceptive and helpful team member.
Take time to understand the culture around you, but don't, as this author suggests, ignore the tried and true devices of other cultures.
I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job.
My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble.
If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised.
Of course they might be clueless! But it takes time and deep questioning to be sure.
Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about.
But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.)
I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.
190 comments
[ 140 ms ] story [ 1984 ms ] threadI spoke with a coworker about this and we agreed that you just need to be humble as a software developer: we all are going to screw up, we don't all know all the answers, and we don't know why others in our teams say / know specific things, but we should not take their advise lightly it might of been a painful lesson for them to begin with!
The issue with this culture is that using optics to achieve an advantage generally works, but is not a good long-term--big-picture strategy.
So reasonably, of course you need to learn all of these quirks, just to be able to get rid of the vermin in your org.
I'm not so good at the Machievellian political aspect, so I personally opt to leave when I notice behaviors like this are rewarded in the current system. I also wonder if I was able to rise in an organization that functions like this, if I would b the type of person to actually root out that toxicity in the first place.
10. Hide your actual productivity. IE: get done with your coding tasks in half the time, leaving other devs have to fix all the bugs that QA kick back. (This is probably a managerial issue, actually, but perpetuated by devs who do # 9.)
"If it ain't broke, don't fix it; if it is broke, just use duct tape."
A lot of places have infinite budget for fixing things an a patchwork fashion, yet zero budget for planning ahead for the maintenance phase, or for scheduling preventative maintenance. It's the equivalent of never going to the doctor for a checkup, and only going to the Emergency Department at the nearest hospital when an organ explodes. Nobody wants to be in a long-term relationship with an exploding-organ person, and it's the same for code.
---
#10 is an organizational issue. If a dev has "ownership" of a particular domain, they will naturally work very hard in the short run at setting it up so that they may be as lazy as possible in the long run. But if they are continually kicked off their catbird seat of smoothly-running machinery in order to clean up other people's messes, then there is some incentive to exaggerate the effort it takes to clean up their own mess. Or to make it appear as though they have a mess to clean up.
Even worse, if no one has ownership over anything, there is incentive to always drag heels on the current thankless and tedious task just to delay assignment of the next thankless and tedious task. Do the minimum amount of work to fix the current issue, and let the next guy deal with the fallout, even if the next guy is also you. Because if you bust your ass to fix it right, the next guy won't thank you, because there is no next guy. You can only work on the stuff that is broken, and if there's not enough work to do, people get laid off.
And that is the equivalent of under-staffing the POS cashiers, so that none of them are ever idle. That strategy results in fewer customer transactions, because when cashiers are never idle, that also means that there is always a wait for customers to check out, no matter what size the order, and the cashiers have zero individual incentive to complete an order quickly. Monitoring scan rates only covers the problem, which is that employees are implicitly punished for doing their job too well. Go to Wal-Mart, and all the cashiers are always busy, but also always dragging ass, and all the check-out lines are three customers deep. Go to Publix, and cashiers with empty lanes cheerfully offer to check you out the instant you have found everything you need, and will direct you to the correct aisle if you haven't. Idleness is not just doing nothing, but is also customer responsiveness.
When other devs do this, your best tactic is probably just to follow their lead, and possibly collude with each another against management for your own benefit. The org is broken, and you won't be allowed to fix it.
I've seen a couple fresh grads come in with that attitude and get away with it. I think it is more personality type than anything. What I saw usually happen was they were allowed to work on a new feature as kind of a treat for joining, but after when tasked to start fixing issues from legacy, they flat out refused. Even taking it to the head of engineering and making a stink.
The boss can't hire new grads to work on it, because they can smell the manure from a mile away. So as long as you're willing to slap on yet another coat of superficial patches, they'll keep paying you to do it.
That's an equally-bad symptom of the same problem, approaching from the opposite side. The structural problem still doesn't get fixed, because the developers aren't repulsed by it at a visceral level quite enough to kill it with fire or nuke it from orbit. It's just scary enough to scare off the competition.
The technical debt is kept in place, so that people can live off of the technical interest payments. It's not an honorable living, but it is a living.
Every, and I mean every, development shop has some amount of tech debt. But even if the code is generally good quality, you have a subset of devs who think maintenance is below them. That's a bad attitude and people don't want to work with that.
I sometimes feel like I don't see anti-patterns as I go through my career, I fall over them and sprawl on the floor.
That the article is clearly refusing to even mention this casts a big shadow over the rest of its conclusions. Some of the other things are the result of personality (like taking credit or sloppiness) but making excuses is 100% context and a defensive coping strategy literally every time I have seen or done it.
Be humble, be kind.
That is Linus' job (or one of his trusted lieutenants). Kernel contributors generally do not interact with each other directly. There are simply too many kernel contributors to hold all kinds of "team meetings". The problems that the article mentions, exist mostly in a corporate environment. Virtual, distributed teams generally do not have these problems.
Software engineering is probably the most collaborative work in today’s world.
Yes, but successful software, such as the linux kernel, is not developed in the way he believes it is. What corporate IT typically does, is certainly not a reference.
A manager who doesn’t understand this is a manager who doesn’t understand software engineering.
A manager who does not read, evaluate, and merge pull requests, is not a manager; and does indeed not understand software engineering. The article complains about the side effects of one particular, rather outdated approach to software engineering. You will, for example, not hear the PostgreSQL or the Debian team complain about that kind of issues.
The article was in no way specific to "corporate IT".
But, literally by definition -- we're talking about the huge mass of applications that run most of the planet, here -- overall, "corporate IT" is way more representative than the handful of elite open source projects you're referring to.
The Dunning-Kruger effect is that the best people underestimate their relative abilities, and the worst overestimate. So, the worst 10% may estimate they are about average, while the top 10% might estimate they are in the top 20%. These are more realistic figures than the graph used in this article.
Dunning-Kruger boils down to something a lot like "people tend to think other people are like themselves". So if you are low-skill at some task, you tend to think other people are low-skill, and as a result you see yourself as roughly average. If you are high-skill at some task you tend to think that other people are also high skill, so you over-estimate the average skill level.
This article is an example of shoehorning it in when it makes little sense, and I argue that they are claiming that Dunning-Kruger says the opposite of what it actually does. Yes, people can be arrogant and incompetent, but they can also be arrogant and highly competent. Dunning-Kruger would imply that someone who is highly competent would not be likely to be arrogant, since they would overestimate other people relative to themselves, and as a result they would give more credence to the ideas of others than is warranted given their relative skill levels. A total incompetent would indeed overestimate their own ability, but they would still see themselves as roughly average, which you wouldn't think is likely to be the trigger for an arrogant attitude.
All people will from time to time feel like the ideas of another person are silly or not worth listening to, but of course it is considered extremely rude to express those feelings. I think arrogance is just the expression of those feelings, which makes it a symptom of poor socialization.
Dunning-Kruger effect is not a way of thinking or reasoning about yourself or others, but a cognitive bias. You need to be put into a quick decision making mode where you have to compare your skill to others for it to skew your assessment.
Like at one point I thought this code was obvious and worked great. I remember feeling that way about it and feeling all accomplished here, but now I don't feel that way and this code seems impenetrable or at least a big hassle now...
Especially when you're new like me. I go back even after a month and "Oh man I'd never do it like that again."
No to say it didn't work or was even bad but I just found a better pattern to handle that case that I'd use by default now and it changes so much.
The fact our ancient rewards system considers it embarrassing is of little importance.
It's just that the code is still there, and will need to be replaced in due time. Over and over again.
I feel like I'm actually getting good at this software thing, and I'm actually not a total idiot. However, sometimes I look up simple things and I think I'm still an idiot. But when I look at the bigger picture I can see how much I have learned and understand the whole process. Servers, database, software, documentation, good code is great but there is more to software and I love it.
Even future me hates me.
Edit: The domain is unreachable for me, I assumed it was for others also. It is still unreachable for me for some reason.
The real problem is they believe "lazy" coworkers will eventually be below them in every subject. They may seek out colleagues' advice some times, but likely will never return because they "get it" now."
They'll act like a "jack and master of all trades." This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand let alone maintain. So experts need to be brought in, anyway.
These people let the quick ascent of "Mount Ignorance" multiple subjects get to their head. No such thing as a Renaissance man anymore.
Sadly, I'm that flavor of arrogance.
I'm not suggesting you transition into becoming a PM or Architect or anything like that, just saying that developers like you count, too. If you have a decent work ethic, then you and your unique brand of knowledge-seeking have something to bring to the table.
As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything.
We were all born without any knowledge. We all learned everything we needed to know to get where we are today. We've put men on the moon. We've sent probes to escape our solar system. We've sent submarines to the bottom of the ocean. Humans have the capability to do anything we put our minds to. You can too. Everything you understand today, you've learned in the short lifespan you've had. Today you will learn more, and tomorrow and the next. Just because you find humility in your place, doesn't mean you're not capable of anything.
> Humans have the capability to do anything we put our minds to. You can too.
> doesn't mean you're not capable of anything.
That does sound like you're talking to individuals. Turn down the hyperbole a notch and I might even agree
That said, fixing someone's shitty microservice code is probably not bottlenecked by our cognitive capacities. It's probably bottlenecked by financial constraints.
The answer to your problem is actually and always "the internet". There, you've peaked.
> I'll never forget that knowledge exists and where to find it if I should need to relearn.
Meaning you'd have to practice to again reach your former performance. Sure you may reach your peak level again and reach it quicker thanks to your old practice. But you do need to practice again. And then again, if you want to keep it.
- let people finish their statement: If you don't let someone finish and you interrupt, they will decide that you are just refusing to hear them out rather than disagreeing. It doesn't matter if you can prove mathematically with extensive sources and footnotes, most of the time they won't be able to accept that you understood their point and showed it to be flawed.
- pause long enough after they speak: Again, if you instantly explain why they are wrong, most of the time other people will not be able to handle this. They will decide you didn't actually consider what they said. It doesn't matter what is actually true, and if you somehow do convince them that you are right they will be doubly resistant since you are making them feel stupid on top of everything else. A huge benefit of this and the previous bullet is that you will often find that at first you misinterpreted what the person was saying, so you were about to disagree for no reason.
- don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts. It may seem silly, but replying 'I don't think that will work because ...' is going to be the source of turmoil, when saying 'Interesting. Previously we did something similar to that but we had a problem where ...' is going to win the other person over instantly most of the time. Later they will see that they were wrong, but you didn't rub their nose in it and force them to grapple with it in a social setting where they are going to have to feel shame.
Failure to do these things is just what people mean whenever they say someone is arrogant.
For milder/more moderate cases, giving someone a way to concede without publicly admitting they're wrong is a often a useful tactic to get said person to do things the right way while building trust in your relationship with them.
This is a management issue. In a rational engineering organization this guy's manager would be like "okay, so we know there's a problem with this tool. Now how do we work around the tool so we can move on to another problem?" And if the conversation becomes "workarounds are stupid we need to make them fix their tool" then the manager needs to be all like "I agree with you in a perfect world that's how things would work, but we're engineers being paid to solve people's problems and not to build the perfect software system. So build the workaround so we can solve the problem and we'll circle around and fix the tool when we have time."
This will let you feel superior and get the pleasure of making the dumb person feel terrible, but it really won't accomplish anything productive. What do you hope to gain by doing this? Will they start being smarter? Will they be better at their job?
I'm sorry, doing what you describe is just being a bully. If management isn't dealing with the problem person you should privately make them aware of the issues (in writing if possible). If management is aware of the issues and won't do anything about it, well you did your part and you aren't allowed to fix the problem. Unless it is a life and death or national security situation, either accept that the dummy is going to be around or resign.
If they haven't done any work for a year their manager is useless. You work at a place where managers don't do their job. If you take it upon yourself to set this person straight, you are basically propping up this useless manager. Useless managers hire useless people and chase away good people. Fixing this problem treats the symptom and may let the bad manager last longer than they would have otherwise, which means you are going to have to go set two additional people straight about how useless they are next year.
I do not think it's bullying to give a bully a taste of their own medicine. It may not solve the problem, to be sure, but pushing back on bullies is not wrong. Pointing out their cognitive dissonance, and drawing a line from their stubbornness to being a bad developer is not wrong either. In particular where the manager doesn't care because 90% of the time that developer is delivering the goods, and just doesn't properly assess the ensuing (UI/UX) hostility.
Bad UI will piss off users. It's I completely expect they should express that frustration directly to the responsible developer. If that developer can't handle it, both accepting the criticism and making appropriate design adjustments, get out of the UI/UX development business.
I don't really subscribe to Kant-style categorical imperative thinking or defeatist attitudes, but in this case I've always made better progress changing an existing bad thing by being "demure" and accommodating. I might have agency to change things, but if an group of others have have agency to keep it the same, failing to cooperate is counterproductive unless I entirely opt-out or leave.
I think that an inability to admit a mistake is arrogant and results in a lack of accountability and ownership over individual's work. If someone makes a mistake they should be proactively owning it and trying to find solutions to avoid similar mistakes in the future.
> if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts
Your response to my post:
> I doubt you properly understand that other people are full thinking beings equal to yourself since you assume everyone secretly agrees with you about every detail of everything all the time and the only issue is whether they are going to admit it or lie.
To me, you're contradicting your own position. It also seems to me that you're the one that doesn't "properly understand that other people are full thinking beings equal to yourself" based on the arrogance and condescension of your response.
https://news.ycombinator.com/newsguidelines.html
If the ground premise is wrong, and you see where they are going with this silliness, it’s challenging on multiple levels to “let them finish”.
It is failure of this one way more then just lack of pause - especially in long term relationships.
Expert in what? There will always be people "more expert" than me in any particular domain (specific tech, hobbies, whatever). At some point, there's diminishing returns in becoming 'expert' in things you don't need to be an expert in, when "competence" is enough.
I can't be the expert in all things, or even most things I want to be. There's simply not enough time - people with 10 years of experience on me will always be 10 years ahead - and usually that means there's more 'expert' than me on XYZ (not always, time != expertise exactly, but it's often an signal).
I think one of the symptoms is not picking up enough detailed understanding of anything because you keep moving around and don't believe in most external knowledge anyway (eg. don't want to learn [beyond a certain depth] SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up, don't want to learn economics I don't trust those science cargo-culters). But the other reason you don't want to specialize is that it would be to accept a limit on yourself (OK I'm going to get specialize on getting very good at c++, my upper salary cap is 500k and likely cap 200k, career is mapped out).
One of the things that's slowly curing me I think is running into examples of systems that are genuinely very heavy to understand/improve, and examples of people who are just unarguably higher ceiling in different ways than you.
eg. go watch a SGM play 30 second hyperbullet chess, I don't think I have either the memory or raw processing speed to do what they do, ever. If those guys exist a lot of other people have way higher ceilings. Also realize that chess (and by extension must be a lot of other activities) rely on both a crazy cpu, an amazing memory and an insanely built-out internal database of positions and ideas, and since my cpu is good but not unbelievable, my memory is nothing special and my time is limited there must be a lot of activities I'll never really be good at. Also just getting older and staying unsuccessful relative to your ego, you just start to compromise I think.
SQL syntax may be ugly, but for once, it's an example of a widely used technology that is based on a very firm and well thought out theoretical framework.
As a developer, it is definitely worth investing time in understanding relational databases and the theory behind them.
https://en.wikipedia.org/wiki/Relational_calculus
https://airbladesoftware.com/notes/relational-databases-are-...
In fact, I wonder if the narcissism you speak of might have more to do with insecurity, deep down. In my experience, when I see myself taking a behavior that I consciously am against, the cause tends to be emotional and the solution tends to be to gently, curiously observe those situations and start questioning how I feel. When I love and take care of my emotional world, it becomes way easier to interact in a way I feel is more optimal on the fly.
However, generalists are a very useful component of a team. They tend to be able to have a higher level view of all the moving parts, and typically are great for, say, proposing integrations, or high level system design. Also, often specialists will solve a problem in their specialization, fit be damned. They need someone to derail them and say e.g. "this would be much, much easier if we leaned on MySQL to do this".
So, this feels like a baby and bathwater situation to me.
I'm sorry to read so deeply into your anecdote, but there's some interesting stuff to unpack.
> This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand
This describes nearly every company's MVP, so if you're thinking of a person in particular who had to cobble together some dynamic mess, chances are they have great regret for their design. But remember, tech debt is a luxury in these cases - often the alternative is no job or company, as the runway was exhausted, or investors were not impressed.
> A person believes they're the smartest, but not most knowledgeable, in the room.
I think there's no getting around this. In fact, TBH I hope my colleagues feel this way - I want them to advocate for things they think are better, and I don't want them to instead fall prey to their own insecurities.
It's actually kind of a little self-help bullshitty -- the "you can do anything" stuff -- but truly it's actually not awful advice. I guarantee there's someone you work with who has a better way of doing things, but isn't confident enough to endorse it.
Anyhow... thanks for the writing prompt? ;)
I also believe that whatever domain you're currently in I can outperform you in 5 years MAX.
It's crazy the bullshit we believe that 'feels' right day by day
I was quite sour over the fact that I felt like during the interview process I was lied to about the position and what it would entail. Naturally, I was a bit salty about it and the fact that people were doing things that I would get criticized for. It ultimately hurt my confidence in myself. This made me exhibit most if not all of these traits during my stay at this company. I was trying to make lemons into lemonade. Ultimately I was able help us get on the right path and I was happy with my contributions to the team even if it did ruffle feathers and those people hated me afterwards. I took their criticism and I still try to use it to be a better person to work with.
Crybullies, manipulative people, people driven by greed to have power over others, hazing the new team member for whatever reason. Some are much more likely and zealous to report colleagues to the supervisors, some less. Some are more likely to be listened by the supervisors, some less.
In unlucky circumstances, couple of rounds of conversations with managers and suddenly you are the asshole nobody wants to work with.
"If someone complains, it focuses the attention on the negative side of things."
(...after a whole article complaining about behavior s/he does not like, ironically)
If you want to see big disasters look in organizations where warnings are ignored as "negativity" and people blame the messengers.
does your comment about Dunning-Kruger "say more about you" than the author?
Sloppiness seems to come with enough examples... but I must say that it's not really a direct problem unless you are in a supervisory role and nevertheless insist on modifying the codebase, as that makes it significantly harder to correct you on your sloppiness.
Disrespect of others' time is being directly connected to meetings here -- I sympathize but I do think that the bigger issue is that "deep work" is best done in ~2-hour uninterrupted batches, and so a company culture which encourages actively scheduling those on shared calendars so that we can have "open spaces" for meetings during other parts of the day, would help a lot. Especially, I am growing more confident that meetings which exist should revolve around some decision to be made that needs input from a bunch of people -- in other words, every meeting is a negotiation and if it's just a "progress update" or a "question and answer" session it should be moved to an asynchronous medium like Slack or (to a lesser extent) email. If you insist on daily standups at least have the courtesy to schedule them in the afternoon so that when I come in off of my morning commute having thought, "I am going to do X, then Y, then Z" I am not burdened by "I have only 1 hour to work on X before I have to drop everything for the daily standup..."
I am probably more guilty of the constant negativity, I think a piece of wisdom from Seth Freeman is helpful here: that one wants to separate problems from people and be hard on problems, soft on people. You can be constantly be negative towards a problem and this will be tolerable if you are consistently cheerful towards the people who might have other needs with which they pursue those ends. "I am really worried that without a proper auth strategy we may get hacked, I know that you all strongly value being able to go forward without wasting time on such a frustratingly difficult problem, I fully understand that, but there has got to be some way that we can get a proper auth strategy which doesn't bog us down so that we're also not trivially hackable" is a very negative position but it somehow doesn't carry the same "drag" as "you're so stupid, trying to implement this insecure thing, you're going to be the reason we get hacked."
Greediness is a hard thing, definitely, but I would observe that all of the examples seem to have to do with private communication channels, and I wonder whether that's endemic to the situation. I also wonder how it subdivides with a manager taking credit for the successes of their team -- in some cases this respect is due and in some cases you feel like "we spent more time evading my boss than being led by them!"...
I think the weakest part of the article was "disregard for the team," I feel like that's just a catchall for "doing anything that was annoying to me personally" and it's like "well yeah but that's not helpful." I think any friction can be couched as "disregarding the team" whereas true disregard has something to do with "you went off and made your own decisions and never told any of the rest of us about it and we could have told you that they were not wise decisions because of needs that you would not have been expected to anticipate" -- but the sin there is really just falling out of step with the community and thinking "I can sail this ship entirely on my own!" and I th...
But I didn't write that very clearly the first time.
>gives cryptic names for variables, or at best not self-explanatory
sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it:
>Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param
>Needlessly reorganizing data structures or renaming variables so that it becomes more difficult to reason about the flow of data
Naming things isn't just the hardest problem in programming, it's also the quickest way to piss off your peers if you're lazy about it.
if(!FeatureNotDisabled){ .... }
It drives me absolutely bonkers!
Feature1Disabled=False
Feature2Disabled=True
Feature3Disabled=False
Instead of using feature flags to enable a feature, he used feature flags to disable features. He was very consistent and the logic is all correct, simply inverted.
Yes, `if (!FeatureEnabled){ ... }` would be clearer.
It's only a double negative (“disabled” is affirmative, though the same sense can be communicated by the single negative “not enabled”.)
Generally, every capital letter indicates another hierarchical relationship from left-to-right. Usually these are implementation details that shouldn't be publicly exposed, or at least could be separated out/encapsulated better in a different object/function structure.
Obviously it's a rule-of-thumb and there are exceptions, but I've found this works pretty well.
'Real arrogance', and even greed, backstabbing - those can also done by people who seem to be well liked.
'Perceptive arrogance' I think is mostly a matter of posture, demeanour and communication. If you smile, let other people talk, have an easygoing manner, and are agreeable, you will not be perceived as 'arrogant' even though you may have all of the qualities of a truly arrogant person.
I don't think 'perceived arrogance' has anything to do with actually humility or gauge of one's own abilities, or of one's sense of self importance in the group.
If you're terse, blunt, dour or gregarious ... it can be perceived as arrogant.
'Real arrogance' i.e. the notion that one's thoughts and ideals matter more than others etc. I think is not even correlated with posture and communication style.
The most successful people in the corporate world are pure political players, and have never cared about outcomes, doing a good job - anything. All they care about is perception and their careers. But they are actually nice enough, generally charismatic.
Actually caring caring about a product can simply cause contention, and possibly give the perception of arrogance.
I prefer to consider arrogance in terms of measured behaviours, outcomes etc.. Glib political climbers to me are arrogant. Anyone actually trying to 'do a good job' and stepping on toes is just a bad communicator.
> We all know at least one developer who ... will always insist on following “best practices” without understanding why those practices are considered “best” (there is no such thing as best practices that adapt to every team)
For any developers out there recently starting on your path, I cannot stress the importance of taking the time to seek out best practices for new skills and technologies you pick up.
Find all the "best practices" you can, then ignore some of them for a while with some pilot code, then try to follow a combination of the ones that make most sense to you. Compare the two modules for legibility, clarity, maintainability and conciseness.
If, however, your team already has an entrenched way of doing things, don't be that jerk who comes to the party blasting their own music. Follow the existing style guides to a T and only offer advice for improvement after you've spent some time working with them.
Even if you immediately recognize a glaring problem in the way things are done, no one is going to take you seriously and you'll just come across as arrogant unless you already have rapport as a perceptive and helpful team member.
Take time to understand the culture around you, but don't, as this author suggests, ignore the tried and true devices of other cultures.
I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job.
My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble.
If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised.
Of course they might be clueless! But it takes time and deep questioning to be sure.
Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about.
But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.)
I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.