Stories about Software


A Taxonomy of Software Consultants

The conversation that follows this paragraph is a dramatization.  But it’s a composite of actual conversations that I’ve held, distilled and focused.  And I think it will illustrate why I believe we need a taxonomy of software consultants.

“What do you do?”

“Oh, I’m a software consultant.”

“Oh, nice.  So, what, you like, go out to client sites and help them with their projects?”

“No, I work for a software consulting firm and I just go there.  My company writes apps for other companies, and I’m on a team working on something for one of those companies.”

“Ah, okay.  Do you interact with your client over the phone or via chat or something?”

“No, that’s mainly the project manager — I just code up requirements.”

“Oh, gotcha.  So no one really consults with you, per se.”

“Yeah, huh, I guess not.  I guess I’m more like a contractor or something.”

The surface problem here is that the definition of consultant has been somewhat watered down.  But I’d say the deeper-seated problem is one rooted in history.

In a world (of, say, 30 years ago) where software was mainly a maintenance concern for line of business automation and hardware-based products, the people that wrote code were employed by the companies that consumed the code they wrote.  Someone without domain knowledge that went around writing software would rightly have been considered a consultant, since specialized knowledge of software was uncommon.  But as the balance of the world shifted to software being ubiquitous, someone unmoored from a particular domain, writing code for a living, is no longer highly specialized nor is that person likely to be consulted for their unique expertise.


As the world evolved, however, the terminology did not.  A software consultant continues to be defined as “anyone who writes software for a company other than the one direct depositing pay into their bank accounts.”  This can be the ‘consultant’ described above, an agency staff augmentation, a CRM specialist installing a CRM installation, or a person advising the dev manager on a migration strategy.  To gain some clarity, I propose some clarity around terms.

Read More


How to Get People to Review Your Code

Editorial Note: I originally wrote this post for the SmartBear blog.  Go check out the original here, at their site.  If you like this content, there’s a lot more over there, by numerous authors, to check out.

On the bus ride of my career, the stops have been numerous and eclectic, much like a line that runs through an entire city.  On the subject of code review alone, I’ve seen the gamut.  I’ve worked in an environment that prided itself on mandating that every line of code, written anywhere, be reviewed by several people.  Because HIPAA or ISO or something.  I don’t recall.  I’ve also been in a situation where my instructions were “here’s a bunch of C code on a hard drive, and if anyone else ever looks at what you do with it, that will be because you’ve done something terribly wrong.  Oh, and you should probably backup the C code from time to time.”

I mention this because I’m anticipating varied reactions to the title of this post, which is very much “what you see is what you get.”  I’m going to offer you advice on how to convince people to review your code.

A lot of you reading are probably thinking, “that’s crazy — what kind of shop doesn’t do code reviews?”  Some of you are probably thinking, “I wish I had that problem because I’m sick of micromanagement.”   But, even if it seems improbable to these two groups, there’s a cross section of folks reading and thinking, “Yes!  I’d love to get some feedback for once.”

Believe me when I tell you that there are legions of folks out there, particularly less experienced developers, that would love more feedback.  They’d love to understand the tricks of the trade from grizzled veterans.  They’d love to learn to anticipate mistakes and pitfalls before getting calls outside of working errors because they’ve dumped some avoidable bug into production.  They’d love to improve their craft in ways more interactive than online training videos and books.  But, they don’t have much luck.


It might be that they’re lone developers in their small companies, and, if that’s the case, there’s not all that much to be done as long as their solo labor remains the status quo.  But, more likely, they just work in a group where the development labor is heavily siloed and/or where all of the experienced developers are extremely busy.  In this scenario, there is plenty that can be done to secure meaningful feedback.

Read More


Gathering the Confidence to Leave Your Job

It’s Thursday night, and I’m holed up in a hotel in Lansing, Michigan.  I figure there’s never been a better time to answer a reader question.  This one is about how to summon the confidence to leave your job.

The question is actually a rather lengthy one, and here is a redacted/obfuscated version of it (removing anything that could be identifying).

I have had my developer position for several years. I’ve been promoted, but I’m still not a senior developer. I have become extremely “silo-ed” in my skills, because those are the types of projects I’ve been assigned.  I read your statement that salaried employment is a bad economical decision for developers. The developer should be making $50 or maybe a bit more at $60. I get paid {a good bit less} an hour for 40 hours a week of expected work.  I feel the need to grow my abilities.

I watched your video on Pluralsight on how to propose practices. My manager bought into some,  but most of my coworkers are ignoring the new stuff.  My place of employment fires developers once they are called as a references for checking if they ever worked there.

I need a goal, something I can achieve to give me confidence to start pursuing other options. Something that gets me into a situation where people seek me for relevant development.

There are actually several questions and issues here to unpack, so I’ll tackle them in order of complexity.

Pay is Relative

First of all, when I talk about developers making 50 per hour/100K or 60 per hour/120K, I’m mainly catering to myself and ease of math.  100K is a nice, round figure, and 120K makes monthly finace (10K) easy to calculate.  These figures were slightly high in the Chicago-land area as of 2+ years ago, which was when I was last seriously hiring and evaluating pay there.

But, beyond that, pay varies a lot by geographic location, industry, filing status (nonprofit, for profit), etc.  If you salaried a developer working in San Francisco at 150K per year, he would probably need to move into a homeless shelter.  (I kid, but only slightly).  Pay that same wage to someone in central Kentucky and “should we install a second hot tub on the master bedroom deck” becomes a topic of debate around the marble dinner table.

All that being said, your wage was fairly low for a developer anywhere of your experience.  But don’t base your assessment of how low on my blog and what I know (I don’t pay much attention these days).  Base instead off of researching in your region.

We’ll Fire You for Looking…

Okay, this is where I offer the IANAL (I am not a lawyer) caveat.  This is based on my experience doing management consulting and working as a manager, much of which happened in at will states (this can vary by state and certainly by country).

If you’re a company, terminating employees is like playing Minesweeper, except instead of bombs, there are lawsuits.  You’re clicking along gleefully when suddenly, one day, BLAMMO!  Wrongful termination!  So you learn your lesson and you start looking at all of those numbers really carefully and insulating yourself against potential problems.

Minesweeper Read More


Are Your Arguments Falsifiable?

Editorial note: I’d like to clarify something here upon re-reading this post.  When I refer to not engaging comments, I’m talking about in other venues (other blogs than mine, social media, and sites like reddit).  On this blog, I do my best to engage with everyone that takes the time to leave a comment, regardless of its contents.  Please don’t read this as any sort of deterrent to commenting — keep ’em coming!

These days, I’m writing for 6 blogs besides my own.  All of the posts get announced on social media and some of them wind up on commentary sites like Hacker News or Reddit, which means that there’s a lot of surface area, so to speak, for comments.  I make a good faith effort to respond, but I must confess that my response/comment ratio is declining amidst lots of writing and my consulting practice.

My failure to respond to a comment tends to fall into one of three categories.

  1. Never saw it.
  2. Saw it, made a mental note to come back and respond later, but “later” never came.
  3. /Sigh/

It’s this last, and admittedly enigmatic category, about which I’d like to talk today.

The Ones that Make Me Sigh

You’re probably thinking here that I’m talking about the occasional piece of random insult or profanity.  Perhaps someone leaves a comment on the site saying, “you’re a #&%$ing idiot.”  But no, it’s not that.  A comment like that (which is actually refreshingly rare) doesn’t induce much reaction in me one way or the other.  Just a half amused, half bemused, “well, okie dokie.”


The ones that make me sigh are comments that I think of as “specious definers.”  They are thoughts offered as correction and conversation advancement, but that wind up falling flat in a subtle way.  Make no mistake — these are thoughts offered in earnest, and I’m not complaining about tone or being corrected or anything like that.  Rather, I’m lamenting that I read, re-read, and re-read again, and realize that what I’m looking at is a near tautology.  It’s a non-falsifiable closed loop, to borrow slightly from Karl Popper.

Let’s get out of generalities and deal with a couple of examples.  Please note at this point that I’m operating off of admittedly imperfect memory, and thus paraphrasing.  I don’t know where either of these examples is nor even in what medium it was offered.  But please believe that I have no real interest in distortion here — the critiques are not objectionable.

Read More


Visualizing Your (Real) Architecture

Editorial note: I originally wrote this post for the NDepend blog.  Go check out the original at the NDepend site.  Take a look around at the other posts while you’re there as well — there’s a lot of good stuff to be had.

Diagrams of software architecture have a certain aesthetic appeal to them.  They usually consist of grayscale or muted pastel colors and nice, soft shapes with rounded edges.  The architects that make them assemble them into pleasing patterns and flowing structures such that they often resemble 7-layer cakes, pinwheels, or slalom courses.  With circles and ovals arranged neatly inside of rectangles connected by arrows, there is a certain, orderly beauty.  If you’re lucky, there will even be some fluffy clouds.

If you want to see an example, here’s one that has it all.  It’s even got a service bus.  Clearly, the battle for quality was over long before the first shots were ever fired.  After the initial conception of this thing, the mundane details of bringing the architecture to life would likely have been a simple matter of digital paint by numbers.  Implement an interface here, inherit from a framework class there, and Presto!  Instant operational beauty that functions as smoothly on servers as it does in the executive readout power point.

At least, that’s the plan.

Read More