Category Archives: Software Development

The Infinity-X Programmer

Forget about the 10-X programmer. I think we’re in a time where AI coding assistants can make you much better than that.

Even if you think I’m crazy, I don’t think it’s a stretch that some programmers, particularly less experienced ones, will get a big relative boost compared to themselves without AI. Meaning, they could become 10x better using Cursor than they would be if they didn’t use AI at all.

The norm is less for experienced devs. I think I’m getting about a 2x or 3x improvement for my most AI-amenable tasks. But when I have to do things on projects where I don’t know the language ecosystem as well, it’s much more. So, it’s less about overall skill, and more about familiarity. As long as you know enough to write good prompts, you get more of a multiple the less you know. For example, for my main project, I might save an hour on a 4-hour task, but a junior dev might save days on that same task. Even if I finish it faster this time, they are still going to improve on that same kind of task until we’re about the same.

But, I also think it’s possible to get very high objective, absolute multipliers against all unassisted programmers with projects that are not even worth trying without the AI assistance.

I’ve started calling this Infinity-X programming. I’m talking about projects where it would take weeks for a programmer to complete, but no one is sure that it’s worth the time or cost. Using tools like Cursor and Replit, I’ve seen instances where a person with some programming ability (but not enough to program unassisted) do it on the side, working on it for fun just because they want to. They get somewhere fast, and now we might approve more work because we can see the value and it feels tractable. I’ve seen this happen a few times in my network lately.

It’s not just “non-programmers”. I’m also seeing this among my very experienced programmer colleagues. They are trying very ambitious side-projects that would be way too hard to do alone. They wouldn’t have even tried. But, now, with AI, they can make a lot of progress right away, and that progress spurs them on to do even more.

Without AI, these bigger projects would be too much of a slog, with too many yak-shaving expeditions, and lots of boring boilerplate and bookkeeping tasks. But, with AI, you get to stay in the zone and have fun, making steady progress the whole way. It makes very big things feel like small things. This is what it feels like to approach infinity.

The Central Question of a Code Review

When I prepare code for a pull request, I construct it commit-by-commit in a reading order that convinces you that it is correct. So, when I stage code, I ask myself: “Is the code in this commit obviously correct?” If it’s not, then I probably need to add commits before this one that make the code more clear because I only make explanatory comments on a PR as a last resort.

A PR comment becomes code in a few steps. Step one is that I make comments in the code instead of in the PR. This is better because now anyone reading the code will understand it better. A PR comment isn’t tied to the code unless you think to check the logs and follow that back to the PR.

Step two stems from my belief that a random comment explaining a block of code indicates that that code isn’t clear. This is usually something you can fix with a behavior-preserving refactor. Maybe a variable name is unclear or some code should be extracted into a function. The name of that new function should make the intent of the code inside it easier to see.

But, changing this code might break something, so step three is try to cover this area with unit-tests. When I read a commit with unit tests, I know that all of the cases in the tests are checked, so my job is to think of things that aren’t checked.

It’s tempting to want to fix things in code you are reading, but if they aren’t clarifying the work at hand, that might be a waste of time. By concentrating my efforts on making the PR easier to review, the code will be merged faster if I fix the code.

How it Feels to “Program” with AI

When I type a prompt into the chat pane in Cursor, it is indistinguishable from programming to me. The part where I tap tap tap on the keyboard and code comes on the screen isn’t programming, that’s typing. The part where I use keyboard shortcuts to navigate the IDE isn’t programming either. Both of those parts (the typing and navigating) is being done by a robot when I prompt Cursor, but the programming is still done by me.

When I look at a ticket in JIRA that says, for example, “add a way to archive a contact” in my React/Node/MySql application, when I estimate, I think

Add an archived field to the contact entity, default to false, set as non-nullable
Generate a migration and run it on my local database
Add DB service functions to archive and unarchive contacts
Write unit tests for those DB service functions
Add GQL mutation functions to archive and unarchive a contact
Add archived to client GQL queries
Add archived to the client-side contact model by running the GQL code generator
Make sure to set up the model’s archived field from the GQL query in Redux
Add a Redux reducer to set the archived field
Add Client-side functions to optimistically update the redux and call the GQL mutation (undoing on error)
Add an “archive”/“unarchive” button on edit on the contact edit dialog (show the one that applies to the contact)
Look at lists that show contacts and decide if they need a way to filter archived contacts out or not

I can tell you from experience, that I can do steps 1, 3, 4, and 5 with a prompt that has basically what that says and at-mentioning the files that will be updated and that serve as a model (I probably have another entity with an archived field). Step 2 is a yarn script for me that compares the schema in my code to the one in my DB. Steps 6, 7, 8, 9, and 10 would be another prompt, and finally I will do 12 & 13 manually or with completions because I might want to adjust the UI.

Before Cursor, I still wrote out that list because I like to Build a Progress Bar for My Work that helps me make an estimate, keep on track, and know if I am not going to make it. When I work with Junior devs, I often develop this list with them to communicate what I want done with more details.

Is this programming? I think so. Instead of TypeScript, I am “programming” in a loosely specified, natural language inspired, custom DSL. I run scripts to generate my migration code from schemas and my client side models from GQL queries, and to me, prompting Cursor is basically the same thing.

Push, Kick, and Swim (through Tech Debt)

My swimming workouts are in a pool, so each lap starts with me pushing off the pool wall, kicking underwater for a bit, and then turning that momentum into a freestyle swim until I get to the opposite wall and start again. The speed of my lap is determined by the efficiency of my strokes, but the push and kicks overcome the water resistance and generate the initial momentum. That push-off is analogous to how I incorporate tech debt payments into my work and is the core idea in my book, Swimming in Tech Debt.

In a single lap, most of the distance is covered by swimming, and that’s the same in my programming. Most of what I do will be directly implementing the feature or fixing the bug, but I start with a small tech debt payment to get momentum. That small payment is improving the area I am about to change, which makes it easier and faster to do that change.

After the push comes underwater kicking, which is so effective that its use is limited to 15 meters in competitions. After that, the swimmer must begin normal strokes. The same principle applies to tech debt payments. They are effective, but they are not the goal. If all you do is pay down debt, you won’t deliver anything of real value. Paying tech debt makes me happy, so I have to limit how much time I spend on it and get back to my task.

Finally, while I am swimming, no matter how tired I am or how slow I am going, I know I’ll get to the other side eventually. When I do, I get to push and kick again to get some extra momentum. Similarly, when I am stuck on a coding task, I sometimes switch to an easy and productive task (like adding a test) while my brain works on the problem in the background. I know I will do this if I have to, so I keep coding on the main problem for as long as I can. I finish my lap.

Then, I push and kick to start a new lap. That cadence of pushes, kicks, and then a nearly full lap of coding is how I finish the task at hand but leave a series of tech debt payments in my wake.

Question on r/ExperiencedDevs: Getting Code Reviewed Faster

I saw this question on the ExperiencedDevs subreddit today: My colleague’s code gets reviewed no questions asked. Getting mine reviewed takes a couple of nudges. How can I improve the situation? The answers on this subreddit are usually helpful, and I saw one that I resonated with me:

Personally quick PRs, sub 15 minutes total review time, I consider to be a mini-break from whatever feature I’m working on over the span of multiple days. If your PRs are 1000s of lines long and require an entirely different headspace it may cause delays that way.

This is what I was getting at in PR Authors Have a lot of Control on PR Idle Time where I told a story about the analysis a colleague at Atlassian did on our PR data. He found that short PR’s had less idle time.

On my team, where short PRs were highly encouraged, most reviews were done in a couple of hours, with 24 hours being the absolute max. Any longer than that would often be resolved by a live 1:1 review because it meant that the code was too complex to be reviewed asynchronously.

The thread on r/ExperiencedDevs has some more advice on solutions that try to resolve the social aspects, which are helpful, but I do think PRs that are easier to review will sit for less time. If your code is inherently complex, there is still a lot you can do to make the review easy (see A Good Pull Request Convinces You That it is Correct).

A Good Pull Request Convinces You That it is Correct

My onboarding peer-mentor at Trello described a good pull request as telling a story. In practice this meant that you would edit and order the commits after you were done so that the reviewer could go commit-by-commit and understand the change you made in steps.

So, for example, let’s say you were working on a feature. In your second commit, you introduce a bug, but then in your fifth commit, you find and fix that bug. Instead of just PR’ing that, you would edit the commits so that the bug was never introduced.

This is analogous to sending a document with superfluous text deleted, not crossed out. If you don’t edit the commits, you will waste the reviewers time because they might see the error in the second commit, make a comment, and then have to go back and amend their comment in the fifth. If you did this a lot, they might not even finish reviews before rejecting them (which is what I suggest you do to PRs with obvious problems).

I like the story frame, but I have started to think of a PR as more of an argument of its own correctness. I am trying to teach the reviewer the details of the problem and convince them through evidence that the new code is correct.

In a PR, I might start by introducing a unit test into the area you intend to change. Then, to make things clearer, I might commit a small refactoring (that isolates the change). It’s now possible to add more tests and possibly a failing one that shows what my intended fix will address. My small code clean-up commits are in service of that argument. Without them, it’s hard to tell if my fix won’t break something else. With them, the fix feels like a natural and inevitable conclusion.

Like a philosophical argument, I will anticipate and address the cases the reviewer might think of. But it’s not enough to handle a case in the code, your whole PR needs to make it clear that you anticipated and addressed it (with tests, comments, screenshots or any other evidence you can think of).

But the most important reviewer to convince is myself, of course, and doing the work to write the argument gives me confidence that my code is correct.

One Time I Recognized a Junior Catalyst

This is a followup to Some Behaviors of a Catalyst where I said that I didn’t think you needed seniority to be one.

More than 10 years ago, I was interviewing college seniors for an entry-level position. Among the group of very talented students there was one obvious front-runner who we offered the position to (and who accepted). But there had been another candidate that impressed us.

They interviewed well and were qualified for our position. But, we preferred candidates with some C/C++, and they had less than our preferred candidate, maybe none, I don’t remember. In any case, that was probably the deciding factor. But in a lot of other ways, they were outstanding (in the literal sense of the word). They stood out.

Here’s what I mean. A bunch of the candidates had worked together on their senior, two-semester, capstone project. We heard about this project from several angles. Over and over, a candidate would point to another person as the reason the project went well. They would, of course, talk about their own contributions, but they would also specifically point out what this other person had done as well. The thing was, the other person was always the same person, the “outstanding” one.

Even with this clue, we didn’t hire them.

About a week after we had made our decision and the offer, my boss called me in. He said a friend of his (another tech business owner) had sent in an unsolicited recommendation for a student he knew. I think he had them as intern or something. In any case, the recommendation was effusive. The student was, of course, that same one who had been recognized by their peers.

At this point we felt as if we’d be idiots not to hire them, but we didn’t have a position. The good thing about junior developers, though, is that they are cheap and you should always have a position if you see a good one. So, we created a position and made an offer. I think this is the only time I recognized a junior catalyst before working with them—the key is that people like working with them and attribute success to them. When that fact comes to light without seeking it, it’s a good sign.

Some Behaviors of a Catalyst

Yesterday I wrote that you should recognize catalysts, but didn’t say how. The problem is that so much of what they do is under the radar, but one tell is that they always seem to be part of successful teams and everyone on the team knows that they were an important member.

Catalysts can be technically great, but perhaps not the most technical person on the team or the best specialist on your corner of the company. In my experience, they are more likely generalists. They likely know the most about the other teams in your organization, which is why they can get things done with them. They often know who to go to, and those people often know them.

It’s not just the other teams, they also know the most about the architecture of other services. They might even have commits in repos they don’t own and in the third-party dependencies they use. When they need to get things done, they don’t limit themselves to just their own codebases.

Their colleagues like them and like to work with them. And the catalyst genuinely liked working with those people too (and they like people in general). They are often your best source of candidates. The best way to hire a catalyst is through a referral from someone on your team that raves about working with them.

Knowing what I know now, if I were to look for them I’d be looking for what Atlassian called “Feature Leads”, which were engineers that led a “feature” project. They often needed to orchestrate the work of several other people and perhaps several other teams. I guess to make sure they were good at it, I’d be looking for people that did it repeatedly at the same place. This work doesn’t rely heavily on their commits, but I’d be interested in people that had commits in disparate parts of the feature, not because of the technical skill it requires to do that, but because it would indicate a holistic view and might indicate a tendency to clear roadblocks, both of which are catalyst behaviors.

As I said in How Senior Software Developers Think, the more senior you are, the more you think of how your work relates to the mission of the company. Catalysts at any level do that. It’s often easier to have success as a catalyst the more senior you are, but I don’t see this as a requirement. Feature leads at Atlassian could be just past the junior level (pre-Staff/Senior level). It was a good indication that they should be promoted, but they didn’t need to have that level to catalyze.

Recognize the Catalysts

I tried to pattern my career after An Unnamed Programmer in Peopleware, whose contributions weren’t always clear, but “had never worked on a project that had been anything other than a huge success.” She was overlooked by her management, so I learned that to do this, you needed to make your contributions clear.

As a manager, I didn’t always know how to hire for this quality, but I knew it when I saw it and made sure they were on the projects that mattered. And I keep track of them, too. I might not know if a new candidate is one, but once you know someone is a catalyst, you can always hire them at your next gig.

I Prompt Cursor Based on My Progress Bar

In Build a Progress Bar for Your Work I explained how I take a task and break it down into subtasks. Each subtask then becomes a commit. A benefit I didn’t mention is that I can look at the commits and see the time it took to do each task, which will be a good way to adjust my estimate going forward. Unlike in Using Zeno’s Paradox For Progress Bars where you have no clue how much time is left, I actually do have some idea.

Having this progress bar of subtasks has also been useful in working with Cursor. I use each of those subtasks to drive my prompt. Here’s an example:

I am working on an app that has a thing like a feed with a concept of posts and reactions, like slack or discord. My stack on the server is MySQL, a TypeScript based ORM, and a TypeScript based GQL wrapper that is served by node and Apollo. My Tasks/Subtask progress bar looks like this

Add Reactions to Backend
- Create reaction entity and relate to shared objects
- Create SQL migration
- Create ORM service function to react to a shared object
- Test the service function
- Update shared object ORM getter to have a reaction summary
- Test the reaction summary
- Add a field resolver to the shared object resolver to get the reaction summary

Having that, I use each sub-bullet to create my prompt. I give Cursor a lot more information though. As an example, here’s my prompt for the first bullet (I also need to put in the context files)

Add a reaction.entity.ts with a UUID id, a many to one relationship with sharedObject (and do the reverse in sharedObject). Have a reaction type (string), a User, a createdDate (like sharedObject) — do a unique that is like this UNIQUE (shared_object_id, user_id, reaction_type), but in TypeOrm syntax at the top of the class

From that it knows what fields I would likely want to index, and adds that too. It picked the delete rule I usually use (CASCADE), and it updates the User entity and SharedObject entity to have the reverse relations. It made some slight errors, but they are easy to check and fix.

Once I have that, I make a commit and move on to the next one. In that case, I use an external script for migration, so I just do that myself, and commit.

I go on like that, picking the next thing in my list, coding or generating and fixing, and then making a commit. The result is a PR that looks the way I want (not just the whole change in one commit) in the order that makes sense for a reviewer. I do this even though I am the reviewer (as I wrote in Pull Requests for One) because I do actually do a review and I want it to be easy.

This activity (to me) is very much like programming, which is what I was getting at in Can non-programmers use Cursor? A complete non-programmer? Probably not, but I do think someone could do this if they had some programming skill. The main thing I am doing is what I said in Programming is Disambiguating: “Programming is taking a nebulous problem and breaking it down, understanding it, trying to find building blocks, and then building up something that solves the problem.” Those building blocks could be prompts or code, it doesn’t matter, as long as it solves the problem.