Get a cute credit card and overtip

Highly recommend: get a BB-8 or similarly lovely icon from your favorite mythology on the credit/debit card you most frequently use. I have a couple lovely bonus conversations with folks per week because of it. Sometimes it’s “like your card” but sometimes it’s full “did you see the latest thing?” and it’s nice to talk to people outside my normal routines.

Of note, I get as many comments about BB-8 on my card in a week as I did for Darth Vader in a month. QED the fandom is wrong, bring more fun stuff and less super-serious Skywalker stuff. And don’t be cowards, let Chewbacca and Maz resolve their romantic tension!

ps. tip everyone you can until our country’s terrible treatment of people in service jobs improves. They work hard, get paid too little, have basically zero safety net, and serve on the front lines of the “may I speak with the manager” wars.

Unblocking oneself

Succeeding and thriving at remote work is largely about getting very good at asynchronous (Slack, discussion threads, email, etc.) and nearly-asynchronous (phone calls, video meetings, screen sharing) communication.

Productivity in remote work is often bottlenecked by the availability of teammates for near-asynchronous collaboration.

Therefore: boost your productivity as a remote team member by writing up context and questions your teammates can think through and help with when they’re available to collaborate. Then, pick up another task to make progress on in the meantime.

Continue reading “Unblocking oneself”

Sharing context in code review

A nice guide on code reviews (unfortunately no author is attributed on the Notion doc) is making the rounds. If you do code reviews, you should read it. If you don’t, you should start, and then read it.

I do have a personal quibble with this particular guide. I find code review most valuable for “education and context sharing”. I rarely detect bugs or “safety” issues when reading PRs. I’m trying to build this skill, so maybe check back with me later on that.

On the flip side, I want to boost a couple ideas that I wish had been in force for code reviews I’ve given/received in the past:

  • “No stylistic preferences” enforced by humans. This is indeed what linters and style guides are for. If you object to the use of linters, I can’t help you.
  • “No blocking tips”. Lately I’ve tried leaving comments that start with “not a blocker…” followed by an idea on how to make code clearer. This gives the code author the option to address it immediately if they have the gumption, return to it later if they don’t, or take it under consideration for the future.
  • “Any PR that introduces…a security or privacy issue should be blocked”, in particular user privacy/safety issues. I’m lucky to work on a team that is considering user safety and data privacy very early in the process, so we often don’t come across these issues as late as code review. That said, expanding code review scrutiny to include ways that customer data could be leaked or people could act maliciously feels like a cultural win.

Lastly, this whole paragraph hits home. Onboarding and “mind-melding” is possibly the second most important thing to keep in mind regarding code review in the year 2020:

Nobody went to school for hacking on your company’s stack. Outside of software fundamentals all of us had to learn how to make things work while on the job. Code reviews are one of the best ways for us to share knowledge and context about different ways things are done or tricks we’ve figured out to get things done in better ways.

In my opinion, the most important thing to remember about code review is that it is often the worst time to offer non-trivial feedback. Most pull/change requests land when a project is wrapping up and the author is ready to ship the thing. This is the riskiest and most frustrating time to make substantial changes. If you want to improve code design and practice, pair programming is the better tool, not code review.

Reading massive tomes: less slog, more joy

I’m drawn to expansive views on a subject. Sprawling narratives are irresistible. Giant books are my weakness. It’s rewarding to finish a chunky, 500-page book but getting there is quite the chore. The more pressing problem is, there are far more tomes out there than I can ever read.

Previously, my strategy for reading large non-fiction tomes has been to 1) slog through them or 2) let them sit around making me feel guilty. Instead of accruing a backlog, I’m looking for opportunities to get the essence of longer books with a smaller investment of time and energy.

Thus, I’ve organized my ideas into a 2×2 diagram to how I’m making tradeoffs and deciding which books to read this year:

A 2x2 diagram showing tradeoffs between reading/skimming, podcast interviews, articles/reviews on the book, and reading the Wikipedia article.
Besides reading a bajillion pages a day, how can I read more of the books I find interesting?
Continue reading “Reading massive tomes: less slog, more joy”

Little victories amongst the bigger vision

A couple of my favorite Ruby friends mentioned that they’re trying to keep their side projects small. Despite that very practical aspiration, the siren call of larger projects still beckons. We know the pragmatic step is to find the little projects inside the big projects and share/ship those.

And yet…it’s easy to fall back into big projects, forgetting to show progress. So here I am, showing a little bit of progress! 🤞

Here’s a behind-the-scenes look: I wrote this months ago, when I was trying to get back to consistently blogging. It was my the little push to get the habit started again.

The astute amongst have noticed that I’ve been somewhat consistent for the past few weeks. But I’m about to jaunt off for a few days of vacation and I didn’t want to let my progress reset to zero. So I dug this post back up and here we are. Repurposed for a good purpose.

I’m still here, showing progress. Finding the little victories amongst the bigger vision. Keeping the candle lit, per se. As it turns out, if perfect is the enemy of good, skipping your blogs because you’re going on vacation is the enemy of sticking with the habit of blogging. 📈

When management clicks

As a manager, I hear about things that are interesting and things that probably need changing.

“We want to do three projects but only have two teams.”
“The next production release is held up by this one task that needs seven people to agree on a minor but complicated detail.”
“The backend team has to spend the next week upgrading dependencies to meet new security requirements from the operations team.”

Lots of work to do there. Eyes bigger than stomachs, weird coordination issues, past decisions piling up and haunting us all at once. Assembling these data points into a theory of how the organization works, without falling victim to us-vs-them narratives and cynicism, is an essential challenge of management.

On the other hand, I hear things that are categorically good.

“Alice has saved us a ton of work this week.”
“Bob did fantastic work on this product and we’re going to ship early.”
“Carol stepped up and coordinated everyone when the project lead had to take a few sick days.”

In my few years of leading and managing teams, these are the best kinds of things to hear. Something about people is working here. They’re turning accountability for their work into positive outcomes.

Stacking repeated positive outcomes yields trust in people and teams. That yields agency to tackle future projects in creative, potentially better ways. That usually leads to even more positive outcomes. Even more importantly, it makes for teammates who are excited and satisfied by their work.

Bringing teams together across an organization to make positive outcomes for people who are excited about their work: that’s when management feels like it is clicking.

Three (increasingly wild) bits about Prince

As unreleased material trickles out of the Prince estate, some fantastic stories have emerged. I haven’t yet read The Beautiful Ones, but even the stories that aren’t part of his incomplete autobiography are top-notch Prince mythology.

Prince hired a DJ to play music for just him and his date:

“And then it hits me,” WallyWaves writes. “There’s only two people in there. Prince and a girl. I’m not there to DJ a private party. I’m there to DJ a date. Prince is on a date and I’m the entertainment.”

Prince shopping before Tower Records opened:

Mike: “How do you want to pay for this? Would you like us to ring it up now?”

Prince: (smiles)

Jerome: “Yeah, talk to THIS dude, here’s his number, he’ll handle it.” (hands us digits for the President of Warner Bros. Records)

Finally, for all your conversational and expressive needs, an Official Prince GIF Archive.

Do you think he's making a guitar sound with his mouth here?
Do you think he’s making guitar sounds with his mouth while he films a music video for a recording of him making guitar sounds with his hands?

Contracts made older objects better

Developers love contracts, i.e. types and type systems. Except, and especially, when they don’t. Contracts tell us, this module has a few functions and they definitely take these inputs and produce these outputs. Some languages (Haskell, Elm) even encode the possible side-effects of calling a function in the types. Contracts place useful, and sometimes comforting, constraints on the relationship between two bits of code.

A consequence of software eating the world is real-world contracts became weaker. Physical objects no longer have the constraints that made them special before.

That fancy car you bought might mix artificial engine sounds in with whatever’s playing on your speakers. It may also collect data on where you’re going, upload it through a cellular data connection you’re not even paying for, and sell it for “marketing”. All of this a departure from what was previously considered the “contract” for a high-end car.

That porch camera an e-commerce giant sold you so people don’t steal packages off your porch may also be accessible to their customer support. Or, the police. Again, a departure from the contract most of us grew up with for household electronics.

That book you bought might get “turned off” if it’s no longer a good business for the vendor. It might get changed if words in it were wrong or politically inconvenient. You guessed it, not quite the contract most of us expect from a bag of words.

That computer-enhanced movie you went to see might get revamped wholesale because the teeth are creepy, a human hand where a cat’s paw should be was overlooked, or because people were having too much of a laugh about the whole movie. Notably, this is not Martin Scorcese’s vision of what cinema should be.

Before they were software it was natural that cars, books, appliances, vinyl, etc. had better contracts:

To understand why books are still around, and why they delight as they do, we need to do some “media accounting” — What are the costs (individually, socially) of engaging with certain media and mediums, apps and publications?


Understanding the contracts into which we enter with media helps demystify why physical books (and, similarly, vinyl, analog film, et cetera) not only remain compelling, but become more compelling the more their digital twins grow vast and fuzzy.

Stab a Book, the Book Won’t Die – Craig Mod

The software we’re building today is in almost every way superior to the immutable objects we created before. But I can’t help think that the constraints that make a copy of Cat’s Cradle, The White Album, an Omega watch, or a Porsche 911 special might make software better as well.

Perhaps what we need is a little less change and a little more purpose.

Training & Learning

A thing I’ve learned from weightlifting (also from Destiny, but that’s a whole other thing), is the value of showing up several times a week and putting in the right kind of work.

Learning is training, and the quality of your reps is important. David Perell makes the connection better than I could:

Athletes train. Musicians train. Performers train. But knowledge workers don’t.


Knowledge workers should train like LeBron, and implement strict “learning plans.” To be sure, intellectual life is different from basketball. Success is harder to measure and the metrics for improvement aren’t quite as clear. Even then, there’s a lot to learn from the way top athletes train. They are clear in their objectives and deliberate in their pursuit of improvement.


Knowledge workers should imitate them.

Learn like an athlete

In short:

  • Train intentionally: choose one learning project per quarter.
  • Do the reps: learn every day.
  • Train in public/on Instagram: write/blog/etc. about your journey.

Economist Tyler Cowen also commented and shared his routine.

My personal routine this month is: read fiction and non-fiction every day. Write or revise every day with an eye towards building up my muscle for publishing articles on this blog.

Also: floss every night. 🤷‍♂️

Related: applying a fitness training mindset to software development is a great way to reach “I know this”!