Stories about Software


Narrow Niche: When is Narrow Too Narrow?

I think I’m going to abandon the idea of “reader question Tuesday,” or any particular day.  I’ll keep writing reader questions, but, in keeping with my announcement of blogging for fun, I’ll just post them whatever day of the week I feel like.  So today, a Wednesday, let’s do a reader question about a narrow niche.

So, let’s get into it.  Here’s the reader question.  It’s in response to a point I made about how to build an audience.  Specifically, I said to find problems that people Google and offer solutions.  In response, a reader asked the following.

One of the issues I face when I think of writing anything on a topic is that I immediately find lots of other articles discussing the same thing. But if we write about a specific question we could have more [readers to ourselves].

However, how do we know if a question is common enough?

The Narrow Niche in Content and in Specializing

Let’s consider what he’s asking here.  Take a topic like, say, test driven development.  If you Google test driven development, it’ll seem like every imaginable topic has been covered.  But if you Google “cobol TDD,” the results quickly turn to the sound of crickets.  So write about TDD in Cobol and get readers, right?

Well, if there are any.  I say this because I have a number of tools that estimate the quantity of searches for a term in a given month.  And it appears that almost nobody is searching for posts about TDD with Cobol.  Hence the reader question.

How do we know if the question is a common enough search to be worth writing about?

Well, at the simplest, most tactical level, you could install the Keywords Everywhere plugin and see for yourself.  Here’s what Google shows me, for instance.

But that’s a pretty short-sighted answer.  The real question here is a deeper one.  How do you know if a series of topics is worth writing about, and how do you pick your focus for a blog.  And, for all of you free agents and aspiring free agents, how do you pick a specialty and competitive advantage?

You want a narrow niche, or you’re just a miscellaneous, generalist laborer.  But if you narrow it too much, you might have no audience or customers.

Read More


DaedTech Digest: Packing Edition and What We Take

As I mentioned in a recent digest post, we’re heading to Vermont in a few days, where we’ll stay for a month.  Since mentioning that, we’ve gotten questions about leaving our house unoccupied and about what packing is like.  Since I answered the former last week, I’ll answer the latter this week.

What Does One Pack for a Month?  Necessities

I’m going to try to resist the impulse to turn this post into my packing list.  Instead, I will simply mention that I make a packing list.  I use Trello for the packing list, and tend to reuse the same one each time we vagabond.  So, protip, I guess.

But, in terms of what we take, let me lay it out in broad strokes.  Amanda and I each pack a large duffel’s worth of clothing, representing about 10 days to 2 weeks’ worth of clothes.

This can be surprisingly lightweight or a little bulky, depending on the weather.  Not so much cold vs. warm, but how variable.  For instance, we’re going to Vermont for October, which means that we might encounter anything from t-shirt weather to frost and snow.  This means we need to pack more stuff.  If we were just going to, say, the Equator or to Alaska, we could bank on one kind of weather and pack more lightly.

From there, we pack certain necessities.  This includes our cats and their stuff.  It also includes my fairly meaty computer setup.  That actually speaks for most of the cargo space in our Jeep, with the rest going on top.

And Then, the Other Stuff

Work, animals and clothing is the core of our packing efforts.  But we also bring some things we could live without.  I always haul around a bag of electronics, which includes a few Alexa devices, a cordless phone, power strips, and other stuff I tend to like having.  Amanda brings a small suitcase thing full of makeups and nail polishes and such.

After that, the other main thing that we bring is some foldable, economical furniture.  This includes a folding chair and a folding table, in case the place we’re going doesn’t have a serious desktop setup. (We’ve learned from experience after buying these things upon arrival, when the AirBNB doesn’t have a desk.)  We also, space-permitting, will bring things like little bedside fans or humidifiers/dehumidifiers.  Again, things we’ve purchased after arrival and learned to take with.

And, speaking of buying things after arrival, I’ll close with this note.  You’ll always buy some stuff after arrival.  Assume that you’ll spend a couple hundred dollars when you get onsite, buying fans, cheap tables, coffee makers, or other things that aren’t there and that you realize that you need only after seeing they aren’t there.

And that’s packing.


  • This is kind of a weird one, but I want to throw a nod to Quest Diagnostics.  Following a routine physical, I had to go for routine blood tests, and that experience can be anything but routine.  But with Quest, I made an appointment online, showed up a little early, and they had me in and out in 5 minutes or so.  Remarkably efficient.
  • This past weekend, my old Fitbit dipped to an unacceptable battery life after a respectable 2.5 years.  So we went out looking for one during the middle of our Hit Subscribe outing in Chicago.  At a Target, at like 9 PM on a Saturday, we found a Fitbit Flex 2 on clearance for $29.99.  It’s lightweight, holds a good charge, and has been making me pretty happy so far.
  • Speaking of Hit Subscribe, I can’t help but do a slight bit of homer bragging.  We’ve been growing and bringing on more people and we now have our first employee that isn’t me or Amanda.

The Digest

I’m kind of light on written things of late.  I’ve done a few, but clients have yet to publish them, and I’ve been doing more video and audio content, lately.  So, in that vein, I’ll offer some new media for the digest, all of which are videos.

  • First, here’s a Youtube video on the Hit Subscribe channel where I describe topic planning for clients.
  • Amanda and I have also been doing Facebook Live videos about running a remote business.  Here’s the first one we ever did, a couple of months ago in Durango, CO.
  • And here’s the second Facebook Live (pardon the wind).

And, as always, have a great weekend, folks!


Coding as the Boss: My Story of Developer Hegemony

Last night (this morning), I clicked “publish” at about 3 AM and went to bed.  Now, those of you who follow this blog probably assume that I clicked “publish” in WordPress, firing off a 3 AM blog post.

Not so.

I did this in Visual Studio, where I published a little web app called El Dorado to Azure.  I source control the thing in Github and I publish to Azure, where it serves as a little line of business application for me and some of the staff at Hit Subscribe.  And, while a Visual Studio publish isn’t exactly state of the DevOps art, it gets the job done.

The significant thing here isn’t any of the techs that I’m using.  It’s also not the fact that I was up late coding, nor is it the purpose of the app.

What matters here is that I own a non-trivial and growing business and that I’m also writing code.

The Classic Management Track vs Technical Track Conundrum

Years ago, I wrote a blog post in which I told a story of something most enterprise-y/corporate programmers encounter sooner or later.  It’s the “where do you see your career going, management or technical” question.

Choose wisely, young programmer.  Down one path, expense accounts and Gantt charts await.  Down the other, UML diagrams, and… well, probably also Gantt charts.

I could never really wrap my head around this dichotomy.  I mean, I get that furiously banging out code and leading departments are somewhat divergent activities.  But I never understood why the line blurred so little and so infrequently.

I poked around the internet a little to see if this was still true, and I think it mostly is.  I found some posts like this one, talking about the coding dev manager.  But this has always seemed like just taking the role that most companies call “architect” or “tech lead” and having people actually report to it.  That just kind of kicks the can down the road slightly.  If you’re a “coding manager,” you’re probably in a fairly vertical, tech-focused organization where line managers still don’t really think about “the business.”

Are Technical and Business Savvy Mutually Exclusive?

So this begs an interesting question.  Are technical savvy and business savvy mutually exclusive?

Oh, I mean, don’t get me wrong.  I’m not honestly asking whether techies can become startup CEOs or whether leaders with f-you money couldn’t learn to code.  Of course those talents can both exist in the same human being.

What I’m asking is whether or not someone can do both of these things meaningfully, at the same time.  Can someone run a department (beyond a “tech-lead-y” line management role) and also have legitimate business reasons to bang out code, and do it halfway decently?

I have a hypothesis that the answer is yes.

Yes, people can run non-trivial organizations while having good reason to code.  And no, applied, simultaneous technical and business savvy are not mutually exclusive.

Read More


DaedTech Digest: Do You Worry about an Unoccupied House?

In past DaedTech digests, I’ve talked about the topic of whether we miss our stuff and about packing.  This kind of naturally gives rise to something that people ask me here and there.

Do you worry about leaving your house unoccupied for long periods of time?

The simple answer to that is no, we don’t.

But that wouldn’t make for much of a mini-blog-post, so let me elaborate a bit.  There is a set of circumstances that apply to us, but may not apply to others.

First, as I mentioned once before, our primary residence is something we purchased originally as a lake house.  We don’t exactly think of it (or anything) as a primary residence, and that informs our lack of concern.  In short, this is a house that we have a lot of practice leaving unoccupied for long stretches.

Also because this is a lake house, it doesn’t exactly make for a rich target for thieves, particularly during the winter.  The house exists in a sleepy little town with the sort of crime rate you’d expect in such a place.  Plus, most of the houses on these lakes around here are vacation properties or rentals, meaning slim pickins when it comes to things of value.  People tend not to stash their bearer bonds and family heirlooms at summer homes.  So, between that and our ADT alarm system and Nest cam, we’re not overly worried about break-ins.

And the final point is that my wife and I have lived life in transit for quite a while now, which creates an existence that necessarily deemphasizes material stuff.  So even if a break-in or Biblical flood or something happened, we’d just be out a bunch of stuff we hadn’t seen for a while anyway.  An insurance check, and we’d be all set.

If you decide to go the slow travel route, it might feel nerve-wracking at first to leave your place.  But practice makes perfect.

And so, without hesitation, we pack up the car, assign one of the cats as navigator, and hit the road.


  • This is kind of a strange pick because it’s not a service that I’ve used myself, but rather one that someone recommended to me today.  It’s called wealthfront, and it’s apparently a savings/investment tool that lets you specify your risk level, including a “never let this go below my original investment” setting.  So you can get a nicely higher return than a savings account, but without risk.
  • This is sort of a weird pick, because it’s more like a tiny hack.  But if you have a card or a board open in Trello, and you delete the URL information after its basic identifier and add “json”, you can see all of its API details.  This post describes it.

The Digest

And, that’s it.  Kind of a thin content production week for me, obviously.  I’ll have to try to step up my game on various other blogs.  As always, have a good weekend!


Value Prop Workshop: A “State Matrix Audit”

Alright, let’s try something new for this week’s reader question.  As regular readers know, I do a “you asked for it” column where I answer reader questions.  But lately, I’ve been getting a specific form of questions.

People ask for help with their free agent/moonlighting value propositions.  Sometimes, these requests even involve offering to pay me some sort of hourly consulting rate.

Well, since I don’t do B2C consulting, and since I do have a blog to write, I’ve decided to start using these requests as fodder for blog posts.  My hope is that some examples round out various posts that I do on the subject.

So here’s what I’ll do.  If you have nascent ideas on positioning and value propositions and want feedback, hit me up via email (erik at daedtech) or on Twitter or something.  Let me help with your positioning ideas.

I haven’t yet fully worked out the best format for this, obviously, but I figure we can iterate.

The Value Proposition

Alright, let’s get down to business.  Here’s the first idea for a value prop that a reader sent to me.

I sell State Matrix Audit to small dev teams.

My ideal client is a team that built an app which works most of the time. But the devs or the management want to be sure it is correct and has [high availability]. My contribution is to audit the tech stack and application code and provide a report – which sequences of failures would lead to error states (downtime, data loss, etc). Along with estimated recovery times, automation suggestions, stack tweaks, etc.

I have a great track record of doing just this as a salaried employee and am thinking about converting this into a consultancy company of one.

The request was some help in refining this value proposition.  So let’s dive into this.

There’s a Lot to Like Here

First of all, let me address the state of the current prospective value prop.  And, I think it’s a relatively strong one on its face.  There’s a lot to like here.

The first favorable thing is that this sits in the realm of road-mapping.  In a post I wrote some time back, I talk about four phases of problem solving.

  • Diagnosis of a problem.
  • Prescription of a therapy.
  • Application of the therapy.
  • Re-application/maintenance of the therapy.

The further left (up?) you move with this, the more you’re perceived as an expert.  This means higher rates, better treatment, more demand, and generally a better life.  One of the problems with miscellaneous app dev is that it tends to sit squarely in the third bucket (with the first two often given away for free and called “discovery.”)

We don’t have that problem here.  This is diagnosing and prescribing therapy.

There’s also a clear appeal to the people within the organization that hold the purse strings.  People in leadership have a definite interest in acquiring knowledge ahead of time when it comes to potential outages, errors, etc.  It also helps that you offer remediation.

This is the core of something good.

Read More