DaedTech

Stories about Software

By

Impostor Syndrome and Expert Beginners

Happy Tuesday, everybody.  Let’s start the week with a reader question, the way I do every Monday.  This week, I’m going to answer a question about impostor syndrome and expert beginners.  And I’m going to do it on a Tuesday because I was on the road this weekend and didn’t get a chance to post ahead of Monday.

I was reading about “expert beginner” and it was fascinating and rude awakening in some parts. How does this compare with the feeling of impostor syndrome ? Are they even related?

First, let’s start with some background.  The question asks about two terms you may or may not be familiar with: expert beginner and impostor syndrome.

Expert beginner is a term I coined years ago in a blog post (and eventually made into a satirical Twitter account). You can read the blog post and the eventual series for extensive background on the topic, if you’d like.  But for our purposes here, I’ll describe him more briefly.

An expert beginner is a small king in a small kingdom.  If you go to work at a small software development shop, you might encounter him as the senior architect who has been there forever.  Management gives him the run of the place in spite of the fact that, as it turns out, he’s not really very good at what he does.  Management trusts him because it doesn’t know any better, and he equates this trust with objective demonstration of his superior skill and ability.  He seeks no oImputside input or validation, ruling with an iron fist from a position of mediocrity.

A small king in a small kingdom.

Impostor syndrome describes something entirely different.  Those suffering from impostor syndrome believe their achievements the result of luck or favor rather than merit.  They constantly feel like frauds or impostors.  Think of a programmer with 5 years of experience and a track record of delivering results thinking he’s not a “real” programmer.

Impostor Syndrome vs Expert Beginnerism

This is pretty simple, right?  These things are opposites.  Expert beginners overestimate their competence and impostor syndrome sufferers underestimate their competence. Case closed.

And I suppose one could close the case with that take.  But that isn’t my take.  I think something more subtle is at play.  I’d say that expert beginnerism and impostor syndrome are sides of the same coin.

Both represent a critical inability to meaningfully internalize feedback.

Now, before I proceed, I want to be clear about something.  Not everybody that is prone to coming off as a blowhard or who doesn’t recognize the value of a coworker’s suggestion is an expert beginner.  Likewise, people who have moments of self doubt aren’t all suffering from impostor syndrome.  If you didn’t suffer at least occasional self doubt, you’d be the sort of narcissistic maniac that I once characterized as a “master beginner.

With both true expert beginners and true impostor syndrome sufferers, you have a sort of cognitive blindness.

Read More

By

How to Politely Say No and When To Do It

Another Monday and another successful Reader Question Monday.  Usually I go with kind of a FIFO model for reader questions, but I bumped one that I’d just logged because it seems interesting.  It concerns how to politely say no and how to know when to say no with clients and prospects.  I’ve excerpted some of the question here.

 I have a problem I have run into and it has to do with when to say “no” to work.

I have the chance to work on a project where my gut says I should not, not only is the project at least two months, it is at a rate that is too low for 1099. There are also many issues with current infrastructure and architecture which the owner wants to bypass. I guess my point is how do I turn down the work gracefully. In the past I have taken on this type of project and worked 12 hour days for 9 months to get it done, obviously, I don’t want to do that again.

I guess my point is, it is really hard to say “no” but it would be easier if there was a way to vet possible work with others [who] are knowledgeable about architecture so perhaps a way to audit upcoming work to see if taking on the work makes sense. How do you weigh the pros and cons? How do you get second opinions that are good, not random?

When a prospect is proudly showing you a dumpy house, how to politely say no is a good skill to have.

Extracting Themes Around No

This is a common situation for an independent.  But it could just easily apply to anyone reading in the midst of a job search.  Or even in even less dramatic fashion — maybe your boss pitches you working with a different group for a time.

Some common, recognizable themes emerge.

  • Saying no to things is hard, professionally.  Our very wiring tells us to please, as illustrated by the phrase “the customer is always right.”
  • Saying no to things has real downsides.  For employees it can mean lost capital and for free agents, lost revenue and belt tightening.
  • We see red flags, but have a predisposition to proceed anyway and hope for the best.
  • It’d be nice if we could get some insider information to tell us whether to heed the red flags.
  • In general, a framework for sizing up work would be good.

How to Politely Say No

I should note that I did dedicate a chapter entitled “The Art of No” to this subject in Developer Hegemony.   That was more about how aspiring opportunists should steer themselves away from politically perilous situations, but some of the techniques certainly apply.

You never really want to just say a blunt “no” outright to a client prospect.  Even if you think working with them makes for a terrible fit or they’ve rubbed you wrong during discovery, you’re running a business.  You want a reputation for playing nice and being professional.  Here are some general ways to demur on a prospective gig.

  • Say no, but offer to help them find someone who will say yes.  In a sense, this isn’t “no” at all.  You could almost think of it as steering them toward a lower tier offering.  “This isn’t a great fit for me, but let me put you in touch with Steve, who…”
  • It’s not you, it’s me.  “Given the budget you’ve allocated for this and your engagement model, I don’t think I’d be a fit.  I usually direct projects like this and am used to incremental value delivery, and it appears you’re looking for an app dev staff augmentation.”  I suggest doing what I did here — subtly phrase it in a way that positions what they want as a budget offering.  This will prompt them to start making concessions if they really want you.
  • Say that your calendar presents a conflict for the work.
  • You can be direct and honest and just say that you don’t think the work is a fit for what you offer.  Careful here, though.  Direct and honest sounds like the best (and to some, only) option, but it puts a lot of clients and prospects in a defensive posture.  It may leave them with a bad taste in their mouths.
  • Or, finally, you can get them to say no instead.  More on this later.

Read More

By

A Slice of My Life: What I Do, Why I Have Money, and How It All Works

It occurs to me that I spend a good bit of time weaving narrative into my posts.  I tell personal anecdotes to ground stories, and I add in a good bit of figurative language.  But it’s always fairly superficial.  I don’t generally get heavily into my own story.  As an introvert, this makes sense, since talking extensively about myself or receiving compliments feels awkward.

But I’ve received a number of requests over the years like today’s reader questions.  So today, for reader question Monday, I’ll talk about this subject.  Here’s the reader question.

I’m interested in how you’d describe what a week, month or a single engagement in your shoes is like. I know a couple of people who are consultants and see them going out to coffee shops, meeting with clients to socialize and making pretty good money. I’d like to read an article about what your routine is like. Nothing where you give away client specifics or anything. I just think others who read your blog are taking in what you write about, putting what they find is useful into practice but are left wondering in their head ‘I wonder what work is like for Erik?’.

Before I dive in, it’s worth noting a couple of things.  First, I have to address this at different times because my life has changed a lot.  And, secondly, it really depends on what kind of consultant you are, so I’ll speak a bit to experiences other than mine as well.

I’m predicting a fairly long post on this one, so buckle up.  I’ve always found that it’s the absolute most difficult to be brief when I’m trying to explain myself, as if I’m constantly mounting a legal defense or something.  Anyway, here we go.

Modern, Reclusive Erik, A Day in the Life

For the last six months, most of my days look pretty similar, weekday or weekend.  I usually wake up around 9 and shuffle to the kitchen for some coffee, preparing to sit at my computer.  Morning time is usually writing time.  This isn’t for my personal edification or for my books, but for my growing content marketing business.  That typically carries me through lunch and a little after.

In the afternoon, I’ll spend some time handling emails, corresponding with clients, and working on the businesses, but that usually stops at some point.  For the last six months, I’ve been living in a house on a lake, featuring usually great weather, great scenery, and generally great marrow waiting to be sucked out of life.  So I go outside.  I jog, I kayak, I do a bit of yard work, I fish, or I make a fire in the fire pit and just enjoy my surroundings.  The weather is getting a little suspect for that here in late October, but we’re getting ready to head south for the winter.  So I expect this routine to continue.

After enjoying life a bit, I eat dinner and then either call it a day or go back to work, depending on how I feel.  This is typically non-writing “deep work.”  Minimal distractions after 8 PM, so I can get in a solid block of concentration until I go to bed around 2 or 3 AM.  Sometimes I also write during this time window.  Other times, I’ll work on software for my codebase assessment practice or my own longer form content marketing.

Why Does This Matter?

You’ll notice what I don’t really talk much about here: consulting.

That’s because I don’t honestly do much of it anymore.  And that’s by design.  I have engineered and hacked my life deliberately and specifically to look like this.

When I do consult these days, the clients seek me out, and I agree only after a heavy round of disqualification.

  • Is it a short term engagement (a few weeks or less)?
  • Will it pay enough really to be worth it?
  • Can I do it from anywhere?
  • Is it a high value, high leverage engagement for the client?

A “no” to any of these questions and many more results in a “no thanks” from me.

I give you this vision of my life, mostly “retired” from serial consulting in order to set the stage for the rest of the post.  Consulting is fun, rewarding, interesting, and lucrative when you do it well.  But it’s also a treadmill unless you specifically make it not one.  It’s the career equivalent of an interest only loan unless you’re careful.

Read More

By

Should I Incorporate? The Knowledge Worker’s Dilemma

Happy Monday, everybody.  To help prolong your procrastination over morning coffee just a little bit longer, I’ll offer you the latest installment of reader question Monday.  Today, I answer a question that many reading my blog probably have: should I incorporate?

Here’s the actual question, as I recorded it.

What is the cost/benefit of incorporating? Should I just keep paying for domain/hosting through my [credit card], or would it be worth the hassle to move to a real business?

As you can see, I’ve generalized a bit in order to make it more broadly applicable.  But I’ll speak to all salient points through the post.

Should I Incorporate?

Yes.  Alright, post over.

Just kidding.  At least, I’m kidding about the “post over” part.  I do think that you should incorporate.

“But you don’t know anything about my situation, my job, or my life!” you protest.  And, while that’s true, I’d argue that I don’t need to know anything about it, assuming you’re a knowledge worker.  To make my case, let me now speak explicitly to costs and benefits, as requested.

Should I incorporate? The monopoly guy here thinks the answer is yes, and so do I.

Read More

By

How to Deal with an Insufferable Code Reviewer

Time for another installment of reader question Monday.  Today, I’m going to answer a short and sweet question about how to deal with an “irksome” code reviewer.  It’s both simple, and fairly open ended, making it a good candidate for a blog post.

How do you deal with peer code review and irksome coworkers? Any trick?

Okay, first things first.  This could cover a lot of situations.  Theoretically, someone could be writing extremely problematic code and finding coworkers “irksome” simply for pointing that out.  And, at the complete other end of the spectrum, the code may be fine but a toxic culture creates endless nitpicking.  In environments like this, the code review becomes an adversarial activity, as much about political games as about code quality.

So you must introspect and also think in terms of your goals.  What is it that’s irking you, exactly, and what is the desired outcome?  I’ll frame the post roughly in terms of goals, and my advice for achieving them.  Really, that’s the only way to do it, since code review processes vary so widely from team to team.

A Bit of Perspective on Code Reviews and Code Reviewers

Before going into any advice, let’s consider the subject of code review itself.  There are two conceptual levels at play.

First, let’s talk about the obvious one.  A well-conducted code review process helps with code quality and it helps developers learn.  In his book Code Complete, Steve McConnell cited a study that found “formal code inspection” to be the most effective defect prevention method.  This put it ahead of even automated unit tests in the study.

But, beyond that, code review has important human ramifications as well.  People learn and share knowledge through this process.  And they use it to prevent the kind of defects that result in frustration for the team: rework, embarrassment and even a need to come in on weekends.  People with a stake in the codebase get emotionally invested.

There’s also another, more subtle element at play, however.  I talk extensively about these terms in my book, Developer Hegemony, but you can read a brief primer here.  Software developers (to my endless irritation) are pragmatists (line-level laborers) with almost no actual influence in the corporate world.  When you participate in the so-called “technical track,” you typically never have people reporting to you, earning only developmental titles that include things like “senior,” “tech lead,” and “architect.”

So often, the only simulacrum developers get of actual organizational power comes during interviews and code reviews.  Decent human beings handle this well, looking to mentor and teach.  But there are a lot of less-than-decent human beings out there, who relish these opportunities to wield what little power they have.  The phrase, “a little man with a little power” comes to mind.

An angry code reviewer

Read More