DaedTech

Stories about Software

By

Your Job Title of Tomorrow: Efficiencer

Since I boasted about this on Twitter, I have to follow through.  I’m going to do “Developer Hegemony Week” on my blog, leading up to the book launch on May 2nd.  (I suppose this makes Developer Hegemony Week a misnomer of sorts, since we’re talking about 9 days of posts.)  I can think of no better way to kick this off than to talk about “the efficiencer.”  For those of you not familiar, Developer Hegemony is the book I’ve written and am launching on Amazon soon.  In it, I coin the term efficiencer.

First, though, some housekeeping.  I need a bit of help from you, if you don’t mind helping.  I’ve started a Thunderclap.IT campaign to help with the book launch.  Thunderclap operates according to a simple, kickstarter-like premise.  If I can get 100 people to sign up to tweet or share the book, then all of those shares go out on launch day.  If I fall short, all becomes for naught as none of the shares go out.

Okay.  Back to explaining why I’ve coined a word and why you should care.  For the rest of this post, I took an excerpt from the book and modified it a bit.  I’m now offering it here as a canonical definition for the blog.  And in it, I explain why we need to go from shrugging when presented with wire-frames and specs to saying, “I understand the business problem you’re trying to solve — let’s talk revenue goals, and you can leave the specs to me.”

I’m Glad You Called — I’d Love Some Unsolicited Financial Advice!

My cell phone rang about mid-morning, and it presented me with the ultimate conundrum for an introverted entrepreneur/consultant: an unrecognized phone number from my area code. On the one hand, it could have been a prospective client or generally someone whose call it would make sense to take. On the other hand, I didn’t recognize the number, which usually signals some kind of solicitor or scam. I decided to answer because I thought I’d seen the number before. Either someone really wanted to talk to me or I’d have to tell them to put me on their do not call list to get them to leave me alone.

I instantly regretted my decision to answer. A criminally cheerful voice said, “Is this Erik Dietrich?!” You’d think he’d just gotten his personal hero on the phone.

I sighed, recognizing the forced, chipper tone of someone who lives by the motto “Always be closing.” “Yes,” I said guardedly.

He told me that one of my friends had referred him to me, saying that I was someone that would potentially be interested in his services. He was a financial planner, you see, who specialized in helping young couples achieve their dreams — couples like my wife and me, as my luck would have it. “When is a good time for us to get coffee?” he asked after blithely glossing over this dubious introduction. (My friend never had, in fact, briefed me that this guy would call.)

Do you see what he did there? It’s a classic sales technique wherein you don’t give the mark prospect the option of saying no. This bit of slicked-back-hair salesmanship is a close cousin of the “loaded question” logical fallacy. “Have you stopped cheating on your taxes?” “Yes, I mean, no, I mean—hey!!” No matter how you answer the question, you implicitly concede a point made by the asker. In the case of our used-car salesman cum financial planner, answering his question politely leaves me no choice but to agree to meet him.

I sighed again. Briefly, I thought about setting a meeting at some Starbucks in the area and then never thinking about him again. But that seemed disproportionately cruel, so I broke script and told him that I wasn’t interested. After taking one more stab at me with a “When is a good time to follow up to see if you’ve changed your mind?” he’d exhausted his slimy script and hung up on me with no fanfare. Class act from start to finish. I should call him back, say I’ve reconsidered, and set up that phony meeting after all.

Read More

By

Static Analysis for the Build Machine?

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re over there, download a trial of NDepend if you want to see some quantification of the tech debt in your codebase.

I remember my earliest experiences with static analysis.  Probably a decade ago, I started to read about it during grad school and to poke around with it at work.  Immediately, I knew I had discovered a powerful advantage for programmers.  These tools automated knowledge.

While I felt happy to share the knowledge with coworkers, their lack of interest didn’t disappoint me.  After all, it felt as though I had some sort of trade secret.  If those around me chose not to take advantage, I would shine by comparison.  (I have since, I’d like to think, matured a bit.)  Static analysis became my private competitive advantage — Sabermetrics for programmers.

So as you can imagine, running it on the build machine would not have occurred to me.  And that assumes a sophisticated enough setup that doing so made sense (not really the case back then).  Static analysis was my ace in the hole for writing good code — a personal choice and technique.

Fast forward a decade.  I have now grown up, worked with many more teams, and played many more roles.  And, of course, the technological landscape has changed.  All of that combined to cause a complete reversal of my opinion.  Static analysis and its advantages matter far too much not to use it on the build machine.  Today, I’d like to expand on that a bit.

What Does It Mean to Have Static Analysis on the Build Machine?

First point of expansion should be to mention what this means.  In the general sense, this means that the machine responsible for assembling your code into something deployable executes static analysis on said code.  Back when I first discovered static analysis, this would have meant pulling the code from source on that machine, running the analysis and building it.  These days, hopefully your build involves more automation than this.

To get a bit more detailed, a commit may trigger your build machine to kick off a build.  That could just mean compiling your code and packing it into a deployable format.  But shops commonly do other things, such as execute automated unit tests and check on code coverage.  And you can add static analysis to the mix.

You can certainly get creative with how you do this.  But two common (and not mutually exclusive) approaches include having the build generate a code health report and failing the build on egregious violations.

Read More

By

Alternatives to Lines of Code

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, download NDepend and give it a try — see if your code lies in the Zone of Pain.

It amazes me that, in 2016, I still hear the occasional story of some software team manager measuring developer productivity by committed lines of code (LOC) per day.  In fact, this reminds me of hearing about measles outbreaks.  That this still takes place shocks and creates an intense sense of anachronism.

I don’t have an original source, but Bill Gates is reputed to have offered pithy insight on this topic.  “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”  This cuts right to the point that “more and faster” does not equal “fit for purpose.”  You can write an awful lot of code without any of it proving useful.

Before heading too far down the management criticism rabbit hole, let’s pull back a bit.  Let’s take a look at why LOC represents such an attractive nuisance for management.

For many managers, years have passed since their days of slinging code (if those days ever existed in the first place).  So this puts them in the unenviable position of managing something relatively opaque to them.  And opacity runs afoul of the standard management playbook, wherein they take responsibility for evaluating performances, forecasting, and establishing metric-based incentives.

The Attraction of Lines of Code

Let’s consider a study in contrasts.  Imagine that you took a job managing a team of ditch diggers.  Each day you could stand there with your clipboard, evaluating visible progress and performance.  The diggers that moved the most dirt per hour would represent your superstars, and the ones that tired easily and took many breaks would represent the laggards.  You could forecast milestones by observing yards dug per day and then extrapolating that over the course of days, weeks, and months.  Your reports up to your superiors practically write themselves.

But now let’s change the game a bit.  Imagine that all ditches were dug purely underground and that you had to remain on the surface at all times.  Suddenly accounts of progress, metrics, and performance all come indirectly.  You need to rely on anecdotes from your team about one another to understand performance.  And you only know whether or not you’ve hit a milestone on the day that water either starts draining or stays where it is.

If you found yourself in this position suddenly, wouldn’t you cling to any semblance of measurability as if it were a life preserver?  Even if you knew it was reductionist, wouldn’t you cling?  Even if you knew it might mislead you?  Such is the plight of the dev manager.

In their world of opacity, lines of code represents something concrete and tangible.  It offers the promise of making their job substantially more approachable.  And so in order to take it away, we need to offer them something else instead.

Read More

By

Eliminating the Job Interview via Partnership

If you follow this blog with any regularity, you probably know my take on the job interview.  One of my more popular posts asserts that hiring, as we know it, isn’t worth fixing.  And, my book, Developer Hegemony, contains an excoriating treatment of job interviews.  The practice started as a silly whim about 100 years ago, and we’ve just kept doing it, uncritically, ever since.  I’m going to talk today about partnership, and how I think we can leverage it to help.

But let me set the scene a bit, first.  In Developer Hegemony, I talk in more detail about the world without job interviews.  On the blog, however, I’ve just advised developers to interview with companies that minimize the stupidity of the process.  On the company side, the only advice I’ve offered is to picture a world where you weren’t allowed to interview.  Using this creative constraint, come up with alternatives.

Because of this less than detailed treatment, I’ve received reader questions like the following.  And, understandably so.

I love these articles, but I wish you would write one about what I should be doing to make good hires, instead of reinforcing how bad all the possible options I can think of would be 😉

So I’ve decided to address this.  In today’s post, I’ll offer an idea for an alternative.  I may turn this into a series, with different ideas, but I don’t want to get ahead of myself.

Caveat Emptor

First, a quick disclaimer.  What you’re about to read contains absolutely zero long-contemplated, research-backed academic work.  I haven’t even asked anyone for an opinion on this.

Instead, you can think of this more as something I dreamed up in the shower a few weeks ago.  Since then, I’ve idly contemplated it while waiting to board a plane or going for a walk in nice weather.  In this post, I will actually flesh it out in a bit more detail for my own clarification.

I won’t belabor the point further, but I do want you to understand that holes will exist.  I’m not writing this post to give you a ready-made playbook, but to give you the seed of an idea that you might incorporate as you make hires.  And, plus, it feels good to write something optimistic instead of frustrated and cynical every now and then.

Read More

By

Habits that Pay Off for Programmers

Editorial Note: I originally wrote this post for the LogEntries blog.

I would like to clarify something immediately with this post.  Its title does not contain the number 7, nor does it talk about effectiveness.  That was intentional.  I have no interest in trying to piggy-back on Stephen Covey’s book title to earn clicks, which would make this post a dime a dozen.

In fact, a google search of “good habits for programmers” yields just such an appropriation, and it also yields exactly the sorts of articles and posts that you might expect.  They have some number and they talk about what makes programmers good at programming.

But I’d like to focus on a slightly different angle today.  Rather than talk about what makes people better at programming, I’d like to talk about what makes programmers more marketable.  When I say, “habits that pay off,” I mean it literally.

Don’t get me wrong.  Becoming better at programming will certainly correlate with making more money as a programmer.  But this improvement can eventually suffer from diminishing marginal returns.  I’m talking today about practices that will yield the most bang for the buck when it comes time to ask for a raise or seek a new gig.

Read More