Software developer and consultant. Let's build great software together.
One of the patterns I've found particularly helpful with LLMs is the diverge-then-converge pattern. LLMs excel at both of those things separately, and when we put them together, they are an excellent tool to help us solve problems.
Many people's new way of working with LLMs is to start with an idea, have the LLM create a spec (review and approve that), then have the LLM generate a very detailed plan. At that point, people have two options: a) They either spend a lot of time reviewing the plan, ask for changes, and finally approve it. Warning: this may take hours. Or b) They skim the plan, but it's too long, so they YOLO it…
I recently published ExCrap, an Elixir library for calculating Change Risk Anti-Patterns scores -- or as they're commonly called CRAP scores. It made for a perfect experiment: creating the library without looking at the code.
It's always surprising when people don't want to delete dead code because they think they might need it in the future or because they worked so hard on it. Recently, I had one of those conversations with a colleague. I was trying to convince him that we should delete unused code, and that made me think: why is it that we sometimes feel reluctant to delete dead code?
My guess is that most software development teams in the world are at a point where we are drawing the two circles. Those are all the teams where developers use LLMs daily. But then you hear about teams that might be getting closer to building software factories. And that's the "just draw the rest of the ___ owl". How do we draw the rest of the owl?
If you're using LLMs in your day-to-day workflow, and you're only using them as assistants that you ask questions of (like a glorified Google in your terminal or IDE), or if you call on them like a genie, only when you think they're fit for the task (e.g. let's remove that duplication), then this is for you.
Back in April, I decided to write daily for my newsletter. Up to that point, my newsletter was mostly a delivery mechanism for my blog. But I wanted to change that. I wanted to write more.
Thinking about the extremes is a powerful tool to help refine our intuition, unearth second-order effects, discover novel ways of doing things, and generally find alternate solutions to problems when we're stuck.
I had that written on my office whiteboard for a while last year. I had just finished working with a client for over a year where the whole team pair-programmed full-time (we also did a lot of mobbing). I was then starting work with a new client, and I wanted to remind myself to push for pair-programming as much as possible because it is a cheat code for developers AND for businesses. Here are…
A mental model I've been thinking about lately comes from Managerial Economics. It's a framework for analyzing how a firm can trade off capital and labor to produce goods. And I think it's helpful for Software Developers in this new age of AI.