I often do this in meetings and have gotten into the habit of saying "I'm thinking". It's not much but it gives both of us time to think and explicitly makes it clear I don't expect the person to say something. I think that helps.

I just blurt out "processing" when they start looking at me weird. People tend to take it well.

I read this at first as "I just blurt out "processing" and people look at me weird", which made me smile.

Fair enough, I do like parent’s a bit better, “blurting processing” feels like a too high default setting right after seeing “I’m thinking” :) - not that any of it matters anyways, communicating _something_ gets you there. Rest it just triaging around the edges what people will call you weird for, and if they are, they were going to anyway.

"Give me a second" is something I say when someone just has to break the silence with some unproductive comment. Having 20-30 seconds to think silently should be a completely normal thing.

”Thinking longer for a better answer”

I that once in a technical interview and got the job (just paused for 30 seconds until the answer came to me). I think they expected a 15 minute process of problem solving.

If I recall correctly the question was something like:

You are sitting recording cars by their license plate as they drive down a road. You only have N spots on your worksheet. You can overwrite spots as many times as you need to. By the end of the day you must have an unbiased sampling of cars that have driven by you. How do you record the cars?

Nice statistical problem! I only thought of a solution that is valid for many cars and few worksheet spots. Were you able to fully solve it on the spot?

What other situations are you concerned with that your solution doesn’t handle?

The best solution I could think of on the spot was this: First write down every license place until it fills up. Then for each time a car drives by, give it a 1/2 chance to write it down. Moving down the list regardless of the outcome. Then once the bottom is reached, do it again but with 1/3 a chance. Over and over again, decreasing the chance each time.

I checked for which situations it is valid, and it surprisingly was when there are many more cars than the list size. But it is not valid when there are just a few more cars than the list size.

Mine was to roll a number between 1 and N once N is greater than M (N being cars seen so far, M your slots available). If you get a number that is less than or equal to M, replace that slot. If it is greater than M, that sample is dropped.

  > he might shrug and say "I don't know"

I have far more trust for people willing to say this.

  > I would start blurting out half-baked ideas to fill the silence

I find that I'm more likely to do this but try to make an effort to stop. There's times to spitball but we should also spend time thinking. And let's be real 30-60s is not that long

  > This manager also typed with one or two fingers, and pretty slowly too. But he wrote a lot of good code.

I'll be honest, this is the big reason I don't get all the hype around coding agents. I do find them useful but typing isn't the bottleneck. Not even close. Plus, while typing is when I'm doing my best debugging and best simplifying.

> typing isn't the bottleneck. Not even close.

I find it absolutely is much of the time - I'll determine the architecture/overall solution, know exactly what needs to go in a multitude of files, and now actualizing all that isn't really thinking anymore, just donkey work. Getting AI to do this has been incredible now that it's finally good enough. I've had Copilot make flawless 500+LOC C++ classes in the first pass, and when I introduced bugs by changing it by hand, it found them instantly from stack traces without even having symbols, saving me hours. I see a future where writing a large codebase all by hand is seen like raising a barn the Amish way with no powertools - impressive and maybe there's something to be said for it philosophically, but just not practical otherwise.

I find however, that while typing it all out, my mind often continues analyzing and thinking, and that I often find a new idea, or new structure, that might be even better. Typing it out and seeing it appear in front of me. It also gives me a feeling for how tedious, brittle, or annoying the solution is.

Granted, sometimes it's really not that interesting to type the stuff. It depends what one is working on.

Each time I write a routine it's different. Its better. I've learned something from last time. In fact, this is one of the things that got me hooked on computing. That there's so much complexity, often hidden, that there's always more to learn and improve upon.

And truth be told, if I'm writing the same thing many times it's time to create a library. Maybe just for myself or for the company I work for. But the same thing happens. I always learn more while doing it and it always gets better.

I fear the programmer whose bottleneck is typing. They already know the answer. But the problem is that there is none

If you use that much time for donkey work, you are using the wrong tools. If it is so simple so that can delegate it to a LLM, you need to use a language with more expressive power.

There's no such language, sans Lisp with extreme use of macros.

Here's an alternative take: if typing isn't a bottleneck for you, and you don't experience coding as being donkey work, you are thinking too slow, and/or in too small increments.

How often are you actually doing this though? I think I probably work in something greenfield about once a decade. The hard part is always going down a rabbit hole in established code bases. I can do the boilerplate in a few days. It saves time, but not really even one hairy issue a year.

> The hard part is always going down a rabbit hole in established code bases.

Actually, I found that this is exactly where they shine (I wouldn't trust them with greenfield implementation myself). Exploring existing code is so much easier when you can ask them how something works. You can even ask them to find problems - you can't trust them to be correct, of course, but at least you get some good brainstorming going. And, incredibly, they often do find actual problems in the code. Pretty impressive for language models.

How long have you been programming?

I actually felt like I learned the most when I stopped going to Google and StackOverflow for solutions and instead moved to docs. It's far less direct but the information is much more rich. All that auxiliary information compounds. I want to skip it, feeling rushed to get an answer, but I've always been the better for taking the "scenic route". I'd then play around and learn how to push functions and abuse them. Boy there's no learning like learning how to abuse code.

Fwiw, I do use LLMs, but they don't write code for me. They are fantastic rubber ducky machines. Far better than my cat, which is better than an actual rubber duck. They aid in docs too, helping fill in that space when you don't exactly understand them. But don't let them do the hard work nor the boring work. The boring work is where you usually learn the most. It's also the time you don't recognize that's happening

Close to 5 years. I read docs too and love the immersion and the fully grasping of concepts when going with your route, but most days there's just not enough hours for this.

> The boring work is where you usually learn the most. It's also the time you don't recognize that's happening

That was always how I did it before mid-2025. And I do still do boring work when I truly want to master something, but doing that too much just means (for me) not finishing anything.

5 years isn't that long. I've been doing 3X that and I'm constantly learning new things. Not even about new language features but even languages I've been using that whole time. New ways to problem solve. New algorithms. New tools.

Not finishing things can be okay but also not. An important skill to learn is what's good enough. And to write good enough to be easily upgradable. It's important to write code to be flexible for this reason. It's also important to realize it's okay to completely throw away code. But also this is the reason comments are so important. Don't just write what functions do but also write how you envision the design. Even if you can't get to it now. Then when you or anyone else comes back (after lunch, next week, next year, whenever) there's good hints about all that. Knowing how to get up to speed and be effective fast. If anything this helps agents even more. Commenting is a vastly under appreciated skill and only becoming more valuable

> I've had Copilot make flawless 500+LOC C++ classes in the first pass

Lmao, please tell me what products you're working on so I can avoid them

Oh my, the AI bros got upset! You must be cranky from having to fix all those bugs your agent keeps throwing up in your "flawless 500+ LOC" code they keep writing.

If shrug-guy is anything like me, he sat there blurting out half-baked ideas and then shooting them down all in his internal monologue, instead of out loud.

For me, I sometimes feel like I'm an old school chess engine, exploring as many possible moves/ideas as I can - as many steps into the future as time allows. Constantly evaluating them based on some known-simplified fitness function usually involving pattern recognition from past experience in similar problems. Eventually I arrive at a place where I'm either confident I know a reasonable way forward (and why some of the obvious ways forward are unlikely to be ideal) - or I've scatter-gun searched all of the quickly available ideas and discovered I have no idea if some of them are good or bad, and I need to do much deeper research and investigation of the problem.

From the outside, that'd look identical to "he could go completely silent, just staring straight ahead with his fingers to his lips"

Sure, but isn't there still an advantage to this? If two people are silently doing this then they don't influence one another as much, helping find a wider range of solutions as well as identify issues with certain solutions that the other might not have seen.

Instead if you're blurting out your thinking more in unison. Naturally you'll stray less, exploring less.

Of course you want collaboration but I find the magic is going back and forth between alone and together. I even find this helpful when just working by myself, stepping away from the problem or context switching, allowing the problem to distill.

I had the same thoughts reading this. I think there’s an optimal blend of blurters and thinkers, one isn’t better than the other. I find that I do both, it just kind of depends on my comfort with the subject matter.

Another way to think of it is if you're blurting out your thinking you're reducing redundant work and perhaps inspiring the other person to think of additional solutions that are offshoots of what you're dismissing. I see merits to both ways of looking at this.

Yeah I agree but that's why I think there's a balance. But the context here is the more nervous blurting which I think is going too much in the other direction. We should be comfortable with some silence and thinking.

But everyone has their own personal preferences. Which is perfectly fine too. But I think it's worth mentioning that, as illustrated by the comment, it's typically more acceptable to blurt than think silently. And there's the bias that blurting makes it harder to think silently by thinking silently doesn't make blurting harder (the uncomfortable with some silence part is not healthy imo. Of course long silence is a different issue but we're talking 30-60s)

Probably true for many. When thinking about hard problems I'm usually not thinking in language, at least not the kind we speak between us humans, so it can be incredibly distracting if I have to "translate" back and forth while both thinking and communicating.

> I'll be honest, this is the big reason I don't get all the hype around coding agents. I do find them useful but typing isn't the bottleneck. Not even close. Plus, while typing is when I'm doing my best debugging and best simplifying.

As you sort of point out between the lines, it depends on what you work on. I had an AI agent rewrite some ancient (and terrible code) which had stopped working because the v1 of an api on v3 was sunset. It took around 5 minutes out of my day, and most of those were having two people explaining to me where the code was and what they thought had happened to make it break. It would've like taken me a full day to fix without AI because I would have needed to understand things first, and because it was quite a lot of code.

The result wasn't very good, but it was better than what was before, and since that had run for years without anyone tuching it, well... good enough. Heck, it might've taken me more than a day because I doubt I would have left it at "wasn't very good".

Aside from this anecdote I think AI writes a good 80% of my code these days. I'm not sure I buy the whole "bottleneck or not" discussion around typing. I think for a lot of people, myself included, AI does 10x part of the process of writing software. Where it doesn't help is when you need to do computer science, and as you point out, those parts AI don't speed up. I sometimes still use AI for computer science parts, but in those situations the AI will be a rubber duck because I tend to think by talking out my own ideas, and at least the AI duck pretends to answer. Even if the answer is more useless than what the actual rubber duck comes up with, which it usually is, it's more immersive for me.

  > because I doubt I would have left it at "wasn't very good".

Which creates an interesting question. Would that extra time be worth it because your version would break less, do more, and/or last longer?

Don't get me wrong, we all write sloppy code and often not our best. It's one of the difficulties of being an engineer, deciding what exactly is good enough.

> I'll be honest, this is the big reason I don't get all the hype around coding agents. I do find them useful but typing isn't the bottleneck. Not even close.

It's always possible to go slower for practically no cost. -- So, any benefit from going slower is obtainable for everyone.

Whereas, typing faster takes discipline and effort. There are diminishing benefits to putting in more effort to type faster.

The main benefit isn't so much "more output" so much as "reduced latency". e.g. It takes less time to type out queries that help you gather information.

  > typing faster takes discipline and effort.

  >> ***typing isn't the bottleneck***

I believe you read too fast

  > The main benefit isn't so much "more output" so much as "reduced latency". e.g. It takes less time to type out queries that help you gather information.

You've missed the critical part of what I was saying.

While typing I'm doing other things in parallel.

Those other things are things that require you to scrutinize and look at each character. I think the vacuum analogy from the OP is quite apt here. It's much harder to debug other people's code and more so an LLMs.

I do this a lot as well. I have a bad habit of just freezing physically when I start to think. Since my work is conducted over video, my colleagues will often think I dropped off the call XD

Personally I find it a bad habit of mine, I have no idea how people gracefully take time to think. Whenever I do say something like “hold on, let me just think for a moment” my brain completely freezes and I get no thinking done.

I worked with a guy that operated like this, a technical expert in a very specialized domain. You'd ask him a question - he'd just stare at you in silence for 60s or more, and then give a very well-considered answer that you couldn't get from anyone else in the world.

His manager was used to this and sort of enjoyed the mystique of this monk-like expert that he was responsible for.

I once was in a meeting where we had to talk to the great expert on the phone. Let's just say his name was Otto. Of course, he worked remote quite often, in the days before Zoom. His manager calls him and puts the phone on speakerphone for the room to hear.

Manager: Otto, we need your input on <long technical problem>.

<60 seconds of silence>

Otto: Yes, I think that might work, but you'll run into <other problems>.

Manager: Well, yes, we've considered that, but <explanation>

A few minutes of reasonably normal conversation ensues between the assembled group and Otto. Then:

Manager: Well, I think then that this is a pretty good solution, as long as Otto agrees.

Manager looks around the table, clearly waiting for Otto's concurrence

<60 seconds of silence>

<90 seconds of silence>

<120 seconds of silence>

People are starting to get uncomfortable. The manager makes a reassuring face. This is normal for those of us that work closely with the great expert, do not lose faith.

<240 seconds of silence>

Manager briefly lets slip a concerned look, then quickly hides it

<360 seconds of silence>

Manager: Um, Otto?

Otto: Oh, I thought I was waiting for you.

I think it gets at something we've collectively trained ourselves out of: tolerating silence while thinking