Last night, mere moments from letting me commit a new package of Test::Continuous (continuous testing for Perl), my computer acted as though it knew its replacement was on the way and didn’t care to meet it. This tiny mid-2013 11” MacBook Air made it relatively ergonomic to work from planes, buses, and anywhere else when I lived in New York and flew regularly to see someone important in Indiana, and continued to serve me well when that changed and changed again.
The next thing I was planning to do with it was write this post. Instead I rebooted into DiskWarrior and crossed my fingers.
Things get in your way, or threaten to. That’s life. But when you have slack time, you can
- Cope better when stuff happens,
- Invest in reducing obstacles, and
- Feel more prepared for the next time stuff happens.
Having enough slack is as virtuous a cycle as insufficient slack is a vicious one.
Paying down non-tech debts…
Last year I decided to spend more time and energy improving my health. Having recently spent a few weeks deliberately not paying attention to any of that, I’m quite sure that I prefer paying attention to it, and am once again doing so.
Learning to make my health a priority required that I make other things non-priorities, notably Agile in 3 Minutes. It no longer requires that. I’ve recently invested in making the site easier for me to publish, and you may notice that it’s easier for you to browse. I didn’t have enough slack to do these things when I was writing and recording a new episode every week. Now that enough of them have been taken care of, I feel prepared to take new steps with the podcast.
…And tech debts
Earlier this week I noticed a broken link in a comment on Refactorings for web hosting, so I took a moment to check for other broken links on this site (ikiwiki makes it easy).
Before that, I inspected and minimized the differences between “dev” (my
laptop) and “prod” (my server, where you’re reading this), updated prod
with the latest ikiwiki settings, and (because it’s all in Git)
rebased
dev from prod.
In so doing, I observed that more config differences could be easily
harmonized by adjusting some server paths to match those on my laptop.
(When Apple introduced
System Integrity Protection,
pkgsrc
on Mac OS X could no longer install under /usr, and moved to /opt.
With my
automated NetBSD package build,
I can easily build the next batch for /opt/pkg as well, retaining
/usr/pkg as a symlink for a while.
So I have.)
I’ve been running lots of these builds in the past week anyway, because a family of packages I maintain in pkgsrc had been outdated for quite a while and I finally got around to catching them up to upstream. Once they built on OS X, I committed the updates to the cross-platform package system, only to notice that at least one of them didn’t build on NetBSD. So I fixed it, ran another build, saw what else I broke, and repeated until green.
…And taking on patience debt telling you about more of this crud
Due to another update that temporarily broke the build of TMDA, I was freshly reminded that that’s a relatively biggish liability in my server setup. I use TMDA to send mail, which is not mainly what it’s for, and I never got around to using it for what it’s for (protecting against spam with automated challenge-response), and it hasn’t been maintained for years, and is stuck needing an old version of Python.
On the plus side, running a weekly build means that when TMDA breaks more permanently, I’ll notice pretty quickly. On the minus side, when that happens, I’ll feel pressure to fix or replace it so I can (1) continue to send email like a normal person and (2) restart the weekly build like a me-person. If I can reduce the liability now, maybe I can avoid feeling that pressure later.
Investigating alternatives, I remembered that
Spamdyke,
which I already use for
delaying the SMTP greeting,
blacklisting from a
DNSBL
as well as To: addresses that only get spam anymore, and
greylisting from unknown senders,
can provide
SMTP AUTH.
So I’ll try keeping
stunnel
and replacing tmda-ofmipd with a second instance of spamdyke.
If that’s good, I’ll remove mail/tmda from
the list of packages I build every week,
then build spamdyke with OpenSSL support and try letting it handle the
TLS encryption directly.
If that’s good, I’ll remove security/stunnel from the list of packages
too, leaving me at the mercy of fewer pieces of software breaking.
Leaning more heavily on Spamdyke isn’t a clear net reduction of risk.
When a bad bug is found, it’ll impact several aspects of my mail service.
And if and when NetBSD moves from GCC to Clang, I’ll have to add
lang/gcc to my list of packages and instruct pkgsrc to use it when
building Spamdyke, or else come up with a patch to remove Spamdyke’s use
of anonymous inner functions in C.
(That could be fun. I recently
started learning C.)
I could go on, but I’m a nice person who cares about you.
That’s enough of that. So what?
All these builds pushing my soon-to-be-replaced laptop through its final paces as a development machine might have had something to do with triggering its misbehavior last night. And all this work seems like, well, a lot of work. Is there some way I could do less of it?
Yes, of course.
But given my interests and goals, it might not be a clear net improvement.
For instance, when
Tim Ottinger
drew my attention to that Test::Continuous Perl module, being a pkgsrc
developer gave me an easy way to uninstall it if I wound up not liking
it, which meant it was easy to try, which meant I tried it.
I want
conditions in my life to favor trying things.
So I’m invested in preserving and extending those conditions.
In
Gary Bernhardt’s
formulation, I’m aiming to maximize the
area under the curve.
No new resolutions, yes new resolvings
I’m not looking to add new goals for myself for 2017. I’m not even trying to make existing things “good enough” — there are too many things, and as a recovering perfectionist I have trouble setting a reasonable bar — I’m just trying to make them “good enough enough” that I can expect small slices of time and attention to permit small improvements.
Jessica Kerr has a thoughtful side blog named True in software, true in life. Here’s something that’d qualify:
- When conditions are expected to change, smaller batch size helps us adjust.
- Reducing batch size takes time and effort.
Paying down my self-debts (technical and otherwise) feels like resolving. I have, at times, felt quite out of position at managing myself. Lately I’m feeling much more in position, and much more like I can expect to continue to make small improvements to my positioning.
When you want the option to change your body’s direction, you take smaller steps, lower your center, concentrate on balance. That’s #Agile.
—Moi
My current best understanding is that a balanced life is a small-batch-size life. If that’s the case, I’m getting there.
Further repositioning
This coming Monday, I’ll be switching to one of these weird new MacBook Pros with the row of non-clicky touchscreen “keys”. If my current computer survives till then, that’ll be one smooth step in a series of transitions. (In other news, Bekki defends her dissertation that day.)
The following Monday, I’ll be starting my next project, a mostly-remote gig pairing in Python to deliver software for a client while encouraging and supporting growth in my Pillar teammates. I’ll be in Des Moines every so often; if you’re there and/or have recommendations for me, I’d love to hear from you.
The Monday after that, we’ll pack up a few things the movers haven’t already taken away, and our time in Indiana will come to an end. We’re headed back to the New York area to live near family and friends.
No resolutions, yes intentions
For 2017, I declare my intentions to:
- Continue to improve my health and otherwise attend to my own needs
- Help more people understand what software development work is like
- Help more people feel heard
I hope to see and hear you along the way.