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

  • Breadth/Depth

    Jack of all trades, master of none – but oftentimes, better than master of one? Maybe.

  • Soul of a New Machine

    Soul of a New Machine: a review.

  • Revisiting my Emacs configuration as a Java almost-IDE, switching to using LSP.

  • print('foo')

    The humble print statement is probably the unsung hero of many a debugging session in my career: it’s what I reach for first before breaking out the debugger.

  • Failure Modes

    The software we write is fallible, precisely we’re fallible. That’s not to say that all software is unusable though. Failure is always an option.

  • Journaling

    Since November, I’ve been keeping a journal of my work, as a means of data gathering on my own productivity; it also gives me a sort of timeline of events, should I need to look back.

  • 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.