New article at Ranorex, “Raspberry Jam Gets Thin in the Pool”

raspberry jamRaspberry Jam Gets Thin in the Pool (16-Jul-2018)

“The more you spread it, the thinner it gets.” — the late Gerald Weinberg

In this blog post for Ranorex, I talk about the mass growth of our industry, and how as a result developers have on average less experience than ever before. I talk about some ways in which we might thicken up that jam.

The Consulting Legitimacy Cycle: 4+ years to 2 weeks

Four years ago this month, I wrote “The Consulting Legitimacy Cycle,” a post about cycling between predominantly consulting/training and predominantly in-team software development. At the time I’d been consulting for about 15 months, and was pondering when I might next return to full-time development.legitimacy

It turns out that the answer was “a little more than a year.” I signed on to Outpace Systems as a remote developer in August 2013, and wound down my other engagements to be fully engaged with Outpace by the end of the year. Thus after about 2 and a half years on the consulting side of the cycle, I switched to the development side, where I would spend almost 2 and a half years.

Outpace would turn out to be the biggest challenge I’d had in a long time: a pile of new technologies with which I had little familiarity kept me under water for at least the first six months. I’ll be honest and blunt: I felt like an idiot for a half year.

During those first six months at Outpace, I would bounce virtually every day or every other day to something completely different. It kind of works when pairing… but it sure takes a long time to ramp up on something! We began to replace Ruby with Clojure a couple months in, which was great. But when you code in a new language for a day, and then don’t touch it for a week, it takes a long time to get proficient. At maybe a day a week, it took me six months before I began to feel reasonably comfortable in Clojure.

(Among the bigger learning curve elements: using a Mac daily for the first time, the sheer hell of learning Emacs for someone with a solid preference for vim, and for the longest time, a New Library of the Week. See “Surviving Chaos With Pairing” for the complete list of technologies.)

The upside: I picked up a pile of skills and an updated understanding of the daily feeling of being a real team member, as opposed to experiencing it from the outside as a consultant/coach/trainer. And the regular success we had in delivering software to happy customers lends a lot of credibility to what I learned about process and technique.

I’m convinced that my regular cycling back into “real” development is what helps me relate so well to teams I work with as a coach. They can tell if you really appreciate and understand what their daily life is like.

The downside: the business languishes. I managed to sneak in a few short engagements (mostly training) each year by using vacation. But I was too swamped to invest much energy otherwise: I wrote only a single blog post in two years, my web site started to crumble a bit (and continued to look increasingly outdated), I didn’t tweet much, and most other forms of outreach to customers, existing or potential, languished.

In February of this year, I chose to re-start Langr Software Solutions based on the financial assurance of a regular bi-weekly gig that should last until the end of the year. This time around, I decided that continuing to help deliver real software was going to be in important aspect of sustaining the viability of the business as well. As such, I chose to continue providing services to Outpace, and I’m also seeking to close a freelance development gig.

I’m hoping this continued involvement in “real” software deliver will prevent me from ever having to halt in order to take a full-time development gig again, and will help me keep the business continually vibrant and available. Maybe my Consulting Legitimacy Cycle will change from 2+ years for a half cycle (4+ years for the full cycle) to about a week.


Jerry told me about frustrations at his new company. Here’s a possible conversation from my next interview (if there ever is one):

Jeff: Do you block web sites or other things like IM?
Interviewer: We filter on naughty words, we block web mail, and we also disallow use of instant messaging.
Jeff: Interesting. Why do you block web mail and IM?
Interviewer: Because we’ve found that some people tend to abuse it at the office. They also raise some concerns with respect to security.
Jeff: So you also block phone calls, then?
Interviewer: Of course not.
Jeff: Why not?
Interviewer: Well, people have legitimate business reasons to make phone calls.
Jeff: OK, first, there are legitimate business reasons to use IM. Second, you could block calls to individuals’ homes if you really wanted to.
Interviewer: Sometimes employees have legitimate need for personal calls. We find that’s ok if they don’t abuse the “privilege.”
Jeff: So, if talking on the phone all the time was a problem, a manager might intervene and have a discussion with the employee. That seems reasonable. It also seems reasonable that an employee might have a similar, legitimate need for personal emails from time to time.
Interviewer: But we block webmail.
Jeff: Thank you, and have a nice day.

Let’s face it, companies rarely change abusive policies like these. Sometimes, the best we can do is voice our disapproval and vote with our feet.