Analyzing an analyzer - A dive into how RuboCop works by Kyle d'Oliveira

Linters and codeformatters are my favourite kinds of tool because they promote consistency, uncover complexity, and save teams from nonsense issues.

The other thing about a linter is that it seems like one of those problems that seems easy on the surface but has a potentially huge amount of complexity as soon as you think about it. This RubyConf by Kyle d’Oliveira discusses RuboCop, the most popular linter for Ruby.

Kyle briefly talks about how his organisation uses RuboCop, then does a short dive into how RuboCop implements its rules using abstract syntax trees, depth first searching, and other techniques. This talk is perfect if you feel like diving deep, just for a little bit.

Monday Links 21

OpenAI released GPT-4. I’m intrigued by the potential of being able to take a photo of my fridge and get suggestions of what to make for dinner. Even better would be if it could suggest how to tidy up the mess in there and let me know which jars of pickles and salsa should really be biffed.

I love Uses This. Daniel Bogan finds people from a huge range of jobs and asks them four questions: Who are you, and what do you do? What hardware do you use? And what software? It’s a perfect site for finding rabbit holes to go down.

In On Code Coverage Tools, Chelsea Troy argues for framing coder coverage as a satisficing metric as opposed to an optimizing metric so that you consider the context and relative value of your tests rather than just aiming to improve the coverage number.

Rands: Seven Plus or Minus Three

A common question I am asked, “How big should the team be?” My immediate response: Seven plus or minus three. There is a not a lot of hard theory behind this guideline, just common sense.

Everything That’s Ever Gone Wrong on My Camping Trips. Exercises in resilience, including a dog fighting a bear, sand fleas, losing your friends in the wilderness, and terrible french bread.

Neal Stephenson's Opening Keynote at D.I.C.E Summit 2023

Neal Stephenson’s recent keynote at D.I.C.E is titled “Games and the Open Metaverse” and is retitled “Blah blah Metaverse blah blah blah” by Stephenson in the first five seconds. He goes on to talk about the different kinds of markets for things like books and video games, and why we feel icky when the intangible value for goods isn’t part of the discussion. Stephenson talks about the value of ensuring that financialization of things like games needs to come out of the experience and quotes Rebecca Barkin on this point: “You can’t architect a compelling experience backward from a desired financial outcome.”

New addition to the Engineering Manager's Bookshelf: Never Split The Difference

I maintain a short list of books that I call The Engineering Manager’s bookshelf. I’ve just updated it with a new entry

Never Split The Difference: Negotiating As If Your Life Depended On It by Chris Voss with Tahl Raz

Link To Never Split The Difference on bookshop.org

Chris Voss was an FBI negotiator and developed his skills and techniques by talking to kidnappers, hostage takers, employers, and car salesmen. I think the techniques in this book - calibrated questions, focusing on the issue, treating the people you’re negotiating with as partners, observing how people act, building trust - are essential to having a successful career as manager, and to ensuring you and your team are set up for success. I cannot recommend this book highly enough.

Monday Links 20

Even Xero isn’t immune to layoffs

Breccan McLeod Lundy on the pressure to come up with a snappy mission statement or purpose for his company:

You have the choice between saying something that sounds great but isn’t quite true or saying too much and being asked why you didn’t just stick with “Our purpose is to make the world a better place”.

Companies, like people, have a hierarchy of needs - they need to make a certain amount of money to even be able to think about broader social purpose. I think for us we’d have to do a prioritized list of purposes which doesn’t sound as cool as “purpose” but is necessary to be functional in the long run.

What happens when the US Army needs 36,000 kettlebells, fast

LeadDev: Riding the ever-changing waves of front-end development

Will Larson: Writing an engineering strategy

Once you become an engineering executive, an invisible timer starts ticking in the background. Tick tick tick. At some point that timer will go off, at which point someone will rush up to you demanding an engineering strategy. It won’t be clear what they mean, but they will want it, really, really badly. If we just had an engineering strategy, their eyes will implore you, things would be okay. For a long time, those imploring eyes haunted me, because I simply didn’t know what to give them: what is an engineering strategy?