Stories about Software


The Key to Becoming a Software Consultant

Recently, I made an idle threat on Twitter (shown below).  I was thinking of creating some content along the lines of how to go from being a software developer to a software consultant.  People ask me about this all the time, and it makes for an interesting subject.  I was also flattered and encouraged by the enthusiastic response to the tweet.

I’m still mulling over the best delivery mechanism for such a thing.  I could do another book, but I could also do something like a video course or perhaps a series of small courses.  But whatever route I decide to go, I need to chart out the content before doing anything else.  I could go a mile wide and a mile deep on that, but I’d say there’s one sort of fundamental, philosophical key to becoming a software consultant.  So today I’d like to speak about that.

Software Consultant, Differentiated

I won’t bury the lede any further here.  The cornerstone piece of advice I’ll offer is the one upon which I’d build all of the rest of my content.  You probably won’t like it.  Or, you’ll at least probably think it should take a back seat to other pieces of advice like, “be sympathetic” or “ask a lot of questions” or something.  But, no.

Don’t ever let would-be consulting clients pay you for code that you write.

Seriously.  That’s the most foundational piece of your journey from software developer to software consultant.  And the reason has everything to do with something that successful consultants come to understand well: positioning.  Now, usually, people talk about positioning in the context of marketing as differentiating yourself from competitors.  Here, I’m talking about differentiating yourself from what you’re used to doing (and thus obliquely from competitors you should stop bothering to compete with: software developers).

Let me explain, as I’m wont to do, with narrative.

Leonardo Da Vinci: Renaissance Plumber

By any reckoning, Leonardo Da Vinci was one of the most impressive humans ever to walk the planet.  Among his diverse achievements, he painted the Mona Lisa, designed a tank, and made important strides in human anatomy.  But let’s say that, in a Bill and Ted-like deus ex machina, someone transported him 500 years into the future and brought him to the modern world.

Even someone as impressive as Leonardo would, no doubt, need a bit of time to get his bearings.  So assume that, as he learned modern language, technology, and culture, he took a job as a plumber.

Leonardo Da Vinci as a plumber to help you understand the difference between software developer and software consultant

Let’s assume that you happened to have a leaky sink faucet, and you called Leonardo’s plumbing company for help.  They dispatched him forthwith to take a look and to help you out.

So Leonardo comes over and, since he’s Leonardo, figures out almost immediately that your supply line has come slightly loose.  He tightens it, and you couldn’t be more pleased with the result.

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


Always Be Leaving

Last Friday, I published a post called “The Polyglot’s Dilemma”.  I had actually had a stubbed draft for this post, “Always Be Leaving,” before writing that one.  But it turns out that post segues nicely into this one.

Programmers (especially polyglots) face a dilemma wherein the thing that makes them most employable (broad generalist skills) also positions them as resources rather than strategic experts.  To make matters worse, broad industry generalizing also puts programming labor in the category of fungible commodity.  Knowing many languages and techs makes it easy for a company to assign you to any arbitrary upcoming automation project.  But it also makes you easily replaceable by any similar generalist.

The polyglot generalist comes to the company as an easily-deployed generalist.  He then waits for people tasked with organizational strategy to deploy him.  But then, of course he does.  This represents the only way for him to remain indefinitely engaged as an employee.  A specialist comes in to execute on a limited duration charter.  A generalist signs on to do whatever the company happens to need for the rest of his career (theoretically).  This context demands a generalist, since nobody knows what the company will need in 5, 10, or 20 years.

And so we see that the polyglot’s dilemma arises naturally from indefinite employment.

Leverage: A Study in Contrasts

“Always be leaving,” as a title probably reminds you of the pop culture sales phrase, “always be closing.”  Popularized by movies like Glengary Glenn Ross and Boiler Room, it evokes images of the iconic pushy sales guy.  This sales guy does things like cold call you and say, “should I sign you up for two or just one?”  See what he did there?  He gave you no option to say no.  Slick man that he is, he’s always closing.

If you take the self-important testosterone out of the situation, you can see a more basic psychological reality.  “Always be closing” applies to situations with little to no leverage.  Fast-talking sales guys call up “whales” and, through force of personality, convinces them to buy stocks they don’t need.  He has no actual leverage — nothing they really want — so he exerts his dominance by turning on the forceful charm and bamboozling them.  Then he high fives his buddies afterward and rings a bell and screams or some such idiocy.  He creates leverage theater in order to secure the metaphorical kill.

“Always be leaving,” on the other hand, offers a complete leverage reversal.  When you find yourself ending an engagement or an employment tenure, you have tons of leverage.  But you usually forgo using it.  You give your notice, and the notified party often asks what it can do to keep you, even though you feel excited looking ahead to the next thing.

Read More


From Developer to Consultant

Editorial Note: Next week, I’m going to Panama to explore the canal.  I have no idea how much internet access I will see, so next week could potentially be a quiet week for DaedTech posting, if I can’t log in to publish a few cross posts.

If you write software, but not for the company that signs your paychecks, this title may sound strange to you.  “What do you mean, ‘from developer to consultant,’ when you can be both?”  I have answered that question previously, so I won’t rehash it here.  Suffice it to say writing code for someone other than your employer does not a consultant make.  (But read that post, seriously, because it becomes even more important later in this one.)

A few readers have submitted variants of the same question, so I’ll capture it simply, and as a composite.

As an independent, how do I go from doing app dev work to consulting?

I added the bit about independent status because it matters.  Without that, I could answer trivially by saying, “get hired by a consulting firm that wants you to consult, and let them train you.”  But if you go from contract to contract slinging code or if you write code as a W2 employee, you have a less obvious transition.

The Nature of Both Beasts

Before I lay out a tactical set of steps, I need to define the underlying nature of both roles.  In the taxonomy post, I approached the matter in terms of definitions, as one might expect from a taxonomy.  Here, I want to talk philosophy.

I once gave seeking app dev work a satirical treatment.  I asked the reader to imagine a world where, instead of “I’ll fix your garage door” contractors advertised their services with “I have 5 years of hammer, 2 years of table saw, proficiency with 6 kinds of metal, etc.”  As an app dev contractor or W2 employee, you offer the world the latter.  You say, “here’s a brain dump of stuff I’ve done, so all I need is someone who knows how to make me useful and who also signs checks, and we can get going.”  You offer exactly the sum of your experience tuples.


A consultant, on the other hand, offers services akin to general contractors.  “Call me if you have a problem with your garage door, and let me worry about finding someone who can do the job and how many ‘years of hammer’ they need.”  An app dev free agent solves one problem (writes code for someone who can’t) even as he presents another (figure out what skills are needed and manage that person during execution).  A consultant steers clear of execution and offers only guidance.

Read More


How to Get an Edge As a Consultant

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look around at some of the documentation around code metrics and queries.

I’ve made no secret of, and even frequently referred to my consulting practice, including aspects of IT management consulting.  In short, one of my key offerings is to help strategic decision makers (CIOs/CTOs, dev managers, etc) make tough or non-obvious calls about their applications and codebases.  Can we migrate this easily to a new technology, or should we start over?  Are we heading in the right direction with the new code that we’re writing?  We’d like to start getting our codebase under test, but we’re not sure how (un) testable the code is — can you advise?

This is a fairly niche position that’s fairly high on the organizational trust ladder, so it’s good work to be had.  Because of that, I recently got a question along the lines of, “how do you get that sort of work and then succeed with it?”  In thinking about the answer, I realized it would make a good blog post, specifically for the NDepend blog.  I think of this work as true consulting, and NDepend is invaluable to me as I do it.

Before I tell you about how this works for me in detail, let me paint a picture of what I think of as a market differentiator for my specific services.  I’ll do this by offering a tale of two different consulting pitfalls that people seem to fall into if tasked with the sorts of high-trust, advisory consulting engagements.


Read More