Can non-programmers use Cursor?

I wrote Can non-programmers make applications with AI? last month. TL;DR: Yes. But, I hadn’t used Cursor yet. Now, I’m pretty sure that to use Cursor well on a real project, it helps to know some programming. But, if you do, it’s way more useful than it would be to an expert, which is saying something, because I find it very useful.

As an expert, my coding session today was maybe 2x faster for the same code. But, a non-programmer would have taken weeks to do what I did (if they could even do it). I think they have a chance to get close with prompts—I almost did, and they would try harder.

For what I needed to do today, in the first 5 minutes, Cursor did a good first pass. I fixed its syntax errors and the result “worked”. It looked terrible (this was implementing drag drop in a React app)—it took me a couple of hours to get it exactly how I liked it and then polish the code. But, getting me started quickly gave me a ton of momentum, and then I had time to make it exactly how I wanted it.

For a less skilled programmer to do this task, I think the first five minutes goes the same way. I know from experience, that it’s easier for me to just fix little problems, but I think it could be done with prompts. Then, the rounds of successive improvement were helped by autocomplete, but I initiated all of it. I relied on my knowledge of CSS and React to fix issues. I haven’t had good experience with the LLM’s for this—they can’t “see” the problem in the browser yet, and all of my problems were UI nitpicks and complicated Drag/Drop issues (not a static render I could screenshot or easily describe). All of the different modes of Cursor LLM integration have strengths for different uses—but some rely more on your ability than others.

From my use, it feels like knowing some programming is required. But, if it took a less skilled person from 2 weeks to 1-2 days, that’s more like 10x for them. What’s more, I go from 20x faster than them to 4x for this task, and they have more to improve, where my gains are asymptotic.

Three Days of Cursor

I tried out Cursor three days ago. But, before I did, I really did try to give GitHub Edits a chance. I used it for a few things, and it was more trouble than it was worth. I mentioned this to a friend at lunch on Tuesday and he asked why I hadn’t tried Cursor yet. I said I was worried it would interfere with my setup too much, but he confirmed that it reads your VSCode settings and extensions and (for him) just works. I use extensions as Tech Debt Detectors, so they are important to me.

So, the next day, I gave it a try. At 3:15 on Wednesday, I started the download. By 3:20, it was installed and working as I expected. I wrote a prompt to do the thing I needed to do next and its change was perfect. It was 3:27.

My next request did not go as well, but it was a complicated one involving a package I wanted to try. It would not install properly, and neither I nor Cursor could figure it out.

Since then, I’ve been using Cursor a lot. There are three main ways it’s better than GitHub CoPilot.

  1. The Generation from chats is much better than the GH equivalent.
  2. The autocomplete doesn’t require me to place the cursor. It anticipates what I am going to do and offers changes in different parts of the file. Sometimes all at once.
  3. There’s a hotkey for inline generation that works well too. I had been doing this with comments, but this is better because it just lets me type (without interruptions) and it knows I want it to start a generation when I’m done.

For all of these features, I feel very much like I am still programming. I am sequencing the work. It feels like it’s reading my mind since I do know exactly how to do what I am asking, but it’s saving a lot of typing.

This is helped by my app’s code being very regular. There’s only one way to do DB code, one way to wrap it in GQL, one way to call it. My UI is regular. The code has established patterns, and I put example files in the context before I prompt (and mention that I want it done like those files).

The main way it helps me though, is to keep me in flow. I am not constantly juggling files and typing out simple things. I say I want a table with an id, name, and a specific relation, and it knows my id is a UUID, and how I typically name relations. I say I want a cross table and it knows to set up the relations between the tables and the new one (in the way I have done it before). It intuits that I want cascading deletes without me asking. It’s just a lot of little things that save time and let me move on to something else.

January 2025 Blog Roundup

In January, I posted every day. Here were the themes:

I brought my podcast back. I kept it in season 4, which is about the lessons I’m learning while writing a book about tech debt.

Writing every day is part of my marketing strategy for the book. I outlined that here:

I wrote a bunch of articles about Code Review. I had written If code reviews take too long, do this first in December. Here are some follow-ups.

I did a series of 3 posts about how to triple the number of posts you write:

I wrote a few posts about AI

I’m also proud of this toot:

Post by @loufranco@mastodon.social
View on Mastodon

Which I thought of while revisiting We Keep Reinventing Injection Attacks

I’ve been getting interested in helping entry-level developers more. These posts are what I think about it:

Write While True Episode 46: Write as Yourself to Yourself

Podcast: Play in new window | Download

This is the 7th episode of season four. I started this season in January of 2024. My intent was to document the process of writing a book. But even though this season is over a year long, there have only been 7 episodes, and that’s because I took a 9 month break. I want to talk more about what happened during that break, and how I was derailed from my plans, and how I recovered.

Transcript

How to Increase Story Points Per Sprint

Story points are not a basis for measuring and improving productivity because points are just an abstract measure of time. That’s why I said you should Be Skeptical of Points-based Productivity Claims. Any systematic productivity improvement would decrease the points for a future story, and the velocity would go back to a steady state.

If you had a way to compare stories over time to each other, you might see improvement in an individual story. If you literally are doing the same story over and over—like, for example, a set of recurring tasks—then, you could absolutely see its points decrease over time if you automate it. So, one way to get more done per sprint is to automate repetitive tasks, but once you do that, the points assigned to that task will go down and the velocity will not change. But the thing to look at is the comparison of this story in your sprint with its past incarnations, not velocity.

This is why I Estimate Using Time, not points. They are the same thing, but everyone understands time, and no one understands points. If you reread the first two paragraphs, but substitute “hours” instead of “points”, then they are obviously correct. If you automate a task then the number of hours it takes goes down—no one disagrees with that. If I use CoPilot to get systematic productivity, then my estimate of the number of hours it takes to do something will go down. Points obscure this.

There is a problem with using time (which is also true with points, but it’s just glossed over), which is the difference between work time and calendar time. If you estimate with work time, and report that, you will confuse people, because the only time that matters is calendar time. But, Story Points are often a proxy for work time, so I’ll assume that’s what it is for you too.

Given all of that, it’s easy to see how to increase the number of points done in a sprint. You need to either create time or decrease the difference between work time and calendar time. If you do that, you will find more stories get pulled into a sprint and get done, which will show up in velocity because it probably won’t cause the points for a particular card to go down, because most teams estimate points using work time.

So, how do you create time? Easy. Hire more developers. Despite what you have heard, you can add developers to a team to get more done, as long as they don’t need to communicate with each other.

To reduce the difference between work time and calendar time, you need to concentrate on everything that’s not sprint work. The main culprit is unnecessary meetings, but another is long waits for feedback. There are lots of times developers might need to wait, but waiting for code reviews is probably the biggest one because it happens to everyone all of the time. To work on that, read: If code reviews take too long, do this first.

Add Developers to a Team Without Lowering Productivity

According to Brook’s Law (from Mythical Man Month [affiliate link]), adding software developers to a late project makes it later because the number of communication lines increases rapidly with each new person. A team with N developers has N*(N-1)/2 communication lines, so a team of two has one line between them, but a team of 20 has 190 lines, one for each pair. If we accept this, there are several caveats that mean the law might not apply to you.

It should be clear that this won’t apply to a very small team. If you have two developers, then adding two more will help. The number of communication lines goes from one to six, but the amount of time that can be spent working on the project doubles. Compare this to adding two people to a twenty person team, where you might add more than forty communication lines and only 10% more work time. Also, a team of two have probably not created a very large codebase yet, so ramp-up time is not as bad as what it takes to learn what a team of twenty could create.

Another way the law doesn’t apply is if your developers don’t need to talk to each other. If they can work completely independently, then you are not adding communication lines. That also works if they only need to talk to a small subset.

You can also increase the effectiveness of a given team (before adding anyone) if you can remove lines of communication. This does not mean “better communication” (like documentation), which only reduces the cost of a line, not the number of lines. Reducing the cost of lines is good, but will be overwhelmed by combinatorial explosion of new lines if you don’t work to remove them.

Removing a line of communication only happens if the communication isn’t necessary. The model here is to think of that part of the team as external. If I add AWS to my project, I expect a lot of productivity gains, but I don’t add in communication lines to every developer that built it. A lot of teams move to architectures like micro-services to reduce lines of communication, which is supposedly how AWS came into existence in the first place. That’s one way, but you can get there with clean API’s in libraries too. Whatever you may think of external library dependencies (I think of them as instant tech debt), they can make us more productive (just not for free). If you added developers to make a library for you, you would get the same benefit if they could stay as independent.

Once you have independent sub-teams, they can add developers because they are small. At Trello, when I was on the iOS team, I relied on the Trello backend API, but I didn’t need to communicate much with the developers that worked on it, follow their daily PR flow, or go to their meetings. As a principal engineer, I did read their RFC’s, but most of my team didn’t need to. When the backend team grew, my productivity wasn’t affected. Our team was small, so we doubled in size without causing the backend developers any trouble. Our lines of communication increased, but it was manageable.

Independence wasn’t only at the code level. Teams at Trello didn’t have a shared development process. Many teams did sprints, but they didn’t need to sync with each other. Teams that worked on the same deployable had to communicate more, but it was more hub and spoke rather than every possible pair. One way we did this was to have a role called a “feature lead” who was a focal point of communication. They would have a line to each developer on their project, but could help the rest of the team members stay independent from each other.

So, to add developers with less communication overhead, create small, independent teams. To the extent that there are dependencies between them, try to concentrate that in a few people, rather than spread the effect to everyone.

The Case for Adding Entry-Level Devs to Your Team

To be clear, by entry-level, I mean 0 years of experience, but with the skills that you would get from a bachelors in CS (or related) and some internships. Going by myself, when I graduated, I had built a compiler, a SQL-like database, a 3D modeling and animation application, image processing algorithms, a robot-arm controller, a theorem prover, etc. I had used version control, worked in the computer center, and had some tech-related summer jobs. This pales in comparison to what I’ve seen from modern CS graduates.

When I was hired at my first job, I fixed a lot of bugs to learn the codebase. My first big task was to reduce the memory footprint of our application by rewriting our windowing code (this was on DOS, so we simulated windows with ASCII Art). I worked on build scripts. I helped port our software to UNIX. I fixed a lot of core dumps. I worked on our printing code (yes, printing to paper). I could do all of this without understanding what Foreign Exchange Options were (yet). There’s a ton of work like this on most teams, and frankly, you are overpaying if this is what you have your senior devs doing.

That’s the main reason you need entry-level devs. There’s a lot of work that is only cost-justified if they do it. They can learn while paying off some technical debt, automate tests, and fix the quality-of-life bugs that make your app look unpolished. They can learn your domain by participating in code reviews.

The second reason is that all of this work is hindering your senior staff from growing. They shouldn’t be doing this work—they should be driving bigger outcomes (as I wrote on How Senior Software Developers Think). You are risking them leaving because they fear having 1-year of experience 5 times.

Finally, healthy teams have a diversity of experiences. An all-senior team may seem great, but they will have more groupthink than a team with some junior developers. It gives seniors a chance to mentor and will frankly make them code better (because it needs to be understood by less experienced team members). Having to explain things makes sure you understand them yourself. Documentation will be better, because you need it to be.

If you know how to retain them, entry-level developers grow with the company. Our CEO had started right out of school (where he was the first hire, I think). I eventually went on to lead the engineering team. At Atalasoft, we hired mostly entry-level, and they went on to build the products that were the basis of our acquisition. My last job, Trello, was co-founded by Joel Spolsky, who famously wrote about how to find great developers – TL;DR: get them at the entry-level. When I joined, a lot of the engineering team (that had built Trello to 7 million users by this point) had been hired out of college.

I understand that there’s risk, but learning how to recruit and evaluate entry-level developers is a core skill that your team should have.

Supernote Manta: Review at Four Weeks

I got a Supernote Manta about four weeks ago, and I wrote Supernote Manta First Impressions after using it for two days. Looking that post over, the only thing different is that I found out that you can use handwriting instead of typing in a lot of contexts by tapping the globe icon that shows up on the keyboard. This is marginally better than typing (which is very bad), so I still hope that it can get better in software updates. But, those impressions were about the visceral feel of the device, not how useful it is in practice.

After four weeks, I continue to be happy with Supernote as a replacement for paper journals. I have been using paper for my whole life, so I didn’t think this would be possible, and maybe it’s specific to me, but here are the reasons why I find it better than paper:

  1. My ideal journal has a lot of pages. In 2024, my journal was almost 400 pages. It has gotten too big to carry. On the Supernote, I don’t have to think about this at all. I created a custom journal that has a page for each day and a lot more.
  2. I like editing. I have come to rely on undo and cut/paste. I never had this with paper and didn’t consider this when moving to a tablet, but now I realize how important it is to me.
  3. It’s also great for reading. The Supernote with the Kindle app is as good as my Kindle device, which I don’t use any more. So, in addition to not lugging my paper journal, I can also not take the Kindle (which was always in my daily carry).
  4. It has all of my journals. I keep different kinds of journals. I have my daily, bullet-like journal, but I also have project specific ones and others (see Write While True Episode 21: Dedicated Journals). They are all slowly being migrated into the Supernote.

All of this would not matter at all if the writing on the device wasn’t comparable to paper. It is.

For me, the biggest downside (compared to paper) is that it is monochrome. I practice Two Color Journaling, where most writing is in black and important things are in red. I have been using other cues to highlight (symbols, boxes, the highlighter). It’s ok. I don’t think the new Remarkable (with color) would meet my other criteria, but it’s something to think about for the future. I guess I hope that color e-ink becomes ubiquitous and is available in a future Supernote.

The Entry-Level is the Applicant’s First Job

I spent some time today reading entry-level job descriptions on LinkedIn. There seems to be a widespread misconception that entry-level means “doesn’t have a lot of experience”, but entry-level means “no experience” — it’s right there in the name.

In addition to requiring a couple of years experience, these jobs also seem to require skills that would be very hard to obtain without a job. It’s shortsighted and very unlikely to result in good hires.

Imagine what this employer is thinking: There is a person with 2 years experience at a job where they got all of this great experience, and now they are going to move to your (excuse me) shitty job. They are not.

Let’s assume this person is great—I hate to tell you, but they are not looking at junior/entry-level jobs. Either their current employer is smart enough to know how to retain them (hint: with money), and so they will not be considering you or, if they are looking, they are looking to move up.

The person with 1-2 years experience that is fine with another entry-level job is doing this for a reason. In the best case scenario: they are in a bad job and need to get out—guess what, your job looks just as bad. My evidence for this is that you don’t know what “entry-level” means and are likely going to have unrealistic expectations and be another bad job. They know this. They missed the red flags before, but they see them now.

Posting entry-level jobs that are not entry level is a signal that your job sucks.

Why Even Triple the Number of Posts You Write

In Triple the number of blog posts you write and the follow-up to it, I gave some examples of how to triple the number of posts you write. This is the third post in that series, where I will tell you why I even think this is a good idea.

Again, I will turn to Art and Fear [affiliate link], because another lesson I learned from it is that the point of making art is because of the effect it has on the maker. Writing is how you become a writer, so doing it more will make you better, faster.

I prefer that reason to something like: the Google algorithm prefers it, or it’s easier to share on social media, or your AdSense revenue will go up if readers need to click around. There are no ads on this site, so I don’t care about CPM prices or page views. I would love for my SEO to be better or for more people to share my work, but the best way to do that is to just make a lot of good work.

I have no idea which posts will do better than others. I have written before that the highest traffic page from search is my UML Cheatsheet. The second highest had been my explanation of the tech that The Wizard of Oz used to make his ghostly head. Those two posts are over 10 years old. Lately, my review of the Supernote Manta has climbed to the top of that list. I would never have predicted that these would draw the most search traffic.

In Blog Posts, Randomness, and Optionality, I wrote that every post is a lottery ticket to some future benefit. I can’t predict what will happen to each one, but I know that having a lot is good.