Hacker News Reader

Comment by abhaynayar | Hacker News Reader

Something I realized with the new LLM tools is that learning how to type plain English words fast i.e. without capitalization or punctuation, and even typos is not that big of a problem anymore. And so it follows that code-specific typing is even less important if you can just type in normal words fast and then just check it's output. Although yes for stuff this small i.e. super small terminal commands I feel there does still exist an advantage.

Also, another observation I've had is sometimes I just don't feel like speaking, so voice as input to LLMs is really not an ALL time replacement in my personal opinion. In fact, I find myself preferring to type fast and with typos in lowercase much more than anything else.

View on HN

I'm not sure. And to be honest, typing speed was never that big a deal. By the time I got out of college a few decades ago I was in the 110-120wpm range.

However as I progressed in my career as a developer what I found is that both my "working" WPM and then my "normal" WPM dropped over time. Once I moved out of truly junior, pure code grinding roles, I spent more and more time thinking, talking to people, etc than I did typing. At that point, what does it matter if I'm at 20wpm or 200?

Likewise, in day to day life, it's not like I'm sitting there typing a novel. I'm mostly clicking buttons, writing short messages, tweet,s and the like. My day to day typing speed has also decreased. I'm sure it's still up around 80-100wpm, but it's rare that I'm sitting there typing long enough to matter.

Same with LLM. Who cares if it takes me 10 seconds or 20 seconds to type in a prompt, when it's going to sit there and spin for a minute anyways?

I'm pretty sure that also people who write novels aren't held back by how fast they can type.

Probably not. It was a euphemism.

But it's a pretty good indicator of skill level. High wpm means they write a lot.

It's also helpful as a burst speed. It doesn't mean you are always cranking at 120wpm, but you can hit 120wpm when the words in your mental buffer is overloaded and you can empty that fast.

Try writing on pen and paper, you'll find that your mental buffer fills up quickly and you aren't able to hold all of your thoughts, so you have to drop some. It has its use cases, sometimes you have to think more and write less. But in general high entropy write capacity is a valuable spec to have.

To an extent, but not to that extent.

There's a significant difference between (say) 20wpm and 100wpm. -- Your comment is 150-200 words; so that's the difference between spending two or three minutes vs ten (just typing it out, not counting the time it takes to think).

If you limited your typing throughput to 10wpm, how long of a comment are you really going to reply with? Probably not a long one. -- If someone types at 160 wpm, are they going to type a better comment than someone typing at 80 wpm? Maybe? Maybe not? Probably not twice as long / twice as good.

I still think "typing speed is about latency, not throughput" is the key perspective. (Followed by diminishing returns. I think around 80wpm is fine). -- There are some cases where I'm doing the activity so infrequently that the cost of improving outweighs any benefit I'll see.

There is a thing about getting to 120 though. Like, being able to connect at that speed with everything working perfectly in sync.

As the GP, I've been there. And my point was that it really hasn't been useful in my career. To the extent that my wpm has dropped over time.

I’m seeing a lot of people that having that train of thought. I think that is a fallacy. I can understand that some LLM execution can be faster, but definitely not all. Agents need to explore, grep and get back up to speed to get context, if you have a good mental model, you can do changes or adaptions in <7s with a bunch of shortcuts or commands.

One could argue to find the <7s commands in your head takes you more mental power than to just wish it in to the LLM and whilst its running you can wish something else in another session, but I’m thinking that the cost of context is more important than the actual execution time for your task. Every extra task gets more expensive. It’s not a ressource where you have a limit, right from the 2nd task the cognitive load increases.

Therefore I’m thinking one task that can be done in one context window without switching is worth a load in these days of constant distraction.

I get your point but I do prefer delegating almost all of the things to the LLM.

A lot of times human commands are prone to errors / edge cases as well. Example a simple git pull command usually would take < 7 seconds, but then LLM can take care of resolving merge conflicts etc as well.

A simple git push is usually instant but that comes with an overload of some un intended changes being pushed, which LLMs take care of removing themselves.

When LLM is doing its thing, we can spend the same time in writing the next prompt.

> A simple git push is usually instant but that comes with an overload of some un intended changes being pushed, which LLMs take care of removing themselves.

In my experience it can often be the opposite - AI would commit a lot of slop comments and sometimes unnecessary stuff, whereas if you can review things in GitKraken or another program with diffs, things are closer to what you want. Writing commit messages and PR descriptions (maybe change summaries, the intro less so) is easily outsourced to the LLMs though.

Reply on news.ycombinator.com