SIGAVDI #50: Apple Cider Edition

Hello friends,

I’m writing this from Harrisburg, Pennsylvania. I spent the weekend with my kids down the road in York, and today I’m headed back to Knoxville.

One of my daughters asked me why I go to so many conferences, including one over her birthday. The temptation when a kid asks a question like this is to say “I have to”. But the truth is, I don’t have to. There’s very little we have to do. Some choices just have greater consequences than others. (And the consequences vary unevenly based on our circumstances/privileges.)

So I told her the truth: I choose to go to conferences. I choose partly because it helps with my work, and partly because I get to see old friends and meet new ones. But most of all, I go because I get to help people and sometimes change lives. I don’t just imagine this to be the case; I have countless emails and postcards and personal conversations to confirm it. I have a ministry, and my software conference presence is part of it.

I also choose my children. I choose to use my frequent flier miles and credit card points and income to fly up to see them for weekends, because summer break is just too long to wait, and because I can.

My children are not having the childhood I planned and tried to build for them. With changing circumstances, I have reconsidered many of the values I once took for granted.

I used to tell myself (and everyone else) a story about doing everything out of responsibility and obligation. Everything I did was because it needed to be done. There was no personal calling. There was little choice. It was an easy story to tell: there I was, virtuously bearing up under great responsibility, plodding forwards in the only way open to me.

I don’t know what my kids are going to think of me as they grow into adults. One thing I hope they see me model now, though, is agency. I want them to learn from me that people don’t act from opaque “have tos”. No matter what story we may tell ourselves about constraints and obligations. We choose, either consciously or unconsciously. And then we must acknowledge our choices and their consequences, and move forward.

At a conference recently someone asked me: as a Rubyist, what do I think of the Go language? I said: “ uh… it exists.”

There is an expectation in tech circles that if you want to be a serious tech power player, you have to have a hot take on everything. Microservices? Old hat. Serverless? New hotness. Ruby? Not interesting anymore. JavaScript? being ruined by featuritis.

There are people who spend their days on Reddit and Hacker News delivering hot takes on every technology, idea, or opinion that comes down the pipe. Sometimes I feel the need to remind junior devs that if that’s where they are getting their perspective, they are getting their point of view from a self-selecting subset of technologists who have nothing better to do than Have Opinions On The Internet all day.

My hot take on hot takes? As a software developer it’s important to know that technologies exist, and at least a vague sense of where they fit into the ecosystem. Beyond that, you do not need to have opinions. You do not have to have a “take” in order to be a serious player.

Stories, though. Stories are another, uh, story. By all means collect stories! And tell them at every opportunity.

Just don’t mistake stories for universal truths. Every story has a context.

OK, let’s see how I did.

  • ✔ Visit the kids over Easter/Passsover.

  • ❌ Finish landing page/video for Flawless Ruby But! I made some solid progress. All that’s left is to edit the video I made for it.

  • ❌ Edit video on building chatbots in Ruby. No movement.

  • ❌ Nail down my first part-time contracting gig. I’m a lot closer but I haven’t signed contracts quite yet. Contracts are tedious, yo.

  • ❌Start coding in earnest on That One Side Project I keep flaking on. Sigh.

  • ❌ Post another episode of The Cache Flush. Maybe I’ll get this done before it’s time to get on the plane.

Bonus points (stuff I did that wasn’t on the list):

  • ✔ Attend a users group meeting. I went to the local JS group for the first time and had a great time afterwards over beers. I even recorded some more interviews for The Cache Flush!

  • ✔ Clear out my !@%*ing work inbox. There were some things in there that were really stressing me out too.

  • ✔ Help my friend Amy with her upcoming RailsConf talk, which you should definitely go see if you are attending RailsConf. (This sort of thing is one of the reasons I started a Patreon – I’d love to spend more of my time just helping boost new voices in software.)

  • ✔ Mooch some boilerplate contract templates from a friend and customize them for my upcoming consulting clients. This was more work than I expected.

  • ✔ Get started mentoring a friend in how I run RubyTapas.

  • ✔ All the usual RubyTapas editing, copywriting, script review meetings, etc. Word-tier and higher Patreon supporters saw some new behind-the-scenes videos this week!

Yep, another week of carrying the list forward from last week. Ah well, they can’t all be hyperproductive. This week:

  • Prep to speak at Deliver:Agile in a week.

  • Finish landing page/video for Flawless Ruby

  • Edit video on building chatbots in Ruby.

  • Nail down my first part-time contracting gig.

  • Start coding in earnest on That One Side Project I keep flaking on.

  • Post another episode of The Cache Flush.

Wish me luck!

SIGAVDI #49 – Space Vodka Edition

Hello friends,

I can’t brain today and I’m not sure why. I haven’t drunk much alcohol in the last few days, I have received more than adequate cuddles, and I slept way in this morning. Maybe it’s the weather? I’m writing this on the porch in the windy sun between two storm systems.

Read More

SIGAVDI #48 – Smoking Goat Edition

Hello friends,

This week I've been thinking about the tension between catching errors at compile time and catching them at runtime. On the surface level this one seems like a no-brainer: the early you catch a problem, the better.

But in my [mumblemumble] years of static-language experience, what I observed was that the more you focus on pushing all errors into the the realm of static compile-time verification, the more catastrophic and difficult-to-debug the runtime errors become. And there are always runtime errors. Even after you've eliminated null from your programming language.

The resilience engineering community has a counter-intuitive approach: instead of trying to eliminate errors early, actively cause them in production. Then learn how to tweak your sociotechnical systems so that they gracefully handle failure and mitigate damage.

Someone will always object: this is not an either/or. Let's eliminate as many errors as possible at compile time, and make the runtime errors easier to handle as well!

In practice, these seem not to be two dials you can turn up simultaneously. Gracefulness at runtime and static verifiability are design forces in partial tension with each other.

Is this such a surprise? It's just the oak and the reed again. The more rigidly we structure things the more jagged they are when they crack.

I know where I fall, now. I am an oak learning to be a reed. My life is falling forwards. My eyes hurt and my new glasses aren't here yet and my neck hurts because my spine is fucked up and my hand hurts because my ulnar nerve is impinged and parts of my business are failing or falling behind and my kids are far away from me and I probably don't have enough money to get through next month and two more boards in my deck have cracked and the mail is stacking up and once… once upon a time I believed I was going to get my whole house in order before I moved forwards.

No more. My house will never be in order and everything will always be falling apart and this is fine. Because there's beauty in the breakdown but more importantly, there's new order and new life and new happy coincidences. There's new love and new vistas and new collaborations and new restaurants to try with new friends and nothing is ever the right solution forever. Thank goodness.

The big news this week is that I finally started a Patreon. It's still a work in progress. My favorite bright idea was to make a lot of the tier benefits be about sponsoring other people rather than about getting rewards for yourself. I hope this resonates with patrons.

In the process of kicking off the Patreon, I repurposed the name of a now-defunct microblog I used to write and created a new Slack workspace called “Padding Bits”. If you like SIGAVDI but wish it was more real-time (and even more interactive!), you can now join in the fun for as little as a buck a month 😀

Let's see how I did:

  • ✔ Play Super Smash Brothers with the children who are presently interrupting the writing of this email. Done! Granted this one was kind of a gimme.

  • ❌Create a landing page for Flawless Ruby I did put in a lot of work on this one, including shooting some video for it, but it's not quite there yet.

  • ❌ Edit video on building chatbots in Ruby. Nope.

  • ✔ Launch my Patreon because why the hell not. Yes!

  • ❌ Migrate off of Drip for mailing list hosting because they are a total garbage fire since their acquisition. This was overly ambitious but I DID start a Convert Kit trial. They've been the front-runner all along, and when I found out they have Patreon integration they became even more attractive.
  • Bonus accomplishment: learn about the Kuberdoobers with Jessica!

This week's goals:

  • Attend DevopsDays/ServerlessDays/MapCamp Atlanta and learn whatever it has to teach me.
  • Finish landing page/video for Flawless Ruby

  • Edit video on building chatbots in Ruby

  • Evaluate Convert Kit.
  • Nail down my first part-time contracting gig. (I'm still interested in talking to potential clients!)
  • Start coding in earnest on That One Side Project I keep flaking on. Because I really, really need to write code.

As always, thanks for reading!

SIGAVDI #47 – Pear Pizza Edition

Hello friends,

It's been a couple of weeks. Since last Tuesday I've been in St. Louis. Jessica and I paired on some Docker & Kubernetes stuff. It was highly educational.

And we went to the symphony.

And the art museum.

But mostly we ate really good food.

Some of it highbrow.

Some of it less so.

That is an authentic St. Louis “slinger“, a $6.50 pile of sloppy late-night goodness.

A mistake I have made over and over again: thinking of life in terms of forks in the road. Big choices on which everything hinges.

The truth is, there are few choices in life that can’t be a “yes, and…” with some creativity. And most choices can be amended.

Just move. Direction is always adjustable.

I’m thinking of starting a Patreon (just do it, Avdi! Direction is always adjustable!). I’m trying to figure out what rewards to offer subscribers. Thoughts? It can’t be anything that adds a significant amount of work to my weeks.

I should print stickers. Everybody likes stickers, right?

I find myself badly wanting to sit down and code lately. It’s been so long since that was a central part of my day. This urge was one of the motivations for soliciting new consulting clients. Ironically, one of my first gigs may be more about video production than coding (more on that soon, hopefully).

A lot of it is just that I miss the relative simplicity of making shit work instead of deciding what shit needs to be done.

I’m also thinking of doing a talk on communicating technical ideas. I spend a lot of my time these days coaching other people on how to do that.

I’m really struggling with my goals this week. There are a lot of possibilities. Let’s talk about the last two weeks first.

  • ✔ Stream/record some kind of collab with Janelle Klein. Done. It’s probably not going to see the light of day, but it set us up for future recordings.

  • ✔ Finalize my new working arrangement with Cohere. Done. Not in the way that I had anticipated, but I made a decision for the time being and it’s time to move forward with other plans for now.

  • ✔ Get to a tentative agreement on a consulting gig. Done! This was a stretch goal but it happened 🙂

  • ✔ Nail down April travel plans. Done. I’m spending more time traveling than home this month. This is fine.

  • ❌Clean up the weight room and do some lifting. Nope. But! I ran and lifted here in St. Louis!

  • ✔ Sundry RubyTapas and Rubber Duck meetings and related work.

  • ✔ Attend a new meetup Done! Well, sort of. My original plans fell through (who schedules a meetup for 6PM?!) but I made it back to the Knoxville Devops meetup.

  • ✔ Attend some part of Big Ears Festival. YES! Janelle and I caught Max Jaffe doing interesting drum things, and later attended the poetry slam finals which were fantastic.

What am I doing this week?

  • Play Super Smash Brothers with the children who are presently interrupting the writing of this email.

  • Create a landing page for Flawless Ruby

  • Edit video on building chatbots in Ruby

  • Launch my Patreon because why the hell not

  • Migrate off of Drip for mailing list hosting because they are a total garbage fire since their acquisition.

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:

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!

How to meet people at tech events when you’re awkward and shy

Are you a meetup wallflower? Believe it or not, so am I.

Jessica Kerr isn't, though. She's one of the most vibrantly social developers I know. The other day I asked her: what are some ways to get over awkwardness and make valuable connections at tech events? We recorded the conversation, and you can watch it right here. Or, you can get an enhanced version with edited video, audio downloads, and a PDF below.

Want to get the key takeaways AND support more content like this? I'm trying an experiment. I've distilled the conversation down to a concise, tightly-edited 15-minute version. You can have .mp4 and .mp3 versions of both the long and short versions, AND a PDF we authored together containing 32 takeaways (including a few we didn't talk about in the video), for just $5.

Sarah Mei says“Highly recommend… even the PDF summary had several new ideas I’m going to try out at my next meetup.”

SIGAVDI #45: Pimento Cheese Edition

Hello Friends,

First off, sorry if you got another duplicate SIGAVDI from last week. Drip's RSS-to-email service apparently doesn't keep track of the IDs of posts it has already syndicated.

Let's start with a picture of a flower before I get cranky.

Last week I tried to get started with AWS Lambda. It did not go well. I did a lot of cursing on Twitter and on stream.

The AWS developer experience is straight-up awful, and it's a wonder to me that anyone tolerates it. It's reminiscent of J2EE a couple decades ago, in that there is a lot of totally unnecessary ceremony, but it's “the standard” so everyone assumes that this is just the way it has to be.

Now there is a devoted technical priesthood, who have invested both their livelihood and their sense of mastery in the persistence of the status quo. Not to mention the strata of parasitic services which exist solely to put a simplified face on AWS services, and whose existence thus depends on raw AWS continuing to be a shitshow.

These are not good incentives to have in your developer ecosystem.

Example 1: In the 500 page official guide to AWS Lambda, there is a section that instructs the developer to “write the following JSON”. There follows three pages of JSON intended to be entered into a text field. Someone actually wrote that out and said “yep, this is acceptable, ship it”.

Example 2: In order to use the AWS CLI for the first time, I am instructed to:

  1. Log into the web portal
  2. create a new user
  3. create a new administrative group
  4. and search through several hundred permission bundles in order to find the correct one to…
  5. …assign admin rights to the new group, so that I can finally
  6. Copy an ID and a key to the CLI setup.

Compare this to the Heroku CLI experience.

AWS is also reminiscent of the Microsoft developer ecosystem a couple decades ago, in that the breakneck pace of API updates gives invested developers no time to step back and evaluate alternatives.

(For the record, no, this complexity is not essential—from what I've seen so far the Microsoft Azure experience is a shining example of how it can be done better. My how the mighty have… gotten their shit together.)

Someone quoted Hanlon to me in reply to one of my tweets: “Never attribute to malice that which is adequately explained by stupidity”. I don't think systems like this stem from malice. Sociotechnical systems are more like water seeking the least opposed path through which to flow. All it takes for malicious attributes to spontaneously emerge is for no one to reflect on the outcomes.

One other insight that came out of that rotten experience: good APIs and good documentation are inseparable. You can't have the one without the other. You get them both at once, when the people tasked with communicating to developers are empowered to say “the experience I am documenting is unacceptable, let's change this”. I watch Jessica doing this for Atomist on her streams all the time, and it's great. I've also heard the same kinds of stories from Azure's DevRel team, and it shows in the quality of both their docs and their DevX.

I wrote some advice to a friend the other day. It's about the worlds we hold inside, and the longing we sometimes have for someone to come join us in our inner worlds. It went something like this:

No one can join us in our inner worlds.
There is a place inside where we all stand alone.
It's not about finding someone to join you.
It's about joining with others and building worlds in the connections.
This requires a letting-go.
Letting go of control.
Letting go of dreams.
Not forever, just for a time.
Every time I let go it's painful.
Every time, I don't want to.
Someone says “come build this thing with me”.
And it's not my trip. It's not my brand. It's not my dream. It's not my thing.
But I work with them.
And a thousand insights take flight
Worlds take shape between us.
It's… washing up on other people's shores.
Allowing their dreams to take precedence for an hour or a day or a week.
This is how we entangle ourselves with the world
And in return we get leverage.
And our insights are deepened.
And we are enriched.

Let's see how I did.

  • ✔ The usual RubyTapas stuff. Eh, sort of.
  • ✔ Nail down March travel plans.
  • ❌ Write and publish a post about the consulting gig I want to pick up. Didn't happen.
  • ✔ 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. Yep! I picked the “Flawless Ruby” course I've been quietly developing, and added 17 new lessons to make it content-complete.
  • ✔ Submit to a conference. Two, in fact: DevOpsDays/Serverlessdays Atlanta and THAT Conference.
  • ❌ Clean up the weightlifting room so I can start working out there again.

Next up:

  • Create and launch a marketing campaign for Flawless Ruby.
  • Publish “Beyond Business Cards”, a recorded discussion I had with Jessica Kerr about how to meet people at tech events.
  • Get next week's RubyTapas episode out the door.
  • Visit my kids.

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.

Things I’ve Misunderstood About Promises

Since I've been mucking about with JavaScript more, I've discovered that for some reason the Promise pattern is a profoundly unintuitive one to me. In my quest to accurately model their semantics in my mind, I've read through the A+ spec and written a couple of partial Promise implementations of my own. I still don't feel like I've completely nailed it down.

Here is an incomplete list of my misunderstandings (so far) about Promises.

  1. Promises are not boxes that values appear in.
  2. Promises are not really about values at all.
  3. Promises are also not about the work.
  4. Or about managing work.
  5. They are a signaling mechanism off to the side of the work.
  6. Promises aren't about giving you something to wait on.
  7. You don't know when a Promise will be fulfilled; you only get to say what should happen if and when it's fulfilled.
  8. A Promise is not a pure data structure. A complete implementation requires a deferral mechanism (e.g. a way to kick TODOs into a global reactor next-tick queue).
  9. Promises are not about pulling. They are about pushing.
  10. Promises will not make your async code visualizable as a nice clean dataflow diagram (look to actors and channels for that).
  11. Promises are terribly named. They give no assurance about anything. (Cynical readers might argue that this makes them exactly like real-world promises).
  12. Promises do not manage or perform work. A chain of promises:
    1. Signals when new work can be started.
    2. Channels results from one operation to the next.
  13. Of the two, only the signaling part is essential. The channeling part can be and is often unused.
  14. .then() is not an operation on a Promise. .then() is a specialized constructor of new Promises.
  15. Promises are causality insertions.