Musings about the theory and practice of writing software. Not necessarily code-focused, but may occasionally have code.

  • Models

    The map is not the territory, and often when writing software we’re building maps and models of things – which inevitably encodes our own assumptions.

  • On Call

    The operations side of writing software.

  • Taking A Chance

    I’ve been pretty lucky in my career so far, and if there’s one thing I’ve learned: you have to take a chance on yourself.

  • Emacs as a Java IDE

    Into the forays of using Emacs as Java almost-IDE.

  • Trying to get Emacs to work with a whole environment of tools is a lot of work; it pays to look for other Emacs users and ask them how they fit Emacs into the environment.

  • Vocabulary

    Observations on a shared work vocabulary.

  • Firehose

    Diving into the deep end: moving into a new city, and starting a new job.

  • Compromise

    Engineering involves compromises and trade-offs. But is it a good idea to trade-off quality of code for time?

  • Level Up

    As you gain more experience, you realize that there’s more to writing software than just the technical.

  • Writing Readable Code

    Reading code is a necessary skill— most of a professional software engineer’s time is spent reading code. But how do you write readable code?

  • RTFM

    On documentation, the phrase “RTFM”, and writing good documentation.

  • Confidence, criticism, and why code reviews are hard.

  • Sensible Commits

    One thing I’ve learned early on is that commit messages are important; it’s the one thing I always read first when reviewing code to understand the context of a particular change.

  • Workman's Tools

    Thoughts on Emacs and the other tools in my repertoire.

  • Design and Entropy

    I’ve come to realize that a lot of design and architectural decisions are a fight against entropy, and it’s a never-ending battle.

  • Freelancing

    Freelancing and consulting work isn’t my cup of tea, but I’ve learned a lot from it.