Stories about Software


DaedTech Digest: Code Quality, Feature Flags, and Physical Migration

Happy Friday, everybody.  It’s DaedTech Digest time today.

I am just wrapping up my work week and preparing to spend all day tomorrow (today, by the time you read this) driving south to the US Gulf Coast for the next 5 weeks.  Why?  Because it’s cold where I am in Michigan, and it’s not cold down there.

We’re planning a winter/early spring where we split time between a town called Bay St. Louis, Mississippi, San Diego, and Mesa Arizona.  So if you live in any of those places and have suggestions for places to go or meetups to attend, I’m all ears!


  • If you like posts along the lines of the one I made Wednesday, then I suggest a couple of podcasts.  First, the Freelancer’s show, and second, the podcast of one of the panelists, Jonathan Stark, called Ditching Hourly.  They talk a lot about positioning, marketing, getting business, and getting away from the trap of hourly billing.
  • If you have any interest in SEO and keyword research, I recommend a Chrome plugin called Keyword Keg.  I use this constantly for my content business to help look for good blog topics.  When you do Google searches, it shows you the keyword volume right inline.
  • Speaking of my content business, I’ll do a plug for the Hit Subscribe blog.  The blog is aimed at teaching techies to use blogging to advance their business interests.  So if you want to learn about blogging, give it a look.
  • On the coding side, I’ve been enjoying Shouldly a lot for its unit testing assertion semantics.

DaedTech Post Digest

Have a good weekend!


Be a Freelance Web Developer? You’re Asking the Wrong Question

I get a lot of reader questions about freelancing.  People interested in freelance web development or freelance mobile development or what have you.  I applaud the desire to go free agent, and I think you should do it.  But I think you get a lot of bad advice about how to do it.  Bad advice at a philosophical level, that is.

Today I’m not answering a specific reader question, though.  Instead, I’m just going to talk about going freelance.  I did this years ago and have had a good run.  But I really wish I knew then what I know now.  Hopefully I can help you get to joy a lot quicker and in less roundabout fashion than I did.

And don’t worry.  I’ve stated that you’re asking the wrong question, so I will, eventually, get to what you’re probably wondering — what is the right question?

Freelance Web Development?  Here Are Some Tips (That Help Us Make Money Off You)!

If you google advice about freelancing as a developer and about freelance web development, specifically, you’ll probably find a lot of advice from a certain kind of site.  Fiverr, Upwork, and Toptal are all happy to help.  They’ll tell you how great it is, saying things like:

  • Be your own boss!
  • Have work-life balance.
  • Choose your projects.

And they’ll offer you advice, like:

  • Beef up your breadth and depth of tech stack knowledge to have the most opportunities.
  • Build up your portfolio so that you can show it off.
  • Create and promote your personal brand through a website, user groups, conferences, etc.
  • Get your business affairs in order.

All of this is actually good advice for your immediate future.  Full stop.  This stuff will help you blast out of your salaried job and into the world of self employment — they’re right about that.

But here’s the rub.  All of these sites are providing advice to you on how to be a good product for them to sell.  Think of these the way you’d think of recruiters giving you job search advice.  They want you to do an excellent job with the next stage of your career and go exactly no further.  This makes sense, since they earn their revenue pairing freelancers with companies in need of short term labor.

Freelance Development is Basically Just Job Hopping

If this whole thing sounds familiar, it should.  It looks an awful like recruiters helping you from job to job as soon as you’re willing to jump.  The difference?  The world expects you to jump as a freelancer, but feigns shock when you do it as a salaried employee.  Freelancers jump — it’s what they do.

But make no mistake — the difference is only that you jump perhaps a little more often and that people expect it.

Do you want to know what I thought freelancing would be like when I started?  I’m actually chuckling a little as I type this.  I’d had some moonlighting gigs in the past where I did 5-10 hours per week of work in my spare time for someone.  So I just assumed that I’d find 4 app dev clients that wanted about 10 hours per week of work.

I’m not chuckling because this was or is a stupid thing to assume.  I’m chuckling in irony because of how much the world turns out not to work that way.

You get into freelancing assuming that you’ll have a bunch of clients and diversity of work, handling multiple projects at once.  But what you’ll wind up doing is taking sequential gigs with periods resembling job searches in between.

This is a Hamster Wheel

You’re going to need something more than this, eventually.

Becoming just a freelance web developer can feel like this hamster running on its wheel.

Read More


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


DaedTech Digest: Bad Code, Evils of Coverage, Spending Your Money

Happy Friday, DaedTech readers.  I’m at three in my streak of DaedTech digest posts.  So far, so good.

If you’ll recall, last week I introduced the idea of “picks,” so let’s continue with that for starters.


  • (Shameless plug alert)  Someone asked me on Twitter today about finding an epub version of my book, Developer Hegemony.  While I generally link to its Amazon page, I did self-publish it through Leanpub.  If you go there and purchase it, you can download it as an epub, a mobi, or a pdf.
  • If you use Hootsuite to manage social media, I strongly recommend their new Beta composer.  I was actually on the fence about letting my subscription elapse, but that changed my mind — I’m that impressed.
  • If you track your site’s SEO at all, Moz has introduced a cool new feature that lets you look up all of a site’s keyword rankings.
  • And, finally, I bought this roof rack for Jeep Grand Cherokees to haul stuff as we trek around this winter.  If you happen to have a roof rack-less Jeep, I haven’t tested it extensively yet, but install was a breeze and it fit perfectly.

DaedTech Post Digest

Alright, onto the digest.  Here are some posts of mine you might want to check out.

  • I wrote a post for SubMain entitled, “5 Things Responsible for Your Poor Code Quality“.  One of them probably will surprise nobody reading: a lack of automated unit tests.  But there’s more to it than just unit tests.
  • I took a strong position on code coverage for NDepend.  I don’t think management should worry about or track code coverage.  If management is involved at this level, the team has much deeper problems than making Jenkins happy with branch coverage.
  • In a bit of a change of pace, I gave advice for the ASPE training blog about how to spend your training budget as a developer.  I related your training budget to that parable about filling a jar with rocks, pebbles, sand, and water.  So if that sounds interesting, give it a read.
  • I wrote a post for SauceLabs about how to use Selenium Web Driver to improve your web applications.  It includes an introduction to the tool, its backstory, and its value proposition.  If you’re not familiar with Selenium, have a look, because you’re the target audience.
  • And, finally, another post for SubMain about moving beyond using the HTML help file if you want to distribute documentation.  This is certainly a tried and true old friend for longtime .NET developers, but you’ve got better options these days.


Ace Your Exit Interview Using Little White Lies of Omission

Ah, the exit interview.  If you’ve had this experience, the first one probably arose in confusing fashion.  You put in your notice and the team scheduled your goodbye lunch.  At someone point, HR put a meeting request on your calendar that prompted you to say, “an exit what — what is this?”  And then you had an exit interview.

Or, maybe you’ve never had this awkward experience at all so far in your career.

Whether you’re an exit interview veteran or googling it for the first time, though, I’ve got some pointers for how to handle this.  I’ve given general advice on whether to quit a job and how to quit a job before, but this will be specific to the exit interview portion of quitting.

What Is an Exit Interview?

First things first.  What actually is an exit interview?  It’s not the most naturally intuitive concept, but you can probably infer what it involves from its name.  Still, you might wonder, “what’s the point?”

Ah, the exit interview. Crack a beer and tell 'em how you really feel.

An exit interview is a meeting that someone, usually the HR department at a decent sized company, schedules with you.  It’ll generally happen the day of or the day before your departure, and it’ll take half an hour or maybe an hour if they really want to cover a lot of ground.

They’ll ask you a lot of questions, effectively looking for a private, Glassdoor-style review of the company.  For instance, here are some blue chip exit interview questions.

  • Why are you leaving?
  • What did you like most about working here?  Least?
  • How was it working with your manager and your coworkers?
  • Did you have what you needed to do your job effectively?
  • How could your manager improve?  How could the company?

You get the idea.  The exit interview is a standard practice for the company to collect and, hopefully, incorporate feedback from departing employees.  Theoretically, it offers them a unique window into people’s real thoughts about the company, since they can speak freely and without consequence.  Theoretically.

Read More