Adam Keys is Thinking

Granted, quality of idea matters. The worst idea executed swiftly and repeatedly is still probably the worst idea. But it’s hard to know, with ideas, when you’ve got a winner or not. Hence, the power of iteration.

$$output = iterations * rate * idea$$

There are many ways to turn a good idea into great work.

• Generate one immaculate idea, get it done, get it out there, promote it relentlessly.
• Have ten good ideas, try them all quickly, put the best idea out there, pursue the one or two that seem most promising.
• Have one hundred ideas of wildly varying goodness, try them at a fantastic pace, see which one sticks.

For better or worse, the world we live in favors the last one. The person with one great idea is often not the person who is known for great work. Unless they’re lucky, persistent, or both!

(Once you’ve got that good idea, you still need The Quality.)

Allow me an idiomatic metaphor: “Good Vibrations” was a whopper of a good idea but took 7 months to record. Most albums take far less time than that to record (not you, Bruce Springsteen), contain 8-12 songs, and 1-2 songs stand out. Today, you can slop out one hundred songs with AI and if any of them are listened to more than a couple times it’s a big success.

Of the many “All you need is attention, context, cheese-whiz” sort of papers out there, the unsung hero is “All you need is billions upon billions of iterations.”

Hence, evolution and all of human creativity as well! It only took hundreds of light bulbs and dozens of airplanes before Edison or the Wright Brothers found the one that works.

Explosion of mediocrity, video gaming edition: it’s become easier to build games, so there are more and more games every year; but the number of highly acclaimed games per year has stayed constant or even declined slightly (orange dots).

Nabeel S. Qureshi

More accessible does not mean success comes more easily or more work will have higher quality. Accessibility is orthogonal to magnitude and density of quality.

For any creative endeavor, this is true. Axiomatically, if you make something easier, you’re lowering the cost of entry. This applies to average creators as much as potential superstars like Mozart, Carmack, or Einstein.

If you make it easier to do, less devoted, determined, or talented people will do it. More people means you will see more volume, making “merely” average work seem more common. The work you observe might also be more uniform or bland, since making something accessible often means many folks are starting from similar templates or boilerplates.

This might sound a bit elitist. But, I think there’s plenty of room to produce great work without elite skill. ZZ Top and AC/DC are far less sophisticated, and their members less talented, than Prince or Van Halen, but still produce work that carries an appeal of its own.

The same applies to software. You don’t need a room full of doctorates to produce excellent software, you don’t need a master of arcana to produce fast software, and you don’t need a transcendent genius to solve someone’s problem in a well-considered product.

Look at this bit of CSS. For greatest effect, imagine sending it yourself from ten or fifteen years ago, or the first time you hit upon a limitation in browser compatibility or looked at someone else’s stylesheet and wondered “what the heck is going on here and what’s a high-pass filter?”

Marvel at all the things that are just there, no hacks or preprocessors or compilers required. Gradients, animations, input states. CSS has grown into the open-ended, declarative, and compatible system it always wanted to be. I dare say that CSS is (finally?) hitting its mark.

Can Ruby, JS, Python, C#, Java, etc. make a similar claim? Particularly in expanding the capability with, AFAICT, only superficial syntactic changes and adding new rules.

Can you still use Python from ten years ago, add new functionality to a Ruby program with a keyword, or use new features in JavaScript across all runtimes? Were it only true! (Where it’s not, there are usually pretty good reasons, to be fair.)

Based on tinkering with SwiftUI lately: this beats configuring views. Even when I’m building both with the help of Spicy AI Auto-complete. 😉

Previously: low-key CSS libraries.

In that order, every time.

I make a big deal about working downhill. Get stuff done, slice it smaller, get feedback, go again, remove friction, a little faster this time.

But let me tell you, none of that matters if it doesn’t come together and feel great once it’s all assembled in front of you.

When you feel it, you know. The feature makes you smile when you use it. It fits right in, like it was always meant to be there. You want to use it again. You want to tell people about it.

This is the difference.

— Mitchell Hashimoto, You Have to Feel It

Everyone loves a little faster, even if they say they want more function or nitpick on the form. But not everyone asks for it to feel great. That’s what distinguishes the good from the great and the great from the sublime.

Feel, fast, function, form. In that order. Every time.

It has to feel great, feel quick, have the right functions, and pleasing forms. In that order of importance.

I’ll excuse anyone if they’re not a transcendent genius who can create things exhibiting those qualities in that order and every time they sit down to build. But when you can get all four of those things together, even in small quantities, then you’ve got something special.

Feels great, feels fast, gets the job done, all the right affordances and embellishments. In that order, every time. You gotta try, at least.

When leading projects, in any capacity, avoid startling your colleagues. Tech leads, engineering managers, product managers, etc. need to keep peers and stakeholders informed. When there are successes, let them know. When risks are discovered, communicate the steps taken to mitigate them. When setbacks occur, indicate how it will affect the remaining scope and schedule of the project. Dig out, not up.

Stakeholders and peers are startled when they think a project is smooth sailing only to hear the ship is sinking. When things go poorly, projects slip by inches, then feet, then all of a sudden. It’s on project leaders to detect these slips, address the root causes, and let people interested in the project know what’s going on and what you’re doing about it.

This may seem obvious! But it’s easy to get so wrapped up in solving the problem that you forget to communicate the problem. To want to say, with ease, “things aren’t going great, but I have it under control.” Or, to feel like the issue is yours alone and forget you may have peers in the organization that could help if only you communicated it.

A non-obvious way to surprise people is to silently, but suddenly, succeed. Release new features or change functionality in production without any kind of internal notice or documentation, and I’ll bet you hear something from customer support, marketing, sales, etc. They won’t begrudge you for doing your job and shipping code, but they might ask you to please let us know next time so we can prepare our teams, campaigns, or update our documentation. Or, they might come at you with pitchforks, wanting to know why things are changing out from under them.

Corollary: Don’t Be Spooky. If you need to tell someone, IC or stakeholder, that a project has run into surprises, just tell them. Don’t open up with context-free messages like “can we talk?”

Have the hard conversation now, before it gets tougher.

So you messed up. Now what?

Late projects stay late. It’s terrifically rare to “catch up” on a late project. When projects run late, it’s because you’ve missed something in your original estimate: you’ve guessed that work will take x days, but it’s taking 1.5x, or whatever. For you to “catch up”, your estimate would have to be wrong about the rest of the project, but in the opposite direction. Even if you correct what led to the overrun, it’s terrifically unlikely that you’ll somehow make up time.

— Jacob Kaplan-Moss

Don’t tell people you will get back on schedule by working harder or having better luck. As Jacob points out, there’s already evidence that your team’s capacity or luck aren’t harmonizing with your existing estimates and hopes!

Instead, talk about scope/time trade-offs that one could make to focus on what’s most important. Share the results of retrospectives.

Attempt to explain how you got here in the first place. Caveat, you’re unlikely to fully explain how a software project surprised you on the first attempt. You’re working from an estimate, a projection from wildly incomplete information. Now you have slightly more information, but still an incomplete model. (You won’t have a complete model until you finish the project, sadly.)

Share how you might avoid this surprise in the future. Caveat, the remedy is often worse than the disease. Particularly in software development, if we attempted to prevent or foresee every possible illness, the project would barely get off the ground before it was cancelled. See also: agile software projects accidentally reinvent waterfall when they seek to add more predictability and remove risk/surprises from the process.

Previously: Your estimates were wrong? Communicate!

The last 10% of any creative act is the hard part. (Previously: Finishing is a skill.) You had an idea, thought it would take X days, only to find X-1 days of all these other things that have to be done. That’s functional scope creep.

Finishing, actually getting the draft or project out of your computer and out into the world, that’s a whole other list of things. Lots of work, and surprises, are lurking here. Call it delivery scope creep. Or a finishing tax. And, it’s a mental challenge, getting over the “they’re all gonna laugh at you” fear. (But not in the Adam Sandler way.)

The more steps you can remove from putting something out there, the more you can put out there. (There’s always money in the shovel stand.) Ergo, the continuous development of new systems and tools to make online publishing easier, despite the market having excited for nearly three decades.

Related, the programmers’ credo: “we do these things not because they are easy, but because we thought they were going to be easy.” So goes software, so goes any other creative endeavor.

Writing words and writing code feel similar, for me. (And, playing a musical instrument, if I go far back enough.) They are equal parts mechanical performance, exercise of taste, and act of creation. For all of them, I want to be in a flow state. I want to go as deep as I can, time permitting. I want to hold a whole world in my head. I want to work among as many details, as deeply as possible.

Finishing, whether it’s releasing software or publishing an essay, reviewing code, or editing and revising words, are a different skillset. Differently creative, but still putting something new into existence. There’s a nice symmetry there. If you can get good at editing and revising words, you can get good at editing and revising code.

Getting over the last 90% of any kind of project, whether code or words or music, is the same skill.

It’s like the last 90% of anything is just a mindset, almost a resilience of mind. If you can get good at one, the skill carries over into anything that requires finishing.

It feels like life pulls a fast one on us, at times. “What got us here, won’t get us there”. Making the software, essay, or music is different from shipping, publishing, or releasing it. But if you can get good at any one of shipping, publishing, or releasing, you are considerably further ahead on getting good at the other two.

The winning scenario for agent-assisted code, design, science, etc. is humans having more time to do creative and impactful thinking because computers/LLMs do the tedious setup, easily verified work, and gather preliminary materials that humans turn into inventions.

FWIW, I don’t think the worst scenarios are likely. The future isn’t atrophying literacy rates or people turning off their brains to tell LLMs what to do. It’s probably not Malthusian job scarcity or Keynesian leisure abundance, either.

The best outcome, IMO, is that producing almost-good-enough software, design, science, etc. is possible for more people, particularly those without specialist degrees.

You won’t have gym owners producing billion dollar SaaS companies, but they might produce software good enough to run their business without needing to contract out to a software developer.

You won’t have software developers producing the same level of design and art direction you see in major films. You might see them producing design good enough and sufficiently distinct that they can wait to bring a designer on until they’ve found their market.

You won’t have writers discovering new axioms of math and science, but you might see them correctly apply statistics and physics so that stories about finance and space battles are slightly more realistic.😉

In short: experts in topic A won’t find themselves held back by having an idea that requires expertise in topic A and topic B, where topic B is too deep for them to “just get good at”. Fewer Wozniaks will have to find their Steve Jobs, fewer Springsteens will have to find their Landaus.

It won’t exactly be you can just do stuff. But, perhaps you can get far enough along that collaborators to fill in the specialties you don’t can find you.