As I mentioned recently in my post about pressure and resistance, I’ve had a hard time getting started lately. I’ll sit down to work, and then I get distracted. At the end of the day, I’ve accomplished nothing on my to do list.
I feel like an engine that won’t “catch.” Turn the key, it makes the right sounds to indicate that the engine is surely starting. But as soon as you stop turning the key… silence.
Another piece of the resistance, in addition to rebelling against the pressure: I fear doing it wrong or not being able to finish.
I dread writing for a while on a blog post and then losing enthusiasm and giving up.
I’ll think about a section of my book proposal but then worry that it won’t go well or I won’t be able to complete it.
You know what guarantees that I will fail? Not starting.
It makes no sense. Not starting feels safer, even though it guarantees the outcome I don’t want. Why should it feel safer?
And yet, I’ve spent several days this month with the engine turning over but not catching.
Fortunately, yesterday was a good day. Got a (fairly long!) newsletter email written. Yay! And today has been good so far too. Taking the pressure off is helping.
Blank is easy, but not useful
I had to laugh when I saw this. Here are the search engine optimization (SEO) ratings from Yoast for a completely blank blog post:
I had to laugh. That post (or book!) you never write? Sure, as a blank page, it might be incredibly easy to read. And, not having any words, it is unlikely to offend.
But it’s not exactly going to be engaging to your readers. With driving, to get somewhere, you have to actually start the engine. In order to connect through the written word, you must start writing.
I’ve seen a few posts on social media with questions like:
Why are we still trying to figure out exactly how much more productive developers are with GitHub Copilot when it is so cheap? Who cares? Just give them the tool!
Well, let’s think about that. Who does care? (And is Copilot cheap?)
I’m imagining a conversation like this:
Person A: It will make [or it made] our developers more productive!
Person B: How much more productive?
As my dad used to say, “what are you going to do with that information?” If you’re not going to act differently based on what you learn, is the effort to find out going to be worth it?
Person B, what are you going to do if the answer is “10% more productive” vs. “50% more productive” vs. “300% more productive”?
Sometimes my answer to my dad was: “I was just wondering.” Asking a question can still be worth the effort, even if you’re not going to do anything at all with the information.
In this case, though, Person B: is it worth someone else’s effort just to satisfy your curiosity? Seems iffy to me.
Purely research
Maybe Person B is a researcher. Are they comparing different tools to see which is more effective? Are they collecting a baseline to monitor changes over time as tools (hopefully) improve? Are they just trying to be precise, because “I dunno, it’s more than a few percentage points” isn’t great in a scholarly article?
Persuading people to use the tool
Could be that Person B is trying to convince someone to adopt Copilot. They are selling licenses. They think it looks interesting and want access for their teams. They bought a bunch of licenses already and want them to go to good use. They think AI is the way of the future and want to make sure people are on board. And they are hoping for a convincing-sounding number.
Return on investment (ROI)
Perhaps Person B has been pushing Copilot because they thought it was cool (or because their management told them to push Copilot), and now management wants to know if this was a good use of resources.
Could be some judgment involved here too. Person B might be checking for confirmation of their suspicions, thinking “I bet it’s not great, AI isn’t that big a deal,” or “I’d say anything less than ‘2x as productive’ and they’re using it wrong.”
Speaking of resources, is it actually cheap?
People say, “it’s only $20” (per user, per month). True, but there’s also developer time spent learning and experimenting. Add to that, potentially, costs like training, governance, monitoring, reporting, legal considerations, privacy and security concerns, risk management, etc.
Maybe that’s still cheap compared to how expensive developers are, but it’s not quite as simple as “if I cost $50/hr and it can save me an hour a month, then I should have the tool.” That simple math falls through when your developer saves a few hours but also inadvertently exposes private data to the public, causes the company to lose millions in some transactions gone awry, or introduces a security vulnerability. And the company is held accountable by auditors who say there should have been more training.
Changes of plan
My first thought when I tried to answer the question of why find the specific percentage: are we doing math? Like “if developers are 50% more productive, that means every person can now do the work of 1.5 people. That means 2 people with AI equals 3 people without AI. So I can reduce my headcount by 1/3!”
Or: “if developers are 50% more productive, then what they used to get done in 3 weeks should now take only 2 weeks. So I can move up my delivery date projections!”
Both of these worry me…
So many questions
The more I write, the more this topic is raising other related questions I want to talk about. I’m sure I’m omitting plenty of other reasons for seeking a specific percentage. But some of the questions raised:
How do we define productivity? A classic, and a great question to ask anytime that word starts getting tossed around.
How did we get this 50% number? Is it even real? (Okay, in this newsletter it’s for illustration purposes. Please don’t cite my 50% as fact, okay? I made it up. But in real life, if someone gives you a number, ask where it came from and what it actually represents.)
Why the math above to reduce headcount might be a problem
Why the math above to move delivery dates up might be a problem
What skills do developers with AI need in order to get the biggest productivity gains?
I’m sure I’ll be writing more from the questions sparked by this post. I’m still sorting out what writing belongs in my blog vs. what belongs in my newsletter (sign up here!), but I already have something I want to write next. I want to start in exactly the same place as this blog post, but then take it in a completely different direction. That will probably be in the newsletter in the next week or two.
Make sure to join my email mailing list so you are getting the goods right in your inbox. In the meantime, drop a note below with your thoughts about AI and developer productivity. Have you been asked to give a percentage? How did you measure it?
