I'm An Impostor
Tags: javascript, webdev, career, programming
Published: 2021-04-15 07:19:51

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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k5zgoddv6pkqd9pasggg.png)
## 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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yc43bxj0g58ilh65vvjw.jpg)
## "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:

```javascript
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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y25oihsdsocjzejr8qgc.png)
## 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_.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/84amgjyf25ea916c5al5.jpg)
## 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_.   
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rrt1g9ke6eongy9h0pxr.jpg)
## 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_."
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kqvbhuxduzfk9jk7tbcq.png)
## 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.  
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jywj51uqgbzr4uy8c41v.jpeg)
## 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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ju0lctwxquwtily9vqzs.jpeg)
## 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_.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f4fyl5tk9rf2m5jpgtnb.jpg)
## 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_.