Software development is a field that moves at a breakneck pace. Only a few years ago, we hadn’t heard of AI yet. Now it seems like it’s front and center of everyone’s minds these days. Trying to stay up to date and relevant in this field is not easy. Sometimes, it can feel like you’re trying to balance on top of a moving ball, and that ball is moving pretty quickly.
For a minute, though, let’s take a break from trying the latest LLM model or exploring better ways to achieve our craft.
Let’s instead talk about one of the greatest problems in the realm of software development: elitism.
You’ve probably experienced it, or know someone who has — the feeling that someone else is just better at the thing that you’re doing, and they have zero intent of helping you. They might even belittle your knowledge or engage in some other kind of unpleasant behavior.
Why? Because they think they’re better than you.
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.
Elitism creates three problems: bad communication, lack of humility, and an over-reliance on AI.
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 doing 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 is non-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, even in the first place. And so, trying to bridge these gaps in knowledge largely comes to strangers on the internet, in places like Stack Overflow.
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 a 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 customised 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 at 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 swivelled 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, 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.
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.
Having nascent developers bounce off grouchy developers 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.
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
Check out Kiro, AWS’s AI-powered IDE, see what makes it different from other AI coding tools, and explore whether it lives up to the hype.
Here’s how three design patterns solved our Go microservices scaling problems without sacrificing simplicity.
Explore six principled design patterns (with real-world examples) to help you protect your LLM agents from prompt injection attacks.
As AI tools take over more routine coding work, some companies are cutting early-career dev roles — a short-sighted move that could quietly erode the next generation of tech leaders if we aren’t careful.
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.