Stories about Software


Growing the Ideas from the Developer Hegemony Book

Happy reader question Friday, everyone.  Today, I’ll field a question about the Developer Hegemony book.  For any newer readers, I wrote this book over the last couple of years and published it to Amazon in early May.  For a briefer synopsis of its purpose and message, you can check out this announcement post.

The question was a lot longer than this (and contained some much appreciated kind words).  But I’ll leave out any personal details and the backstory and leave just the question (paraphrased).

Aside from joining the Facebook group on the “What Now” page and spreading the word via social media, is there anything else I could do to help you get these ideas to more developers?

For some quick housekeeping, here’s the page in question and the Facebook group, too (feel free to join!).  I appreciate the question, and I also understand it.  I mean, of course I literally understand the English language.  But I mean that I understand the necessity of the asking.

The book release coincided with my “retirement” from IT management consulting.  I went home, published a book, and dedicated my time to three simultaneous pursuits: a dev tools content marketing business, a specialized codebase analysis practice, and selling my primary residence in favor of what I think of as “cosmopolitan homelessness” (and moving).  I offer this not as an excuse, but as an explanation.  I’ve been distracted.

Me going cosmopolitan homeless following the release of the developer hegemony book.

The Developer Hegemony Book’s Promise and the What Now

The upshot of my flurry of activity has included not doing a lot to pursue or facilitate the book’s vision.  I’ve made occasional posts to the Facebook group and I’ve added some content to my Youtube channel about how to get a Tax ID and start a corporation.  But I haven’t exactly kept the pedal to the floor and started a movement in earnest.

So I’ll take on this question and the rest of the post from the perspective of “what would I do to advance the cause if days were 32 hours long and I had more time?”  After all, no one has more interest in advancing the cause than me.

I should also mention that the book contains my thoughts on how individuals and organizations can move toward Developer Hegemony.  I won’t rehash that here, opting instead to address the specifics of how to spread the ideas.

Read More


Starting a Software Company from Scratch

When I reflect back on my free agent career, it strikes me that I more or less did everything wrong.  I mean, I don’t actually believe that when I look at it analytically.  But it does feel that way, knowing what I know now.  Starting a software company from scratch invites plenty of missteps.

In the lead into last Friday’s reader question post, I talked about starting this blog as a journal of sorts.  That’s a good example of what I’m talking about.  In the end, I built an audience, established a brand, and wound up in a good place.  But if I could go back in time 7 years and give myself advice, my path would have been more direct.

It goes beyond blogging, of course.  That was one example, but it applies generally to my entire approach to starting my software development/consulting company.  I did things that worked out, but it hardly seems optimized in retrospect.

You’re probably thinking that this applies to everyone.  Hindsight is 20/20 and all that.  And you’re right, which is exactly my point.  I dove in with severely imperfect knowledge, made a lot of mistakes, and it still worked out pretty well.

If you pursue the free agent life, you’ll flail, make mistakes, and have some false starts.  But you’ll recover, figure it out, and do fine, even if it sometimes seems like you’re drowning in the moment.

Flat Squirrels and Driving Directions

Perhaps you’ve heard an expression.  “Be decisive. The road of life is paved with flat squirrels who couldn’t make a decision.”  Don’t blame me for the macabre nature —  I didn’t make it up.

I like part of the sentiment, but I think it misses the mark slightly.  If you picture a terrified squirrel in the road, its biggest problem is thousands of tons of steel and plastic death bearing down on it.  It starts left, then moves right, then freezes and then… well, you get it.  Indecision costs it dearly, but only once it has a large problem already.

When starting a software company from scratch, indecision won't flatten you, but it will impede your progress.

This probably doesn’t describe you in most situations that call for more decisiveness.  We face paralysis by analysis, rather than paralysis by mortal terror.  Have you ever sat in your car, debating whether to take the highway or side roads during rush hour?  Have you ever sat there debating this for so long that you get to your destination later than if you had simply picked either option and started immediately?  (Come on, I bet you have.)

This makes for a better analogy for our lives, especially when it comes to starting something new.  We put off action out of fear of taking a sub-optimal path.  But, at some point, even a sub-optimal path beats sitting in your car fretting.

Read More


Developer Hegemony: The Crazy Idea that Software Developers Should Run Software Development

Well, today we officially launch the book, Developer Hegemony.  I’d like to thank everyone who followed along, offered feedback, bought books, and generally supported the efforts.  I’ve enjoyed the ride and I hope you all love the book.  Also, congratulations to the winners of the Thunderclap raffle: Justin Neff, Jim Wang, and Gintautas Miselis!  I will be sending free copies their way.  Thanks to them and to everyone that participated!

In the final days of writing Developer Hegemony and throughout launch preparation, I wrestled with an elevator pitch.  As regular readers know, you wouldn’t find “brevity” listed on my resume, even if making resumes was something I did.  And so I struggled.  But I think I have it now.

“Why aren’t software developers in charge of the software development industry?  Developer Hegemony explains why not, and it explains how we fix that problem.”

Today, I’ll explain the book by expanding on this elevator pitch a bit.

Who’s In Charge Here, Anyway?

So, if software developers don’t run the industry, who does?  To answer that question, understand the context in which most developers write software.  It happens in the corporate world, which consists of companies shaped like pyramids.


Reminiscent of military organizations, a tree-like chain of command serves as the scaffolding for most companies.  The CEO gives orders to a handful of C-suite members.  These people, in turn, give orders to a larger number of vice presidents, who then give orders to a whole bunch of directors.  The directors then give orders to hordes of managers, who pass those orders down to legions of grunts.  Finally, with the grunts, you arrive at the leaves of the tree and the bottom of the pyramid.

And those leafy grunts write the world’s software, carrying pyramids of management upon their backs.  So who is more important than software developers in the business of software development?  Literally gigantic pyramids of management.  Oh, and you can also toss in some people who technically exist in the same level of the reporting organization but have titles like “analyst” or “project manager.”

So the question shifts from “who is more important than software developers in the business of software development?” to “who isn’t?”

Read More


The Efficiencer’s Guide: Getting Started

You thought Developer Hegemony Week stopped on Friday?  Nah.  Today I give you post 6.  It contains somewhat lighter fare, since it’s the weekend, but the show must go on.  We’re doing really well on the Thunderclap campaign — 83% as of this writing.  But that means I still need 17 more people to do the raffle.  So, please help me out and spend a few seconds signing up!

In the book, I coined this term, Efficiencer.  I also talked about it on the blog this week.  Today, I’d like to offer what I’ll call the efficiencer’s guide (or, at least, the start of it).  I’ve called out a number of idealized behaviors and philosophies, but haven’t given a lot of practical field advice.

For the purposes of the efficiencer’s guide, I’ll assume you work as a salaried software developer in some organization.  This probably describes most of my audience, and it makes for a natural starting point in this journey.  If you’re already a free agent or you don’t write software, don’t worry.  You can still get some info here.  I’m going to include reading materials and links, so I have something for everyone.

Defining Efficiencer

First things first.  I won’t ask you to go do a bunch of homework.  Instead, I’ll define this term again, off the cuff.  I’ve described it in the book, but I invite you all to participate alongside me in kind of an evolutionary definition of the term.

I think of software developers (or engineers or programmers or whatever) as people who collect a salary to write code.  I feel fairly confident that this definition has blown exactly 0 of your minds.  But consider it maybe a bit more literally.  You collect a salary to code… and, that’s it.

Therefore, you don’t worry about business considerations like sales or marketing.  You generally don’t participate in discussions about why you write the code that you do.  Nope, you just show up, get a spec or something, fire up your IDE, and get to work.

The efficiencer, on the other hand, does ask why.  In fact, the efficiencer doesn’t do any work without understanding and approving of the why.  You see, she doesn’t count herself a coder but an automation professional.  She specializes in making you more efficient.  That might mean writing some code, or it might just mean sending you a link to a COTS product that already does what you want.  She doesn’t accept specs or story cards or requirements or anything like that.  She listens to your business goals around cutting cost or increasing revenue, and she decides how that will happen.

Read More


A Closer Look at the Efficiencer Firm

For Day 3 of Developer Hegemony Week, I’m going to up the stakes on the Thunderclap.IT campaign.  If you sign up, you could win a free paperback copy of the book.  I’m going to raffle off three books at random for everyone that signs up, but only if we meet the goal of 100 participants.  We’re more than a third of the way there, but still have a long way to go.

For Monday morning’s post, I introduced the efficiencer in detail.  But I took an admittedly philosophical tack in that post, offering more rhetoric than specifics.  Today, I’d like go get specific instead.  I want to talk about more pragmatically about the efficiencer firm.

In order to do that, I’m going to start by talking about inefficiency.  After all, as efficiencers, we ought to have a keen eye for such things.

My Stint Making Hearing Aid Fitting Software

Years ago, I went to work for a company that manufactured hearing aids.  This included several brands under the umbrella of the parent corporation, and all of them had international distribution networks.  So, at the end of the day, the company does everything needed for the manufacture and global distribution of hearing aids.

Operationally, this includes something you might not consider at first blush.  Hearing aids need something called fitting software.  The people responsible for prescribing hearing aids to the population, audiologists, use this software to program the devices.  This includes configuring different gains at different frequencies and setting up so-called “programs” that wearers can use in different environments.  For instance, you might have a “restaurant” program with a much different array of settings than a “home watching TV” program.

Since you didn’t come here to learn the particulars of the hearing aid business, I won’t keep going with further detail.  But I could.  A lot.  As I would learn during my tenure there, developer in this space face a steep learning curve.  The complex nature of sound and gains mixes with the bureaucratic world of medical devices and regulations for a rich tapestry of arcane complexity.  Months passed before I got my bearings there.

Read More