Do Geese See God?

Do Geese See God?

By | | Comments 0 Comment

Today I’m writing from 35,000 feet, which means my last three posts have been authored from a plane, a train, and an automobile. Either I’m really good at capturing otherwise idle time and putting it to productive use or I’ve got some puritan work ethic issues that I need to work out in therapy. Hmm, it’s probably both.

Speaking of trying to make boring tasks more interesting, for as long as I can remember, I’ve aimed to pump gas such that the final sale is a palindrome. Forms like $38.83 or $40.40 are acceptable, but all the same digit is the holy grail. I don’t know why I started doing this, but it’s far too late to stop now. And it gives me a little sense of accomplishment every time (especially because it’s getting harder and harder to land on a specific value given inflation).

AI is better at math than it used to be, but I checked, and this doesn’t quite pencil out

I wonder if the above behavior has a root cause in giving my brain a reason to care about the activity in question? It’s a similar neurochemical response to gamification, I’m sure. But more consequentially, we’ve establishing that caring matters and so perhaps there’s value in exercising that muscle in varying ways?

Regardless, I believe there’s something deeply human, something important, to be felt when engaging in boring activity. About this I’ll have more to say soon.

Vocabulary Lesson

Vocabulary Lesson

By | | Comments 0 Comment

If you couldn’t guess from my prior post, “they” is not one of my favorite words. Another disliked one is “just”.

First, everyone will not just. If your business strategy amounts to “if we all just do our job we will succeed,” you’re on the road to failure. I’ve fallen prey to this thinking before. It seems so simple and straightforward. But it’s ultimately lazy leadership. People have their own motivations, incentives, and goals. This is okay. Being a leader means figuring out how to find the right Venn diagram overlaps between individual objectives and company objectives, learning to fight effectively with the army you have, and in the worst case, making the tough calls where there isn’t enough in common.

A closely related failure mode is “we’ll just hire the right people.” That won’t work either. Yes, you should invest a lot of effort in your recruiting and hiring efforts. But it’s hard! And you’ll get it inevitably wrong, because there are no perfect people.

Finally, while it may sound good, “just get it right the first time” is a fool’s errand. It’s doubly impossible: first, no one can get it right the first time. And second, no one gets the definition of “right” right the first time either, so even if you hit your target with your first shot, you’ll find you were aiming at the wrong one. This is exactly what agile process exists to account for. Change along the way is inevitable so embrace it.

Fun fact: I wrote most of this post while riding in a Waymo for the first time, which feels appropriate. Human drivers don’t “just” either.

We The People

We The People

By | | Comments 0 Comment

Been wanting to write this post for 5 years (see the post index as proof). As I sit on a train headed to Los Angeles for a cloud security workshop, it’s finally time to get it out the door, for better or for worse. It may be a bit jumbled, consider yourself warned, but at least that’s good evidence that it isn’t AI generated? Anyways…

When I was in college, I had to take a composition course as a prerequisite. Pretty standard stuff. I’ve forgotten most of what I learned, but one lesson snagged a few of my neurons and never let go: “every pronoun needs a clear antecedent.” Never is that more true than with the ubiquitous use of “they” or “them” in reference to “the other”.

At best, the use of they without an antecedent is lazy. But at worst, it’s deliberately divisive: “they decided X”, “they said Y”, “they did Z”… these are all phrases that set the speaker apart from the people being referenced, shifting the locus of responsibility (or blame). Of course sometimes grammar dictates this type of usage, but often not.

How can we counteract this effect? A good step is to name the antecedent: who specifically decided X? Naming is hard but usually not impossible. And naming gives power.

But I want to suggest another approach that’s worth trying out: any time you’re tempted to use the word “they”, pause and ask yourself if “we” is more appropriate. Instead of putting distance between speaker and subject, try to bring them together with inclusivity. This sort of language is used all the time in reference to sports teams (e.g. “we won the championship”) when the speaker wants to claim association with the outcome, but it’s broadly applicable: “we decided X” works perfectly well in reference to your family, the company you work for, the government you participated in an election to choose, and even the society in which you live.

What you’ll find if you make the above a habit is that there is really no such thing as a binary “us” and “them”… everyone and everything sits along a continuum of “we”. And to quote Gandalf, “that is an encouraging thought” (or at least it should be!) in both personal and professional contexts.

One concrete way this manifests in the latter: when company decisions have to be communicated to teams, it’s critical for front-line managers to use “we” and “us” when speaking about said decisions, even when they were not part of the group deciding, and especially if they disagree with the decision. If a person cannot do that, they are not ready for leadership, full stop.

Is that hard? Yes. But it’s the gig.

The Heart Of It All

The Heart Of It All

By | | Comments 0 Comment

“Once code stops being scarce, the only thing left to pay for is care.”

The above quote from Geoff Scott of Kindness Flywheel caught my attention a few months ago. I can’t disagree. I’ve spoken before about the importance of doing small things well even when they won’t be seen, how details matter, and the motivating power of empathy. Care sums it all up beautifully.

This is not a new concept. I’m told the philosopher Martin Heidegger went so far as to consider care (more precisely the German word Sorge) as fundamental to being human. I’m no philosopher (collegiate aspirations notwithstanding) but that certainly seems to make sense at a time when machines are capable of producing so much content without a care in the world. For such content to mean anything, it needs to come from a place of care: for the topic, for the audience, and for the results. If you have that, using generative AI can be a good thing. Without it, not so much.

Care can also be a fantastic way to focus and prioritize. There’s a certain clarity that comes from being honest with oneself about what is cause and what is effect: it’s hard to claim genuine care for a task that’s put off repeatedly or a person that’s kept at arm’s length.

Of course, caring has drawbacks. The associated emotions can be complex and even contradictory. They come with challenges, outbursts, demands, complaints, and a host of other messy stuff that’s no fun in any setting, let alone a professional one. It’s a real effort to channel that emotion effectively (and I know I’m not always great at it), but the spillover is inevitable and not a sign of complete failure or need to panic. Work being stressful is often a sign that you’re doing things right.

I don’t say this to excuse disfunction, but I’ll take care and its baggage over apathy any day.

My Lips To God’s Ears

My Lips To God’s Ears

By | | Comments 0 Comment

Haven’t posted much lately, been busy with the day job, doing an awful lot of prompting (this is more true than ever). But rest assured, here at Making of Things, it’s all human all the time, unless I say otherwise.

It’s fun watching a bunch of agents writing code all once

I’d like to believe I was early to the idea of voluntary disclosure of the use of AI in writing and especially early to the notion of trying to categorize types of AI collaboration (another post written with the help of Claude). My approach was perhaps a bit romantic (whimsical, even), but this one is more methodical: AI Usage Scale. I quite like it!

Related: Don’t be a meat proxy.

Moo!

Moo!

By | | Comments 0 Comment

“Plan to throw one away; you will anyhow” – Fred Brooks

It’s easier said than done, but don’t get precious about your work. I’m regularly guilty of this, thinking too much like a craftsperson enamored by their creation and not like a servant of the customer and their desired outcomes. So what if the first thing I build gets thrown away? That’s often what it takes to get an idea of what actually needs to be made. The learning is well worth the price of a discarded draft.

Bring a willingness to heavily revise or even restart to your own self-reflection and embrace being told to do so by others who understand the domain better than you (this can be especially hard but it’s essential). With some practice, you may even come to enjoy the experience.

We’ve understood for a while that infrastructure should be treated like cattle, not pets. It’s now true of software in the age of coding agents, where products can be built and rebuilt with relative ease.

Knobs And Buttons

Knobs And Buttons

By | | Comments 0 Comment

There’s a lot to consider when using AI. There are a number of input variables, not the least of which is a free text prompt that can be shaped and rephrased an incredibly large (but not infinite) number of ways for similar requests. Getting to an “optimal” result is probably impossible, and even getting to a local maximum is tough. A ton of testing is required, and that’s neither quick nor cheap.

In order to target variables with high effect, it’s helpful to have heuristics and other rules-of-thumb. To that end, I found this article from Anthropic instructive.

When a result misses the mark, ask, “did Claude not know enough or did it not try hard enough?”

If the former, use a bigger model. If the latter, increase the effort setting. Simple enough!

Another quick win is to consider how much planning a model can do on its own. Per Ken Huang in Claude Fable 5 (Part 1): What Changed, and How to Stop Prompting It Like Opus:

For three model generations we compensated for planning weakness by doing the planning ourselves: numbered step lists, “think step by step,” long behavior checklists, skills files that read like flight manuals. Fable 5 plans better than those crutches, and the crutches now get in the way.

In short: let bigger models do more of the work for you. In my recent experience, Fable 5 especially (and even Sonnet 5 at times) doesn’t need nearly the step-by-step prompting to get the job done, and over-specifying both wastes your time and potentially gives worse results.

Shiny Happy People

Shiny Happy People

By | | Comments 0 Comment

I just got back this week from a vacation that I’ve been dreaming to avail myself of for a decade. It was delightful, and once again served as a reminder that to be effective at my job requires periodic distance from it (though admittedly I did check in a couple times, because sometimes I need a break from my break).

Before heading out I’d wrapped a multi-week project that was a collaborative effort across several organizations. That kind of achievement feels good in and of itself, but I was also reminded that working with great people can be quite a bit of fun. And that fun can power great results. Happiness in work matters!

The project in question was related to verifiable credentials, of which I’ve spoken before. That post has some solid background links on the topic; here’s another series from NIST that’s also instructive:

Or if you have even less time, these one-page introductions to three fundamental concepts, from my friends at Freewallet:

Happy reading!

After My Own Heart

After My Own Heart

By | | Comments 0 Comment

Went back in my draft backlog and found this gem from 2020: Unit Testing is Overrated.

In the age of AI-generated code, it feels even more applicable. When a model writes unit tests (especially when it does it in view of the code it’s testing) they’re at risk of being overfitted to the functions under test. They may indeed prove software executes as it’s written, but that has little to do with proving the software meets requirements (for example, Kiro had created hundreds of perfectly passing tests for this project).

The key takeaways from the article are all worth sticking in your coding agent instructions, because without explicit directives, LLMs are probably biased to do the opposite of these recommendations given the weight of training data pushing so-called “best practices.”

In particular, I can see value in using a separate (perhaps even adversarial) agent/model to write the tests. It’ll be less biased on the context used to write the code, and it can be instructed to “aim at the highest level of integration while maintaining reasonable speed and cost.”

Maintenance Matters

Maintenance Matters

By | | Comments 0 Comment

In case I haven’t said it explicitly enough, I’ll do so again here.

I wrote these definitions a couple years ago in an effort to bring some formality to what would be covered under a maintenance contract. They served well enough to pass along here.

Major Issue: Problems that impede core functionality, such as:

  • application fails to load
  • users cannot log in
  • workflows are inaccessible or fail

Minor Issue: Problems that do not impede core functionality, such as:

  • slow, but functional, responses to user interactions
  • workflows succeed but are sub-optimal
  • typos and visual glitches

Feature Enhancement: Updates that meet all of the following criteria:

  • do not fundamentally alter an existing capability
  • do not create a new user workflow
  • do not require new integrations with or data from external systems

New Feature: Updates that meet one or more of the following criteria:

  • add a capability that did not previously exist in the system
  • create a new user workflow
  • require integration with an external system

Environments

  • Dev: where software engineers do their daily development work
  • QA: where vendor work is tested before going to customer for acceptance
  • UAT: where customer performs final test and acceptance of features
  • Production: where users access the system