Tag Archives: Software

A crumbling railroad bridge over snow, the uprights are worn and look ready to give way.

Zero to One to Crumbling

It’s a golden age of convenience and ease! The speed that we can get something usable up, working and deployed these days is incredible. The sheer amount of good engineering infrastructure we can take for granted is astounding – and that’s good.

In Deb Chachra‘s How Infrastructure Works she has a tricky definition of infrastructure that really works. Roughly it’s that “infrastructure what you can take for granted”. It’s the stuff you don’t have to think about. In my neighborhood, that’s a lot! I don’t think about water, light, heat, electricity, or food supply. At work, I don’t really think much about compute availability or disk availability – though I do have to design systems that use these mindfully at scale.

In software, there’s other kinds of infrastructure. Do you have to manually allocate memory? Do you have to destroy objects and free up allocated memory when you are done with it or does a garbage collector handle that for you? Do you have to optimize your control flow and loops or does an optimizer do an incredibly smart job of that for you? The more that there is good software infrastructure, the more you can spend time on the biggest difference maker for you – handling the business domain problems that you want to solve.

Old Man Story Time:

For my first job in NYC, I was given a C# code test. This was difficult for me, as I had no copy of VisualStudio.net available to me. Also, I didn’t know C# and figured it can’t be harder than C. I had to look up online manuals of C#, write the code in Notepad, and use csc.exe to test if it worked. A lot of what the test demonstrated was that I could write a for loop and that I was bull headed enough to push through obstacles and find out how to get something done. Now I write fewer for loops.

The last repository push I made I didn’t bother locally cloning – I was able to use the web based editor in GitLab to branch, make a change with auto-suggests, then commit, push and create a merge request. Unbelievably easy and cool.

But Jim Nielsen‘s Zero to Unmaintainable raises a good point:

There is such a focus on how quickly you can get going, but so little focus on how you maintain what you just created.

The developers I work with are so bright and smart and full of ideas. And they can get smarter, more reactive, better designed systems than I can think of up and running so quickly it’s astounding. But I see them frustrated, because they are held up by different things than I was. I used to get frustrated by the failures of the technology or the ability to even get simple things connected. They have best practices built into the new tools. But they are now frustrated by the organizational demands associated with new tooling.

Who will support this new application? How will we keep it updated? How will we secure it? When the APIs we interact with change, is this application well enough documented that someone else can fix the problem or do we need to take you off a project to fix it?

Part of my job is to help identify these issues early and turn them into infrastructure so that they can concentrate on the business problem and solutions to them – rather than these concerns. Instead of frustrated developers working out non-functional requirements, it’s better when we turn them into things they can take for granted.

This means working out commonalities across solutions we build for clients. Deployment’s a big one to get right once and then not talk about much. Same for version control. Same for dependency management and security scanning. Same for support after go-live. Same for maintenance. Same for self-service for clients.

The response to people being super fast to solve problem and come up with ideas isn’t to slow them down – it’s to solve the next bottlenecks.

These opinions are, of course, my own and published by me, not my employer.

Default Apps 2023

It’s a blog trend!

Every once in a while, everyone wants to share the tools they are excited about.

When I saw Ankur Sethi’s post about it on Mastodon, I was in.

  • Email: Outlook (because work) / Thunderbird on the laptop
  • Calendar: Outlook (because work) / Thunderbird or a pinned google calendar tab
  • Reminders: put it in the calendar.
  • Chat: Beeper (because it handles everything) or Slack (because work/school)
  • Photos: the iOS camera app
  • Books: BookWyrm, Libby, CloudLibrary, Aldiko, and the Kobo app. But I only really use my Kobo.
  • Mastodon: Ice Cubes
  • RSS: newsblur
  • saving things to read later: Pocket – which syncs to my Kobo
  • Browser: Firefox
  • Search: duck duck go.
  • Music: play:Sub or Navidrome
  • Podcasts: Overcast
  • Audiobooks: I don’t. I don’t understand how the rest of you can. I’m glad you enjoy it.
  • Photo Editing: Whatever iOS provides natively or I use the GIMP on my laptop.
  • Todo: Vim and todo.markdown in project folders, Trello for family projects, otherwise, pick a time and put it in the calendar to get done.
  • Grocery lists: a pad of paper
  • Presentations: Vim and markdown -> pandoc -> reveal.js is incredible.
  • Writing: Vim
  • Code editing: Vim
  • Spreadsheets: Google Sheets
  • Budgeting: Google Sheets
  • Terminal: Whatever is handy, but tmux inside of it.
  • Git: the git commandline. (or fugitive inside vim).

For more of the tools other folks use, Robb Knight is collecting these lists on App Defaults.


I need to see if my remote connection to work is healthy and if my remote connection to video conferencing is suffering.

I wrote a little utility to handle that in the commandline. It’s dumb but it works. Let’s call it pingplotter. It’s in the public domain, go nuts.

It’s fine to just pop in a terminal you have open, but it plays really nice with tmux and glances (I use both).

I think I spent nearly as much time making these screencasts as I did writing the shell script. I should blog that too, if only so I don’t have to research that again.

Why the Business Hates the Software Developers

Inspired by “Why I Hate Frameworks” “Why I Hate Frameworks”

So I wanted a custom spice rack, one that would really help my restaurant, but I didn’t want to build it myself.  I’m no carpenter.  I hired one though.
“Can you build me a spice rack? Here’s what I need – “
“Just a sec,” he interrupted. “I’m going to start building some hammers while you talk.”
“Don’t you already have some hammers?”
“Sure, but those were for past projects.  There’s better ways to build hammers these days.”
“Here – I have a hammer already.  It got left behind by the guy who hung the pictures in the restaurant.  Use this.”
“SIR! I don’t think that using a framing hammer is going to help us develop this spicerack.  Please!”