DaedTech

Stories about Software

By

Hiring is Broken… And It Isn’t Worth Fixing

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

By

Please Stop “Geeking Out”

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

By

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.

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

By

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.

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

By

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.”

OppenheimerChoking

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