Hacker News Reader

Comment by onion2k | Hacker News Reader

To practice quicker typing.

This specific one is something that baffles me. Development is all about thinking. You need to understand what you're building well in order to have any chance of making something that works and is bug-free. You need to spend time thinking of names that will make sense in 6 months. You need to organise things well. The actual act of typing things in is a tiny part of the whole process. If typing faster is improving your dev productivity then either you typed really slowly before, or you're not spending enough time thinking about what you're doing. I really don't understand why speed of text input is considered a useful metric on absolutely any level whatsoever. And I say that as someone who types quite fast and who knows their IDE well enough not to be reaching for a mouse every so often.

View on HN

As someone who types quite fast, if you haven't watched someone who types 20-30 wpm, then you probably haven't seen what a hindrance it can be.

Yes, thinking is more important than typing, but after you've had a thought, you need to see it "in writing" and execute it to evaluate it and see if it was a good thought after all.

Fast typists can go through many more iterations of that process in the same amount of time.

It has often been remarked by writers that writing is thinking. That you don't even know what you think until you write it. There is something very fundamental to the thought process that comes from actually recording the thoughts and seeing them "in print".

A good typist (which I'll call 100 WPM, a point beyond which I diminishing returns make further improvement less important) can do the writing-is-thinking process 4x more in the same amount of clock time as a 25 WPM typist.

> but after you've had a thought, you need to see it "in writing" and execute it to evaluate it and see if it was a good thought after all.

I don't know that that is the only way. For instance, when I have thoughts, I often:

- repeat them in my head from various angles, while pacing around the room

- jot down some key words as anchors

- draw a diagram or two; sometimes to visualize relationships, sometimes to map out individual elements of the thought

- etc.

Then, when I start writing, even then I don't start with full sentences. I think about overall organization so might outline and iterate on that a few times so that I can refine. Only then do I start writing full sentences and edit, edit, etc.

"A good typist (which I'll call 100 WPM, a point beyond which I diminishing returns make further improvement less important) can do the writing-is-thinking process 4x more in the same amount of clock time as a 25 WPM typist."

...if they spend all that type typing.

You see, if you type faster that you think that means that you're typing out things nobody's thought about — which is what it means to be a genius.

I've used to work with a guy who had... dyslexia, I think? Dysgraphia? Basically, he simply couldn't type without typos, although he seemed to do fine with reading. Well, he relied heavily on copy-pasting code snippets around, those sometimes being as small as a single keyword. Quite a sight to see, to be fair.

My point is, being able to type 100 WPM without typos is surely nice, and so is e.g. having good vision (or vision at all, for that matter), but it's not strictly necessary and can be worked around. Although, of course, if you can come into possession of those qualities reasonably cheaply then sure, go on and obtain them.

Absolutely.

Josh W Comeau has a fabulous article about hands-free coding that I think every developer should read: https://www.joshwcomeau.com/blog/hands-free-coding/

Everyone has a different optimum for sure.

I type with 2 or 3 fingers and I usually have to look at my keyboard... but it doesn't slow my code, it's Intellisense (Visual Studio auto complete) that does the typing for me.

Typing well and being fast with the tools changes the code you end up with, not when you end up with the code. It drives the “activation energy” for trying a different approach, or fixing some structural flaw that’s on the bubble of being “good enough”.

People who can tear down and rebuild a piece of software quickly and fearlessly just try more things, just like mechanics who can rebuild an engine have usually have higher performance cars than the rest of us.

It is obviously not a substitute for thinking deeply, but it can be an aid to thinking deeply.

And outside of some rarified hyper-elite of Thompsons and Carmacks or something, thinking deeply is not a substitute for trying a lot of things.

Now time is finite, and learning to type properly or mastering your tools might not be the highest ROI at a given time, but this meme that “I can type faster than I think so I’m not bounded by typing” (which may not be your view, but you’ll agree is often said) is misleading bollocks that young hackers hear and often heed: which is setting them up to settle for less than their potential.

Maybe just different styles and approaches and typing speed is a easy, obviously, and measurable metric to focus on but this sounds like brute force problem solving. I tend to prefer to build a mental model/plan such that once I start writing the first draft is probably within 90% of the final, some iteration taking place on that last 10%. But I don’t write and delete large swaths of code. This sounds like real time refactoring/lack of planning and completely erases any gain I’d get from being able to type twice as fast (I’m probably middle/average speed).

To use your mechanic analogy, the difference is the mechanic is confident in his abilities to tinker. The confidence is built on having a plan and some background knowledge. When he disassembles a carburetor he already knows the performance tweaks he’s going to make and how he’ll reassemble it. He doesn’t just start taking things apart with no plan, or start playing swapping on and off a handful of carburetors to see which performs best. He probably did his research and chose the carburetor/mod that was appropriate. It’s actually even more important with the tangible world because he has to plan and acquire the parts and tools before getting started or risk having a bricked vehicle for some period of time.

Non-mechanics know better than to tinker at all because they’ll likely break something they can’t figure out how to fix. So they might do low risk things like put high performance fluids in, or air filters, but they’ll never match up to the guys that have upgraded the mechanical systems.

Sometimes times the only way to know which way is best is to try all the options.

While true depending what’s meant by the “best” way. I feel like I can mostly do this mentally without typing it out. I utilize my experience instead of a try and see approach. I know what not to try.

Trying many things is usually far beyond an acceptable threshold of diminishing return. Premature optimization and such.

That’s not to say I am unfaltering, sometimes things don’t work out and I need to rethink it. But I don’t approach a problem with this approach of trying a bunch of stuff.

As a junior developer I once had a pair programming session with a more senior developer who was baffled that I don't rely on VS Code features like replace all, I don't copy-paste code from other sections of the application that roughly resemble the feature I'm building, etc.

So, while development is about thinking, delivery speed is always a factor, and they don't care if that speed comes from quick thinking, quick typing, quick replace all or quick copy-pasting.

But copy & pasting or using IDE features is more about consistency than speed. I.e. making sure you really did replace _all_

When someone looks at the keyboard they're not thinking about the problem, they're thinking about typing. They're engaging parts of their brain to do so that touch typists do not.

This means touch typists can think WHILE TYPING, giving them a distinct advantage.

I guess one aspect here - and it will depend on the individual obviously - is thinking through solutions by coding them. As opposed to doodling or whiteboarding, for instance.

If you can do that faster, then perhaps you really can get gains. The typing speed is about iterating quicker to the best solution with draft code, not about literal speed of typing the best solution's code.

> The actual act of typing things in is a tiny* part of the whole process.*

A tiny part of cutting actual code, and a big part of communicating and documenting that code to others. Even for a solo developer, you will always be communicating with your future self unless you are blessed with the kind of eidetic memory that can recall mindstates.

Software engineering today is both an intensely individualized experience (flow state is still A Thing for example) and a team sport heavily reliant upon lots of communicating between people in many different roles. Written communication is a big lever that propels you beyond verbal reach. I frequently see software developers who type slower than an average range of 40-60 wpm produce barely intelligible documentation, actively shirk ticket-based processes that involve much typing, and rarely if ever present their ideas to others in written form.

This is usually a hindrance to their careers. I keep hoping the parsimony of typing speed would act as a forcing function and be made up by concise, elegant written communication but alas, I have yet to run across such an example.

As an avid writer/thinker I do tend to write a lot of software on paper first.

But not all! If I am making an arcade game I might jot down the basic idea at most. I spend the majority of my time in a rapid-prototyping mode. I don’t write good code with all of my usual rigour; I write the first thing that could possibly work with the least amount of code possible. In this kind of prototyping mode I am constantly evaluating something you can’t really specify on paper: does it feel good, is it fun?

However I generally throw away that kind of code once I am done with it and rewrite it using my usual methods.

It is useful to practice “coding fast” for that reason. I had spent a good year or so practicing it as a skill. It can be useful. And being able to type fast can help reduce those iteration cycles. The goal is to get from idea to something that works and resembles the idea as quickly as possible.

The only argument why fast typing could be important that comes to my mind is that you're less distracted (from thinking) if you can type fast without looking at your keyboard.

If you're payed by lines of code, than it's a different story, of course ;-)

For complex programs, you won't be able to keep all relevant aspects in short term memory. So the only option is to quickly write down everything.

I see fast typing not as a programming advantage, but as a thinking advantage.

Good engineers write not just code, but good documentation and technical write-ups explaining decisions and the pros/cons of different choices (RFCs).

If your typing skills are sub-par, that’s just one more stumbling block.

Reply on news.ycombinator.com