SIGAVDI #43: X-Wing Edition

Hello friends,

Jessica was in town this week. We made a spaceship (pictured below). We also did some livestreaming. We Paired with Bunny on some basic client-side JavaScript, and Jessica showed me what she's working on for Atomist.

I've been thinking about a tension in how we think about relationships.

When I was growing up I was heavily influenced by the point of view that compatibility is basically irrelevant, and relationships are all about the work you put into them. This came primarily from a parent who felt that arranged marriages were the ideal kind of marriage, as well as this jackass who taught that dating was a bad idea (he has since repented).

(Aside: never trust a relationship book by someone under 40).

While this perspective can obviously be taken to extremes, there's a kernel of usefulness in it. It's the idea that you're going to have to work at a relationship. That's a pretty good expectation to set.

On the opposite extreme is the societal trope about how when you meet “The One”, everything will just flow. It'll feel right, and easy! The kernel of truth here is that compatibility matters. The failure mode is an endless search for the perfect partner, based on some list of requirements.

I was thinking about this tension recently, and how I've seen it play out in various people's relationships. And what struck me was that while we usually prepare young adults for the idea that relationships will require some amount of work, we don't usually give them any calibration.

How much work is a reasonable amount of work? The easy answer is it depends, but I think that's a cop-out. There is such a thing as an unreasonable amount of work, a not-OK ratio of pain-to-pleasure in a relationship. But without a wide variety of experiences, you have no idea where your current experience falls on that continuum!

And you can try reaching out to friends and mentors for help, but chances are you'll get wildly mixed messages! Because everyone's labor-sensitivity is calibrated differently. One person's “dealbreaker” is another person's typical Tuesday.

It's also not useful to fall back on the idea that “different people have different tolerances”. Because tolerance isn't fixed. One thing I've learned about being human is that we have an almost infinite capacity for building up tolerances. Saying “it depends on your tolerance level” is tantamount to saying “there is no such thing as Too Much Work”.

This problem of calibration extends far beyond relationships. One of the sensibilities I've honed as a developer over the years is a sense of how hard is too hard. What is the pain point that indicates I am almost certainly fighting the system, and that there is a better way to do it?

These days I feel like I have pretty good idea of when to stop, step back, and ask around for alternative approaches. But when you're a novice, it can be scary to do that! You have a sense that this stuff is supposed to be hard, and so the pain you're feeling right now… well, it's probably perfectly normal, right? And you should just apply yourself more dilligently.

From relationships, to documentation, to system monitoring… it's not enough to say “there will be some friction”. Expectation of friction is useless without calibration. Some of the most useful guidance we can receive are concrete heuristics for what amount of difficulty/pain/failure is reasonable… and what amount is not.

Hanging out with Jessica always spawns a lot of philosophical, systems-thinky conversations. Today I tried to sum up some of the ideas we've been knocking around in a tweet, and I thought I'd make a first crack here at expanding on them.

Value over simplicity.

Valuable systems are complex ones. Let's put paid to the idea we can have one without the other.

Communication over correctness.

I'd rather work with a system that gives me a good idea of what it's trying to do and fails at it, than one that is “correct” but inscrutable.

Learning over longevity.

One of the most pernicious, difficult-to-root out biases I've found in my own psyche is the idea that something has to be long-lived
(at least theoretically) in order to be “good”, “right”, or “important”.

E.g.: A divorced marriage is a “failed” marriage. A political system is “broken” unless it can last forever. Tests are only valuable if they can be retained indefinitely for regression-checking. Successful code is modified rather than replaced.

I'm trying to replace this bias with the idea that a thing is right, good, useful, and important so long as you (or more importantly, the entire sociotechnical system around it) learns from it.

Importantly, this is not the idea of “learning from failure”. It's the philosophy that the learning is the aim. Sometimes other interesting benefits fall out along the way. Sometimes artifacts you create along the way remain stable for a while. Others don't. Sometimes your direction changes with the learning, and the change renders artifacts obsolete. This is fine.

Context over consistency.

This one feels pretty self-explanatory to me… there's no such thing as a universal best-practice. There is little to be gained and much to be lost from aggressive standardization. Things that work well only work well in a given context. There is no universal or objective correctness.

Movement over stability.

Nowadays I seek forward motion, rather than trying to converge on some ideal stable state. It's deeply uncomfortable for me, still. But I'm working at it.

Remediation over rigor.

I'm not 100% on the terminology for this one yet. But the basic idea is that I'm not interested in making systems rigorously robust. I don't want to trace out every possible failure mode and plan for it. I also don't believe it's possible to make systems that can erase all consequences of failure.

Instead I want to build systems that are optimized for making things right when something goes wrong. That can mean anything from well-maintained backups, to having a well-trained and empowered support team.

Connection over completeness.

This is something I talk about in my #NOCODE talk. It's less important to build a system that covers every last jot of needed functionality, and more important to build one that has well-established ways of reaching out for help when something goes beyond its capacity to handle.

This has obvious implications for life in general, e.g. knowing people with skills you lack. But it's also applicable to software systems which can ask a human for help with resolving an unhandled situation.

Right, let's see how I did.

  • ✔ Tie up loose ends from the Cohere meetings. Inasmuch as I did some due diligence, made some concrete decisions, and communicated them, yes.
  • ❌ Catch up on my snail mail. Ugh, nope. There's something tax-related in that pile and that always puts me off the whole enterprise.
  • ✔ Catch up on RubyTapas TODOs. Done.
  • ✔ Catch up on email. Done. And I finally rigged up a new shared inbox for certain non-business stuff, so e.g. I don't have to forward emails from the propane company to my assistant anymore. Win.
  • ✔ Finish unpacking and go over notes from AIT. Done.
  • ✔ BONUS TASK: Populate and organize my conference RADAR board. I now have a much better sense of which confs are coming up when, and a way to track which confs I'm hoping to get into.  

This week:

  • Burn Catch up on snail-mail. For real.
  • The usual RubyTapas stuff, including several guest chef meetings.
  • Actually show up for a >Code episode.
  • Write and record VO for two RubyTapas episodes.
  • Go running.
  • Investigate my options for some part-time consulting work. I'm looking to close a cash gap, make myself useful on a team, and satisfy my urge to have a real sociotechnical system to bang my ideas against again. (Feel free to get in touch if you have a lead…)

As always, thanks for reading. Cheers!

SIGAVDI #42: Ultimate Answer Edition

Hello friends,

I spent last week on the tropical island of Anguilla with a bunch of software luminaries. My life is sometimes surreal.

At the moment though, I'm looking out on a chilly, thick fog up here at Fair Pavilion. I can't see the sun. This matches my internal climate pretty well. The world has sharp edges, and my journey seems to be one of exposing ever greater surface area to it.

This is fine.

“This is fine”. My friend Jessica says this a lot. It has been seeping into my personal vernacular lately. To me it represents a whole philosophy of life, strongly at odds with how I once lived.

“This is fine” is the choice to accept a situation exactly as it is, without panicking. Without judgment. Without amplifying the negatives. Without feeling compelled into instant corrective action. Without appealing to outside powers for intervention.

The kids colored on the wall. This is fine. They are kids. We will paint these walls before we sell the house.

The venue I was going to get all my friends together at is unexpectedly closed. This is fine. We will buy some beer, rearrange some furniture, and hold it at my house. Mess be damned.

I spent my afternoon crying in grocery stores and parking lots. This is fine. Longing means I am living.

I mentioned previously that I have been talking with my friends at Cohere about helping me out with aspects of my business that I suck at and/or just don't enjoy very much. These discussions brought me face to face with the fact that I did pretty terribly, business-wise, last year. I dropped my revenue by $60k and increased operating expenses by the same amount.

Or to put it another way, I coped with the aftermath of an unexpected divorce and almost a year of solo parenthood by delegating as much as I could, and doing the bare minimum to keep the business afloat.

This is fine.

Let's see how I did. There wasn't a SIGAVDI last week, but that's because I was traveling. Here are my goals from two weeks ago.

  • ✔ Make preparations for a week of travel. Yep.
  • ✔ Get this week's RubyTapas out. Also yep. Check out this awesome episode on building a REPL with Ruby's Binding class from guest Adam Fernung.
  • ✔ Make sure next week's RubyTapas is on track.
  • ❌ Tie up loose ends from the Cohere meetings. Not quite there yet.
  • ✔ Finish at least one new RubyTapas script and record VO.
  • ✔ Catch up on my email.
  • ❌ Catch up on my snail mail. God I hate the mailbox.
  • ✔ Somehow leave the house to see other human beings during this crazy week. Amazingly, I managed to make this happen.

This week, like every post-travel week, is all catch-up. Sigh.

  • Tie up loose ends from the Cohere meetings.
  • Catch up on my snail mail.
  • Catch up on RubyTapas TODOs.
  • Catch up on email. Again. Sigh.
  • Finish unpacking and go over notes from AIT.

See you next week!

Why I suck at writing talks with good transitions (and how I’m improving)

Smooth transitions help hold the audience's attention

Saron Yitbarek has a great post about how improving your transitions can really spruce up a tech talk. Specifically, about how the transition to a new slide should begin before you actually switch to that slide.

The goal is to make slides support your points, rather than having them introduce your points. It's an important skill to learn for giving talks. Go read her article.

But it's difficult to remember what the next slide will be

I try to practice this technique in my talks, but I've never found it easy. I often have trouble remembering exactly which slide comes next, and it's hard to transition when you can't remember what you're transitioning to.

This problem was exacerbated by some technology choices I made early on. Like many other programmers, in composing my early talks I looked down my nose at dedicated presentation apps such as PowerPoint or Keynote.

Instead I tried to “keep it simple”. I used presentation tools such as Beamer, S5, or RevealJS, that would enable me to use a text editor I was already comfortable in to write my talks, and generate either PDF or HTML slides.

The problem here is that in most cases, these tools didn't give me the ability to see what slide was “up next” on my laptop screen.

A full-featured presentation app can help

By contrast, dedicated apps like PowerPoint and Keynote have a Presenter View which shows the current slide, the next slide, and any speaker notes you've added. You can set your laptop screen to show Presenter View, and the main projector screen to showing just your current slide.

Now, there's an argument that used to keep me from using these kinds of tools. It goes like this:

“Someday, you might have a problem with your laptop and have to present your slides on someone else's machine using just the PDF backup. And anyway, shouldn't you know your talk well enough to dispense with crutches such as Presenter View? Maybe you're just not practicing enough.”

This argument used to have a lot of weight for me. But my views have evolved over time.

In particular, the idea that you should memorize your talk perfectly is an implicit argument for doing few, painstakingly prepared, carefully rehearsed talks.

But that's not the kind of speaker I want to be. In fact, that perfectionist paradigm of speaking has held me back. I'd rather be the kind of tech speaker who can quickly throw a new talk together and not get hung up on imperfection. If I've fully memorized a talk, that means I'm “resting on my laurels” instead of learning and iterating and flowing with ideas.

And if that means leaning on tools to help me get through relatively less-rehearsed material, I'm OK with it.

Abrupt transitions are a byproduct of bullet-driven writing

The other reason I've had trouble with transitions comes from how I typically compose my talks. Usually I collect a bunch of bullet points around the topic I'm tackling. Then I gradually massage the points into an outline, and then create slides for the outline points.

The problem here is that when you do bullet-driven talks, they naturally turn into a set of semi-connected points, each one introduced by a new slide.

Recently I had a particularly bad experience with a talk. I was on a three-city conference tour, giving a presentation I'd delivered several times in the past. I was pretty confident in it, since it was a “polished” talk.

But once I was on stage in the first city, I found myself with low energy, and constantly losing my place in the talk. I walked off that stage feeling deeply disappointed in my own performance, and questioning whether I could in good conscience give that presentation again.

So build your talk around a narrative

After agonizing over it for a few days and talking it over with some friends, I finally discovered an underlying thread that I'd never identified before. I quickly rewrote the talk to periodically re-emphasize that thread. And I re-ordered sections of it to have a natural flow, guided by the thread.

As soon as I started giving the new version of the talk, I knew I was “back”. The energy was there again, and the post-talk audience reviews showed a clear and marked improvement in how it was received.

The key to the change was in identifying a clear narrative through the material. Since then, I've been focusing more than ever on putting the narrative first, and getting away from the “bullet-driven” approach.

Outline your story, not your points

One thing that has particularly helped with this is a technique I learned while studying copywriting. Somewhere, I ran across the advice to write your content subheadings so that even if someone just skims the headings, they will still come away with a summary of the whole piece. Instead of subheads full of pithy wordplay, have them clearly and plainly summarize the paragraphs that follow.

Recently I needed to restructure another of my talks into a ten-minute version. Instead of pulling out slides which represented the “important points” from the main talk, I first opened up a blank, full-screen Markdown editor. In the editor, I wrote out ten sentences (one for each minute!) that together told the story of the point I wanted to get across.

It looked like this:

- Refactoring and redesigning software is hard.
- I’ve started seeing an underlying pattern to the hard.
- OOP was supposed to be about messaging, 
- But messaging semantics are impossible in the C++/Java/Ruby/etc.
- As a result our systems are full of processes modeled as transactions.
- This exhibits as BOTH splitting processes across multiple objects, and as objects containing parallel “stories”
- Implicit to message oriented is process oriented
- What if we structured our systems, not by actions, not by data globs, but by process?
- What if we used this as the heuristic for refactoring?
- …what if we applied this to our lives as well?

Once I had my rough storyline, I transferred these points as named slide sections into PowerPoint. Then I copied/added slides that would support each step in the story under the sections. In the process, I also edited and simplified the story headings.

The final presentation, with slides collapsed to just show the section names, looked like this:

(By the way, you might have noticed I'm using the same technique for the subheadings in this article 😉)

Lean on tools, tell a story, and let slides be illustrations

In conclusion: great transitions can make a big difference in how your tech talk comes across. But for some of us, they don't come easy. The two main strategies that have helped me improve my transitions are:

  • Don't be too proud to lean on “business-y” presentation tools like Presentation View and speaker notes.
  • Write your outline as the steps in a story, not as a list of points you want to get across.

I hope this helps someone out there.

SIGAVDI #41: Officially bored with winter edition

Hello friends,

“So will you stay here? How long? Where else might you go?”

I've heard these questions from a lot of friends in the past year. I don't know the answers.

Back when I was raising a family here, and thought I was going to be continuing in that for the foreseeable future, I also thought that being adjacent to the Smoky Mountains for the next 5-10+ years would be pretty ideal. Now I don't know.

I love these hills. I love hiking them. Something about the way the land works here settles my soul like nowhere else I've been (yet).

But one of the things I've realized is that my idea of what were “my activities” was constrained by what I could allow myself to like. Or dream of. Hiking was a “safe” pastime in the context of my former living situation. More social activities weren't, and so I told myself I wasn't that sort of person anyway.

This has been an ongoing theme of the past year+ of expansion and reorientation. Coming to terms with how much of what I thought of as “me” was circumstantial rather than innate.

Example: my whole life when I would take those Myers-Briggs tests I'd come out somewhere between INTJ and INFJ. I took one recently and came out ENFP.

My whole life I've identified strongly as an introvert. Lately I've come to question even this. I wonder if perhaps being raised alone in the woods simply gave me so much social anxiety and so few tools to overcome it, that I adapted to being alone. And told myself I liked it.

I used to think the crash that would follow social “highs” was a sign of my introversion. Now I wonder if it was just repressed extroversion going into a sulk after getting a taste of what it needed.

These days I feel like I'm growing in reverse. From settled old man to rolling stone.

One thing is for sure: there is no longer any talk of where I will “end up”. My life is a generator function. There is no known endpoint. There is only .next().

I spent the past week pairing, plotting and planning with my friends from Cohere. Most of the time was spent recording hours of pair-programming video with Betsy Haibel for their forthcoming Untangling Asynchronous JavaScript course. I know way more about JavaScript, Node, and Express than I knew a week ago.

But we also took time to make some concrete plans for working more closely together on my existing business. As I alluded to in a previous SIGAVDI, I am coming to terms with the fact that I enjoy and am good at only certain parts of my work. Namely the parts that involve learning, communicating, and working with people. I am not so good at the daily operations and upkeep aspect: the metrics-monitoring, optimizing, prompt-email-replying, bug-fixing, regularly-promoting parts. The Coheres and I have been hammering out a novel and mutually-beneficial arrangement which I hope will get those parts of my business on track while freeing me up to do more of the stuff I'm best at.

OK, let's see how I did.

  • ✔ Record lots of course video with Betsy. Done! In fact we finished primary filming ⭐
  • ✔ Publish a RubyTapas episode, even if it isn't the planned one. Done! I recorded a short-notice episode on exploring unfamiliar APIs in a REPL.

What's next:

This week I'm preparing to travel to a nifty invite-only conference for most of next week. I would like to be excited about this except that I HAVE SO MUCH TO DO BEFORE THEN that I don't have time to be excited 😱.

  • Make preparations for a week of travel.
  • Get this week's RubyTapas out.
  • Make sure next week's RubyTapas is on track.
  • Tie up loose ends from the Cohere meetings.
  • Finish at least one new RubyTapas script and record VO.
  • Catch up on my email.
  • Catch up on my snail mail.
  • Somehow leave the house to see other human beings during this crazy week.

Wish me luck.

SIGAVDI #40: Absinthe edition

Hello friends,

I found this in my notes and I can't remember if I've written about it yet:

You can choose the rarest, most delicious variety of olive. And pick out the creamiest, most luscious flavor of ice cream. But if you put the two together you're probably not going to get a very good sundae.

It's tempting to pick and choose from “best practices”, or from amongst the most popular features, and try to put them all together in a perfect sundae. We do this sometimes when deciding how our teams will operate. Or what features our programming language should have. Or when comparing feature lists on comparable services.

The problem is that practices and features are never “best” objectively. They are only “best” in a context… of other practices or features.

eXtreme Programming works (when it does) because it's a set of mutually-reinforcing practices. If you pick out just “no code review” and “test-driven development” but leave behind pair-programming, small releases, constant refactoring, and an on-site customer, you are likely to wind up with a big ball of mud that isn't fit to purpose.

See also: programming languages that never met a PL buzzword they didn't try to assimilate. Object-oriented! Functional! Dynamic! Static! Actor-model! Floor polish! Dessert topping!

I said I was going to make this newsletter more personal going forward and it occurs to me I haven't actually written much that's personal in the last few. I guess that's because I've been, for the most part, ridiculously happy, and happiness is dull to write about.

Happiness also brings with it the dangerous temptation to write about “how to be happy like me”. And that's where shitty self-help books come from.

Happiness is always spiky and ephemeral too. If you sampled me regularly over the last month you'd get an overall trend of joy, but you'd also get individual datapoints way down in “anxiety”, “loneliness” and “depression”.

Brene Brown says that everyone practices dulling their emotions to some degree. And that when you dull one emotion, you dull them all. Conversely when you allow yourself to feel more strongly, you don't get to pick and choose which feelings. I'm in a period of opening up to levels of pleasure and happiness I'd never felt before. And that means also feeling sadness, loss, sympathetic pain, loneliness, and fear that much more keenly.

OK. Let's see how I did.

  • ✔Submit a talk proposal to NordicJS (and use this as a pull to get my ducks in a row for talk submissions – update bio, abstracts, talk history page). Done! In the process I put together some convenient pages with abstracts, video, and nice things people have said about the talks I've been doing lately.
  • ✔Make sure I'm on top of at least the next two RubyTapas episodes. Well, sort of. I've caught up on a lot of my RubyTapas TODOs, but I think this week's guest ep is still going to be delayed. I may have to come up with something short-notice while the originally planned episode is completed.
  • ✔Make plans for the upcoming Cohere/ShipRise Smoky Mountain Retreat. We'll be working on the AsyncJS course and other plots & plans. What do I need to do to prep? I checked this off by saying “hey, I'm super anxious because I never host people so please work with me on this, OK? 😅”. Sometimes “done” means “feelings communicated and expectations managed”. 
  • ❌Reimplement Promises in Ruby, again, based on the A+ spec. Nope, but I wound up writing some new code to illustrate polling solutions to async problems, which needs to come before Promises in the sequence that I'm building.

Extra credit:

This week:

This week is unusual because Betsy Haibel is in town so we can work on Cohere's AsyncJS course together. We've been working on the course a little at a time for a while, but we kept losing momentum. So we decided it might work better if we just huddled up and focused for a week. Wish us luck!

As far as an actual TODO list goes…

  • Record lots of course video with Betsy.
  • Publish a RubyTapas episode, even if it isn't the planned on.

As always, thanks for reading, and don't be a stranger to my inbox!

SIGAVDI #39: Bird and Book Edition

Hello friends,

It's been a couple weeks. I just got back from visiting Jessica Kerr in St. Louis. We saw the St. Louis City Museum, which I can only describe as like crawling around inside Neil Gaiman's mind.

We also recorded some live coding videos in which we, as two aging mostly-backend developers attempt to create a new web application using modern JavaScript technologies. While drinking beer. They were a lot of fun to make. Let me know if you'd like to see more video in this vein.

One thing those pairing sessions reinforced: we really, really like Glitch. It's a phenomenal leveling technology. It removes a number of barriers to learning to code web apps. You don't have to figure out hosting, or understand version control (but it keeps a history and exports to Github!).

On the other hand, it doesn't insulate you from file structure, so you won't be totally at sea when you do start working from a local development environment.

Another data point: I have a friend I'm helping learn to code and she was able to construct her first website in Glitch on her phone. A lot of people don't have reliable access to a computer, so that's kind of a big deal.

Oh yeah, we also recorded a Greater Than Code episode with Jean-François Cloutier. Go check out his video about building learning robots in Elixir, it's great.

OK let's see what I got done. This is kind of dated, but…

  • Make sure the January 7 episode gets out the door.
  • Finish unpacking from Australia (seriously it's getting embarrassing at this point)
  • Catch up on the my assistant's daily briefings (bad llama)
  • Catch up on email AGAIN (frickin' holidays)
  • Prep a RubyTapas freebie because it's been way too long.
  • Make SIGAVDI easier to sign up for.

The plan for the rest of this week:

  • Submit a talk proposal to NordicJS (and use this as a pull to get my ducks in a row for talk submissions – update bio, abstracts, talk history page).
  • Make sure I'm on top of at least the next two RubyTapas episodes.
  • Make plans for the upcoming Cohere/ShipRise Smoky Mountain Retreat. We'll be working on the AsyncJS course and other plots & plans. What do I need to do to prep?
  • Reimplement Promises in Ruby, again, based on the A+ spec. Mostly because I feel like it, and it feeds into some RubyTapas scripts, I've been writing, as well as into improving my understanding for the AsyncJS course.

OK, I know this is short on pontification this week, but I'm late and I feel like it's most important to keep the habit going.

Talk to you soon!

SIGAVDI #38: New Years edition

Hello, friends.

You know, the only problem with writing these is that it immediately shifts me toward a pensive mood. Like, OK, correspondence mode, time to reflect on existential ennui. Of course, that could just be the fact that I'm in an airport after having dropped off my kids in Pennsylvania.

On the other hand (writing this 20 minutes later), it's the 1st of the year and I just got upgraded to first class, so maybe this is gonna be a good year.

This week I said some things on Twitter about the question “why”. I don't think this question is the panacea some people think it is.

A while back I realized that every time I ask one of my kids “why did that seem like a good idea?!” I'm not really looking for an answer. I'm just trying to shame them. I'm irritated and I want to make them feel bad by having to stand there and stammer out some rationalization.

Like, this past week I found one of the USB device charging cables with a bend connector. My daughter fessed up to it, and without thinking I said “why would you DO that??”.

Here's the thing: Rationally, we both know the real answer: there is no “why” most of the time. At best, she barely thought about it and forcing the connector seemed like a good idea at the time.

More often, these kinds of mistake don't even rise to the level of conscious consideration. Why did you jump off the couch onto me while I was carrying a beer? Because I'm a child and it is in my nature to jump on you, same as it is in a Kangaroo's nature to lick its arms when it's hot.

In theory, one justification for asking these kinds of “whys” anyway is as a way to encourage mindfulness. I'm a big fan of mindfulness teachings, a la Thich Nhat Hanh and other teachers. I'm also a big fan of cognitive research a la Thinking, Fast and Slow. It occurred to me last week that in light of what little I understand about neuroscience, constant mindfulness may be an unrealistic goal.

We each get a finite pool of emotional/creative/decision energy per day. What if mindfulness saps that pool? What if the price of high creativity and emotional presence in bursts is “going on autopilot” (“System 1”, for fellow Kahneman nerds) the rest of the time? What if better habits and trained reactions is a more practical goal than constant mindfulness?

At any rate, “why” is not only a problem in early childhood development. I've started paying attention to the nascent Resilience Engineering movement, and one thing people in that field are saying is that asking “why” about failures—i.e. doing root cause analysis—is a problematic practice. Just like with young children, the answer you get is often an after-action rationalization. Successful systems are complex systems, and complex systems don't contain singular root causes. It's easy to pick a convenient “why” in retrospect. The “why” you arrive at for a given failure may not say anything about the next failure coming down the pipe.

Speaking of resilience…

The earbuds you use once a month aren't charged so you can't use them. The fire extinguisher you stored under the sink five years ago has rusted shut. The mice have gotten into the spare bag of flour. The canned food you put aside in case of a bad blizzard were eaten by your hungry teenage children and their friends. Your backups stopped backing up three months ago and the warning emails went to an old address. Your scripts for spinning up a new server are out of date.

A fundamental rule of resilient systems is: use it or lose it. Backups, fallbacks, excess capacity, failovers, contingency plans… if you're not actually using them, they aren't going to be there when you need them the most.

Enough pontificating, let's see how I did.

  • Catch up on snail-mail. Done.
  • Catch up on my YNAB budget. Done.
  • Survive the holidaysBeing on this plane was pretty much my criterion for surviving, so… check!

What was good:

  • I've been playing with Glitch as a way for total newbies to quickly jump into coding without being held up by the need for a local development environment, hosting, understanding version control, or even owning a PC. So far my experience has been very positive!

What sucked:

  • The weather in Pennsylvania.

What's on deck for [the rest of] this week:

  • Make sure the January 7 episode gets out the door.
  • Finish unpacking from Australia (seriously it's getting embarrassing at this point)
  • Catch up on the my assistant's daily briefings (bad llama)
  • Catch up on email AGAIN (frickin' holidays)
  • Prep a RubyTapas freebie because it's been way too long.
  • Make SIGAVDI easier to sign up for.

That seems like more than enough.

SIGAVDI #36: Beef wellington edition

Hello friends,

It feels very right to be sitting down and writing this on a Monday. Normally what I'd be doing right now is dithering over the dozens of things I “need” to do in the coming week. Instead, I am going to write to you and together we're gonna figure this week out.

Read More