We discuss factors that lead to this phenomenon and how to detect it in yourself and overcome the trap if you've fallen victim.  Erik also discusses the types of organizations and management practices that promote this toxic persona.

Resources:
Book: The Expert Beginner
Blog post: How Developers Stop Learning: Rise of the Expert Beginner
Wikipedia: Dreyfus Model of Skill Acquisition

Today's Guest
Erik Dietrich
https://daedtech.com/
https://www.hitsubscribe.com/

Transcript

Speaker: Ladies and gentlemen, The Tiny DevOps Guy.

[music]

Jonathan Hall: Hello, everyone, and welcome to another episode of Tiny DevOps. I'm your host, Jonathan Hall, and today, I have with me my special guest, Erik Dietrich, who is a former programmer, architect, and IT management consultants. He's the founder and CEO of Hit Subscribe. Welcome, Erik. What can you tell us a little bit more about yourself?

Erik Dietrich: Well, thanks for having me. Let's see. I guess if I had to summarize my career, and who I am, these days, it feels like a weird, long-winding journey through opportunistically doing different stuff so as not to get bored, I guess, is how I'd put it. I had a pretty traditional career for a long time where I worked my way up the software engineering org chart, getting titles like senior whatever, and then eventually wound up in management. My last salaried role was as a CIO.

Then I guess, for lack of a better way of putting it, figured out that I maybe couldn't work for other people or something, so I became an independent management consultant, did that for a number of years. Then, the way I like to think of it, that strikes me as funny. After all that, of course, I started a marketing business but actually, what happened is I used to write a lot of blog posts in my spare time for my site, DaedTech, and people would more and more approach me and say, "Hey, if we paid you, would you write for our corporate dev tools blog?" I would say, "Sure."

After enough of this, I figured out that, "Hey, this is an actual business opportunity." I partnered with my wife on what was originally going to be a side hustle but there was so much demand that we just wound up doing it full time. I think the rest of my career, apart from the marketing company, makes fairly straightforward sense. I always feel the need to explain this particular right turn a little bit more but yes, that's me in a nutshell. Mostly career-wise, application development, and in and around software, and the marketing business Hit Subscribe is still in and around software. It's dev tools companies that we're working with, but it's just a different core value proposition.

Jonathan: One question I've had for years, actually, since first coming across your website, which as you just mentioned, is daedtech.com. Why the spelling D-A-E-D Tech?

Erik: Oh, it was around that time, I was doing various projects, and I had a server and satellite computers in my house, and I got in the habit of naming everything I was doing after Greek mythology figures. If memory serves, this is now like, 11, 12 years ago or something, but at the time, I had built this home automation server that I had called Daedalus. I saw wanting my moonlighting and side hustle to eventually be home automation-focused so I took that name and called the business DaedTech. Then, of course, even a year in, I wasn't doing anything like that, it was just moonlighting application development or whatever, but the best laid plans.

Jonathan: [laughs] Nice, a good story. All right. The reason I brought you on today is to talk about actually a book that you wrote, I guess, originally a series of blog posts that you turned into a book, polished up a little bit, and I read the book. It's called The Expert Beginner, I read this book, probably shortly after it came out.

I remember sitting on the southern coast of Spain, and so I'm reading this book on my Kindle, and it was just blowing my mind a little bit and some of your other material, too. When I started this podcast, I'd love to have you on to talk about this concept of expert beginnerism. Maybe you can just briefly tell us what the concept is? What the book is about, if you were to go read it? Just briefly, in a couple paragraphs, what is this so-called expert beginnerism?

Erik Dietrich: The easiest way for me to describe that is, well, I guess without walking through a narrative, the idea is that you can, and kind of dived into the Dreyfus model of skill acquisition, which for anybody who's not familiar, has these five stages, which is novice, and then advanced beginner, and then I think it's competent, proficient and expert. The last one of the phases in that sequence, and which you don't really understand the big picture is called the advanced beginner. I riffed on that concept to describe people, generally in the software world, but it could really be, and this went pretty viral, and commenters weighed in, saying this applies to a lot of industries.

For me, it was specifically in software to say that there are people, especially who maybe, are the incumbent or only senior software engineer in a shop, who aren't actually particularly good at their craft, but there's nobody around including themselves, that understands that. They calcify into this role where even though they don't really understand what they're doing very well, they're still the incumbent expert, if you will.

What I was talking about is how common this actually is, given the proliferation and explosion of software, where, it's something like, I think Bob Martin had said that because the number of software engineers doubles every five years, so at any given time, half of the workforce is pretty inexperienced. That was true then, probably true now, and so you have all these shops where somebody gets a senior title, and makes decisions in spite of not really knowing what they're doing. That's the general concept that I explored in this content.

Jonathan: I remember reading it, and of course, names and faces came to my mind. "Oh, I know somebody who's like that." Did you have that experience when you were writing this? Don't tell us names but did you have people in mind, like, "I'm writing about this person."

Erik: Yes, at the time, I guess, when I first started writing, I think the first blog post I wrote was, 10 years ago. No, it would have been a little less than that but yes, very much so. I hedged at the time and I was like, "Well, this is a composite." There were two specific people in particular that I could picture and my interactions with them had been, I was at a shop and when I came in-- I don't even remember the title I came in anymore.

They were above me. I had been in the industry seven, eight years at this time so I wasn't a newbie programmer. I slotted in where they were making decisions, and at first, I was subject to them but eventually, I started building up a reputation for myself, and bringing in practices like unit testing, doing lunch-and-learns. What the hell was I doing? Putting static analysis into the build, things that were sophisticated back in 2012, 2010, whenever this was, and I gained a reputation.

It was this long, uphill battle, to slowly win over the favor, compared to these folks who were there, that really didn't believe in these things and it was a whole, "I've been doing this for 20 years without writing a single test, you can't tell me what to do," that type of thing. Eventually, I won things over and achieved the things I wanted to, but it was such an utter slog that I eventually left. It was tiring, that every little good thing you did had to be such a pitch battle.

For me, it was easier because I earned a claim in the group, and did all these things, but other people who believed in this stuff would just get pooped on by these guys. It was very much about them and there was some catharsis, I guess, in how frustrating it had been for me, but I think it was a lot more frustrating or cathartic for people who had been there that didn't have the same cachet that I wound up building to fight back. Point of fact, there was a guy there who had less experience than me and we ran an experiment where these two people in particular, and some of the senior folks there in general, would just savage him at code review time, and demand that he changed everything.

We took body changes that he was going to do and put my name on it, and just went and saw what happened to code review and it was way different. This was hard on these folks, and so I channeled their experience, and to some extent, my frustration in the beginning, and wrote about this. Then the response from people everywhere. The original post still goes viral on Hacker News, I don't know, once a year, and just the amount that this resonates with people, I was not prepared for that. 10 years later, I see this is super common, and very frustrating and demoralizing for people.

Jonathan: Yes, definitely. Do you have a concrete example perhaps in the past, or it could be made up of an expert beginner in action? Something that they do this cargo culting mindset where it's wrong?

Erik: Trying to think back to the original situation that I was in, so examples of the things they would do. There was a lot of conflation of personal preferences with the way you ought to do things. I remember these people that I'm thinking of in particular, imposed all kinds of cosmetic coding standards on junior level people that weren't exactly-- this was a Microsoft shop at the time, it wasn't like Microsoft's standards where you might be able to point to that and say, "Yes, do an M, then underscore or whatever before class fields."

It was random stuff. Like there was one guy that just insisted that everybody alphabetize the using statements in every file. One thing is, "I've developed this preference and now everybody will do it my way." That could be a bit of a power trip, but it's also something I've seen in expert beginners, like, "Everything I've done, because I've done it, is the right way to do it."

There was cosmetic or just superfluous power dynamic things but then this general assumption that whatever decisions I've made in the past are the right ones. That was pretty common and then I think-- I don't know if there are less toxic versions of this persona, but a lot of it wasn't just insisting that this is the right way, it was being downright nasty at times to people who, not even questioned it, but just didn't do it their way or didn't think to. This disdain for anybody that hadn't gotten on board with everything they wanted done.

Jonathan: The theme I hear through all this is essentially a lack of humility, right?

Erik: Yes. I think that's pretty evident in there. If I were to dive into it psychologically, I almost wonder if there's this kind of back of the mind-- I think I did write about this in the latter chapters before fleshing it out into the book, but there's different levels of cognitive dissonance, I think, in this type of persona. I think a lot of this tends to come from, perhaps this feeling that they really aren't all that in control, or they're really not right. There's probably nobody who's more prone to being hyper defensive than somebody who feels like they might be wrong, and that they barely got a grip on their situation.

Jonathan: Have you ever been an expert beginner?

Erik: I don't think so. I mean, it's not that I think I'm immune to either hubris or overestimating my own competence. I mean, I think that the ladder, in particular, is a cognitive bias but if anything, number one, I veer more towards imposter syndrome, where I'm convinced if I write something, somebody's going to find something wrong with it, and I'll get obsessive about justifying it with outside sources.

I think that proclivity prevents me from sliding into that trap naturally, not that I wouldn't be capable of hubris, or being wrong, or anything like that. I don't think I'm ever convinced that just because I've had success doing something, or just because I've done it, it's the best way to do it. Whatever, various sundry character flaws, I think that's one.

Jonathan: Well, I imagine the reason that this post resonates so strongly, and I say this out of personal experience, because it's the way it resonated with me, is that I can finally point to something that's been bothering me and I almost feel camaraderie that somebody else knows how I feel. That feels good and it's fun but it might also be dangerous. If we all just sit around all day pointing fingers at that guy over there who's doing it wrong, we're probably not improving things.

I'm interested in exploring the topic today, if you don't mind, and it might be a little beyond what you thought about it but that could be good. How can we identify if we ourselves are expert beginners, and try to avoid falling into that trap?

Erik: The thing that strikes me is maybe the first sanity checkpoint that you would have is how am I responding to criticism? To go back a little to whether I've been an expert beginner or not, if I actually unpack in a self-honest fashion about how I respond to criticism, the answer is often not well, but not well, in a different way. I can easily get defensive and dismissive in the moment, but what happens to me is that I start to second guess myself. I go back, and I want to really make my case or see that I'm wrong.

I think I would do a check-in about how you respond to criticism but the thing I would say is, is there that initial defensiveness and then dismissiveness? Are you responding to people who point out, "Hey, maybe this isn't the best way to do things," or, "I have questions about this," or whatever, is your response defensiveness, but also dismissiveness where you don't even consider what they're saying because they're so far beneath you?

One way that you could be in a mindset like this, I think, imagine, I was looking at a bunch of stuff on Stack Overflow. You have at this point system. If you had this idea of like, "Well, I have 80,000 rep on Stack Overflow so there's no way that somebody with only 50 reputation points can be right and me wrong or something." I think that idea that there's some kind of status, whether it's in the org chart, or some objective metric, like points or whatever, that you can get to a status where you can't be wrong. That is the core defining thing. The idea that I can't be wrong about this, tying that in with status, so I think that's the first sanity checkpoint.

There are others like if you're self-aware enough in an organization where you're kind of the architect or the person who's in charge of tech decision or technical decisions, and there's a lot of turnover in your department. That can also be a sign, bad morale, but I think the biggest thing is do you react to second-guessing or questions by just dismissing the person out of hand?

Jonathan: That's really good. I'm definitely guilty of that, at times. I try to catch myself. Stack Overflow is a great place to accidentally fall into that trap. I don't have 80,000 reputation but I do sometimes find myself on the subject matter where I feel like I should be an expert thinking, "Oh, this newbie doesn't know what they're doing." That's good advice there.

Erik: Well, there's a corollary to which is like, if I look at when I talked about having various sundry flaws, I'm not just saying that to seem humble or something. The flip side of that is if you let anybody, however inexperienced, with however silly a question, send you into this spiral of self-justification, that might not always be the most productive use of your time. Because frankly if you've been somewhere a long time, and you have good subject matter expertise, the more common cases that a newbie questioning you isn't going to be right.

There, I think, is a balance to be struck. I don't know exactly how to strike it. I think I tend to err on the side of getting unproductive to prove my points, but I do offer it as a check-in if your response to everything tends to be, "This isn't worth considering, I can't be wrong about this," that's something to, I guess to evaluate if that's how you're always responding to contrary suggestions.

Jonathan: Supposing that you've identified that you might be an expert beginner, what advice would you have to climb out of that hole? Other than just stopping to react defensively and dismissively, how do we elevate ourselves from expert beginners to the next level in the Dreyfus model?

Erik: According to the Dreyfus model, which I don't have a super in-depth grasp off of the top of my head, but they say, if memory serves, that advanced beginner as the last stage where you lack broad context. Advanced beginners, typically, are basically doing almost a form of cargo cult. The way that Dreyfus describes this is when you know nothing about something, you don't really, in the very beginning, overestimate your skills, you understand that you know nothing. Then you purely imitate people who know what they're doing, and then suddenly, through that imitation, you have this rapid ascension in your skill where you're just doing what somebody else has done.

Then, "Hey, look, I cobbled together these three tutorials to get started in this tech stack. Look, I just did a web app," and that's kind of intoxicating. That's where you start to develop an overestimation of your own skill because you're rapidly moving up in competence. The trouble is, in that phase, you don't really understand the big picture well enough to understand what it is to be truly good at this, versus just cobbling stuff together.

In that phase, you're kind of doing cargo cult stuff, you're just imitating, and what you're doing is picking the right people to imitate, and you don't have broader context. I think the biggest thing between advanced beginner and when you get into competence, is the competence can react to unprecedented situations in rational ways with good approaches, because they're no longer purely in the realm of just cobbling together existing solutions.

To go all the way back, my thing here was that expert beginners were this calcified stage of advanced beginner where you still lacked the context. I think the path out of expert beginnerism, one is, I guess, the humbling admission that maybe you could be better at this. I'd say, more importantly, a tangible way, like a very actionable way to get out of it, is to start to quantify or put evaluation criteria to the things you're doing, or at least put some kind of research in it.

To make that a little less abstract, if, and I'm going to go back to the example of these people that I was interacting with, if you're saying something like, "Hey, doing unit tests on a code base, there's not a good return on investment. You are writing all this extra code that doesn't do anything for you." Well, prove it, go and do some research, run an experiment, come up with a way, whatever that looks like to show I'm right about this. Those people who are questioning you, you're not going back and forth with citing your level of experience or resume. You're saying, "No, here's tangible conclusive evidence."

I'd say the path out of expert beginnerism is to get good at justifying what you're doing with outside sources, or with experiments that you're running, and to get comfortable with doing that, because that's what people at higher levels of the chart would do, people that are professional experts. They've run experiments like that in the past or they have things that they can cite and call up at will, that aren't just cargo cult imitation.

Jonathan: What sorts of environments or businesses, cultures, team size, company size? Of all this sort of context, have you seen any common threads that lead to or promote expert beginnerism, or maybe that do the opposite that help promote humility?

Erik: In my consulting travels, earlier in my career, the first company I was at, I stayed there for six years all in, which is by far the longest stop, and then I had shorter stops. Then when I went on my own as a consultant, I got the opportunity to go in and look at all kinds of different places. What I observed vis-a-vis the expert beginners, that this persona exists in all kinds of shops. I think the single biggest enabling factor, especially once I got into management consulting, and I was helping organizations assess personnel problems or build org charts, et cetera. The biggest correlation with expert beginnerism is hero culture as perceived by management.

Management tends to be cripplingly afraid of expert beginners. They are perceived as like a Dr. House type figure often. They're irascible, they're mean to people, they're a morale problem, but they're so productive, they're such heroes, that we don't want to risk annoying them in any way. I think that's the single biggest correlation with that persona because it feeds back into them and gasses them up.

Often it's self-reported. Often, these people are telling management how great they are and there's not actually a lot of evidence to suggest it, but they're telling management how important they are, and then management will infer that from watching them act like Dr. House. They're like, "Oh, man, this must be somebody I really ought to listen to."

I think that's the single biggest determining factor and why I came to talk about seeing it in enterprises, where teams often shuffle around, and there's fluidity, and you would think maybe this wouldn't develop as much. Then I've seen it at this really small captive-type shop, where you've got four engineers and one of them's been there for 20 years, but it happens everywhere. The common thread there is that fear from leadership of angering this hero.

Jonathan: That leads to my next question. As somebody in a leadership or management role, what can I do to avoid these traps? I think you've already hinted at a big part of that, but maybe you want to just finish out that thought?

Erik: The advice I used to give in this situation, depending on how populist your leanings or whatever you may love, or you may hate me for, but what I would tell leadership in IT is that it is unlikely that-- assume this person is as good as you think they are, they're still probably a net negative, and they're also probably not all that important to your organization. The advice that I used to settle on when people would behave this way is I would go to the leaders and say, "What you should do is treat the morale problems and the plays-well-with-others and all that as part of this person's core job performance.

They're used to getting exceeds expectations on every performance review, now you're going-- because I didn't get called into organizations when things were lovely, so there were problems, and the advice I would give if one of those problems were a person like this torpedoing morale, is I would say, treat this as incompetence. If they're upsetting people, if they're causing less experienced developers to leave, if there's turnover, if people are complaining to HR, take those things, and throw it right alongside anything they're doing technically as part of how you're evaluating them, and label them incompetent until they fix this.

One of two things typically happens. It drives them nuts, and they change how they behave, or they leave the organization. Frankly, either one of those is a good outcome, in my opinion.

Jonathan: Suppose you are working with somebody like this, but you're not in leadership, you have no authority to change things, how do you cope?

Erik: Honestly, me personally, I used to leave. It would just get tiring and I can find other jobs. Inasmuch as I'd stick it out, the original experience I had, where I was at first, I guess you would say, below them in the pecking order, and then an equal, it was a hard-fought battle, but it was usually done by responding to silly proclamations with overwhelming evidence.

I wish I could remember the specifics, but one of these folks said something, sent out this group announcement about having to do something every time the garbage collector fired off, and it was nonsense. It was an act of detriment to the code base and complexity. Basically, recommending, this is always a bad sign of things if you feel like you need to write code that goes in and tells the garbage collector how to do its job, you're probably barking up the wrong tree.

I remember in this instance, I wish I could remember the specifics, but doing research coming out, showing somebody who had run trials on trying to do something like this and what happened. Then even, I think, running an experiment with a memory profiler to show that this guy had basically laid out a blueprint for a massive memory leak. I spent a day doing that and putting together this email, and then sending it out as a counterpoint. That's tiring, it's fraught. It does lead to conflict, but the one thing I think this persona hates to do is be demonstrably proved wrong beyond all shadow of a doubt.

These types of interactions over the course of time, led to them leaving me alone more. It makes me think of that silly bit of advice. When you go to prison, punch the biggest guy in the face or whatever. That's like a version of that, but man, boy, that is a tough route to go, so that's one route. I would personally leave or just ask for transfers out. If you're stuck in a shop like this, it may seem like this will always happen, but it's not like this everywhere. I hate to give advice that's like quit. I mean, you can stick it out, duke it out, but I think more often than not, absent that person leaving or going somewhere else, it's tough to stay.

Jonathan: We'll have a link to the book in the show notes. Is there anything else you'd like to add about this topic before we close out?

Erik: It's been interesting to reflect back on it so many years after having written it and think that it still resonates with people, it still seems like-- with other blog posts I wrote 5, 6, 10 years ago, I go back and read it, and I'm like, "Oh, I was pretty silly." With this one, it seems to be fairly evergreen in the sense that it still resonates. When I read it, I think this reflects experience that I would have over the next however many years of my career.

I'm not saying that as a self-plug for being prescient or anything, it's more that just looking back at what I've written, this one seems to be enduring and resonates with people. I guess that the negative side of that is it continues to be an issue in an industry that I think is often maybe a little too preoccupied with coming up with "objectively right answers", and that can lead to a tendency to equate answers with earnable status, like titles, or points, or levels or whatever.

I think the thing that I'd suggest is, as a parting bit of wisdom such as it is, that you don't ever assume that your past experience makes you infallible, weird as that is to say, but you don't earn up to a certain badge, or a certain level, or a certain title, and then your word becomes gospel. That just never happens. If you think that it does, that's the path to this interpersonal anti-pattern.

Jonathan: You have any other recommended resources for people struggling with these sorts of problems?

Erik: I think in general, like in the abstract, I don't know of any specific ones. If you can find communities where mutual career support or something. A good place to go is with others that are in similar positions. If this is interesting to you, I've written over the years a lot about career-oriented topics and software. My blog, daedtech.com, has stuff like this. Not super well-curated, I would add. It's just me having written for something like 11 years now. There's a lot of articles, organized loosely by time, and that's about it. I remember there was the career Stack Exchange, where people used to post and wonder about topics like this. I don't know if that's still going.

Jonathan: How can people get a hold of you?

Erik: These days there's two main places that I hang out. There is DaedTech, which if you go there, it'll look like I haven't written in a long time. That's because I haven't but it's also because I just had a baby and I'm very busy. I don't intend to stop creating content there, but that site is just mine. It used to be my consulting site. I don't do consulting any more, so now it's just my musings, and you can find links to my YouTube channel and social media, though I'm not particularly active there, either.

Then the other thing I'm doing is Hit Subscribe, which is the business of which I'm currently the CEO, and that's hitsubscribe.com. The main interest for anyone here is that we're always looking for people to write technical blog posts, or create technical content for our customers who pay us to do that. If you think you'd be interested in creating content and getting your name out there a little, that is something we do.

[music]

Jonathan: This episode is copyright 2021 by Jonathan Hall, all right reserved. Find me online at jhall.io. Theme music is performed by Riley Day.