Hut 8 Labs

Hut 8 Labs

The Blog

Speeding Up Your Engineering Org, Part I: Beyond the Cost Center Mentality

It is a truth universally acknowledged, that engineering orgs—like greyhounds, sports cars, and wide receivers—slow down as they age.

Odds are good that you have experienced this phenomenon personally at some point in your engineering career. The slowdown was gradual, frustrating, and oddly stubborn. It survived: numerous rounds of hiring; a spate of offsites where inspiring speakers harangued everyone to “cut through the crap” and just “get shit done”; a blood-spattered re-org or two; and even a few ground-up rewrites that utterly failed to deliver on their promised boost in velocity.

If you’re now involved with engineering leadership in some capacity, you may well have accepted the slowdown as a sad universal truth. Accordingly, you may have shifted your efforts from the impossible task of making the org go faster to the thankless but crucial job of jealously guarding how engineers spend their time—because as it takes longer and longer to get even simple features out the door, those engineering hours become increasingly precious.

If all this sounds familiar, I have good news and bad news for you.

Read more…

No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies

In Coding, Fast and Slow, I talked about one of the deepest challenges involved in writing software: the near-total inability of developers to predict how long a project will take.

Fortunately, as that post mentioned, I believe there is a way to work, where the software you write ends up being valuable, and the business people you work with end up being happy. And, critically, this way of working does not involve committing to estimates of how long work will take (which is good, because, personally, I suck beyond all belief at such estimates… even for work which I initially believe will take no longer than a single day).

In a lot of ways, this is The Most Important Thing I’ve learned in my (let’s just say many) years of being paid to write software for people.

The core idea is: put uncertainty and risk at the center of a conversation between the developers and the rest of the business (instead of everyone pretending such nasty things don’t exist). Doing so allows the entire business to tackle those genuine challenges together.

To show what such a conversation might look like, I’m going to develop this approach in detail, in the context of a story.

Read more…

Introducing Diffscuss: Plain Text Code Reviews, Right in Your Editor

Earlier this year we at Hut 8 Labs were working onsite with a client who didn’t have their own code review system. Since a life without code reviews just isn’t worth living for us, we found ourselves emailing diffs back and forth to each other, with messages like “about halfway through the diff you do X, maybe you should do Y?” Eventually we even started inserting comments right in the attached diffs themselves—comments like “EWJ RENAME THIS VARIABLE OR DIE IN A FIRE!!!”—which worked surprisingly well, except that:

  • it was easy to miss comments and replies in large diffs, even when the comments were all caps and followed by multiple exclamation points

  • it was a pain to co-ordinate reviews and replies from even two other people

  • it was a pain to track down the actual source lines a comment referred to, which meant an unpleasantly high activation energy for applying small fixes and suggestions

So we created diffscuss—a code review format based on unified diffs, with editor support for threaded inline comments, basic review management and git integration, and (best of all) support for jumping right from a comment to the local source it addresses, without ever leaving the comfort of Emacs (or, because Hut 8’s own Matt Papi is a Vimmortal, Vim).

Jump to Source

We’ve been using diffscuss for about 6 months now, and we’ve been happy enough with it that we figure it’s time to share it with the world.

Check it out at Github or read on for an example of diffscuss in action.

Read more…