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
All’s Well That Ends Well

All’s Well That Ends Well

By | | Comments 0 Comment

I reposted the broader announcement on LinkedIn, but thought it’d also be worth capturing here, that the final proposals for the Technical Executive Leadership Initiative class I took earlier this year have been published. I was part of a great collaborative team; while I had some contributions across the board, my focus was primarily the mockup website and accompanying demonstration.

Digitizing the JobsNOW! Intake Process for Medi-Cal Clients in San Francisco

If you’re a technologist working in the public sector and want to get better at working with government, I highly recommend this program. You’ll also get a nifty public profile out of the deal (as if I needed more to add to the collection).

Judson Neer

I’m now reminded that it’s been a few years since I’ve had a professional headshot taken, something I should probably rectify.

Not All Rainbows and Unicorns

Not All Rainbows and Unicorns

By | | Comments 0 Comment

As much as I love being a generalist and believe it’s the better end of the breadth/depth spectrum in the current tech environment, it doesn’t always feel like a great way to operate, for several reasons:

First, it’s often difficult for a generalist to describe their job, not just to folks like friends and family who are unfamiliar with their domain, but also to managers in 1-on-1s, performance reviews, and promotion documents (I’ve had firsthand experience with the latter). A term related to generalist, factotum, can even have negative connotations in certain settings, despite a “glue person” being an essential role within pretty much any organization. Specialists, on the other hand, are easier to understand, as their work is often simply “what it says on the tin” (i.e. their job title).

Second, while a generalist has proximate knowledge of many things, when they spend time with legitimate experts in a topic (which is often, because they’re so curious), they are quick to realize how much they don’t know. And since this happens so much, the experience of “I don’t know as much as that other person” compounds into a malaise of “eh, I don’t know much about anything.” Inferiority complex ensues.

When interests and aptitudes are varied, it’s also tough to determine where to focus, paradox of choice and all that. Similarly, while there’s value in doing extra at times, it’s easy to get distracted and fail to deliver the most important thing, losing the proper balance between work work and non-work work. This leads to a feeling that one is “mildly disappointing everyone all the time.” When I have that feeling, burnout lurks not far behind.

I don’t have a tidy conclusion to give here, it’s just stuff I’ve been sitting with.