Herding Lions

Coding is deciding

Fri, 22 Aug 2025 21:09:00 -0400

We often talk about computer programs purely as collections of “code”. Lately I’ve been thinking about it a bit differently: a computer program is the encoding of a huge series of nested decisions, made intentionally or otherwise.

Let’s say we’ve decided to build a calculator app. That overall goal is the first decision, but there are many more decisions nested underneath it.

What features does our calculator app need? (Just basic arithmetic or are we buliding a graphing calculator?)
What platform are we building for? (web, mobile, desktop, VR?)

Once we know generally what we’re trying to do, there’s still a bunch of fundamental decisions to be made before we write any code

Is this a client only app or is there a server component?
What framework should we use?
How will the app be hosted and distributed?

Then once we start actually writing code, we find even more nested decisions.

How are we going to structure our files?
How will we break functionality up into components, classes and/or functions?
Is this a single file, a single app, or some sort of distributed system?

And then even within a given class we nest even more decisions

What functionality should the class have?
What is the high level logic of each function?

And then we come down to the lowest level of decisions

What syntax will we use for that? (For example: for loops or iterators to run through a list)
Will we use a library or write some functionality from scratch?
Tabs or spaces? Single quotes or double quotes?

We can think of these as functional, infrastructure, architecture, logical and syntax level decisions.

The history of computing has mostly involved changing which of those decisions a software developer needs to make as tools have changed. Many of those changes have removed the need to make decisions in favor of a generally acceptable standard implementation. The vast majority of programmers no longer worry about the details of the bytecode or assembly definitions of programs — those have been standardized by higher level languages. Most modern languages also remove or significantly reduce decision making around memory management, cloud platforms reduce¹ the decisions many devs need to make around infrastructure for their apps, and API frameworks like Django or Ruby on Rails reduce the decisions somebody needs to make about how to structure their API code.

Each of these abstractions have allowed developers to focus more on the decisions around what their program should do and less on the implementation details of how it does it. They’re also all leaky abstractions to varying degrees, and there are times and situations where a developer will need to go without or work around the standard tool to make a different decision.

Applying this model to think about LLM based coding tools, it’s useful to talk about the use of LLM in terms of what decisions we’re making vs offloading to the coding tool. LLMs are essentially tools for replacing decisions that you might have had to make while generating text with a reasonable standardized option. However the way we use them can lead to different sets of decisions being made by the tools.

Vibe Coding

Vibe coding, the buzzword of the year in tech, is commonly understood to mean that you’re creating an application solely through prompting and iterating based on the observed output without reading the code. This is effectively choosing to make decisions at the functional level (and maybe the infra level) and let AI handle the rest.

Tab Complete

We can contrast this to a tab complete interface like those provided by Github Copilot or Cursor, where an IDE will offer to insert a chunk of code based on context. Here AI is mostly deciding on syntax, with more ambitious implementations like Cursor possibly moving up to the logical level

Feature Development With Agents

There’s a lot of room between these 2 extremes. Tools like Claude code, Cursor and Copilot can take on tasks at a variety of levels depending on how they’re prompted. You can ask a coding agent to generate a new feature for instance, which might live completely at the logical / syntax level or could end up infringing on architecture if the feature has new architectural considerations or the coding agent introduces a new pattern or dependency.

Who decides what?

As I’m personally moving back into more of a heavy coding role this month, I find this framework of who is making decisions helpful.

While building enterprise software at work, I’m ultimately responsible for the quality of all the code I write, so while I find it helpful to move faster by using AI tools to get a rough solution in place, I encode some decisions through the prompts I give and end up reviewing and tweaking everything to make sure what comes out of PRs I open represents my decisions. I’m also quickly building an intuition for which tasks a coding agent is likely to produce a useful output for that I need to tweak, vs one where I’m unlikely enough to agree with the decisions that its faster to just write it myself².

On the other hand if I want to experiment with something quick and dirty or prototype a concept, the freedom these tools give to ignore every level below the functional one is wonderful (I just don’t want to maintain such a system).

Working with these tools has reminded me once again that reality has a surprising amount of detail. There is no magic in the world and decisions are always going to have to be made. If coding tools help us to go faster by focusing more on the decisions that really matter, I’m excited to see what they help us bulid.

Ok given the huge ecosystem of choices and configuration in cloud computing its probably more accurate to say that it changes the decisions devs need to make ↩︎
Given the rapid evolution of the tools of course, this is something that needs to be checked over time. Claude Sonnet can do things reliably that Chat GPT3.5 would consistently fail on, and the agentic system seems to have a good deal of impact on quality as well. ↩︎

Fri, 25 Jul 2025 09:16:19 -0400

This is a good summary of the state of AI takes right now I think

No one knows anything about AI

AI is important. But we don’t yet fully know why.

AI currently has all the “noise” and incentives to hype that crypto had a few years ago, but underneath that is clearly much more “real”. It makes things hard to evaluate for now.

Retraining our Brains To Review LLM-augmented work

Tue, 22 Jul 2025 10:05:07 -0400

Something I worry about with generative AI in business and commercial use: almost no one fully reads anything in those environments.

Now imagine when even the author hasn’t read what was written… yikes. How does AI writing and reading impact this reality?

Steven Sinofski has an interesting post here about “slop” at work. I think about this in terms of heuristics. Our brains are lazy and we all naturally develop “shortcuts” to evaluating a piece of work. Historically seeing a PRD or tech spec that was fully fleshed out with diagrams and clear explanations of context was a good indication that some serious work and discovery had gone into the document. A PR full of detailed test cases indicated attention to detail, and that thought had gone into all the possible edge cases. But with LLMs it is easy to take a few half thought through bullet points and make them look credible, or generate plausible test cases at scale.

We’re going to need to retrain our brains.

A Simple Path To Building Trust

Tue, 25 Jun 2024 14:22:10 -0400

Being trusted is a superpower at work and in life. When we’re trusted things move faster. Communication is more open, people become more cooperative, and work becomes more enjoyable as relationships can grow deeper.

I’ve found that there’s a very simple¹ formula to building people’s trust.

Here’s the formula:

Identify a need
Say you will meet the need. Say when you’ll do it by and with what quality.
Go and do it the way you said you would
Tell people you did it
Repeat

That’s the whole process. Do that enough as an individual and you will develop a reputation for reliability and trust. You’ll find that people tell you things and give you more opportunities. If your team does that you’ll find that other teams become easier to work with.

A few notes:

Misses count more than makes

Fairly or unfairly, one missed commitment is more memorable than 4 that were completed on time. If you’re operating at a trust deficit it will take time to rebuild trust, but the process is the same.

When you do miss, always try to miss early and clearly. Nothing erodes trust like discovering that somebody has been hiding failure.

Sometimes you’ll discover that while you don’t have to miss, your commitment no longer makes sense after making it: priorities have changed, new information has emerged, or another opportunity has presented itself. You can choose to make changes in this situation. If you communicate the change and your reasoning early to the people you’ve committed to², this probably won’t be counted as a true miss. However it probably won’t build trust either, and if you’re regularly doing this you may create the impression that no plans can be relied upon if you’re involved. The tradeoffs here will vary based on context.

People can hold you to implicit expectations

You can lose trust if you share a secret, even if you never explicitly promised not to tell anybody the secret. You may lose trust at work if you don’t meet some standard of quality that other team members are hitting, even if the expectation wasn’t explicitly stated. This is also why it’s useful to say when and at level of quality you’re committing to something - if you think you’re committing to a rough draft of a tech doc by next week but your manager is expecting a polished doc to be done by Friday, you’ll lose trust even if you hit what you think you’re committing to. Since misses count more than make its important to understand and clarify any implicit expectations you might be held to

People trust kindness

When you’re kind to others they want to trust you and are more likely to overlook or forgive misses. Jerks fight an uphill battle to earning others' trust.

As always, simple does not mean easy. ↩︎
For work tasks it may not always be clear who is counting on your commitments: other departments might have been promised this work by somebody else, or be relying on another project that is dependent on your work. Be careful here. ↩︎

Mon, 17 Jun 2024 13:26:31 -0400

The intended takeaway from all this is exactly where we started in the introduction: creating quality is context specific. Be wary of following the playbook you’ve seen before, even if those playbook were tremendously successful. They might work extremely well, but they often don’t unless you have a useful model for reasoning about why they worked in the former environment.

Loved the thoughts on quality here from Will Larson: lethain.com/quality/

Sun, 09 Jun 2024 19:54:25 -0400

Over a year old, but new to me – I thought this series of posts was a great roundup of some of the issues that make tech a less happy place to work than in the previous decade: Software and its Discontents

Sun, 09 Jun 2024 19:52:08 -0400

Very helpful writeup on LLMs in production: What We’ve Learned From A Year of Building with LLMs

Thu, 09 May 2024 15:00:05 -0400

Reality Has A Surprising Amount Of Detail

This is an old piece, but new to me. What a great turn of phrase, and accurate insight about doing hard things.

Sat, 12 Aug 2023 14:44:45 -0400

Diving back into (Neo)Vim this week for the first time in a few years (have done my core work with VS Code for a while).

Telescope Plugin + Language Server Providers are nice additions to the landscape, and it all feels so powerful, but everything is still so fiddly to setup :/

Wed, 22 Feb 2023 22:36:41 -0400

Really enjoyed these reflections on LLMs: medium.learningbyshipping.com

AI, ChatGPT, and Bing…Oh My

Setting Expectations: 4 key areas for performance management

Sun, 12 Feb 2023 17:00:00 -0400

Performance management processes have been different at every company I’ve worked in, ranging from “basically non-existent” at a 15 person startup to “months of work for managers each review period followed by clear expectations that growth feedback will be given throughout the year” in big tech world. Some of these differences are good and bad, most are more about the context of the company. I’ve found that regardless of process there are 4 things that it’s important for a team member to align with their manager on throughout the year. Hopefully there’s process supporting this, but if not both the team member or the manager can take the initiative to make it happen.

Focus - Where should the teammate be putting their energy? Depending on seniority and the level of change within the organization, this might be something to resync on every 6 months, monthly, weekly or even daily[^1].

Baseline Expectations - It’s important to agree not just what you’re trying to do but what results are expected. This means being clear on what a team member is and isn’t responsible for, what success looks like, and giving feedback when the manager believes things are off track or a miss has occurred.

Opportunities - This is about above and beyond. What things aren’t expected but could be an opportunity for growth (to help the team/business, show that the teammate is ready for a promotion, or ideally both)? It’s useful to clearly delineate these from expectations, so that you don’t risk a lack of clarity on what is “good enough”, which can cause unnecessary stress/burnout or poor prioritization.

Risks - I find that this part is usually left implicit, but its helpful to align up front on what likely areas of failure might be, where the teammate and manager see the most risk of missing expectations (or finding out that the expectations weren’t correct!). This could be due to ambiguity, a known skill gap from the team member or those they’re collaborating with, a new type of challenge, or business level needs/expectations that aren’t realistic.

[^1] Long term syncing daily on priorities/focus areas might be micro-managing or a sign that the team member is struggling to manage their own work, but it can be useful in a rapidly changing environment or during onboarding for a time

3 Pillars For Effective Work

Fri, 13 Jan 2023 07:33:53 -0400

There are 3 primary reasons why one human may be more effective than another in a given work situation.

Caring - All things being equal, somebody who cares more about a problem / product will generally be more effective¹. Caring can range from “startup founder” level obsession to being completely checked out, and effectiveness will vary on that spectrum.

Capacity - The amount of time and mental resources a team member can bring to a problem matters and will vary over time. Illness, stress, a busy personal season or competing work priorities can reduce this temporarily for anyone. Some people will have longer term lower capacity than others due to factors like life circumstances, health, and outside of work commitments.

Leverage - People’s skills, experiences, tendencies, relationships and abilities can allow them to be disproportionately effective or ineffective in different situations. Some of this is situational: “he wrote that library and knows all the details”, “she is an expert on this technology”, “he has admin privileges on this system”, “she knows the tech lead on that team”. Other factors like communication ability, broad technical experience, or credibility within an org tend to persist across problems.

When trying to understand why somebody is more or less effective than [their peers | what you expected | your own performance], it is useful to pull out this model². Trying to help somebody who is capacity constrained level up their skills likely won’t move the needle. On the other hand, if you have team members who have the skills but lack capacity or don’t care about their work, there may be an opportunity to help address those underlying challenges and get a better outcome. Similarly if you’re trying to “outwork” your way to a promotion while you see peers who seem to be doing less than you getting better outcomes, its worth looking into what leverage they might have (skills, access, relationships) that are helping them be more efficient.

A caveat: be careful not to prejudge caring vs capacity issues in others. It can be difficult to tell whether somebody seems disengaged because they don’t care, or because they don’t have capacity to care. Best to work through that with them before solutioning.

Caveat – if the level of care for a sub-section of a product/problem/org is disproportionate to the business value, this can become a negative. Think of an employee who spends their time improving line-level code quality of a feature that the team intends to deprecate. ↩︎
I don’t recommend it for hiring however – trying to judge “caring” can tend toward unconscious biases, and most long term capacity issues fall under protected categories / more explicit biases. Better to focus on proven previous effectiveness and testable “leverages” (tech/people skills / knowledge) ↩︎

Wed, 11 Jan 2023 10:53:51 -0400

Basically from a “quality triangle” perspective – execs can control costs or time, but holding the line on a minimum quality bar is essentially a core piece of my job, and nobody wins when you try to promise impossible combinations of scope/quality/dates.

Wed, 11 Jan 2023 10:50:17 -0400

In an ideal world, org leaders define goals and teams figure out what to do. But top down asks happen. How I decide whether to push back on top down asks as an EM:

It’s fine to be asked for a date or a scope (not both)
Never ship something likely to cause an incident

Tue, 03 Jan 2023 11:41:27 -0400

The idea that things become hits mostly due to a small number of large audiences rather than point to point viral sharing seems intuitively correct to me: www.lennysnewsletter.com/p/viralit…

Or at least the large audiences “seed” the viral behavior

Tue, 03 Jan 2023 09:57:40 -0400

As employees return from holiday break, [Shopify] said it’s conducting a “calendar purge,” removing all recurring meetings with more than two people “in perpetuity,” while reupping a rule that no meetings at all can be held on Wednesdays. Big meetings of more than 50 people will get shoehorned into a six-hour window on Thursdays, with a limit of one a week.

This is fascinating to me. I get the desire to remove bloated meetings, but there are recurring meetings that I find genuinely valuable to have sync (project standups / staff meetings). Curious if this ends up being a long term policy for Shopify or more of a culture reset.

2022 Books

Tue, 03 Jan 2023 09:47:30 -0400

I read 13 “work related” books in 2022¹. They’re broken up by category below. I didn’t think any of these books were bad, but the ones I would recommend have a star next to them.

Decision Making

⭐ How To Decide by Annie Duke - Annie Duke takes her poker background and applies it to making decisions in other contexts – lots of practical decision making strategies here

⭐ The Scout Mindset by Julia Galef — somewhat similar ground to to “How You Decide”, but more of a focus on viewing the world objectively. I really enjoyed reading these 2 books together.

Productivity

⭐ Make Time by Jake Knapp and John Zeratsky — A nice book full of practical tips for managing your time and reclaiming control from distractions

Product Process

⭐ The Messy Middle by Scott Belsky — The best description of what it’s like working in a “startup land” situation (either a real startup or high change/growth in a larger company) that I’ve read. Plenty of good practical wisdom as well

⭐ Escaping the Build Trap By Melissa Perri — This book lays out a great vision for what a healthy product organization looks like. As a non-product manager, I’ve found it mostly helpful for recognizing when things are going wrong and giving feedback.

⭐ Kill It With Fire by Marianne Bellotti — An engaging review of how to work with legacy systems (the title is ironic) with lots of real world examples and principles that apply even for newer systems.

The Lean Startup by Eric Ries — This book is very well regarded and I don’t remember disagreeing with anything as I went through it about a year ago, but it left no impression on me. Possibly I’d already absorbed the main ideas through other sources?

Soft Skills

The Speed of Trust by Stephen M.R. Covey — A look at how to build trust in business and why its important

Rituals For Virtual Meetings by Kursat Ozenc and Glenn Fajardo — This was more of a workbook, with a ton of examples of possible “rituals” that you could implement during remote meetings. I in theory like this idea, in practice most of these felt too hokey for me to try – but if you’re willing to go full “icebreaker game” for your team meetings, this has good ideas.

The Culture Map by Erin Meyer — Another book that I read a year ago that I don’t feel I’ve retained very well — but the big idea was that business communication and practice varies wildly across cultures and its important to understand the background of the people you work with.

Career

⭐ The Staff Engineer’s Path by Tanya Reilly — My most recently completed book, this was a great exploration of the “advanced IC” career path. I’ll have a longer review coming later, but this was my favorite work related book of the year.

Miscellaneous

Product Led Growth by Wes Bush — This was pretty specific to a work project, but a decent review of the business requirements for moving to a product led growth model rather than sales driven. Useful for folks who are bootstrapping a new SaaS business or trying to move to PLG.

Building For Everyone by Annie Jean-Baptiste — This is a high level overview of accessibility and inclusive design practices by a design leader at Google. I wanted to like this more than I did – a lot of the content here is about changing large organizations to institute more inclusive design practices, I had been hoping for more “local” things that I could learn to get better here.

Going Forward

One of my 2023 goals is to spend more time with fewer books, including taking deeper notes on some books that I’ve read in the past which had interesting ideas that I don’t feel I’ve retained well. In particular I want to revisit Scout Mindset and Escaping The Build Trap from this year and am already writing up notes for Staff Engineer’s path.

You can see non-work related books on my “non-tech” blog ↩︎

Fri, 30 Dec 2022 20:23:44 -0400

I love this clear visual summary of a Staff+ Engineer’s role from Tanya Reilly’s The Staff Engineer’s Path

Thu, 29 Dec 2022 10:30:40 -0400

Growing as an engineer is less about being right more often and more about finding ways to stop being wrong quickly

Thu, 29 Dec 2022 10:27:53 -0400

When working on a “stretch project”, it’s tempting to keep your plans high level when getting review / sign off. This sabotages feedback - the value of experience is in the details.

Write out specific plans and then seek out feedback from folks who’ve done work like it before.

Sun, 25 Dec 2022 12:53:55 -0400

“God and sinners reconciled”.

Merry Christmas everyone.

Fri, 23 Dec 2022 18:08:50 -0400

This is a nerdy but helpful way of explaining an important management concept – an org can’t prioritize if people don’t say no till its too late. twitter.com/benskuhn/…

Mon, 19 Dec 2022 10:00:00 -0400

Having a lot of discussions about documentation lately. 5 things matter with docs:

Does it exist?
Is it the right info?
Is it delivered clearly?
Is it reliably up to date?
Can people find it reliably?

If your “documentation is bad” make sure you’re solving the right problem.

Sun, 18 Dec 2022 15:50:38 -0400

Free Speech didn’t last long twitter.com/TwitterSu…

Blog Updates: New name, new platform

Sat, 17 Dec 2022 17:58:43 -0400

I’ve been working for the past month on some updates to this site designed to make it easier for me to post a bit more. The key pieces you should know if you follow this blog:

I’ve pulled the name of the newsletter I ran last year (Herding Lions) into the blog – this is now Herding Lions and I’ll be putting all my eng leadership content here in addition to the other content I’ve historically covered here.
I’m adding a micro blog for shorter posts / to have a central controlled place for my short term content while Twitter meltdowns and everybody sorts out what’s coming next in that space.
If you subscribe to my existing RSS feed you’ll now receive both full articles and micro blog posts. If you prefer to receive only the full articles (longer form stuff on engineering leadership and software as posted here in the past) you can switch your feed reader to track https://benmccormick.org/categories/article/feed.xml. Email subscribers don’t need to change, I’ll send occasional roundups of blog content through my newsletter.

For anyone interested in the implementation details:

My former writing setup (the 4th tech setup iteration of this site) was using

Gatsby.js for creating a static generated blog (hosted on github pages)
Revue (Twitter’s newsletter solution) for my email newsletter
Twitter for occasional short form - writing / a way to work through ideas that weren’t post-worthy

I liked the flexibility of Gatsby and my setup was free to run, which is always nice. However it was relatively a pain to keep up to date and I was building a lot of the “blog” features myself as Gatsby pivoted to focus more on ecommerce/business use cases. I also wanted to write more short content on the blog but found the static-site setup tedious as I couldn’t easily publish from my iPad or phone. This wasn’t un-overcomable but generally I preferred to spend less time maintaining my site and more time writing.

Revue and Twitter 😅… Revue is shutting down next month, and Twitter’s future is unclear, as is the alternative / next place to read and write short thoughts.

All of which led me to investigate solutions with a goal of:

An easier writing experience (something should be hosted somewhere ideally)
Some flexibility on style experience (I like playing, but hopefully off a solid foundation)
Ideally: an email newsletter option
Ideally: easy short form blogging

My initial review primarily led me to look at Ghost and Micro.blog. Ghost has the most polish, integrates a newsletter feature, and is actually something I’ve used before (in the very early days of that platform). Micro.blog was new to me, but the emphasis on short form content, the community around it and being built on Hugo (what I would have looked at if I was just trying to find a better static site generator) was appealing to me.

Ultimately this blog is a side activity for me, so pricing was a heavy consideration and micro.blog (with buttondown for email) was significantly more affordable at my level of newsletter subscribers than the hosted versions of Ghost.

So this site is now hosted on micro.blog, using a custom theme loosely based on my previous Gatsby theme. The theme is a customized version of Paper which was originally converted for use with micro.blog by Amit Gawande. I’ve been enjoying the setup a lot so far, we’ll see how it ages.