I originally published this post about a week ago, on the DaedTech blog.
Apologies for my absence last week from the tech pundit-o-sphere. I was, well, what I mostly am these days: busy. But today, I’m back with a premise that sounds suspiciously motivational-speakery.
Don’t worry, though, realpolitik fans. It’s not that. Not exactly.
Sure, don’t let anyone tell you that you aren’t a ‘real’ programmer because (1) that’s a crappy thing to say and (2) because you’re awesome and all of that. But I’ll leave those lines of argument to others. Instead, I’m going to talk about why letting this nonsense into your head is bad for your career and your positioning.
The No True Scotsman Fallacy
First, though, let’s wander down to the anthropology dime store and categorize what we’re dealing with here. When someone tells you, for whatever reason, that you’re not a ‘real’ programmer, they’re most likely indulging in something called the “no true Scotsman” fallacy.
The gist of this is to create a subjective, moving-goal-posts purity test for membership in some club. And people generally do this as a direct follow-up to painting with too broad a brush and having someone subsequently call them on it. For instance, here’s the eponymous example, quoted from the Wiki article:
Person A : “No Scotsman puts sugar on his porridge.”
Person B : “But my uncle Angus is a Scotsman and he puts sugar on his porridge.”
Person A : “But no true Scotsman puts sugar on his porridge.”
In my personal experience with purveyors of this fallacy, I generally see two principle motivations, often intermixed:
- Zealous, subjective belief in the purity test itself.
- Having made a strident claim before really thinking it through, accompanied by a personal tendency never to back down afterward. (Sound familiar?)
Now, take a dash of this part of human nature, mix it into a heaping bowl of the internet, bake it in the oven for 20 years, and get ready to enjoy a bottomless casserole of “why you’re never good enough.”
The Many Flavors of ‘Not-Real’ Programmers
By now, you might find yourself nodding along, imagining programming-oriented statements like this. Maybe people have painted you with a brush like this, or maybe you’ve just seen them do it to others.
- No real programmer works heavily with CSS and markup.
- Real programmers use the command line — not user interfaces.
- In 2019 you’re not a real programmer if you’re using anything but git.
- No real programmers just use their IDE out of the box, without customizing it. (Also, bonus for, “real programmers use VIM and not IDEs.”)
I imagine these statements sound quite familiar. There sure are a lot of armchair arbiters of ‘real’ programming, aren’t there?
So, having defined what this is and given examples of how to recognize it, I’d like to spend the rest of the post talking about why this type of seemingly-minor bloviating is actually insidiously pernicious for those exposed to it.
How This Can Subtly Affect Your Career
Let me restate something briefly for emphasis. People no-true-Scotsman-ing other programmers are behaving childishly and being needlessly mean. And you should do your best to ignore them — to not let the bastards get you down — because you don’t deserve this kind of treatment.
If you program, you’re a real programmer.
But I’m not writing a “let’s be nicer to each other” call to action, or am I attempting to give a motivational speech. Rather, I want to talk software developer careers.
So let’s do that. Specifically, let’s look at how the general miasma of “no real programmer” that floats around internet forums threatens to encourage bad decisions among those subject to them. And please understand that it’s no single one of these declarations, but rather the effect of the entire universe of them, often-conflicting, always-confusing, and never-helpful.
1. It Encourages Hyper-Generalization
Long time readers of the blog know that I consider long-term career generalizing to be an anti-pattern. When your career is a never-ending stream of stacks, domains, verticals, psychographics, and roles, you risk having a career that consists of 45 entry-level years, rather than 45 years of cumulative, compounding experience. This acts as a drag on meaningful career advancement.
Now, think of a huge subset of the “no ‘real’ programmer” proclamations and their contrapositives. Real programmers sanitize their database inputs and parameterize their queries. Real programmers know that string concatenation is expensive. And so on, and so forth, ad near infinitum.
As software developers, we head to the internet for help and pointers, and we end up with a gigantic laundry list of professional obligations, according to random internet people. But if all programmers should know all of the basics across all stacks and all areas of programming, we have essentially no specialization of labor. Instead, everyone should pursue this bottomless checklist of table stakes.
The aggregate of the “real programmer” distinctions out there encourage you to focus on “rounding yourself out” with knowledge that might have literally zero applicability to your current gig, employer, or context. And that is quintessential over-generalizing.
2. It Invites Commodification
Part and parcel with generalizing is labor commodification. You know how it seems like programmers (and probably knowledge workers, in general) really don’t like when people call them “human resources?” That visceral protest is a subconscious objection to their inevitable commodification.
Don’t call me a human resource! I’m a unique human being, with unique talents, unique skills, unique perspectives, and unique ideas!
It’s great in theory, and it’s actually true in real life. But the trouble with becoming a generalist on your tech stack is that your actions belie your protest. You say, _nay, _scream, that you’re not a resource, but you choose your skills to optimize for maximum deployability and interchangeability with your fellow resources coworkers.
The collective culture of “real programmer” exacerbates this dynamic. When bombarded with the idea that “real” programmers use or avoid certain tools, stacks, approaches, etc., you experience natural pressure to move toward the area of greatest consensus, and thus greatest resource supply.
To put it much more plainly, “real programmer” declarations encourage you to make yourself imminently replaceable and unremarkable.
3. It Discourages Early Adoption
Commodification isn’t the only issue that arises when you find yourself drifting toward the center of the herd. Think also of the bell curve of adoption. At the center of that herd lies the fine line between “early majority” and “late majority” adoption.
I’m an old man in the programming world, and it’s about to show.
When I was a newly minted CS grad, Javascript was, well, garbage. It was a gimmick of a language, thrown together in 10 days for marketing reasons. And, back in those days, real programmers didn’t use Javascript.
I use that example because it sounds funny in retrospect. But if you think of the consensus ‘wisdom’ of the “real programmer” declarers, they’re almost invariably touting the mainstream and poo-poo-ing the bleeding edge as fads and toys. They’re screaming at you to remain risk averse in terms of adoption.
4. Collectively, It Invites Sloppy Practice
One thing I haven’t touched on very much is how contradictory the entire cloud of “real programmer” assertions is. “Real programmers don’t use IDEs, but favor text editors,” some will say. But others will counter with, “_real _programmers take full advantage of their tools and only use IDEs!”
Now that’s a pretty binary example, but others are less obviously contradictory, perhaps encouraging tools that don’t conflict but don’t play well together, or approaches that create more complexity than the sum of their parts. And the danger here is that the whole corpus of this type of internet ‘advice’ creates incoherence in your own approach if you try to synthesize it.
I once wrote about this in a short, old post about what I called the “synthesize the experts” anti-pattern. Now, imagine that conundrum, but, instead of synthesizing established experts, you’re synthesizing armchair experts, like Bobby9442 on some random Q&A forum. Your quest to be viewed as a “real” programmer has the potential to result in some collectively weird approaches to software.
5. You Risk Becoming One of Them
And, finally, consider the worst fate of all. I might argue that this particular one is worse than being discouraged out of the industry, to pursue a vocation where people aren’t so… vocally worked up all the time.
This is the fate where you become one of these “no real programmer” commentators — you become a person that spends their time arguing on the internet. And arguing on the internet is not just a complete, utter waste of your time, but a bad look, career-wise. And, it’s a doubly bad look if your arguing starts to veer into “bullying via logical fallacy.”
The Animal Farm-esque metamorphosis here isn’t as far-fetched as it seems, either. If you spend years trying to learn all the techs, adopt all of the approaches, build your “real programmer” checklist, and generally steer toward this collective ‘wisdom’, you’re investing heavily in this effort.
And, humans have a cognitive bias that causes us to defend our past decisions and investments to the point of irrationality.
Internalizing these statements will thus make you disproportionately likely to make them later. It’s the same cycle of hazing that defines college fraternities and Enterprise Silicon Valley interview processes. So internalizing the message that you’re not a real programmer will make you more likely to send that message to others, later, “for their own good.”
“Real” Isn’t a Thing in This Context
In the end, I think the most helpful thing is to adopt the mindset that “real” is literal nonsense when applied in this context. I mean, “real programmer” is something of a tautology in the sense that anyone who does any programming is a “real programmer” unless you want to get weirdly metaphysical. And, even something like “good” or “competent” has more meat as a modifier than “real,” even if those aren’t particularly helpful or objective either.
But “real” or “true” or whatever? Utterly useless.
So don’t respond to people on the internet (or in your company) that toss this around. Ignore it, let it roll off your back, and have a quiet laugh at how worked up people are getting over their own nonsense.
But, if you really can’t help yourself — if you really must respond — then I’d try this one on for size. When they say to you, “real programmers _____” respond with “real programmers don’t use the term ‘real programmer’.”
If they’re half as smart as they think they are, that self-referential statement will make their brain hurt so much they leave you alone, and go off to ponder both of your roles in an MC Escher loop of useless judgement.
Top comments (7)
What is a programmer in a professional sense?
Someone that does it as the focus of their job, with a title of "computer scientist" or "software engineer" or "developer"? Is someone in IT that uses the command line to access her routers and write scripts also a programmer? Is an accountant that writes Excel VBA scripts a programmer? Is someone that exclusively uses WYSIWYG web development tools a programmer? Is an author that writes about people who write code a programmer? Is a mathematician that writes pseudocode on paper but never enters it into a computer a programmer?
Or is a programmer simply someone that self-identifies themselves as a programmer, regardless of any actual touching of an electronic system nor writing of any code?
I suppose one could apply any of those definitions. What I was hoping to express is that there's no upside for anyone, in any of those positions, to internalize the message of "you're not a real programmer."
At best, the message would be tautological. If you tell the accountant with her macros and VBA that she's not a real programmer, because if she were, then her job title would be "programmer" and not "accountant," her response would probably be "uh, okay, I suppose you're right, but you probably didn't need to say that out loud." But, whoever is telling her that probably isn't simply a set theory buff that enjoys a little stating of the obvious, but rather someone being snide to her about what she's doing.
In the end, I think the question of "what makes someone a programmer" is an interesting one in a world where a lot of knowledge work will include at least little bits of automation. But I think the question "what makes someone a real programmer" is a much less productive one, because I don't think people using that terminology are looking for definitions as much as they are looking to feel superior to people.
First of all, "Real programmers" in xkcd is a mandatory reference for this topic.
To me is as simple as someone who write programs as a main occupation, to me you can be a programmer even if you don't earn money from it but then you're not a "professional" one.
Q:Is someone in IT that uses the command line to access her routers and write scripts also a programmer?
My A: not to me is a thing of focus, just as update my OS doesn't make me a sysadmin
Q: Is an accountant that writes Excel VBA scripts a programmer?
My A: just as before, if you develope accountaint systems yes, if you use Excel as a tool you are not a programmer just like I'm not an accountant because I manage my personal money.
Q: Is someone that exclusively uses WYSIWYG web development tools a programmer?
My A: Are you making a "program" or designing a website? if the later I would call them a designer.
Q: Is an author that writes about people who write code a programmer?
My A: Nope, s(he) is a writer
Q: Is a mathematician that writes pseudocode on paper but never enters it into a computer a programmer?
My A: Nope, pseudocode is not a computer program just like a blueprint is not a house and an architect is not a civil engineer.
To me one of the main problems with this "real programmer" is that people turns a qualitative thing in a quantitative one. Being programmer is not "better" than other profession, is just a label to describe what you do and can do. I don't call myself a lawyer being an engineer not because an lawyer is more or less that an engineer (maybe lawyer was a bad example, ew, just a joke, not sue me) is because it would be a lie, I don't do that job, and actually would be a felony in most places.
Does your IDE/text editor, make your code not run? probably not, so there is no effect in you being or not a programmer.
To play a friendly devil's advocate...
Sometimes it's good to have a bit of a 'wake up call' part-way through your career and realise that you had a really big blind-spot for a long time.
People won't necessarily tell you what you're missing. They may not be aware or they may not want to demotivate you or put you on the spot.
A big blind-spot for me was time-efficiency. It simply never occurred to me that an algorithm could get exponentially slower if its time-complexity increased disproportionately to its inputs. This actually stung me once, when writing a selector that mapped from a Redux store. So no, this isn't just theory, it can actually affect real-life development!
Still, great post, thanks for sharing!
Thanks for the kind words!
And, I wouldn't dispute anything about what you're saying here. But I feel like it'd be just as effective, or moreso, for someone to come to you and say "hey, computing Fibonacci via recursion is pretty slow -- you should read up on this O-notation thing" as opposed to "real programmers don't use recursion."
I think that latter message has little, if any benefit. It would put most people in a defensive posture, it's an oversimplification, and it's kind of a non sequitur for just about any context in which it arises. In other words, I think you can have that epiphany/wake-up call without the baggage that comes with internalizing someone's judgement.
Personally, I often have such wake-up calls stumbling through things all on my own, absent any external stimulus.
Oh, thank you for adding that Git thing. Now I can look in the mirror again...
Wow, thanks for the kind words! I'm glad if you get something out of the posts.