DEV Community

loading...
Cover image for I'm An Impostor

I'm An Impostor

bytebodger profile image Adam Nathaniel Davis Updated on ・9 min read

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.


Alt Text

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.


Alt Text

"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
  }
}
Enter fullscreen mode Exit fullscreen mode

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.


Alt Text

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.


Alt Text

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.



Alt Text

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."


Alt Text

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.



Alt Text

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.


Alt Text

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.


Alt Text

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.

Discussion (95)

pic
Editor guide
Collapse
jfbrennan profile image
Jordan Brennan • Edited

Imposter syndrome is a dumb idea invented by people who want to sound smart on LinkedIn. I hate it! It needs to go away.

It's called doubt. The word is "doubt" people and it's completely normal. Everyone who ever started anything hard (like a career in tech) has had doubts. To anyone wrapped up in this imposter syndrome fad:

You belong wherever you are and you will grow! So shake it off and go get it done!

Someone will always be smarter than you and unintentionally make you feel like an amateur and, in time, you will make others feel the same. It's part of the natural course of growth. Just remember to be patient with yourself now, and patient with others when they are standing where you currently are.

Btw, the MDN Array docs are like 80% of my browsing history too haha

Collapse
ashleykolodziej profile image
Ashley Kolodziej • Edited

I wouldn’t be so quick to say doubt is the only cause of these feelings. The idea behind being an “imposter” is that you’re playing a role you don’t believe you fit in. This could be from a knowledge perspective, but it could also be because you look, think, act, or come from a different background than the people around you and your role models. Or, maybe your expertise is not as “highly valued” as others. For example, my expertise is in frontend development - HTML, CSS, JavaScript - but I still hesitate to own that knowledge and call myself a frontend developer because my background is in design, and the parts of HTML, CSS, and JavaScript I am best at reflect that.

I won’t lie, I even feel out of my depth posting here. My peers at my employment level are all male, I’ve never had a female mentor or manager, and I grew up without internet access at home, so my story of growing up in web development is not the same as most others my age. I relate to a lot of this article, but I don’t think it’s because I doubt myself. I think it’s because others, whether they realize it or not, inherently doubt me, and when you live in that world, it wears you down as you simultaneously fight those assumptions while trying not to internalize them.

I just read this great article (hbr.org/2021/02/stop-telling-women...) about how imposter syndrome can be a harmful term, because it places blame on the victim for feeling those doubts, instead of addressing where the doubt comes from (unhealthy cultures, biases, etc). Over the past few years, I think we’ve done a good job bringing this experience to light and normalizing talking about the fact that it is happening. It sounds like we’re now in a good spot to move on from that and start pushing to examine why it happens in the first place, so we can reduce it.

Also, RegEx is the actual worst. I’m convinced it’s impossible to learn. I can get a handle on just about anything except RegEx.

Collapse
jfbrennan profile image
Jordan Brennan

Thanks for sharing, I'm a frontend dev too!

You know, you are very lucky to come from a design background because after a couple more years of coding you will begin to unintentionally and unknowingly make other engineers working on frontend feel out of place because you can code and design. You will make others doubt whether or not they are worthy to work on the UI since they suck at design.

I hope you are okay with this because there is NOTHING wrong with any of that. Nobody is a perfect fit. Some person or some circumstance somewhere will do or say something intentionally or unintentionally that makes you feel that way too because at every company and in every level of your career, including CEO (probably even more so!), there is going to be an inner monologue. A healthy mindset looks inward and says, "I'm not a victim. In fact, my unique challenges have only made me stronger. I don't need or want a scapegoat because I am the commander of my ship and I will get to where I want to be despite storms, pirates, or mutiny!" and then moves on. An unhealthy mindset dwells on victim doctrines like Imposter Syndrome looks externally and says, "Life is so unfair! Somebody needs to fix this for me and then I can progress."

Thread Thread
darkwiiplayer profile image
DarkWiiPlayer

after a couple more years of coding you will begin to unintentionally and unknowingly make other engineers working on frontend

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.

Collapse
mungojam profile image
Mark Adamson

On regex, if you have got the basic concept, check out regex101.com. I use it every time now.

It will break down any regex pattern into its parts and explain each bit. It also has a nice interface for testing them

Collapse
darkwiiplayer profile image
DarkWiiPlayer

I think it’s because others, whether they realize it or not, inherently doubt me

It's completely normal to doubt people until they somehow prove what they're capable of. Picking up on this doubt and internalising it might just be a bit of a self-fulfilling prophecy: you feel like everyone doubts you, so you become very careful in expressing your opinion, so the others never get to see what you're actually capable of.

Maybe this is a matter of some internalised misconceptions about what a programmer should and shouldn't be like, or maybe it's simply a matter of personality. Either way, showing others what you're good at is the only way for them to know, and to break out of the loop.

Collapse
kwstannard profile image
Kelly Stannard

You may enjoy this thing I wrote.

dev.to/kwstannard/why-not-regexp-563

Collapse
dvddpl profile image
Davide de Paolis

when 5 years ago i first read about Imposter Syndrom, i was blown away with a warming feeling of relief. now whenever i encounter someone mentioning his Imposter syndrome I ... want to puke..

as you said. it just a fad, it is just a nice wrapping of the concepts of doubts.
imposter syndrom is, well, just being aware of your shortcomings and being humble.
it's a new fancy way of the Socratic paradox "I know i know nothing"

Collapse
mungojam profile image
Mark Adamson

I'm a bit confused by the reference to it as a fad. I've heard and used it for around 10 years I think. Scott Hanselmans blogged about it around that time.

Thread Thread
dvddpl profile image
Davide de Paolis

It's not that the syndrome is a fad. The fact that everybody now has it, and has to Blog about it is. ( not referring to this post of course!).
BTW I found out of the Syndrome exactly from Scott's post, and it blew my mind.

Collapse
metalmikester profile image
Michel Renaud • Edited

I think the first time I heard of "imposter syndrome" was here on Dev.to, and I've been a member for less than two years. I've been frequenting online forums since 1988.

I agree with your use of "doubt". I've been doing this for more than 30 years and still doubt myself sometimes (it's hard to keep up in this fascinating but ever-changing field; how many new versions of this or that or new frameworks came out while I was typing this post?), but "imposter" is certainly not a word that ever came to mind.

Every single week I have this, "argh... I don't think I can solve this one" moment. Well, the number of times that was the case I can probably count on my fingers. As you said, shake it off and go get it done.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

The term does seem to have come into fashion only recently. And it's a stupid - and potentially harmful - term. Thank you for adding your perspective!

Thread Thread
tomstreeter profile image
Tom Streeter • Edited

A 1978 academic study of self doubt among 150 high-achieving women.

It’s not new. It’s not trendy. It’s not a clinical term,. It is, however, often how people react to working in environments where people are willing to spout off on things they don’t understand .

Thread Thread
steve50244 profile image
Steve Harris

It may not be new, but it has become trendy. everywhere I have looked the past few months I have seen "imposter syndrome"

Collapse
maco profile image
Mackenzie • Edited

I think of doubt as a normal thing everyone experiences and imposter syndrome as a thing that comes from having others belittle your skills over and over. The term was created specifically to talk about women's experiences because it's a product of misogyny.

Shorthand:

  • If it arises from entirely internal factors, it's just plain old doubt.
  • If it's based on external factors (eg other people always wanting a second opinion because they don't trust your opinions), it's impostor syndrome.
Collapse
jfbrennan profile image
Jordan Brennan

I have had my opinions ignored and debated by others countless times. I can accept my piece of humble pie and move on or I can look for reasons why people aren’t treating me like the center of the universe.

I have also:
Been passed up for promotion.
Had a bonus reduced.
Rejected for jobs I was 100% perfect for (or at least I thought I was).
Lost my job.
Been at a dead end job.
Sucked at my first job - big time!
Bored to death at another job.
Surrounded by people I don’t relate to (and at more than one company too).

And on and on the external factors go. All these things make me go, “Geez, I don’t know...maybe I’m not as smart as I need to be. Maybe I’m in over my head. Maybe I should start gaming so I fit in more.”

Those are called doubts. Everyone gets them and they come from all kinds of places and people. We can choose to just move on and grow or we can dwell on them and stagnate while we wait for others to fix it.

Collapse
leob profile image
leob

Spot on, the incessant "impostor syndrome" hype gets really tiresome, let's abolish it ... maybe people won't like it when you call it a fad, but I think you're right - it's just "doubt", or the simple fact that there's more that you don't know than there's what you do know - it's normal, and fine, let's stop exaggerating these things people!

Collapse
codefinity profile image
Manav Misra

Regarding browser history lookups - I have managed to reduce those a bit and have my 'go to' snippets saved in VS Code with thiscodeworks.com/user/dashboard

Regarding rest of the points, yeah, 💯. Takes time and patience.

Collapse
trenthaynes profile image
Trent Haynes

I first heard of imposter syndrome sometime around 1994. That fad is probably older than a chunk of the people on dev.to.

BTW, Imposter Syndrome !== Doubt. There is a difference.

Collapse
makeshift_name profile image
Alex Longsdale

100% agree. To many people are pushing imposter porn as I like to call it.

It is nothing new and it doesn't help people grow and get better rather they revel in it.

Collapse
emirryhn profile image
Emir

Nice perspective!

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

Beautifully said!

Collapse
christiankozalla profile image
Christian Kozalla

Your articles are most entertaining!

My 2cents on the topic: I never really knew what this "imposter" thing was all about, or why it is even a thing.

Sure, I wouldn't go through StackOverflow blindly copy&pasting everything that remotely seems to solve my problem.

But I can't feel bad for actually solving the problem after googling and reading through some docs / blog posts / tutorials / other examples.. 👍

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

Absolutely. I feel like there's this urban legend about this army of crappy coders who blindly copy-n-paste everything out of StackOverflow without understanding how any of it actually works. In reality, I've rarely witnessed this from any coder - even the most junior ones. Sure, they may search StackOverflow (we all do), but it' almost always serves as a catalyst to better understand the actual solutions that are being suggested.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

Not so much an urban legend as much more a joke that spread too much among beginners. In itself it's just self-deprecating humour among programmer. We're all aware that we have to rely on online help a lot, so it makes sense to joke about it.

In itself, this might even be a good thing: Experienced developers continuously joking about how much we all rely on looking things up sends a strong signal to beginners that this isn't a bad thing. As much as I hate the joke for how over-used it is, the message it sends, although very hyperbolic, isn't a bad one: "None of us really has a clue, so don't worry if you need to look something up".

Collapse
siddharthshyniben profile image
Siddharth

Yep. We mostly copy logic, not code.

Collapse
panditapan profile image
Pandita

aaaah you pretty much explained how I feel about being an imposter! the only difference is that I do have a degree in computer engineering but honestly? I was a little more worried in getting a boyfriend (whyyyy????) than really paying attention to class so, while I studied, passed tests, earned scholarships and even an honorable mention in my thesis... I don't remember most of the theoretical concepts I studied hahaha I'm always looking things up because I have a bad memory for these things! XD so yeah, even us with degrees have to be a bit of an impostor sometimes!

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

I have friend who decided, years after he was already an established programmer, that he should get his CS degree. And he did. And he's always told me that it was a complete waste of time and money. I think it's one of the few things he's done in his career that he'd truly take back if he could.

Not that there's anything wrong with a CS degree, of course. (Or any other degree, for that matter.) But he got absolutely no value from it. And it cost him a great deal in time-&-money.

Collapse
panditapan profile image
Pandita

aaah well I think it's because he was already an established programmer! I sorta realized mid-way through my studies that what they were doing (at least in my uni) was training my mind to solve problems in an "engineering" sorta way? I can't really explain it! It's like they already have the framework to help you get there, though I think symbolic logic is the main class that helped me understand programming in the end xD

But, if you already know how to solve problems because you're self taught, then you're not going to get value from the classes itself! you might get a bit from the connections and networking but still, you can do that much easily now with social media, conferences and such.

I did have friends in uni who did the same as your friend and honestly, they too where like "I know this already aaagh" but they found value on Fridays when the class would go out and drink hahahaha

There's also that this was in a Venezuelan university that was very acce$$ible at the time. I think I paid very little for my degree compared to other universities, I got a scholarship for 80% or a bit less on my last three semesters (if you were the top student of the semester the next one is free! met a girl who only paid for her first semester only, afterwards all free) so for these friends, they didn't really see it as a money investment, rather an investment that helped open up opportunities for them in the market since Venezuela value degrees a lot. I think that nowadays the uni is a lot more expensive due to situations.

But yeah, I don't regret getting my degree because it helped me be the programmer I currently am, but I also understand that it's not life changing for those who are already established programmers, unless you studied in a very prestigious university (not my case) :3

Collapse
darkwiiplayer profile image
DarkWiiPlayer

I "wasted" three years of my life at university without getting a degree. I'm still disappointed that I could count on one hand the useful things I learned from university, yet figured out countless things on my own that have ended up being much more useful. During those years I learned to use Git, to set up a linux server, a whole lot of programming concepts, how the internet works (I'm basicalle "the CSS guy" at my company now, whenever some web-related task comes up every few months), and the list goes on and on and on. All of this from home and on my own.

Every now and then I wonder if I should get a proper degree just to have that piece of paper that says "This guy's cool", but every time I quickly conclude that, even though to others a degree might lend me more credibility, to me it would be worth its weight in toilet paper.

I wouldn't discourage anybody from getting a degree if that's what they want to do, but I just refuse to treat anybody who has one as inherently more competent.

Collapse
pelayomendez profile image
Pelayo Méndez

I agree 200% with all your conclusions. I specially don't understand the timed exercises. Work interviews had changed dramatically in the last 20 years. They fell like exams. I bet you that many developers that have been successfully performing their job for years in the same company, would fail in an interview for that same position today.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

YES! I know this to be true. During in-person interviews, I've seen one of our guys absolutely stump some candidate on the whiteboard with a very tough question. Then I've posed that exact same question to our existing employees who weren't in the room, and watched as they struggled to answer it. And the effect is only magnified when you throw that ominous countdown timer into the whole equation.

Collapse
d4vev profile image
David Vincent-West

I bet you that many developers that have been successfully performing their job for years in the same company, would fail in an interview for that same position today.

I think this is where someone would chime in with a comment about the time the developer of Homebrew applied and got rejected for a job at Google.

Collapse
webketje profile image
webketje • Edited

@bytebodger this article resonates a lot with me, especially the parts on timed exercises, nomenclature mismatches and dev-ops. In my exp. being allowed to focus on code instead of "meta-code" (pipelines, routing etc.) has become a luxury though, and I reluctantly dived into a lot of it because the industry expects non-junior devs to be full-stack at least to some extent.

From the part on "Nomenclature mismatches", is it safe to suppose that you are in big part self-taught? I've witnessed such between uni grads & self-taught (=me) devs. The former learn the concepts upfront, the latter by encountering them in existing code.
I find that React is also responsible for a lot of 'nomenclature confusion', as the React team loves to re-appropriate/ repurpose patterns and name them differently, which tricks devs into believing it is something unique to React. I wonder how many devs are aware that HOC's are higher order funcs, and "render props" are just callbacks that happen to return DOM elements. I don't know who chose to call it Hooks in React, but it doesn't conform to what is understood under Hooking in programming at all.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

the React team loves to re-appropriate/ repurpose patterns and name them differently

This isn't a unique problem to react though; a similar thing is the concept of "tree shaking", and how it tricks many beginners into thinking this is some super-high-tech thing that's unique to javascript, when in reality, dead code elimination has been around since forever.

Everywhere you look, developers make up new names for known tools or use known names for different tools. Sometimes they even do both at the same time (aka. they get their terminology wrong).

This definitely doesn't make IT easier to navigate for newcomers and self-taught people, but to a large extent we could counteract it by spending a bit more time clarifying our use of terminology when we explain concepts.

Also, obligatory: "a monad is a monoid in the category of endofunctors, what's the problem?"

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

The former learn the concepts upfront, the latter by encountering them in existing code.

Bingo. Whenever I'm introduced to a new concept in coding, I'm inevitably confronted with some sort of online documentation. And that's great. So I read through it for about... 30 minutes. That's usually sufficient to give me a (very high level) understanding of what the concept does. But if I'm to truly learn the concept, I need to quickly transition into trying to play with it. I gotta install the package or try to use it in some existing code. I have to find a way to make it useful. Because, if I don't, it just sits in my brain as some sort of esoteric, abstract concept.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author • Edited

In my exp. being allowed to focus on code instead of "meta-code" (pipelines, routing etc.) has become a luxury though, and I reluctantly dived into a lot of it because the industry expects non-junior devs to be full-stack at least to some extent.

That's an interesting point. I've actually never understood "full-stack" to necessarily include devops-kinda stuff. Like... I can do frontend (many different JS frameworks) and backend scripting (Node, PHP, VB.NET, etc.), and compiled languages (Java & C#), and I'm really solid with all flavors of SQL. And I've always considered this to be "full-stack".

But I do agree that it can be a luxury to only focus on code. At a certain point, if you're really an experienced dev, it's inevitable that someone's gonna want you to set up these pipelines, or that monitoring package, or this server, or that AWS configuration. And... I can do that. And sometimes I do , indeed, do that. I just... don't like it much. And I'm not terribly efficient at it, because I don't have much interest in learning all the crazy details of each environment and their various tools.

For example, I have a friend who's, like, Captain Docker (nee Kubernetes Man). I have Docker running. And I can spin up a new container and configure it. But you can really get into the weeds on that stuff. And I really hate when I get sucked into the weeds on that stuff.

Collapse
webketje profile image
webketje

I think the definition of full-stack is relative to being able to set up an app/ tool/ site from A-Z (or from D-Z, depending on what responsibilities the team has). So in a team that manages a Drupal website (front-and backend) on their server but whose connection is proxied through a Varnish server and connects to an externally managed DB, full-stack would be: Linux, Apache, deploy pipelines, PHP, Drupal & front-end.

In a team that manages a bigger-scale Java-backend SaaS, the "full-stack" might include: Linux, ansible, server monitoring tools, database & cache mgmt, and ofc front-end. I know it is common for these responsibilities to be split up at larger scale, but in my current project for example, I am expected to work on all of: frontend (React, SCSS, storybook), Git pipelines, NPM mgmt, Linux (bash, deploys, processes), ansible, Redis, Node (express). It doesn't include database but I would still consider it full-stack.

Thread Thread
bytebodger profile image
Adam Nathaniel Davis Author

Yeah, I don't disagree with you, although I think the "definition" is a bit fluid from one job, and one environment, to another. The first time I ever heard the word "stack" used in a tech context was with regard to the LAMP "stack". I'm not a Linux or Apache guru, but I'm definitely comfortable grepping around in Linux and I've done a lot with regard to Apache installations and configurations. And I've, for many years, been extremely comfortable with PHP and MySQL. So, from my perspective, I'm a dev who's very competent in that particular "full stack". I wouldn't tell someone with strong experience in each of the LAMP components that they're not "full stack" just because they don't have, say... Kubernetes experience - although I realize that in some environments, the LAMP stack would absolutely be used in conjunction with Kubernetes.

I've long since gone on to become quite comfortable in other "stacks" - which I often see annotated as A) operating system/environment, B) web/application server, C) programming language, and D) data access language/method. In more recent times, I've been very heavily into the "full" MEAN/MERN stacks. But "MEAN" and "MERN" don't really say much about how the app is hosted or deployed.

As you pointed out, I think the key is that, at larger scales, the entire app pipeline gets split up between teams. At one job, I was working on jQuery/Angular/React on the frontend and on Java/Oracle on the backend. And all of the web services (that I was writing) were required to go through a broker called DataPower (from IBM). I had absolutely no expertise in DataPower. Nor did I need to (or want to), because that was all handled explicitly by a separate team. In that paradigm, DataPower was a critical part of the application infrastructure, that I suppose you could define as being part of the "stack". But I don't think it'd be accurate to say that I wasn't a "full stack" developer there, just because the DataPower aspect was a black box (to me).

Again, I know this is all kinda semantic. I just think it's interesting to ponder the different ways that we all define these terms in our particular environments/experiences. It's useful for me to be more cognizant of these terms because I realize that sometimes, when I say something like "full stack", someone else understands it very differently.

Collapse
jmau111 profile image
Julien Maury

A huge part of the job consists of learning new things. Even if you don't know it yet, you can learn it.

The key is efficiency, whether you use command lines or not.

For example, if you don't use a GUI to resolve git conflicts, you are probably doing it wrong, but command lines are sometimes mandatory to solve specific issues.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

This is a great point. I will admit that, in the past, with certain tools that have command line interfaces and GUI interfaces, I have sometimes spent too much time trying to figure out how to do something through the GUI when I could've just done it with one or two terminal commands. But I didn't do it because the command line syntax felt obtuse to me, and I was resistant to learn it. But I would've solved the problem faster if I was not so stubborn (because I usually ended up having to complete the task... by doing it in the terminal anyway). In other words, my "sin" was not that I wasn't already adept at the command line. My "sin" was that I was stubborn and thus, I was working inefficiently.

With nearly any class of problem, I'm not so much concerned with whether you've already memorized how to fix it. I'm much more concerned with whether you know where-and-how to search for the answers (cuz that, in itself, is a skill). Noobs will burn a lotta time randomly clicking through poorly-focused google searches. For seasoned pros, even when they don't already have the solution in mind, they can leverage the internet as something like the 3rd lobe of their brain.

Collapse
jmau111 profile image
Julien Maury

I agree with you, you have to learn how to learn and learn how to search. With experience, things get more intuitive, even when you're not in your comfort zone.

Collapse
webketje profile image
webketje

Some examples where command-line is more interesting to invest in:

  • Changing environment/ tools. If you're consultant learning command line pays off way better than using a GUI (company A requires everyone use IntelliJ, company B Visual Code)
  • No local development possible, no TTY on remote server: you can only use command-line.
Collapse
bytebodger profile image
Adam Nathaniel Davis Author

If you're consultant learning command line pays off way better than using a GUI (company A requires everyone use IntelliJ, company B Visual Code)

I totally understand this point - although... my "answer" to this has been to not even consider opportunities anymore where the employer tries to dictate my toolset. I've had people contact me about Java opportunities, and then they tell me that, "The whole team is standardized on Eclipse." And... that's the end of the discussion for me.

I know that everyone doesn't have the same luxury. But I've actually run into this and I think it's borderline insane. After wrestling for years with Eclipse, and then seeing the night-and-day difference in writing Java in IntelliJ, I'm simply never writing another line of Java code in Eclipse again. If the employer thinks it's critical that I use the same IDE as everyone else on the team, then I am definitely not a good fit for that employer.

All that being said, I know that my little retort here is a diversion - and your central point is understood, and solid.

Thread Thread
darkwiiplayer profile image
DarkWiiPlayer

If the employer thinks it's critical that I use the same IDE as everyone else on the team

Then the employer is probably wondering why none of the top applicants end up taking the job and always end up picking the other company where the boss isn't micro-managing what socks they wear on thursdays.

Collapse
paulmajor profile image
paul

"...You're a dictionary. That doesn't make you a problem solver." -- This right here.

The static around what you need to know to provide value to the private sector is painfully misleading. We all have our eyes on a handful of online resources (you thought of all of them as you read this article), and there's nothing wrong with that. You are adding value when you come into a company and start solving problems for them.

Spoiler/hot-take alert: with some exceptions, of course, they don't care how you do it.

I'm not advocating bad practices, I'm advocating no one be discouraged by what you're told you need to know. Being able to think-through-a-problem, communicate, and work well with others goes a lot further than having a single snippet of any programming language memorized.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

I love that "hot take". Too many times, the interviewer/screener cares about all that nitpicky detail because they're just trying to find a way to logically eliminate candidates until they're left with only one. But your employer probably couldn't care less if you use async/await or .then()/.catch() (or 1000 other nitpicky possibilities about how to write an app).

Collapse
bytebodger profile image
Adam Nathaniel Davis Author • Edited

One more note on this:

I'm sure you already get where I'm coming from, but it's not as if being a "dictionary" is a bad thing. Some of the sharpest coders I knew where guys who had vast swaths of minutiae memorized. But people so often fail to appreciate the difference between correlation and causation.

Those super-sharp coders weren't amazing code jockeys because they had memorized all that crap. They managed to memorize all that crap - over a span of years - as a side-effect of the fact that they're amazing coders. But just having everything memorized doesn't make you a good coder.

It's kinda like chess. The grandmaster have tons of openings memorized. But they're not grandmasters because they've memorized those openings. The opening memorization came as a side effect on the road to becoming a grandmaster. If you were trying to evaluate the skills of an unknown chess player, it would be silly to just quiz them on their knowledge of openings. I've actually met numerous very-low-level chess players who have an impressive command of openings... but they're still very weak chess players.

Collapse
arealsamurai profile image
An actual, Real Samurai

@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?

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

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.

Collapse
arealsamurai profile image
An actual, Real Samurai

I appreciate the response, and I'll take it onboard.

Collapse
sebring profile image
J. G. Sebring

You can easily spot experience not by that they use Google but how they google. "mdn reduce" or rather clicks around w3schools looking for a way to solve the problem. Jokes! Kind of..

Good post, could relate allot!

Collapse
leob profile image
leob

Haha this is so true, just brilliant ... I think EXACTLY the same about all of the items or topics that you mentioned, I mean, every single one of them! The idea that you "should" master every subtlety of regex, that you "must" know every frigging command like option of git, etcetera, or you're not a "real" dev - that's so pedantic ...

Collapse
valkn0t profile image
Thomas Shallenberger

I loved every single point, except the section on DevOps; however, although I believe I am a very versatile, experienced developer, I love the fact that I can scaffold a prototype application with a continuous deployment pipeline that I can just keep rolling updates out to, and never need to worry about regressions (as long as tests hold), or config issues, or server maintenance, etc.
Basic DevOps introduced a peace of mind that I hadn't known before, by eliminating virtually all the stress that went into a deployment to production servers.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

I totally understand this. The truth is that I kinda sorta want to be better at the whole devops side of things. But when I get stuck on something, it's more frustrating than when I get stuck on code. With code, I'm like a bulldog, wanting to fight through it. With devops stuff, when things just won't line up properly, I find myself getting exasperated faster.

But you're absolutely correct that it's valuable knowledge that can give you much peace of mind.

Collapse
riccardop87 profile image
Riccardo Polacci

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.

Collapse
technoglot profile image
Amelia Vieira Rosado

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.

LMAO! Apply ice to the burned area! 😂

Awesome rant by the way! 👏🏻 I could not help but be reminded of all the tech fanatics in this field.

Collapse
bidetaggle profile image
bidetaggle

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).

Collapse
san00 profile image
Osania - sancodes

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.

Collapse
dmahely profile image
Doaa Mahely

Love your writing, Adam!

Collapse
bytebodger profile image
Collapse
saunved profile image
Saunved

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 :)

Collapse
darkeye123 profile image
Matej Leško

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.

Collapse
steve50244 profile image
Steve Harris

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.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

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.

Collapse
bpkinez profile image
Branislav Petrović

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.

Collapse
antmik profile image
Anton

Adam,

Each of your articles is a great pleasure to read. You are one of the first who talks about struggles of self taught programmers.
Major part are trying to hide the fact they don't have a degree.

Regarding the interviews and technical tests you are absolutely right. Usually they are so much disconnected with the real work.

However usually this is the way companies hire and test candidates. May I ask what is your strategy to overcome those barriers? Do you search only the specific type companies or you have a way to hack this "matrix"?

Collapse
cariehl profile image
Cooper Riehl

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.

Collapse
realityexpander profile image
Chris Athanas

Spot on. Ive been developing software off and on for nearly 45 years now, and i agree on all these points.

Collapse
nefomemes profile image
Nefomemes

The title... oh no

'nam flashbacks

Collapse
isaachagoel profile image
Isaac Hagoel

The irony here is that once one admits to having gaps around topic/skill x or y, they are no longer an imposter in relation to it

Collapse
bytebodger profile image
Collapse
dvddpl profile image
Davide de Paolis

Oh, Adam. you have no idea how much I can relate to your posts. sometimes I even get pissed, because in my drafts I must have bits and pieces of similar rants, that now I have to throw away..
:-)

Collapse
bytebodger profile image
Collapse
biffbaff64 profile image
Richard Ikin

You sound exactly like myself, even down to being self taught.

Collapse
codesomething profile image
Code Something

Interesting take. I like the regex-hieroglyphs comparison.

Collapse
juanfrank77 profile image
Juan F Gonzalez

Join the club. I'm an Impostor too masquerading as a web engineer.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

We all have many masks! 😁 😁 😁