Leap Day

Leap Day

The world is a complex place. Time is hard, as evidenced by the plethora of things going wrong today. Naming is hard. Designing architectures is hard. Getting GenAI right is hard when the answers really matter.

And as it turns out, color is hard too! Did you know there are “imaginary colors”? I didn’t? How cool!

This is not an argument to run away from technology, but to say that we who do this work must be vigilant and realistic. The answer to “how long” is never “five minutes”. And we must engage across a broad set of disciplines, because our own perspectives are limited.

When confronted with complexity, the wrong answer is to retreat to comfortable simplicity. Read. Listen. Have an open mind and broaden your view of the world.

Two Things True

Two Things True

On the same day I wrote about radical responsiveness, I came upon this post that seems to contradict it. I really respect Ethan Evans and enjoy his writing (especially this bit about why you fail to get promoted). And I understand the point he’s making about fragmented attention. The temptation to conflate interruptions with importance is real, and amplified by modern communication technologies. But I’m not prepared to say he’s right and I’m wrong.

For one, I believe it’s possible to be both radically responsive while remaining reasonably non-fragmented. Some degree of interruption is inevitable, but using techniques such as pomodoro can help protect focus while still ensuring important messages don’t get missed for long. Good old-fashioned discipline is required to stick to a plan, but it can be done.

The discipline gets easier with a well-configured set of tools, which is where many folks fail. Learn your tools! And not just the basic features, but the myriad of options for managing notifications, filtering messages, scheduling reminders, etc. It’s not a badge of honor to be “bad at email” or “not understand Slack” if you’re a professional in 2024.

(If any of my coworkers are reading this, they may quickly point out that as recently as last month I didn’t know how to join cell phone calls into a conference. Which… is true. But I learned! And now I know for next time).

Finally, Evans makes an assumption about communication that I don’t believe holds true. It comes through most obviously in this statement:

“Allow chaos to build up within the trivial (the inbox) to accomplish the meaningful.”

Did you see it? The assumption that messages in an inbox are trivial? Tell that to your customer who is informing you of a serious issue with your latest release, or your team member whose employment status is in jeopardy if you don’t respond to their immigration lawyer. Yes, we all get spam, but sometimes interruptions truly are critical and need attention. To lump all of that into the category of “trivial” for the sake of personal flow is a leadership fail. Communication is part of the job; sometimes it’s all of the job.

Of course, I could be wrong. Read the posts and decide for yourself.

It Is And It Is

It Is And It Is

Last night ChatGPT had a bug. But not your run-of-the-mill problem like increased latency or complete unavailability. No, it went completely off-the-rails: spouting gibberish, repeating itself ad infinitum, and other nonsensical behavior.

Hilarious though some of the outputs were, it was a powerful reminder that AI technologies are still new and mysterious, and definitely require human oversight. While this incident ended up with random output, I can now imagine a whole class of bugs where language model outputs are wrong in all manner of specifically bad ways. Humorous now, but perhaps less so once we give them agency to act on our behalf.

I anticipate the day coming when I ask my personal Scarlett Johansson to book a family vacation to Fiji and it instead sends an email to my mom lambasting her for wearing white after Labor Day and then sells my living room furniture on eBay.

The future’s going to be something else, of that we can be sure.

Not All Who Wander

Not All Who Wander

There’s a danger in over-indexing on successful outcomes when evaluating a decision. As a LeBron fan I respect making the right play even if the shot doesn’t go down. When watching football (I hear there’s a game today?) I shake my head at coaches who punt when the data says taking a bigger risk is worth it. The same is true when making business decisions and evaluating technical tradeoffs.

Simple math makes the above obvious in certain cases. Whether a decision has a 90%, 60%, or even 51% probability of success, it is the right decision to make, even if it doesn’t work out (presuming the cost of failure is equal no matter what decision is made).

Of course a nice probability cannot be known in most real-world situations. It’s in those moments when it’s especially important not to focus too much on the outcome. Because a failed result doesn’t tell us anything certain about the original likelihood of success, as even 95% certainty fails 5% of the time.

I don’t say any of this to mean that a pattern of failed outcomes should be ignored, but that full context should be used in any process that attempts to evaluate the road that led to certain results.

To The Point

To The Point

Today I finally came up with a layperson’s descriptor of the CTO role that I’m happy with:

Responsible for making sure we build things right, but more importantly, that we build the right things.

Yup, that sums it up nicely.

Fork In The Road

Fork In The Road

Recently I got a Google reminder about a trip I took nine years ago. It was a business trip to the East Coast, and I remember it well, because it was at that meeting where I successfully convinced a customer that we needed to launch a large new development effort.

Little did I know at the time how the decisions made at that meeting would steer the direction of my next several years. And not just me, but our company, and the raft of individuals who we hired to work on the project. A handful of whom are still involved after all this time. And several whom I number amongst my friends.

The more I think about it, 10,000 people influenced over a lifetime is starting to sound like a low estimate. Our actions have real consequences. That’s a sobering thought, but also an inspiring one.

Remote Learning

Remote Learning

Ohio in the early 90s had few educational options for a middle schooler interested in computers. But when there’s a will (and willing parents, thank you) there’s a way. Somehow I got signed up for a correspondence course in Pascal in 8th grade. Yes, an actual class where I never met in person (and only rarely spoke to the teacher on the phone). Where the majority of exchanges were via the good old fashion United States Postal Service. Where code had to be printed out, mailed, marked up, and mailed back (how’s that for slowing down rapid iteration!)

Despite it seeming painful to modern ideas of remote learning, the material was quite useful in my overall development. Up until then I was completely self-taught; reasonably good in BASIC and some rudimentary C. Learning Pascal, however, really opened up a new world. And luckily for you all, I still have a number of my Pascal programs, which I recently uploaded to Github for your browsing pleasure. Here’s the good stuff that awaits you:

  • MARKET.PAS – This one’s special for two reasons. First, it’s the oldest of all these files, with a last modified date of Dec 6, 1992, making it the earliest example of code I wrote that I still have in digital form (the absolute oldest being this handwritten BASIC program from 1987). And second, it was my attempt to implement the Stock Market Game, a board game from the 1970s that my mom and I played together when I was a kid. No one else in the family ever wanted to join; it was kinda “our thing” (as was Scrabble).
  • GRADE.PAS – A simple gradebook app for teachers. I believe this was the final project for my correspondence course.
  • CYBER.PAS & CYBORG.PAS – Today you couldn’t pay me enough to get into video game development, but as a youngling I had a thing for trying to build them. This code is a tiny step towards what looks like a side-scrolling shooter involving robots and lasers.
  • KARATE.PAS & KGRAPHIC.PAS – Another game effort, this one a fighter like Mortal Kombat, but with stick figures, because I am terrible at visual art. Pretty sure I got it to a reasonably playable state, though the mechanics were terrible and it required two people because there was no AI to speak of.
  • JDNCRYPT.PAS – Built this encryption tool to protect DIARY.TXT, which I still have (but no, I’m not gonna share it). Basically I reinvented a simple rotation cipher using an insecurely predictable pseudo-random number generator, with an easily bypassed magic parameter kill-switch on the executable. How cute. Rule one of cryptography: never ever write your own.
  • GAME133.PAS – In college a mathy friend of mine and I got really into the Number Jumbler. I wrote this solver to do research into combinations that had no solutions. Two years later when I started my first real job, I was tasked to learn Ada, and as part of that effort I ported this solver.

FYI, in upcoming posts I intend to expand on my personal tech history; including a visual history of my computer setups. Will it be of interest? Maybe! But I’m going to do it regardless.

Life Hack

Life Hack

It may not seem like much, but you never know the lives you touch
just by always showing up, even on the days you feel so small.
Turns out it all matters after all
.

– Derek Webb

Want an easy way to be perceived as good at your job? Set aggressive goals for being responsive across all your communication media, and especially strive to avoid failing to respond or missing messages altogether.

My own personal targets are the following:

  • Slack / Text: 5 minutes ideally, 1 hour median, never more than 24 hours
  • Email / Voicemail: 4 hours ideally, 24 hours median, never more than 3 days

Even just an “I got it, will have you a better response by X time” goes a long way (assuming of course that you do indeed follow-up). Liberal use of tools like reminders, snoozed messages, and do-not-disturb / notification settings make this achievable without completely giving up on work/life balance.

I call the approach “radical responsiveness”. In my experience, it’s a simple way to earn trust with colleagues and customers alike. It works across levels and roles, though it’s particularly helpful when being attentive is part of the job, like sales positions, and especially critical for people management. Be the boss that always responds quickly and your team will be imminently thankful.

Of course you won’t be able to meet these objectives 100% of the time, but being known as a responsive person 95% of the time usually means others will assume the best of you for the 5% of time you fail.

Distant Well-Wishers

Distant Well-Wishers

Of all the sources of happy birthday messages (which are truly delightful, by the way), one I least expected was a text from the customer service agent at CoveredCA that I worked with to get health insurance after I was laid off nearly 5 years ago, and haven’t interacted with since.

I get that it’s trivially easy for any organization that knows your date of birth to send out such messages, but…

That’s gotta be some kind of automated message, right? Or a mistake? In any case, thanks for “thinking of me” on my special day!