Blog

SIGAVDI #46: Corned beef & cabbage edition

Hello friends,

It's been two weeks since the last SIGAVDI. I visited my kids in Pennsylvania last weekend, then came home and went into a bit of an emotional tailspin. As of today (Sunday) I'm feeling a bit better. I attribute the improvement mostly to getting some much-needed human touch and socialization over the past two days. It's amazing how much these things help.

Heads up: I'm officially looking for a part-time consulting client. There's some more info here; feel free to pass it along!

Some premises about my relationship with unit testing:

1. I like test-driven development.
2. I like driving out individual object design small, isolated (e.g. no database) unit tests.
3. I think of these unit tests as a design aid, full stop. Any help they provide with preventing regressions is gravy.
4. I treat unit tests as disposable. Once they have served their purpose as design aids, I will only keep them around so long as they aren't getting in the way.

These four premises are strongly interconnected. Take away #1 (test first), and tests are no longer a design aid and none of the other points are valid. Take away #2 (isolation) and we get into integration test territory where there's a much higher possibility of tests having regression-prevention value. Take away #3 (design focus) and the other points lose their justification. Take away #4 (disposability) and I spend all my time updating tests broken code changes.

This makes  it easy for me to find myself at cross purposes with others in discussions about unit testing, because often they come into the conversation not sharing my premises. For instance, if your focus in unit testing is on preventing regressions, you might well decide isolated unit tests are more trouble than they are worth. I can't really argue with that.

A recent conversation on this topic inspired the thought from the driving-design perspective, maybe unit tests are really just a crutch for languages that don't have a sufficiently strong REPL experience. While I don't think this is strictly true, I think the perspective shines a useful light on what we're really trying to accomplish with unit tests. I almost think that what I really want out of unit tests is the ability to fiddle with live objects in a REPL until they do what I want, and then save that REPL session directly to a test for convenience in flagging API changes.

That conversation also spawned the idea of immutable unit tests: unit tests that can only be deleted, never updated. A bit like TCR. I wonder if this would place some helpful incentives on the test-writing process.

So I tweeted about some of these thoughts and someone was like “don't say that in public, you might lead junior developers astray”. And it got me thinking about how I've said similar things in the past. There's a trope in the developer practices conversation that goes: “there are some things experts do which we shouldn't talk about in public, because someone impressionable might get the wrong idea.”

The more I think about this, the more I wonder if it's healthy or constructive. What do you think?

Sometimes you make me feel like I'm living at the end of the world.

— The Cure, Plainsong

I've been thinking and talking to friends about apocalyptic relationships. That's my phrase for relationships that are premised on a model of “you and me against the world”. Imagine the post-apocalyptic film or novel of your choice, with the two romantic leads braving a treacherous wasteland full of bandits and mutants, and you have the right idea.

Apocalyptic relationships are inward-facing. They survive on the energy of “anti”. They have only one speed: intense. They draw their intensity from scarcity. You and me: we're the only ones who can help each other through this hellscape.

For many years I was in a relationship that only really worked when it was in the apocalyptic mode. Now I feel like I'm keenly sensitized to the “smell” of potential apocalypse. I've been talking to friends about their experiences with apocalyptic pairings. Once likened it to a “Bonnie and Clyde” feel. A relational suicide pact. They all agree though: these relationships are engrossing, intoxicating, profoundly difficult to move on from, and they feel like nothing else could ever come close in terms of intensity of feeling.

I'd be curious to hear your experiences and thoughts, if any.

OK, let's see how I did:

• ✔ Create and launch a marketing campaign for Flawless Ruby. So the campaign turned out to be “just get it out the door and announced and worry about further marketing later” and by that definition I succeeded!
• ✔ Publish “Beyond Business Cards”, a recorded discussion I had with Jessica Kerr about how to meet people at tech events.Yep, along with an experimental microproduct consisting of a cleaned-up version of the recording plus a little PDF we put together! 
• ✔ Get next week's RubyTapas episode out the door.
• ✔ Visit my kids.

This week my friend Janelle is visiting (you should check out her book!). We're mostly going to be working on our own respective projects, but I'm hoping to make some kind of collaboration emerge as well. Goals for the week:

• Stream/record some kind of collab with Janelle (IdeaFlow demo??).
• Finalize my new working arrangement with Cohere.
• Get to a tentative agreement on a consulting gig (probably over-optimistic but I can hope).
• Nail down April travel plans.
• Clean up the weight room and do some lifting.
• Sundry RubyTapas and Rubber Duck meetings and related work.
• Attend a new meetup (I have one picked out already!)
• Attend some part of Big Ears Festival.

OK, that's it for this week. Thanks for reading!

SIGAVDI #44: Goat Cheese Edition

Hello Friends,

I'm having trouble writing this today. I'm already two days late, and I feel completely uninspired.

Spring has been sputtering hesitantly to life around here. Here is a flower of some sort from my front garden.

While I was working with Betsy Haibel on her Asynchronous JavaScript course I got curious about what some of the patterns would look like in Ruby. Specifically, I wanted both to understand Promises better, and figure out whether they were also necessary in a language like Ruby that has built-in Fibers (short answer: nope).

I spent a lot of the past week writing and re-writing Ruby demo code to explain various async patterns like demultiplexing, Reactor, Promises, and JavaScript's async/await keywords. This is all going to make its way into some RubyTapas episodes. But now that I've spent as much time on it as I have, and written this much code about it, I think I'd like to expand it into a course of some kind. “Understanding Async with Ruby and Marshmallows”, how does that sound? Would you be interested in such a course?

In the process I wrote up a list of all the many ways I misunderstood Promises along the way.

I am very anxious today. For the usual reason, money. My income consists of a) subscription income plus b) some kind of special sale or two, often of a new product, over the course of a year. I haven't done (b) in quite a while, and I'm getting to the point of wondering if I'll make each upcoming month's expenses.

This anxiety always comes with a heaping helping of frustration at the sense that I'm constantly mired in upkeep. I want to make new things and yet week after week I feel like I just tread water. It's a vicious cycle: the longer I do it, the less inspired I feel.

And then when I do  have time to work on something big, I feel like I don't know what project to choose and so I dither.

I wonder if this is what it's like for other people in my line of work? I'm pretty successful as pro-developer-trainers go. I wonder if other people who do what I do, feel this way?

My laptop is failing and this is bumming me out too. I really want to buy a shiny new video editing laptop to take the failing laptop's place while it's in the shop, and then to become my “home” machine once my little lightweight Spectre comes back to me.

Do I need to buy a shiny new laptop? No. I could resurrect one of my old machines for the interim. I want to buy a new one because I'm anxious and stressed and feeling useless, and my brain wants to avoid these feelings with dopamine. Shiny new computers come with lots of dopamine. Unfortunately, it always runs out.

It's time to take a consulting gig for extra revenue. Well, not just extra revenue. I haven't worked with a team since… 2011? I burned out hard on working other people's problems, and that burnout played a big role in the creation of my education business.

I want to be in the thick of it again. I've had a lot of new ideas since my last coding job, and I want to have a real sociotechnical system to bang those ideas against. See what sticks and what falls apart.

And I want to feel the pain again. I want to remember firsthand why I care about making systems better. Maybe feel some of the frustrations that burned me out last time around, but this time collaborate on ways to overcome them.

In short I crave inspiration. If you have a lead on a position you think might be right for me, please do reply!

Prefer part-time and flexible, since I still have a business to run. Must at least partially involve pairing/coaching/collaborating with other people. Bonus points if the company doesn't mind me livestreaming some of the work.

OK here's the thing: I take a look at my situation. I come to the conclusion: I will take a consulting gig. This will help.

Then I waffle, and dither. If I take a consulting gig, I won't be able to work on new products! I won't be able to do any of the stuff on my list! What if it's a terrible mistake?!

But (and here is where I give myself advice): interaction spurs progression. The point is not to make the right call. The point is I need to put certain stresses on my mental system in order to cause it to respond in desirable ways.

Stresses like time pressure. Stresses like other people's perspectives and questions. Stresses like client expectations. I can't simulate these stresses.

This is what I don't remind myself of often enough. Analysis paralysis is never-ending. A nice hike or a vacation in the tropics can help with clarity, but true shifts only occur under stress. And true inspiration only occurs in friction with other ideas. I don't need to make the right call, I need pressure to force me to make more calls.

OK, let's see how I did. I'm going to cut myself some slack and include stuff I did in the “overtime” since Sunday.

• ✔Burn Catch up on snail-mail. For real. I only got about 2/3 of the way through but I'm counting this as a win.
• ✔ The usual RubyTapas stuff, including several guest chef meetings. Done.
• ✔ Actually show up for a >Code episode. Done! We talked to “Pragmatic” Andy Hunt and it was great 😁
• ✔ Write and record VO for two RubyTapas episodes.
• ✔ Go running. I got three miles in and I am gloriously sore.
• ❌ Investigate my options for some part-time consulting work. I did not scope this well enough.
• ❌ Livestream on my own at a “regular” time. Didn't happen.
• ✔ Livestream with Jessica. Did happen! We paired on her Atomist microgrammar GUI.

What's next:

• The usual RubyTapas stuff.
• Nail down March travel plans.
• Write and publish a post about the consulting gig I want to pick up.
• Evaluate open loops of projects-that-could-be-generating-revenue-if-I-finished-them, pick one and make a concrete plan to finish it by a specific date.
• Submit to a conference.
• Clean up the weightlifting room so I can start working out there again.

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!

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:

• I was interviewed by Chris Toomey for an episode of The Bike Shed podcast
• I was interviewed for an episode of Jason Herrington's devpath.fm podcast
• I did a 2-hour rubber duck session for a private client. (Did you know you can book my time for consulting and coaching?)
• I went dancing, arguably my most important self-care habit. There was absinthe! Hence the title.

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!