DaedTech

Stories about Software

May
3

By

Applied Consultant Taxonomy to Prevent Confusion

Category: The Life of a Programmer Tags: | 2 Comments

A few posts ago, I proposed a taxonomy for software consultants.  My reasoning for doing so was that I wanted to attempt a bit of clarification.  As software has taken over the world, “consultant” is no longer singlehandedly up to the challenge of describing everyone working in software not associated with any particular domain.

So I proposed the terms software pro, specialist and consultant as a means of bringing some clarity.  At the end of that post, I also alluded to a future post, in which I would talk about the problems that crop up when one of these personas is mistaken for another.  This is that future post.

Having been in and around the consulting world for a long time now and having served time in all three of these roles, I’ve seen firsthand how weird and sometimes damaging confusion of these roles can be.  There are too many permutations of mistake for me to want to list all of them in a post, so I’ll stick to the ones that are the most common and interesting, in my opinion.

The Aggrieved Grunt

For better or for worse, rightly or wrongly, software pros are regarded as the grunts of the non-salaried software development world.  Consultants and specialists are hired in non-delivery and possible-delivery roles, respectively, which means that they’re being hired for their expertise.  Software pros are hired into delivery roles, and while their expertise may interest their clients, it’s their labor that’s being purchased.

DevOpportunityCost

A non-expert labor purchase has two interesting characteristics for our purposes here.

  1. It means that someone else, and not the software pro, is making the strategic decisions (i.e. “we’ve put together all the requirements and design specs and need you to code ‘em up”).
  2. It puts the software pro firmly on the hook for execution.

Significantly, the software pro’s charter looks a lot like the line-level developer’s charter.  After all, architects and team leads make strategic decisions, and managers supervise delivery rather than owning it.  The grunt coders on the team, by contrast, faithfully execute the strategic visions of others.  So if we map the consultant taxonomy to familiar team roles, consultants are roughly like managers, specialists are roughly like architects, and software pros are basically developers.

Read More

Apr
28

By

Hiring is Broken… And It Isn’t Worth Fixing

Category: The Life of a Programmer Tags: , , | 52 Comments

Usually I fly home from client sites late in the day, but the whims of fate had me driving home instead, early (for me, anyway) this morning.  The end result was a pocket of uncommon free time this evening, before resuming long days and seemingly non-stop travel on the morrow.  Naturally, I wasted this free time poking around the internet.

My travels led me, via Twitter, to this blog post entitled, “F*** You, I Quit — Hiring Is Broken.”  Apparently, this led to some heated, sometimes-angsty debate on Hacker News, where the original piece earned a good number of points.  And, why wouldn’t it?  “Hiring is broken” would serve as a rallying cry for those who don’t play the interview game well, while seeming a shot across the bow of those who do and are now on the other side of it.

Read the article, please.  You need to for context, because when I reference it further, it’ll just be a reductionist tl;dr.  I’ll come back to that.  First, I’d like to address one of the few points that almost everyone seems to agree on, before they get down to armchair dissection of Sahat’s character and market worth.

The hiring process is imperfect deeply flawed (if not broken), but no one knows how to fix it.

Except, that’s not actually true, because I know how to fix the interview/hiring process.  It’s actually pretty easy.  Just stop doing it.  If the value proposition you’re offering to prospective laborers is so weak that you have to solicit and subsequently torture strangers, you should prioritize fixing your organizational mess above making the mess larger (or, in the case of attrition, before doing the same thing again).

Trivia Interview demonstrate why hiring is broken

I’m honestly not kidding, but let me come back to the mindless growth point later.

Read More

Apr
26

By

Please Stop “Geeking Out”

Category: The Life of a Programmer Tags: | 6 Comments

Mostly, I try to stay away from semantic quibbling and I almost always try to stay away from anything sensational, so please forgive me in advance.  I’m taking a hard line of sorts with a blog post entitled, “stop geeking out.” and I’m somewhat doing so for effect.  But this is coming from a place of earnestness.

I don’t really care too much about the term “geek” in and of itself; it’s the concept of “geeking out” that frustrates me.  And it truly is the concept — I’m not interested in term policing.  It’s not like I’d blow a gasket and be insufferable toward someone saying this in front of me; rather saying it in front of me inspires sort of a vague sadness in me, upon which I wouldn’t bother to comment.

But before I get to the reasons for my objection and my sadness, let’s take a look at the origins of the term “geek” as we know it today, originating from the idea of a “geek show.”

The Online Etymology Dictionary give the following for “geek”: “sideshow freak,” 1916, U.S. carnival and circus slang, perhaps a variant of geck “a fool, dupe, simpleton” (1510s), apparently from Low Ger. geck, from an imitative verb found in North Sea Germanic and Scandinavian meaning “to croak, cackle,” and also “to mock, cheat.” The modern form and the popular use with reference to circus sideshow “wild men” is from 1946, in William Lindsay Gresham‘s novel Nightmare Alley (made into a film in 1947 starring Tyrone Power).

The billed performer’s act consisted of a single geek, who stood in center ring to chase live chickens. It ended with the performer biting the chickens’ heads off and swallowing them.[1] The geek shows were often used as openers for what are commonly known as freak shows. It was a matter of pride among circus and carnival professionals not to have traveled with a troupe that included geeks. Geeks were sometimes alcoholics or drug addicts, and could be paid with liquor – especially during Prohibition – or with narcotics.

Okay, so quick recap.  Before the term meant “technology enthusiast” it meant, “idiot substance-abuser that earns a living performing unspeakable acts to amuse mobs.”  That’s quite the transition!

GeekShow

The Historical Connection

Let’s examine that transition a bit.  When I was a kid in the 1980s, I remember “geek” being an insult, but it was sort of interchangeable among a bevvy of insulting synonyms: dork, dweeb, nerd, etc.  You can go looking for meaning in a taxonomy if you’re so inclined, but I don’t remember much distinction.

But, as I’d learn later, “geek” had a special and unique flavor of implication.  It conveyed obsession and interest in technology.  Interesting.  But how do you get from “slow-witted alcoholic that will eat chicken heads for free booze” to “guy that really, really likes computers?”

Read More

Apr
20

By

A Taxonomy of Software Consultants

Category: The Life of a Programmer Tags: | 13 Comments

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.

DevSkills

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

Apr
18

By

How to Get People to Review Your Code

Category: The Life of a Programmer |

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.

DevOpportunityCost

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

« Older Posts
Newer Posts »