Lewis Cianci, a senior developer with 18+ years of experience, discusses how developer elitism breeds contempt and over-reliance on AI, and how you can avoid these perils in your own workplace.
Imagine for a moment your job is to sit in an office and count to 10,000. You can count up in sets of 100, but you must count down in sets of 10. You get quite good at it — so good that you become the Senior Number Counter. You have to count down in 5’s, 10’s, 20’s, and there’s the occasional division. It’s more difficult, that’s for sure.
Now, if you get interrupted during your count, and you remember what number you were up to, you can pick up where you left off. But if you forget the number you were up to, you have to start again.
In addition to this, people keep coming up to you at work. Someone asks you how division even works. Someone else wants to get into an extended discussion about their weekend. Still, other people joining the team struggle to count down in sets of 10, something that you mastered, and they want to ask you for help.
But, you feel like you can’t forget the number that you’re up to, otherwise you’ll have to start again. In the beginning, you write down the number, turn to the person asking you the question, give them an answer, and then continue.
As time goes on and the interruptions continue, this engagement turns to rejection, or even ignorance. High-level noise-canceling headphones are purchased, and a piece of paper is stuck to your chair saying “DO NOT DISTURB”.
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
This is a trivial example of what it is like to be a software developer. On an issue or bug, we need to review large codebases to find where the issue could be coming from. This is the “counting up” phase, as we establish context relating to the problem at hand.
Once we have good context, the problem-solving and tinkering begin. In the early days as junior devs, these are simple problems or issues solved by Stack Overflow or AI.
As a senior dev, the complexity scales dramatically, as we have to come up with completely novel ways to solve things that have not been solved before.
How good you are at solving a problem or being a software developer is proportionate to how much people will want to talk to you. As you become more senior, more aware, more talented, you will have bigger features and badder bugs to solve, which will require more mental grind. At the same time, people will also want to talk to you more, as you become the domain expert for whatever you’re putting your hand to.
But you just don’t have the time. It’s hard. You have to ship this feature by next week. As it is, you’ll be writing tests on the weekend… at midnight. And the junior dev keeps asking you questions about a system you wrote a year ago because he’s got a few things assigned to him to solve. Well, you’re out of time, so he’s just going to have to figure it out, right? You figured it out, so why can’t he?
This continues over time, and that sensation beds in, and it leads to a superior attitude. Truly, when would you ever have time to become approachable? And even if you did, the other devs wouldn’t think you were.
And that’s a big problem.
Without realizing it, you make the other devs think that you are better at the thing that you’re doing, and you have no intention of helping them. You’re kind of this hallowed elite developer, and it seems like you’ll never get time to loop back to them and give them a hand.
And you know – it’s a gross sensation to be on the receiving end of. It burns people out, makes them regret asking questions, and turns them to lower-quality, but kinder, sources of information.
I’ve been a developer for a couple of decades now, and unfortunately, elitism is woven throughout much of our technical culture. The places where developers frequent — GitHub, Stack Overflow, and even Discord or Slack — are where complex problems are solved and good answers are produced.
At the same time, they’re a breeding ground for an utter contempt for new developers, or even people who are new to a particular language or framework. The developers who come across as elite would never identify as such – they’re just busy after all, or think you should know more. But are they going to be the ones to help you know more? Well, no.
Elitism creates three problems: bad communication, lack of humility, and an over-reliance on AI. In this post, I will sum up the damage that elitism can have on communication, the damaging effect it has on training the next generation, and how you can overcome it within your workplace.
I will admit, I’ve not surveyed every software development company in the world. This is more based on my experience over the last decade in the software space.
Communication is a natural, organic thing. We need to communicate to survive. But we also need to communicate to learn and grow. If we are talking to people who think they are better than us, communication will be strained or disrupted entirely. How many times can someone be asked, “How could you not know this?” before they just stop asking?
Communication problems have caused immeasurable damage in the past and will likely continue to do so. Large, billion-dollar projects with huge failures like the Columbia and Challenger were principally caused by a breakdown in communication.
Most of us are probably not in the business of launching spaceships. But elitism is such a blocker to communication that we need to remember how important that communication is.
It pays to think about the effect that elitism can have on software projects and the organizations that we work for.
Not everyone springs forth from the womb with an innate ability to debug code and create amazing apps. Everyone has their own journey, and no two developers take the same path.
Even the path that people choose to take can have an impact on how they are treated. Someone who is self-taught could be looked down on. You can imagine the retorts of, “oh you haven’t been to university, that explains a lot.”
It’s fair to say that being accredited with a computer science degree or equivalent does give you more to work with in terms of understanding the specific implementations of various software techniques. But not everyone can afford to do that. Some people don’t learn well in a university setting.
Take me, for example. If you want me to sit down and listen and learn something in a classroom, you’re going to be in for a rough ride. Even if the topic is relevant to my interests, being still and trying to concentrate on what’s being discussed is not how I learn best.
You don’t want people forcing themselves through university just so they can say they did it. You want them to do it because they’re genuinely engaged and interested in what’s in the courseware. Plus, if you’re early in your career, you will meet a lot of people who are clever and productive developers, even though they‘re self-taught.
Unfortunately, the inverse is also true. You will meet people who achieved top marks who still write genuinely baffling solutions to a problem. And you may have a harder time convincing the person who graduated at the top of their class that their solution isn’t optimal!
I started as a developer simply because my work area needed someone to have a crack at fixing some software. Prior to this point, I had only really worked on applications in my spare time as a hobby. But, given the opportunity to try my hand at something more interesting, I jumped at the chance.
I’ve gone back to these days and viewed the questions that I asked on Stack Overflow. Well, they’re bad even for the most amateur software developer.
Being one of the only developers on my team meant that there weren’t a lot of other people to bounce ideas or concepts off. So, I just had to use Google to search for an answer. When there were no good hits, I tried my luck asking on something like Stack Overflow.
Most of the time, that’s a good option. But sometimes, you don’t even know enough to be able to formulate a good question in the first place. And so, trying to bridge these gaps in knowledge largely comes to strangers on the internet.
Asking for help on sites like Stack Overflow is a process in itself. If you just rock up and ask “How do I X?” then there is a very good chance that what you are asking is a duplicate, and will be closed as such, and you’ll be linked to a vaguely related question.
And so, you can ask again, but unless your question is substantially better, it’ll be closed as well. This is because the quality bar for questions on Stack Overflow is very high: questions are asked and answered to contribute to an overall quality within the site. This serves Stack Overflow well, but serves newbie developers poorly.
Eventually, if you ask enough bad questions, you’ll be prevented from asking any more questions. At this point, it’s possibly intuitive to just delete the questions and attempt to try again. But doing so makes the questions uneditable, so you can’t actually fix the questions at this point. Maybe at this point it’s tempting to throw out that account, create a new one, and try again. But in doing so, you run afoul of Stack Overflow’s rules and run the risk of that new account getting banned as well.
Logically, as Stack Overflow exists to be a repository of high-quality information, moderators act to preserve this quality. But getting stuck in an unsolvable labyrinth of low-quality questions is frustrating, and even new developers are expected to contribute sooner rather than later to their projects. People may want to learn “how to ask a good question,” but may not have the time to do that at that exact moment due to other time pressures.
Personally, I dread asking questions on Stack Overflow. I comb through my question in high detail to make sure that it won’t be shouted down by the masses. And I’ve worked as a senior developer for several years now.
Questions that I would normally direct to Stack Overflow, I just ask ChatGPT. But there’s an important caveat to this.
It would be nice to say that AI can help overcome the hostility towards novice developers on Q&A sites like Stack Overflow. In some ways, it would be a neat solution; AI could train on a huge amount of solutions provided by developers and be more concessional when helping newer developers to learn various concepts.
Certainly, AI is quite polite when discussing various elements of development with a junior developer, even if that developer lacks basic knowledge of the subject matter. But the problems with this are more nuanced.
Sometimes, AI can make suggestions about how to solve a given problem that are completely wrong, but written in a way to make it seem believable. I’ve never had AI say to me, “I don’t know how to do that”, and that’s because AI doesn’t really know if something is outside of its scope of knowledge. Instead, it’ll make up stuff that seems believable, which is just a hallucination.
I experienced this when working on something in Rust. Continuously, ChatGPT would give me wrong information, and no amount of telling it that it was using the wrong crates and syntax would make it work correctly. In the end, I abandoned even trying to use it for my particular problem.
The key difference here, though, is that I knew how long it would take me to do it myself without using AI. I wanted to have a chance of getting through a particular problem faster. Bailing out of using AI was only something I could do because I knew there was a better way.
Newer coding tools like Cursor and even existing chatbots like ChatGPT have the immediate appeal of not being judgmental of the users’ knowledge. But they face the immense downside that they may peddle incorrect information or give outdated info for a developer to implement.
Both of these outcomes are terrible. Someone may get frustrated from having their time wasted, or get stuck in bad habits from outdated information. Even to this day, ChatGPT tells me the wrong way to get values out of an Angular form.
So, the crux of this problem is: would a junior developer ask a senior developer for help with something if there is a chance of ridicule or some kind of humiliation? Or would they turn to AI for a less judgmental experience? Most of the time, they’d probably choose the latter. That introduces more problems around swathes of code being pasted into something like ChatGPT as the developer looks for a solution.
Somehow, all of the developers with the knowledge to help another junior developer have to be easier to approach than an online chatbot. And that can be a pretty big problem.
Five or so years ago, I knew enough about software development to find and fix bugs, and even to implement new features. But there was a ceiling to my knowledge: a point where I would simply Google a fix, and try to find solutions that would work for me. Unflatteringly, but accurately, I would have said at this time in my career, I was a bit like a “copy-paste developer”.
It’s all good, as long as you do find a solution. But you end up writing quite a bit of mapping code, trying to transplant code from random places into your software. You bounce around a bit trying to solve the more complex problems. And sometimes, very complex problems are simply beyond your realm of knowledge.
Eventually, my position changed teams, and I was plunged into a bespoke software suite that was entirely custom. There was no point in searching for solutions to what I was doing because it was an entirely customized system. It was terrifying, but also signified the next chapter of my developer journey.
For the first time ever, I had to compose what little knowledge I had and create novel solutions to things. No online resource was backing what I was doing. I couldn’t point to a webpage and say, “I got this idea from here”.
I had to carve out new features and functionality and rationalize the implementation entirely myself. I could feel my brain wrinkling. I would come home from work and just want to stare at a wall, as I’d exerted every last thinking bit of my brain. Only because I enjoyed being a developer did I stick with it.
And also, because of my legendary senior developer in this role.
Big reveal: I’m not a developer because of my intelligence. I’m a developer because I have a natural joy in creating software that solves problems. I feel like my curiosity and satisfaction from writing good software have more to do with my ability than my intellect ever would.
The same could not be said for our senior developer. The guy was just smart. In terms of raw computational power, recall ability, and the sheer size of context that he could fit in his brain, he probably could have chosen to do anything with this. He could have been an engineer or architect for actual buildings. But instead, it seemed like he chose software development as an outlet for what could only be described as raw intelligence.
The stupid mistakes that I made in that team, and the rubbish that I checked into source control, were significant. I was still grappling with the concept of creating my own solutions. When I had exhausted all other means, I swiveled to the senior dev and asked a question. I expected to be shut down pretty hard.
A few words into the explanation (which was about B-trees), he stopped and asked, “Did you go to university?”. Essentially, querying if I had done a computer science degree or equivalent. Silently, I shook my head. Traditionally, this is where someone would be right to puzzle out loud over why they spent tens of thousands of dollars to become accredited, while people with almost the same money just rolled into the job.
Instead, he said, “Oh, that’s okay. Some of the best people I know never went to university.” And with that, he got up, whiteboard marker in hand, and proceeded to draw out a B-tree. It was insightful, and I still remember it to this day.
Most of what I wrote in this role was functional, but it took a long time and lacked polish. Frequently, I would check in code in TypeScript with debugger statements still present. Optimistically, he said, “Oh, maybe Webpack takes them out for you at compile time….?” when he probably knew full well that it didn’t.
At the time, I did think I was a bit clever for keeping my job as a developer, but the humility of our senior developer humbled the heck out of me. If he could be this patient with me, I could be patient with anybody. Nobody ever had more reason to drill into me than he did, and yet he didn’t. So what reason could I possibly have to ever light someone up over a bad pull request or solution to a problem?
This actually benefited my career and prospects as a developer in the long term, as I was super approachable to pretty much anyone. I had the same people ask me the same question day after day, and every time I ran them through it again.
I shudder to think about what would have happened if our senior developer had shut me down. I probably would have changed careers, rationalizing that I couldn’t ever aim for the mighty heights of the senior developer role. And yet, that’s what I am today.
Developer elitism arises because one developer thinks a second of his time is worth more than a second of another developer’s time. Perhaps that’s not an entirely unfair assessment: after all, senior developers get paid more. But it is absolute poison to the progression and training of junior developers.
Lead developers or even management may be aware of this problem, and they may want to solve it. And then they may come up with something that actually makes the problem worse. How?
Since the COVID-era lockdowns, managers have been very excited to identify the cause of any problem as a lack of being in-person together. If only we spoke to each other more, we would have fewer problems.
Surely a Friday lunch of pizza/Coke will help devs exchange their ideas. More communication = more better! Problem solved!
I’ve seen these kinds of things happen, and they do not work. You have all the junior devs on one side of the room, smashing down the free pizza, and the senior devs on the other side of the room patching YAML files to get their builds to work. Maybe they bring a laptop and try to keep working. And then what do you do, ban laptops? It’s a slippery slope.
Here’s what to do instead: Recognize that you have a time and focus problem. Booking more things will only exacerbate that problem. Acknowledge the pressure the senior devs are under, but also acknowledge the need to train up the juniors on the team.
Then put all options on the table, like:
If you can’t associate desirable behavior (ie, senior devs being approachable and training up the junior devs) with cash bonuses, you’d be surprised at the things people would do for more flexibility/work-from-home days/or a pre-stamped coffee card.
Despite the rise of AI, we still need developers for a long time yet. If anything, we’ll need more developers to fix some of the vibe-coded monstrosities that are being released.
Nascent developers bouncing off grouchy senior devs into the arms of AI is a recipe for failure, and it’s something that must already be happening. Instead, we should take the time to mentor the next generation. What don’t they get? What’s confusing for them? Taking the time to listen and give good suggestions can make a world of difference.
Plus, being more approachable and working on communication is something that will only help us be more valuable candidates for recruiters. Eventually, when our brains can’t actually do the software development anymore, those soft skills of being approachable and communicating well would help us transition into other roles (like a project manager, for instance).
Every developer needs to work on combating elitism and continuing to be approachable so they can mentor the next generation. Because we’re going to need really good developers for a long, long time.
This tutorial walks through recreating Apple’s Liquid Glass UI on the web using SVG filters, CSS, and React. You’ll learn how to build refraction and reflection effects with custom displacement and specular maps, and how to balance performance and accessibility when using advanced filter pipelines.
tRPC solved type safety for full-stack TypeScript teams. oRPC borrowed the best parts and added interoperability. This article breaks down how both frameworks work and where each one fits best.
Check out Google’s latest AI releases, Gemini and the Antigravity AI IDE. Understand what’s new, how they work, and how they can reshape your development workflow.
Learn about Bun 1.3, which marks a shift from fast runtime to full JS toolchain—and see the impact of Anthropic’s acquisition of Bun.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn more →
One Reply to "It’s time to break the cycle of developer elitism"
I feel like this is more a StackOverflow issue then an issue in general. One on one, great s/w dev’s are great. For some reason so seems to attract bullies, though there are definitely exceptions.