First, a quick announcement: I'm available for work, and I'm starting to put out feelers for my next contract. To that end, I've been working on my pitch.
- Do you have a team that's having a hard time shipping software, and you're having a hard time figuring out why, never mind helping them?
- Do you have a timing or consistency bug that you can't seem to figure out or solve?
- Are you building a system that has tight performance, consistency, or reliability constraints, but also want to ship something quickly?
- Do you need to help getting observability set up and integrated with your system, or moving to a new observability stack/system?
- Are your tests flaky and unreliable, and you're having a hard time getting engineers to spend time fixing them?
- Are you trying to build a developer "platform," with Kubernetes or similar?
- Or are you trying to get your developers to actually use the platform the infrastructure group built for them?
- Are you an XP-influenced consulting agency that's scoping a big, tricky project with a large client?
- Or a consulting agency that's looking for an engineer with experience writing TDD'd Ruby or Elixir?
If any of those problems sound like yes please it's terrible please fix it now please, send me an e-mail or reply to this one. And please pass that page on if you know someone who I might be able to help. I'm always interested in talking to folks who are having reliability and delivery problems– it's why I'm good at solving them!
On good chairs
Can I use the word sacred in a technical post?
I'm Nat Bennett, software engineer, and I was raised as a Unitarian Universalist, so I have a kind of unusual attitude towards religion. I don't flinch when I hear the words mystical or spiritual or god. I use "sacred" to mean something like, "having inherent value, independent of its function or uses."
Human life is sacred. So is the Grand Canyon, or spending the evening eating with friends – whether you've got candles lit or not.
And there's something sacred about making a really good chair. So sacred, in fact, that it is something like a sin to make a bad one– at least for any purpose other than learning to make good ones.
I can't say exactly why I think this. I feel it.
My partner and I call this "the god of chairs." We'll notice that someone shares this feeling and say, "they follow the god of chairs." To follow the god of chairs is to believe that there is something wrong, according to fundamental, inarticulable laws of the universe, to change the world in a way that makes it worse. The shorthand: That god will be mad at you if you make a bad chair.
And I believe that this applies to software. There's something sacred about a good program, about making one and appreciating one. There's something sacred about a good function, a good refactor, a good Git commit. There's something deeply in-itself-valuable about these things.
If there's something sacred about a good program, then maybe there's something profane about making a bad one.
I'm uncomfortable with this conclusion because– really? Tech debt? A sin?
Seems a little extreme.
I think it explains, maybe, the alienation and frustration and burnout that some of us feel in the tech industry. We value doing things well, making good things. When we don't have the time or the energy or the knowledge to do things well, when we're asked to do things poorly on purpose, to just ship it, it hurts.
I think it's especially tough because we're so suspicious of the notion of sacredness, of words like spiritual and mysticism and god. Software engineering is supposed to be rational. There's no place for vague religious feelings in it.