Tag: Are Right A Lot

Coming Up For Air

Coming Up For Air

Believe it or not, I’m not going to say anything about Claude today.

I wrote a post a couple years ago about statistics I tracked while doing daily crossword puzzles. I took a couple years off, but last year I was back at it, this time using a calendar from the New York Times.

The NYT crosswords are supposed to get harder as the week goes on, with Monday being easiest, and weekend ones being the most difficult. I wanted to prove that out, so I noted my average solve time (capped at 30 minutes) on every puzzle, and then computed an average solve time for each day. The results are below:

Lo and behold, my experience aligns perfectly! I thought that was cool.

No Seriously, Don’t Stop

No Seriously, Don’t Stop

I’m starting to feel a compulsion to keep as many Claude Code terminals running as I possibly can. Ready for lunch? Try to kick off a large implementation. Bathroom break needed? Run a research project in parallel. Bedtime? Don’t you dare until you have your swarm of agent teams configured with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS and everything allowed thanks to --dangerously-skip-permissions.

Time to git add --all && git commit -m "yolo" && git push -f up in this business!

And is it time to graduate to Gas Town? I’m already using beads to good effect, and I’ve now reached Stage 6 on the Steve’s Evolution of the Developer chart.

Gift, What Gift?

Gift, What Gift?

It’s Christmas today, yay! In that spirit, I have two applications to share with the world. The first one I’ll talk about today, the other later this week.

My family loves to play games of all varieties, especially on holidays. An old favorite is Pinochle, which I first learned from my grandparents in Michigan (pretty sure card playing is the only thing to do in the Midwest in winter). Almost 3 years ago I first spoke about creating an online score tracking tool for Pinochle, and released in an initial form last year. Today it’s finally useable. Check it out at onlinescoresheet.net, scoresheet.info, scoresheet.mobi, or scoresheet.space (I do like lots of domain names). You can also find the source code on GitHub (completely AI-written).

This is a very bad Pinochle hand

What got it over the hump from “fiddly prototype” to “ready for prime time” wasn’t the choice of development tool or a eureka moment on my part. It was actual usage by real users others than myself. Putting it out there, and then convincing my family members (across a couple generations and device types) to try it. Got enough feedback to make a handful of critical improvements, and while it could certainly be better, it’s perfectly usable and doesn’t have any glaring functional bugs.

Usage is a gift. Seek it out, and don’t take it for granted.

Winning Business

Winning Business

My team just wrapped up a big proposal. I love the feeling when a month of writing and design work comes together. And it’s not just completion of the response itself that’s satisfying; it’s the culmination of all the groundwork that comes before, often a year or more of it.

Doing sales work requires a certain amount of brazen optimism that doesn’t come natural to many technologists, as we tend to be pessimists realists. To win customers’ trust (and their pocketbooks), you have to believe deeply that you are the best option for success. Deeply enough that it shows as genuine, because this kind of belief can’t be easily faked.

No, I’m not advocating for recklessly abandoning reality or straight-up lying. And yes, things are going to go wrong. We all know that. But the challenge of delivering a solution to a problem can’t solve itself. You can’t work it if you can’t win it. So yeah, you gotta first figure out a way to get into the ring, and leave future problems for your future self. Trust that you’re smart enough to address them, or at least be brave enough to risk failure.

I’m reminded of a chapter from The Geek Leader’s Handbook that talked about various approaches to proving truth in the workplace. While I wasn’t thrilled with the way the book broadly framed “geeks” vs “non-geeks” as fixed categories, it’s certainly the case with many engineers I’ve worked with (myself included) that we tend to disbelieve a statement until it’s proven true, and we especially don’t want to claim a fact without ample evidence. Whereas sales folks can operate more on hunch and gut feeling, believing something is achievable even when the outcome is unsure.

No where does this show up more than in the process of scoping and then selling projects; business folks need a cost (i.e. people x time) but engineers say giving such an a priori estimate is impossible. While the latter is true in the literal sense, it has to be done regardless. Rigid thinkers like myself have to get over themselves and do the best they can.

What I’ve found to work best is to find colleagues who bring a perspective at the other end of the “it must be proven before we call it true” and “it feels true so it is true” spectrum, and partner together on sales efforts. Is that not what we partly mean when we say there’s power in diverse thinking?

It’s even more powerful when some of these colleagues have been buyers of what you’re selling, because ultimately they’re the type of person you have to convince.

Oh, The Places You’ll Go!

Oh, The Places You’ll Go!

Today marks the 10th anniversary of this blog. It’s been quite the career journey since I sat down to write my first post, appropriately titled Hello World.

At that time, I was sitting in a drab cubicle in a perfectly ordinary office building, probably gingerly sipping a cup of coffee (I didn’t start drinking coffee until about that time, if you can believe it) and getting ready to start my day of rewriting a large Perl application to meet a silly set of coding standards.

At least the conference room was kinda cool

Today, I sit writing this in the Rose Reading Room of the New York Public Library, about to embark on a morning of (hopefully) focused effort to provide architectural guidance and documentation feedback on a couple projects I’m overseeing. In the afternoon, I have a project kickoff to attend, and will likely have a smattering of emails and Slack messages to respond to.

Not a half bad backdrop

Such is the life of a CTO. Gone are the days of 9-5 coding. Little did I know back when I started writing here (let alone 25 years ago when I was earning my computer science degree) where my career would be headed or what it would entail on a day-to-day basis. But that’s pretty normal it seems.

If you’re here, thanks for reading. I hope to keep doing it for another 10 years. But for now, time to get back to the day job.

Never Forget

Never Forget

Technologists love to collect and share horror stories (see, for example, The Daily WTF). It’s one of the reasons this blog exists, as a brag document of a different sort.

No matter how stressful the situation may be, no matter how long the debugging session took, no matter how brain-melting the eventual solution was to implement, on those days when you experience a moment that you know will go into the annals of “how the heck did this happen” infamy, it brings a smile to your face.

For me, yesterday was one of those days.

It’s a little too early to tell the full story in a public place (the key stakeholders should get to hear it first), but I hope to eventually. It’s an all-time head-scratcher.

Like Riding A Bike

Like Riding A Bike

Yesterday I re-passed the AWS Certified Solutions Architect – Professional exam. It’s my third time taking it (2019, 2022, and now 2025). I went into it cold turkey, absolutely zero preparation, and while my score wasn’t as good as before, a pass is a pass.

I guess at this point, I’ve done enough work in AWS that the knowledge is pretty much permanently ingrained. It reminded me of this article on Buying Moves:

There’s an amazing quirk of the human body that makes fitness adaptations work a bit like powerups in a video game. You can spend some resource to add capabilities to your “character,” and if you do it right they’re always available to you (for the most part). I’m talking about muscle memory and our ability to “lock in” physical skills.

Perhaps there’s a mental version of the same phenomena?

Speaking of that link, being one myself, I’m a big fan of True Generalist. While it isn’t for everyone (and that’s okay), I can’t disagree with his take on competencies that every person should have, and further skills that generalists need to function effectively. Both worth a read if you’re this type of person.

Figuratively Speaking

Figuratively Speaking

Speaking effectively to non-technical people can be a challenge for technical folks, but it’s an essential task for all but the most mundane (read: least-effective) of roles. One mechanism that I’ve found helpful is the use of metaphor. I’m a huge fan of trying to describe complex topics by mapping them to more broadly understood concepts. Being able to come up with such mappings fluently is a powerful skill. There may be many ways to develop it, but I suspect one is cultivating a wide set of interests.

While I was writing Tuesday’s post, it occurred to me that today’s Generative AI tools are to software what today’s 3D printers are to physical objects. On one hand, it’s incredible to be able to provide a specification and have it manifested in near real-time. Printers can make a variety of solids: toys, some kinds of replacement parts, that sort of thing. GenAI can create chunks of useful code, quick user interfaces, and basic apps, like my Pinochle scoresheet. But there are limits. Can either of these tools produce high tolerance, precision parts / highly secure, performant code? Can they build complex solutions like electronics / web browsers?

A 3D printer creating a figurine

I could be wrong, but just like we’re a long ways from 3D printing an iPhone, we seem a ways away from vibe coding Microsoft Word or an entire government system of record.

Diamonds and Digital Files

Diamonds and Digital Files

I’m a fairly good archivist. Today I happened to be rooting around some old files from college, and found (amongst other things I’m not going to share here) a paper I wrote in 1999 about the leadership style of Thomas J. Watson of IBM. I concluded with this summary that perhaps is still relevant today?

  • One of the most effective ways for a leader to build a cohesive team is to create an organizational culture that binds the employees together.
  • Having a vision for an organization is important, but being able to motivate others to get behind the vision is even more important.
  • Kindness shown to followers goes a long way towards developing loyalty and trust.
  • An autocratic leadership style can be very effective if interpersonal relationships are not ignored.
  • A good leader must not fall into the trap of wanting recognition.

I can mostly still agree, though that bit about autocracy makes me wonder.

Quasi-related factoid: I remember this class well because I pulled an all-nighter right before the final, not to study, but to drive across the state to the Lennox Theater in Columbus to watch The Phantom Menace at midnight. Good times, but a poor choice in retrospect.