Experienced Developers and Impostor Syndrome


Summary

In this episode of Developer Tea, host Jonathan Cottrell addresses a common but often unspoken issue among experienced programmers: impostor syndrome. He challenges the assumption that this feeling is exclusive to beginners, arguing that seasoned developers frequently grapple with self-doubt despite their accumulated knowledge and skills.

Cottrell introduces a central metaphor to explain this phenomenon: the difference between acceleration and velocity. He explains that as a beginner, a developer experiences high acceleration—a rapid, tangible rate of learning new information. This feeling of progress is powerful. In contrast, an experienced developer often operates at a high velocity (speed) but with low acceleration, solving familiar problems without the same palpable sense of growth. Without external references, it becomes difficult to perceive one’s own high speed and competency, leading to feelings of being an impostor.

The host then outlines four key strategies to combat this perspective problem. First, learn to recognize your own speed by finding an external reference, such as mentoring a junior developer. This act reveals the depth of knowledge you now take for granted. Second, become a beginner again in a completely different field (like ballet, as Kent Beck did) to regain perspective on your fluidity and skill in programming.

Third, take regular, complete breaks from programming work to mentally evacuate. Re-entering the intense focus required for development after a break underscores the depth of skill involved. Finally, try to describe what you do to a non-programmer or write down every tool and skill you’ve honed. This exercise forces you to articulate fundamental concepts, making the vast body of your acquired knowledge visible and concrete, thereby validating your experience.


Recommendations

Concepts

  • Dunning-Kruger Effect — Briefly referenced as being similar to the overconfidence beginners can feel during high acceleration, where they perceive they are learning faster than they actually are.

People

  • Kent Beck — Mentioned as an example of someone who became a beginner again by taking up ballet, which is suggested as a strategy to regain perspective on one’s programming skills.

Services

  • Linode — The episode’s sponsor. A cloud hosting provider offering instant SSD Linux server deployment, eight data center locations, plans starting at 20 credit for listeners (code: DEVELOPERTEA20).

Topic Timeline

  • 00:00:00Introduction to Impostor Syndrome in Experienced Programmers — Jonathan Cottrell introduces the episode’s topic: impostor syndrome isn’t just for beginners. He shares that many experienced programmers, including himself, still experience this feeling. He promises to explain a primary factor causing it and provide tips for escaping it.
  • 00:01:56The Core Metaphor: Acceleration vs. Velocity — Cottrell introduces the central framework for understanding impostor syndrome: acceleration versus velocity. He uses the analogy of driving a car, explaining that beginners feel the strong sensation of acceleration (learning quickly), while experienced developers operate at a high but constant velocity (solving problems proficiently). Without the feeling of change, it’s hard to perceive one’s own speed without external references.
  • 00:06:07Sponsor Break: Linode Cloud Hosting — A sponsored segment for Linode, a cloud hosting provider. Details include instant SSD server deployment, choice of Linux distributions, eight data centers, plans starting at 20 credit for listeners using the code DEVELOPERTEA20.
  • 00:08:06Revisiting the Acceleration-Velocity Dichotomy — Returning from the break, Cottrell reiterates how the lack of acceleration (learning new things) at a high level of proficiency can lead experienced developers to question their skills and expertise, feeding impostor syndrome.
  • 00:09:36Tip 1: Recognize Your Speed & Find External Reference — The first strategy is to learn to recognize your own speed. If it’s difficult, find an external reference. Cottrell suggests mentoring a young developer. This process reminds you of the foundational steps and complex concepts you’ve mastered, which have become muscle memory, thereby validating your expertise.
  • 00:11:38Tip 2: Become a Beginner Again Yourself — The second tip is to intentionally become a beginner at something unrelated to programming, like Kent Beck learning ballet. Experiencing the jarring feeling of true inexperience in a new domain helps you regain perspective on your fluency and competence in your primary craft when you return to it.
  • 00:13:10Tip 3: Take Regular Breaks for Mental Evacuation — The third strategy is to take regular, complete breaks from programming work—a ‘mental evacuation.’ Stepping away and then re-engaging with the deep focus required for development helps you appreciate the intensity and skill involved, reminding you of the depth of your acquired skill set.
  • 00:14:39Tip 4: Describe Your Work to a Non-Programmer — The final tip is to describe what you do to a non-programmer friend or write down every tool and skill you’ve honed. This exercise forces you to break down your craft to its fundamental elements, making the extensive body of knowledge you possess visible and concrete, which serves as proof of your experience.
  • 00:16:14Conclusion: All Tips Are About Regaining Perspective — Cottrell concludes by emphasizing that all four tips are about resetting your perspective, not objectively measuring output. They are designed to help you internally recognize and reinforce the reality of your skills and experience, combating the subjective feeling of being an impostor.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2016-03-25T07:00:00Z
  • Duration: 00:18:23

References


Podcast Info


Transcript

[00:00:00] Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell. And in today’s

[00:00:07] episode, I’m going to be talking to you about imposter syndrome, and when experienced programmers

[00:00:13] actually go through imposter syndrome. If you are an experienced programmer, it’s likely

[00:00:20] that at some point you’ve had this feeling. And it’s very likely that that happened early

[00:00:26] in your career as a programmer. Often as experienced programmers, that’s what we would

[00:00:32] expect. We expect imposter syndrome to be associated with young developers, with being

[00:00:37] a beginner, and maybe just beyond a beginner level. Maybe the first time you get a job

[00:00:44] and you walk in to a group of programmers, maybe that’s when you experience imposter

[00:00:49] syndrome. And we like to think that we’re over that. As experienced programmers, we

[00:00:54] like to think that we’ve gotten past that.

[00:00:56] This feeling that maybe we don’t really know what’s going on. But I know for myself that

[00:01:02] that’s actually not true. And in fact, I’ve had conversations recently that validate that

[00:01:07] with other experienced programmers that I know. So I’m going to give you today what

[00:01:13] I believe to be one of the primary factors that causes a feeling of imposter syndrome

[00:01:18] in experienced programmers. And then I want to give you a few tips for how to escape imposter

[00:01:24] syndrome as an experienced programmer.

[00:01:26] But today’s episode is sponsored by Linode. We’re going to talk more about what Linode

[00:01:31] has to offer for developers later on in the episode. If you are looking for a cloud hosting

[00:01:37] provider, specifically if you run Linux, Linode may be the perfect answer for your situation.

[00:01:46] So we’re going to talk more about what Linode has to offer for developer T listeners later

[00:01:50] on in the episode. But first, I want to talk to you about that primary factor, that main

[00:01:56] primary factor. In my opinion, it’s more of a description of how this occurs in experienced

[00:02:04] programmers. And we’re going to frame it through the concept of acceleration versus velocity.

[00:02:11] Acceleration versus velocity. So the concept of acceleration versus velocity is one that is

[00:02:18] probably familiar to most of you, especially if you have your driver’s license, for example.

[00:02:24] When you’re accelerating, for example, you’re going to have to have a driver’s license.

[00:02:26] When you’re accelerating in a car, you are experiencing a rate of change. Let’s say you’re

[00:02:32] going from zero to 60. You are accelerating because you’re actually going from zero miles

[00:02:38] an hour to one mile an hour to two miles an hour. And that change is increasing. Your speed is

[00:02:46] increasing over time and you have a rate of change. And you can feel that acceleration typically,

[00:02:52] especially if you are accelerating relatively quickly.

[00:02:56] In fact, the feeling of acceleration can be so strong in the beginning that you perceive that

[00:03:02] you’re going much faster than you actually are. And the same is true for beginner programmers.

[00:03:09] You may perceive that you are learning a lot of information very quickly. And where this can come

[00:03:15] back and bite you, this is just kind of a bonus point here, and where this can come back and bite

[00:03:20] you is if you become overconfident, right? If you become overconfident that you are actually

[00:03:26] moving along faster than you actually are, and that you can do more than you can actually do.

[00:03:32] Now, if this sounds familiar to you, this is similar to the Dunning-Kruger effect,

[00:03:36] which we’ve discussed on the show in the past. So we aren’t going to go in depth there, but

[00:03:40] the same kind of concept, the shape is applicable here. But if you’re not talking about acceleration

[00:03:48] and instead you’re talking about speed, well, speed has no rate of change. At a constant speed,

[00:03:56] 60 miles per hour or 6,000 miles per hour, the rate of change is zero. And here’s the important

[00:04:02] part. When the rate of change is zero, it is difficult to know how fast you are going without

[00:04:09] external references. Let me say that again. When the rate of change is zero, unlike when you’re

[00:04:15] accelerating and you can feel the speed, it feels like progress. And when the rate of change is zero,

[00:04:23] no matter if you’re going 60 miles per hour or 6,000 miles per hour, the rate of change is zero.

[00:04:26] It is difficult to know how fast you are going without external references. Now, as is true in a

[00:04:34] car, you cannot let your foot off the gas and expect to maintain the same speed. To maintain

[00:04:40] speed, you must expend some kind of energy. In fact, if you let your foot off the gas, it’s the

[00:04:47] same as if you were doing the opposite of learning. You’re falling behind. So what does this have to

[00:04:53] do with development?

[00:04:56] I’m not giving you a driving lesson here, and I’m not giving you a physics lesson either.

[00:04:59] As a young developer, though your speed may be very low, your acceleration is likely very high.

[00:05:07] You’re learning brand new information, and typically that is happening fairly quickly.

[00:05:12] New information that you have had no experience with in the past. And that rate of change is

[00:05:18] powerful. It’s tangible. You can tell that you are learning and you’re moving quickly.

[00:05:23] Now, for an experienced developer,

[00:05:25] you’re most likely solving similar problems on a regular basis. This is common for most

[00:05:30] development jobs. So your rate of change has decreased, and you don’t have much of a reference

[00:05:36] outside of your current situation to see that you are actually moving along at a relatively quick

[00:05:43] pace. That you do indeed have powerful and valuable skills. That you’re still solving

[00:05:48] problems at a regular interval, at a regular rate. So how can we avoid this feeling? This feeling of

[00:05:54] maybe I’m at a high speed. Maybe I do have a lot of value that I’m adding, but I can’t really feel

[00:06:01] it. I don’t feel that powerful feeling of acceleration. Well, we’re going to take a

[00:06:07] quick sponsor break, and then I’m going to come back and give you some strategies for reversing

[00:06:12] this feeling of imposter syndrome as an experienced programmer, specifically if it is caused by this

[00:06:18] dichotomy between acceleration and velocity.

[00:06:24] With Linode, you can instantly deploy and manage an SSD server in the Linode cloud.

[00:06:30] You can get a server running in just a few seconds with your choice of Linux distribution,

[00:06:35] resources, and node location. They have eight data centers for these node locations,

[00:06:40] and their plans start at only $10 a month. On top of that, you get hourly billing with a monthly cap

[00:06:46] on all of the plans and add-on services. Services like backups, node balancers, and long view.

[00:06:53] You can even have

[00:06:54] VMs for full control. You can log in as root. You can run Docker containers, encrypted disks, VPNs,

[00:07:02] or maybe you want to run a private Git server. These are all things you can do with Linode.

[00:07:07] They also have native SSD storage if you’re worried about speed. And on top of that,

[00:07:12] a 40 gigabit network and Intel E5 processors. Now, if you end up trying out Linode and you

[00:07:20] don’t like it, they have a seven-day money-back guarantee. So there’s really no good reason not

[00:07:24] to try Linode. They have a seven-day money-back guarantee. So there’s really no good reason not

[00:07:24] to try Linode. They have a seven-day money-back guarantee. So there’s really no good reason not

[00:07:24] to try it. But there is another great reason to check out Linode today. And that is, Linode is

[00:07:31] providing you a $20 credit simply for using the code DEVELOPERT20 at checkout. DEVELOPERT20. And

[00:07:40] you can go directly to the link linode.com slash DEVELOPERT and that coupon will be automatically

[00:07:47] applied to your cart. So all of that will be in the show notes, of course. And again, thank you

[00:07:53] so much to Linode.

[00:07:54] for sponsoring today’s episode of Developer T. And again, that promo code is DEVELOPERT20.

[00:08:01] As always, that code and the links will be in the show notes at spec.fm.

[00:08:06] So we’re talking about imposter syndrome and how imposter syndrome relates to experienced

[00:08:12] programmers, how it shows up in experienced programmers. And I told you that the primary

[00:08:17] kind of driving factor, in my opinion, is this dichotomy between acceleration and velocity. When

[00:08:24] you’re a young programmer, you’re not going to be able to do a lot of things. You’re not going to

[00:08:24] be able to do a lot of things. You’re not going to be able to do a lot of things. You’re not going

[00:08:25] to be able to do a lot of things. You’re not going to be able to do a lot of things. You’re not going

[00:08:25] You’re moving very quickly, but you’ve gone from knowing almost nothing at all about programming

[00:08:30] to knowing enough to build something, enough to see something in action, to actually create

[00:08:37] something with code. And that change, that acceleration is powerful. But when you are an

[00:08:43] experienced programmer, there’s a lot of things that may become somewhat monotonous and you may

[00:08:48] not necessarily be learning quite at the rate that you were as a beginner. And this feeling of,

[00:08:54] maybe being at a high speed, a high proficiency level, but not changing very much,

[00:09:01] you aren’t really experiencing that acceleration that you felt when you were younger in your

[00:09:07] career. So this feeling, this dichotomy can cause this sense of imposter syndrome of questioning,

[00:09:14] am I really a good enough programmer to call myself a good programmer? Am I good enough to

[00:09:20] say that I’m experienced or to put on a resume that I’m an expert? So these are all the feelings

[00:09:26] that may creep in if you’re an experienced programmer, but you don’t have that high

[00:09:31] velocity of learning. So I want to give you a few tips for kind of avoiding this feeling

[00:09:36] when you’re at a high speed, when you are indeed a good programmer. Number one, learn to recognize

[00:09:43] your own speed. And if it’s difficult to see for yourself, find an external reference.

[00:09:50] Learn to recognize your own speed. And if it’s difficult to see for yourself,

[00:09:55] find an external reference. So if you’ve ever been in a car that is traveling at 100 miles an hour,

[00:10:02] or let’s say an airplane, this is a really common one, that’s traveling 700 miles an hour,

[00:10:08] 600 miles an hour. If you’ve ever been in that situation and you haven’t been looking outside

[00:10:14] for a while, it may feel like the airplane is sitting still in the air.

[00:10:20] I do this all the time when I go on flights across the country. Of course,

[00:10:24] we’re flying very fast and sometimes we’re flying in the clouds or flying at night,

[00:10:28] and there’s no external references. And it’s difficult to know just how fast we are going

[00:10:34] without that external reference. In fact, it’s so difficult that you can quite literally

[00:10:39] fall asleep and not know the difference. So this is key. If you involve yourself in the process

[00:10:46] of teaching a new developer, teaching,

[00:10:50] a new developer, this gives you an external reference for your own competencies.

[00:10:57] This isn’t intended to show you how much better you are or more equipped you are,

[00:11:02] but instead to remind you of the work it took to get to where you are now.

[00:11:08] If you mentor a young developer, you’re going to see all of these steps that you may have totally

[00:11:13] forgotten. You’re going to show them some of the concepts that may have become almost muscle memory

[00:11:20] and it may give you that reference that you need to remember, hey, wait a second. I do know a lot

[00:11:26] about this subject. It’s just buried. It’s just become an automatic thing for me. Okay. So learn

[00:11:32] to recognize your own speed. And if it’s difficult to see for yourself, find an external reference.

[00:11:38] For example, teach a young developer. Number two, become a beginner again yourself.

[00:11:45] Become a beginner again yourself. This is actually advice that,

[00:11:50] I’m kind of stealing from Kent Beck, but becoming a beginner at something,

[00:11:55] choose something other than programming, regardless of what it is. For example,

[00:11:59] Kent Beck became a, he did some ballet. Becoming a beginner again yourself

[00:12:07] reminds you of what it feels like to be non-fluid, to be in that kind of awkward stage where you’re

[00:12:15] learning and you’re trying to figure something out. When you experience the jarring feeling of

[00:12:19] being truly inexperienced, it may help you regain perspective of your stronger competencies.

[00:12:27] When you experience the jarring feeling of becoming truly inexperienced, of being truly

[00:12:33] inexperienced, it may help you regain the perspective of your stronger competencies.

[00:12:38] When you go back to programming from your ballet classes, for example, you may recognize once again,

[00:12:46] oh, okay, this is, I am actually good at this.

[00:12:49] It comes fluid to me. This experience has paid off.

[00:12:54] So I have two more very quick tips, and that will round out today’s episode.

[00:12:59] Number one was learn to recognize your own speed and find an external reference. Number two,

[00:13:04] become a beginner again yourself. And number three is take regular breaks that force you to

[00:13:10] remove yourself from the context of your work. I like to call this total shutdown or mental

[00:13:16] evacuation. On a regular basis, it’s important that you take a break from your work.

[00:13:19] It’s important that you totally remove your energy from programming, even if only for a few hours.

[00:13:25] This simple step of unwinding may help you gain new perspective on just how much energy you focus

[00:13:32] and how much you actually devote to the craft of programming.

[00:13:36] It helps remind you of the depth of the skill set you have acquired.

[00:13:41] If you climb out of the hole of programming, if you remove your mind, evacuate your mind

[00:13:47] from that really intense,

[00:13:49] process of programming, when you re-enter it, you realize how much and how deep it takes your brain,

[00:13:58] how much that work requires intense focus. And once again, this is going to underscore

[00:14:03] all of that work that you have done in the past to get you to the place where you can do that,

[00:14:10] especially on a regular basis. It takes a lot of skill and a lot of focus to be able to be

[00:14:15] an experienced programmer, an expert programmer. So aside from the fact that taking breaks is good

[00:14:21] for you, it’s just good for your health to not always be working. We’re kind of ignoring that

[00:14:26] all of those other pieces of the puzzle there. But on top of those things, it will remind you

[00:14:32] of how deep that work actually is. And the last tip that I have for you today

[00:14:39] is to try and describe what you do to a non-programmer friend,

[00:14:43] or maybe write down what you do to a non-programmer friend.

[00:14:45] Write down every tool and skill you’ve honed as a developer. In other words, describe what you do.

[00:14:51] Okay, so describe it from the very beginning, from its fundamental level.

[00:14:56] Describe it to someone as if they had never programmed before. And this is very similar to

[00:15:02] taking on a student, finding an external reference, giving a student the advice that they need as a

[00:15:08] beginner programmer. The idea here is to force you back into elementary parts of your craft

[00:15:14] and to be able to do that. And that’s what I’m going to do today.

[00:15:15] And to realize that you’ve ingrained those skills. And that if you’re an experienced programmer,

[00:15:21] you may actually be really quite surprised at how many skills you’ve actually attained over the

[00:15:26] years, right? And so actually going back and walking through each and every one of those

[00:15:32] skills in its fundamental elementary way. This is going to make you realize how much

[00:15:37] information you’ve actually learned over the years. This is going to force you into building

[00:15:44] that all the way through. And that’s what I’m going to do today.

[00:15:44] All the way from the ground up. And once you see the body of information that makes up the work you

[00:15:51] do, that should help you recognize, wait a second, I am in fact a experienced programmer. Here’s the

[00:16:00] proof. Here are the list of things that I know how to practice. Here are the list of things that are

[00:16:06] in my brain that are kind of common knowledge to me now that I’ve memorized. And so I should note

[00:16:13] here that all four of these tools are going to help you recognize that you’re an experienced programmer.

[00:16:14] are really about perspective. They aren’t about the output. They aren’t about testing

[00:16:20] objectively what your output is, but instead it’s about reinforcing what you actually know

[00:16:27] to yourself. Finding a way of figuring out what that speed is by comparing yourself to your peers

[00:16:34] or comparing yourself to another beginner. Now there’s a whole other set of information that

[00:16:40] you can gain by looking at your output. Are you actually successful?

[00:16:44] But this episode is focused entirely on the perspective side of things. How can I reset my

[00:16:53] perspective? How can I regain a perspective of myself that is realistic? So I hope that these

[00:17:00] four tips will help you if you’re in that particular position. Learn to recognize your own

[00:17:06] speed. Find an external reference. Become a beginner again at something. Take regular breaks.

[00:17:13] Force yourself.

[00:17:14] To remove your brain from the context of your work, try to describe what you do to a non-programmer

[00:17:22] or write it all out on a sheet of paper. Explain to yourself what it is that you know.

[00:17:29] Thank you so much for listening to Developer Tea today. I hope you’ve enjoyed this episode.

[00:17:33] If you are enjoying Developer Tea, make sure you subscribe in whatever podcasting app

[00:17:39] you use. Thank you again to Linode for sponsoring today’s episode. With Linode,

[00:17:44] you can instantly deploy and manage an SSD server in the Linode cloud. You can get a server running

[00:17:50] in seconds with your choice of Linux distribution, resources, and node location. And on top of that,

[00:17:56] Linode is offering you $20 of credit just for using the code DEVELOPERTEA20 or by going to

[00:18:02] linode.com slash DEVELOPERTEA. Of course, the links for today’s episode, including

[00:18:08] the Linode-specific links, can be found at spec.fm. Thank you so much for listening to Developer

[00:18:14] Tea, and until next time, enjoy your tea.