Musings about the theory and practice of writing software. Not necessarily code-focused, but may occasionally have code.
-
The new normal will take a while getting used to.
-
Working from home until the end of the month.
-
On my own knowledge, or lack therof.
-
A paean to tcpdump(1), or why knowing how to use it is a necessary skill for today’s networked software.
-
I’m behind on my blogging – let me catch you up on the past month.
-
My ongoing internal debate on static versus dynamic typing, and all that jazz – or why I still like dynamic typing, even with the benefits of compile-time types.
-
Putting things on hold.
-
Jack of all trades, master of none – but oftentimes, better than master of one? Maybe.
-
Soul of a New Machine: a review.
-
Revisiting my Emacs configuration as a Java almost-IDE, switching to using LSP.
-
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.
-
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.
-
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.
-
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.
-
The operations side of writing software.
-
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.
-
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.
-
Observations on a shared work vocabulary.
-
Diving into the deep end: moving into a new city, and starting a new job.
-
Engineering involves compromises and trade-offs. But is it a good idea to trade-off quality of code for time?
-
As you gain more experience, you realize that there’s more to writing software than just the technical.
-
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?
-
On documentation, the phrase “RTFM”, and writing good documentation.
-
Confidence, criticism, and why code reviews are hard.
-
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.
-
Thoughts on Emacs and the other tools in my repertoire.
-
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 and consulting work isn’t my cup of tea, but I’ve learned a lot from it.