I wanted to write this article because I'm routinely frustrated by (what I perceive to be) the continual arrogance of "tech types" and "fanboys" who vomit opinions over their coworkers, or over the interwebs, as though they are the Arbiters of Programming Truth. And yet... here I am. Cranking out my blogs. Spewing my opinion. And ultimately, I probably give the impression that I think I know what I'm talking about.
This hits home for me occasionally when someone pings me for advice. They seek my input - as though I can really provide any "answers". Some of these people are friends or colleagues. But since I started this little Dev.to thing, I've actually had several folks reach out to me on email. With no prior introduction. And while I'm truly flattered, I also can't help but think, "You have no idea just how much I don't know."
This also hits home for me when I hear others talk about "impostor syndrome". And it'd be hard for me to truly communicate how much I hate that concept.
I mean, sure, I understand that, at times, we all have doubts. But it really bothers me to think that anyone sees themselves as not "worthy" enough or "knowledgeable" enough or "experienced" enough. It bothers me because, for most of my career, I've flaunted these norms.
I'm completely self-taught. I don't have a computer science degree (or a bachelors degree of any kind). At times, I've had to, umm... embellish my resume. I've frequently acquired skills that, for years, no one would pay me for. Many of the "fanboys" that I so-frequently deride look at me, or my code, or my "style" - and they dismiss me.
Despite all this, there are still those who think that I've somehow "arrived" - and that they are somehow "impostors". So I'm gonna try to blow that up. Right here. Right now.
I'm gonna spell out, in plain detail, the stuff that's given me fits throughout my career. I'm gonna explain the stuff that still confuses me. I'm gonna try to admit the deficiencies that a lot of other tech bloggers like myself probably don't want to admit at all.
My hope is that you'll realize that if someone like me - a dude with a quarter-century of professional experience, still has these "shortcomings", then you're probably not as much of an "impostor" as you fear. So... here goes.
Regex Syntax
Regular expressions are one of the oldest - and most powerful - tools in a programmer's toolbelt. And you absolutely need to understand the concept of regular expressions. And you need to know the use-cases where they excel.
But syntax...???
Well, listen...
Regex's are less readable than hieroglyphs. Sometimes, I find myself in a scenario where I'm writing regular expressions all the time. And I transform into Regex Man (it even comes with a cape).
But then... I might go 12-18 months without writing anything more complex than a simple [0-9] match. When I go through periods like that, and then I have to dive deeply back into the regex universe? Well... I start googling.
Every few years I find myself re-learning various bits of regex syntax. I have friends that have permanently memorized all of those intricate details. I am not that guy. And I have no problem admitting it.
"College Stuff"
I understand the concept of Big-O notation. But I couldn't honestly care less about the nitty-gritty details. Because I basically don't use it. EVER.
Look, I understand that any "senior" dev needs to grok the intrinsic complexity of his algorithms. And I fully understand that this:
for (let i = 0; i < someLimit; i++) {
for (let j = 0; j < someOtherLimit; j++) {
// do some nested logic
}
}
Already starts to feel "problematic" because of the nested (i.e., exponential) nature of the loops. But if you want me to stand at a whiteboard and slap detailed Big-O notation on a long series of algorithms? Well... yeah, good luck with that. I'll be off in the corner writing functional code while you fret over the theory.
On a similar note, it seems that every Computer Science major drops into the workplace with a ridiculous familiarity with binary tree searches. And that's... great? I mean, yeah... binary tree searches are "a thing". And sometimes they can absolutely be the "right tool for the job". But in a quarter century in this career, I've had to dive deeply into binary tree searches... ONCE. And the next time I need to use them - I'll google that shizz.
Native Language Functions
This is one of my most-visited URLs:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array
I probably hit this page several times every single day. It's not that I don't already "know" about Array.prototype functions. It's just that I still, to this day, can find it hard to grab the "right" Array.prototype function right off the top of my head. So I frequently find myself, with an array "in hand", knowing that I need to transform it in some way, and browsing over that page like it's a menu at a fine restaurant.
I also refactor my code frequently. Not, like... months or weeks or even days later. I'll often write something with say, a plain ol' .forEach() because, quite frankly, that's just the way my brain works. Then, when I have the logic working properly, I'll kinda step back and look at it and think, "Yeah... this should really be using .reduce()." And then I'll spend a few minutes refactoring it into it's "optimal" prototype function.
This trend isn't limited to JavaScript. For years I was writing a metric butt-ton (technical term) of PHP. And PHP has, approximately... 3,842 native functions. All of them have different syntaxes. Different behaviors. Different patterns. Different expected arguments. And I could write every single one of those native functions from memory. (As long as by, "from memory", you mean, "by googling that shizz".)
I've never been impressed with anyone who has memorized a particular language like the back of their hand. Good for you. You're a dictionary. That doesn't make you a problem solver.
Timed Exercises
Of course, (almost) the only time that you'll experience a timed exercise is in a job interview. And my brain has some kinda deep primeval resistance to these types of artificial hurdles. When you give me your silly little demo task, I'm almost certain that I can crush it. But then, when you give me a visual 15-minute timer, counting down in front of my face, it triggers some kinda internal meltdown in me.
The funny thing is that I'm pretty dang effective working under real-world time constraints. In rare moments, I've been "The Guy" working on a live production issue that was costing the company tens of thousands of dollars per minute. And in those scenarios... I slayed that shizz. I literally had execs looking at me in awe as my fingers flew over the keyboard.
But when you put that stupid artificial timer on me? I dunno man... my brain just kinda - rebels. And shuts down. Cuz I know that the whole exercise is just so fake.
Nomenclature Mismatches
At multiple points in my career, I've struggled with concepts that all of my colleagues had supposedly mastered. And then, after struggling with the academic concept - sometimes, for years - I finally realized that I was already doing that concept! I just didn't "grok" the terminology being used.
A great example of this is dependency injection. I dunno why, but for some reason, that term is so dang... obtuse to me. It just doesn't seem to mean, in my mind, what it actually means in the IDE.
So for a number of years, my colleagues would talk in haughty terms about dependency injection. And I'd just nod. And smile. And give them that knowing look of, "Oh, yeah! Dependency injection. I'm all about dependency injection!!" Then I'd go back and read the definition of dependency injection for the 100th time - desperately trying to import it into my brain.
The irony of this is that I'd already been doing dependency injection. For years. I just didn't realize it. What others were calling "dependency injection", I was just calling... "code". And maybe that's why I had such a hard time internalizing the concept?
Another example is closures. I even wrote, a few months ago, in response to one of my readers, that I rarely-if-ever use closures. But that statement was wrong. Very wrong. Because the simple fact is that, as a React dev, I write closures pretty much every dang day. But my definition of "closures" wasn't compatible with all of the code I was cranking out. And then I realized, "Wait... I write closures all the friggin time."
Dev-ops
I often feel like I'm alone with this. Because I have many programmer-type friends who seem to genuinely enjoy getting into all of the ancillary stuff "around" programming. They like configuring routers/servers/build-pipelines/etc. They get excited by hardware. They're very happy dealing with Linux kernels and Docker containers.
I'm incredibly... specialized in what I really want to do. I write code. I like to write code. It's not that I'm incapable of setting up your email server. But I have absolutely no desire to do it. In fact, if it's not a quick-and-dirty process that I can wrap up in a half-hour-or-so, getting everything hooked up will eventually make me annoyed.
I just wanna write my dang code. Show me where my environments are. Give me access to the required repos. And then leave me the heck alone.
Git
I've met many devs who wield their prodigious Git skills like a cudgel. They throw around all these command-line keywords and flags, and they're not very subtle about implying that, "I'm a real developer cuz I've mastered every possible command-line Git operation."
I love Git. I don't know if you can really be a "modern" dev without at least being comfortable with Git. I can happily sit at the command line and create new branches, commits, pushes, merges, etc. But Git is an intricate beast. And when I need to venture outside of the "normal", day-to-day, code-management stuff - I go back to my own cheat sheet.
I've been working on this Git cheat sheet for, oh... about five years. And it has little helper examples of all the "2nd-level" kinda operations that I typically only perform every few months or so. I know... that probably means that I'm somehow "lesser" as a dev. I don't friggin care.
Command Line / Terminal
While we're talking about command lines, there are many devs who seem to get offended at the idea of a GUI. I am not that guy. It's not that I'm impotent in a terminal, but I've never felt that my worth as a developer is tied to my knowledge of every possible grep option.
I can git pretty dang well. I can npm like a pro. I'm really comfortable in PowerShell and slightly-less-so with bash. But there are limits. And I've never felt bad because I couldn't regurgitate, from memory, a complex command line directive, with piping and flags and switches. You can master every possible command-line utility. And you'll get a free cookie. I'll spend my time mastering... code.
Tip of the Iceberg
This list isn't even close to comprehensive. If I spent another few hours thinking about it, I could easily come up with another dozen issues that have caused me fits. (Or are still causing me fits.)
My point here isn't to catalog every single one of my shortcomings as a programmer. My point is to illustrate that there's not a single person in tech who doesn't have at least some of these same handicaps.
That tech blogger you read regularly doesn't magically spit out every line of his-or-her code. They have hangups. Just like the rest of us.
I don't care if they've been coding for 50 years. There's still something that, occasionally, makes them feel like an "impostor". Which is really the just the best evidence for why none of us should ever truly feel like an "impostor".
There's more in this career field than any one person can ever learn. That's not a "fault" of the career field. It's what makes this career field absolutely friggin gorgeous.
Latest comments (93)
Great article, and thank you for sharing. I got a C.S. degree from a fantastic university, and I have the exact same thoughts as you on some of this stuff.
I took multiple classes on algorithmic theory and complexity, where we spent hours talking about Big-O, Big-Theta and Big-Something-Else-I-Don't-Remember. All I remember from those classes is how much I hated them, and how easy it was to just Google the information I needed.
The only time I've ever had to figure out the Big-O of a function since then, is in interviews. And as soon as an interviewer starts asking me about Big-O, I start to wonder if they even understand why they're asking about it, or if they just saw it on a list of "top 20 programming interview questions".
Anyway, ♥️s to you for having the self-awareness to share this article. The more I read about other people struggling with imposter syndrome, the more confident I feel in my own abilities, and the more comfortable I feel with the software ecosystem in general.
Thanks for posting this Adam.
I think the term imposter is so damaging, especially for jnr dev's & something I realised I shouldn't buy into. I hear the term used more & more and I wish more people would actually just call it what it is... doubt.
Its refreshing to hear this from a senior dev & I agree with Jordan's comment below, this is a natural response to doing something new, unknown, hard etc. The term is unhelpful & causes more anxiety when its not needed.
I'm also self-taught and don't have a university degree in anything. I'm not necessarily saying this with pride.
I feel like I've advanced so much in my career and I beat so many odds that it feels like: "this is it, more than this is over-reaching". But somehow I can't stop trying to over-reach.
I'm constantly surrounded by Engineers (I call people that actually have CS degree an engineer), and I many times feel small and ignorant. I can feel more relaxed whenever we're talking about my stuff (Frontend overall).
I use the term "Imposter Syndrome" as a way of compounding many feelings.
I have all the items in your list and more.
Right now I'm actually moving to a new position that increased my "Imposter Syndrome" level to the roof. But, at the end of the day, this term equals: doubt, fear and a long array of what-if's.
If we got here is for a reason. If we're hired and working where we are, there is a reason. And we can always push ourselves further.
Doubt keeps you alert and in check, don't let it drag you down but rather use it as a trampoline.
I relate a lot to what you are saying. Although I'm also quite a lot into the "dev-ops" part. The first reason is that I like to have a fully working project publicly available. The second is that I decided to use GNU/Linux as my personal operating system and all of these tools out there usually follow the same Unix-like spirit (more or less).
For example, git is created and maintained by Linus Torvald, the same guy behind Linux. Therefore using git is like using an Apple app on your Apple device. At some point you just feel how to use it, with the advantage of freedom and security that free/open source software provides.
I connected many dots and many things clicked in my mind since I decided to install Arch Linux as my primarily distro (as a personal and development device).
Interesting take. I like the regex-hieroglyphs comparison.
Nobody in tech knows it all. The best example I could bring up to illustrate this, is the my coworker who sits right next to me. He's a wizard. If you use Ruby for anything slightly more substantial, chances are, you've relied on at least one project he's heavily involved in. I, on the other hand, technically only finished my apprenticeship a bit over half a year ago, and while I did spend 3 years at university before that, I'm still very much "the new guy". And yet, I still get lots of questions every time CSS or JavaScript is involved, and I'm not even all that knowledgeable about those.
Everyone has to specialise in some things, and it's completely normal to just not bother with learning everything. Nobody has the time nor the brain to pull that off.
And finally: Always keep in mind that you're not being paid to "be a programmer", but for solving problems. You don't need to "be a programmer" to post articles on dev, only to have something meaningful to say. Don't try to "be" or "become" a programmer, just enjoy programming.
Absolutely! To me, programming is nothing special; you just learn a bunch of stuff and apply it, but design, that's where the real magic happens and I can only watch in amazement how some people can come up with an awesome UI design when I can't even get a button to look right without just copying something from an online template.
Wow, what a great post! I'm in the shame shoes as you :). I pretty like this thought:
"I just wanna write my dang code. Show me where my environments are. Give me access to the required repos. And then leave me the heck alone."
Thanks Adam.
@bytebodger
This article feels like I've found my spirit animal so to speak. Great work and I've always been wanting to write articles like this, but I'm very curious. Aren't you afraid that maybe some of your colleagues in your company will see it and think 'oh this is making fun of me, because I know all Git commands/regex expressions' and shake your relationship with them?
Hahaha... no. Most of the people that I interact with on a daily basis at work are pretty dang cool. And if I find myself working with someone who's not cool? And that person happens to stumble across my blogs and somehow takes offense?? Well, then... I truly couldn't care less.
I appreciate the response, and I'll take it onboard.
Nice perspective!
I agree with you on everything written in this post. I do pretty much all of you are mentioning.
Not so long ago I had similar doubts and I found out that these occur for me when there is no real challenge for me in the work. When I was doing ok but the work was simple after a few weeks or months I got this so-called impostor syndrome.
After years I learned to comprehend that I'm incomplete and always will be. And I allowed myself to fail. This raised my self-esteem much greatly and reduced these impostor feelings.
Also, some dummy project helps. Just create another React/Vue/Svelte/Node/Django whatever shit on GitHub and just spend few hours digging. Then forgot about it and go sleep happy. This makes wonders.
All it is is just beating your creativity and possibilities you perceive you can do, but not going in that direction kills you.
I relate with this post way too much. My brain does go for the "forEach" implementation and then once that's working, it'll ask me to turn that into a map -> reduce or something like that, and I guess that's just part of the process of learning to grow as a developer.
Maybe our brains will make such connections immediately, purely out of the experience one day. Maybe some people make those connections faster. Deliberate practice and not kicking yourself over that is the key to getting there I guess.
I also feel like nobody is an imposter. Everyone is learning. Everyone is at different stages of learning. And it's beautiful as long as the knowledge is shared in person or via the internet :)
This is great. I like to code, and I have felt "less than" for not being interested in dev ops type stuff. Which to me is beyond boring. Please just let me write the codes and build the thingzz.
Spot on. Ive been developing software off and on for nearly 45 years now, and i agree on all these points.
Thanks! I sometimes feel as if I started way too late in life to ever learn enough code to be employable. As a result, I get very distracted from concentrating on one language for very long, not to mention learning how to work with my server.
I appreciate your comments.