tarquin-the-brave

Some things I think.

— All Posts —

  • An Underrated Engineering Skill

    Spoilers: How well you build on top of other people’s work. A few years ago I was at Microsoft. Their performance reviews were based on what they called “three circles of impact”: your own output, how you support others, and how well you build on top of other people’s work. I hadn’t heard this way of thinking about it before. I liked it. The third one in particular stuck with me.

    Read more…
  • Rust Perspectives for Experienced Engineers

    About a year ago I joined a company. They’d brought me in as “someone with lots of Rust experience”. From the interviews I thought they’d have a few projects here and there in Rust. Turns out it was almost the entire stack for their new product. A lot of experienced folks from other languages were learning Rust for the first time while pushing to ship. Watching how people write Rust when coming from other languages, I thought about what perspectives might be useful to share.

    Read more…
  • The Multi-Repo of Madness

    I should confess upfront: I meant to write this post about four years ago and never got round to it. The tide has turned somewhat towards monorepos now, especially with AI-assisted coding making “grep the whole codebase” more valuable than ever. So this cautionary tale about going multi-repo is perhaps less relevant than it once was. But still. A long time ago I worked at a company that traditionally built big monolithic products.

    Read more…
  • There's No Such Thing as an Error in Rust

    Colleagues have heard me say this. Usually when we’re debugging something, or discussing error handling approaches, I’ll pipe up with: “Well, there’s no such thing as an error in Rust.” It tends to get a raised eyebrow or two. So I’ll explain. How Rust Handles Errors If you’re not familiar with Rust, here’s the quick version: Rust doesn’t have exceptions. Instead, operations that can fail return a Result type.

    Read more…
  • yes, please clear my terminal

    We’ve all been there. You’ve been running some commands. You switch focus away from your terminal. You come back. And your terminal is full of crap you’re not interested in anymore. “Get this out of my sight”, you think. clear you type. Problem solved. Blog post over. Oh but wait! This doesn’t solve all my woes. There’s another time when the ghosts of a command past can muddy your view. Say you’ve run some tests.

    Read more…
  • A Thought on CLI Design

    Recently I was using a wrapper around a CLI tool. It does what you might expect a CLI wrapper to do: set up some peripheral things, environment variables and such like, then runs the underlying CLI tool with some CLI parameters set and passes argument given to the wrapper down to provide extra parameters. This pattern can be pretty useful to make a particular use case of a CLI tool easier to perform.

    Read more…
  • Generating a Config File Reference for a CLI Tool in Rust

    There’s something missing from the documentation of CLI tools. They often have home pages that do a great job of explaining the core concepts, giving a “Quick Start” guide, and demonstrating some use cases. Where I find tools' documentation is missing something, is when you’re already well acquainted with the tool, and you want to know some specific detail about a single field like what possible values it can have or exactly where it sits in the structure of the config.

    Read more…
  • Why I Scatter Use Statements Throughout My Rust

    A standard pattern across pretty much every language I’ve worked with at least, is to stick statements that import modules and libraries at the top of the page. Some languages make you do this. In Rust I don’t do this for everything, here’s why. I started to think more and more about what code is like to read rather than write. I for one was reading code far more often than I was writing, and the code I was writing would, over its lifetime, be read far more often than written or edited.

    Read more…
  • Re-Learning Haskell with Advent of Code - Part 3

    After Part 2, I wanted to go and do some reading. I felt like I could crack on with the Advent of Code problems with the tools I had at my disposal, but felt if I learned more Haskell I could be doing better. I wanted to learn some more about monad transformers and anything else that could improve my solutions. So I started search around to see what resources I could find.

    Read more…
  • Collecting All the Errors - Rust

    A common way to handle iterating over results, Result<T, E>, in Rust is to use collect() to collect an iterator of results into a result. To borrow the example from Rust by Example: let strings = vec!["7", "42", "one"]; let numbers: Result<Vec<_>,_> = string .into_iter() .map(|s| s.parse::<i32>()) .collect::<Result<Vec<_>,_>>(); You only need either the type hint on numbers or the turbofish on collect to coerce the iterator of results into a result.

    Read more…