>You may soon see that coworker with the weird monolith style trackball mouse rocking this strange peripheral and claiming he’s upped his efficiency in ways you can’t possibly imagine.
Since coding is 20% sitting in meetings, 50% reading code, 10% drawing on whiteboards or sticky notes, 15% drinking coffee, 4.5% fighting impostor syndrome and 0.5% actual typing, I think I am quite safe with my good 'ol QWERTY.
I'm having difficulties finding the source right now, but I remember reading a story about a sysadmin that was berated for his typing speed and the story ended with him replying "I don't get paid to type code fast, I get paid to press enter very, very slowly."
playing the devil's advocate, typing speed is important for these reasons:
1. It allows for minimal disruption to thinking process, close to 90% of the time even when coding is not actively typing, but when typing is subconscious and fast it removes the potential of where it interrupts the thinking process.
2. While this has no bearing on individual case (It would be Bayesian, some people consider that to be heretic), but a software engineer who does not type well have a greater chance of having had less practice.
> It allows for minimal disruption to thinking process
Willing to dive into this a bit more? My personal experience is different so I figure this is a chance to learn something new. The subjective character of typing experience for me is like riding a bike, driving a car, walking, or speaking. That is to say that unless I'm mountain biking, off-roading, on a balance beam, or trying to say a tongue twister, for the most part I'm unaware of the intention-execution-results loop, and the intention-results loop is all that consciously exists. My paltry 50-60wpm doesn't feel like an impediment to putting thoughts into text, but maybe others feel differently.
> My paltry 50-60wpm doesn't feel like an impediment to putting thoughts into text, but maybe others feel differently.
That may be high enough that you don't have the impediment, but when you work with someone who types down around 10-15 WPM... You can definitely tell they're spending a lot of brainpower on hunt-and-peck instead of the problem they're actually trying to solve.
Basically there's diminishing returns on increasing WPM and you may be at or past the tipping point. I expect it'll be different not just for different people, but also for whatever they're currently working on.
The thing is, when a programmers starts to generate input, the problem is already solved, he is merely putting the solution into whatever representation the tools demand.
I am not defending 10-15 WPM here ofc. just statingt that the majority of work happens before we start typing in code, and after we typed it.
It's a type-think-type-think cycle (or type-test-think-type-...) and the more time and effort you spend on the typing part, the more it distracts you from the rest. Typing for a few minutes isn't any better than compiling for a few minutes before you can test. It just interrupts the more interesting work.
That's due to unfamiliarity with the input device. And if they end up having to use it several hours per day, this slowness will go away in a few weeks.
For me typing is the frustrating part, because when I know what I want the code to look like, having to type it in is just an annoying obstacle I have to go through before I can move on to the next thing, whether that's testing or thinking about the next bit of code or whatever. So yes, I do find it to be a distraction and frustration. Kinda like having to type a long random password and then dig out your phone and enter a 2FA code and then navigate a hierarchy of whatever before you can get to do the thing you're really after.
I always wish I could type faster and with less effort, or -- better yet -- just wish the code into the shape I want. ~100wpm touchtypist here.
I frequently encounter typing speed as a disruption to my thinking process while developing my personal projects. My personal projects are developed interactively in the REPL - I'll make a few small changes to an existing piece of code, re-run it, and observe the difference in behavior before repeating. In this process, I usually conceptualize code significantly faster (2x-5x) faster than I'm able to type it, which translates to wasted time, where I know what code I want to write, but haven't written it.
Now, from a philosophical point of view, I believe that it's possible to have programming tools that allow a 60wpm user to program at the speed of a 120wpm user without those tools (e.g. autocomplete allows you to type 10-character identifiers with significantly fewer keystrokes) - I just haven't finished building them. That is, I believe that having a slow typing speed shouldn't impede programmers, but does with our current tooling.
It allows for minimal disruption to thinking process, close to 90% of the time even when coding is not actively typing, but when typing is subconscious and fast it removes the potential of where it interrupts the thinking process.
This arguments wholly arbitrary. Maybe someone who types slowly will put a lot of thought into each word and create fewer bugs. Who knows? Why argue random claims you pull out of the air?
Very early in my career, there was someone on my team that did hunt and peck. It was painfully slow, and definitely impacted their productivity. It was honestly painful to collaborate with with them because of this.
> 1. It allows for minimal disruption to thinking process, close to 90% of the time even when coding is not actively typing, but when typing is subconscious and fast it removes the potential of where it interrupts the thinking process.
I agree, and even wrote an article about that a few years ago. :-)
Autocomplete makes programming very different from normal typing. I don't need to type fast, I use my keyboard to trigger lists of options that I pick from. Modern programming is a contemplative interaction with the IDE/language server, normal typing should only come into play when you write comments.
Autocomplete is just a very small subset of modal editing paradigm, the entire editing process, both typing and key shortcuts (i.e. picking options) should be treated as the same.
But in this case WPM or similar are completely useless measures. With the right tooling one can pump out an extreme amount of code in a few minutes. It totally depends on the programming language and the available tooling, templates etc. You don't need quick fingers for programming. Depending on the verbosity of the programming language and if it is statically typed you are much faster in pumping out characters.
Very true for sysadmin. I can type pretty quick, but I developed a habit that when doing risky things I do a "air enter" -- I tap above the enter key, stop and think "am I sure?", before actually pressing enter. It's served me well.
When I'm about to run certain commands - any dd, most database modifications, rm, etc... - I physically lift my hands up away from the keyboard while I reread the command 2-3 times before allowing myself to lower my hands and hit enter. I think the physical cue helps the mental side.
I think things like this are not “everyone must use this new better way of typing,” but more “hey there may be a better way of doing this task.”
I am always surprised, though at this point I shouldn’t be, that there is always pushback against any attempts at improving the status quo when it comes to typing speeds on HN - as though the creator is attacking all of us with lower typing speeds personally…
From another perspective: sure you might speed up only 0.5% of your workday - but how is that a bad thing?
Repetitive stress injuries aside, even if you only spend an hour a week typing (I suspect it’s honestly more) then if you end up increasing your typing speed by double you’re still saving yourself 25 hours a year. Assuming my a career of 35 years that’s 875 hours and you increase your time fighting imposter syndrome by 0.25%.
Scale up as appropriate for how much time you actually spend typing.
The pushback is not against the improvements themselves, but rather at the claims of what the improvements solve, and the criticisms of people who fall below some threshold at some specific task, with dubious claims about the effect on their overall performance (without actually measuring the overall performance).
It seems to be a common theme among tech people to unfairly extrapolate small, vaguely related things to judge big things, even to the point of rejecting job candidates or firing employees over one of them and then crowing about it on social media (for example the "don't hire losers" post a few days ago).
If someone doesn't like how I work, then don't watch me work. I get paid for the fruits of my work, not how I get there.
> …the criticisms of people who fall below some threshold at some specific task, with dubious claims about the effect on their overall performance
It’s unclear to me where this criticism is coming from.
> If someone doesn't like how I work, then don't watch me work. I get paid for the fruits of my work, not how I get there.
Similarly it’s unclear to me where there is anything about anyone measuring how you get your work done. That seems unrelated to the article at hand that only passingly mentions any work context (only of a co-worker making a claim about their own effectiveness) while spending most of the article on games and typing competitions.
> I am always surprised, though at this point I shouldn’t be, that there is always pushback against any attempts at improving the status quo when it comes to typing speeds on HN - as though the creator is attacking all of us with lower typing speeds personally…
I don't think it's a general attack because people are personally offended; most of the criticism right now seems to be that the headline claim is materially untrue. Rejecting snake oil is healthy and reasonable even if there's value to be found.
Edit: Perhaps more succinctly, people aren't pushing back against improvements, they're pushing back on deceptive claims.
Ah yeah, that's fair. I could defend that as cost/benefit analysis, but I'm with you - let's push the limits and worry about utility evaluation later! (I literally have a chording keyboard on my desk right now, so I'm quite serious when I say I want to push the limits:])
What hardware/software are you using? I’ve looked into it a few times, but the cost benefit hasn’t been there for me for doing the research without knowing anything about it yet.
Do you code with it as well, or is it primarily chat/browsing/etc?
I own a https://www.gboards.ca/product/ginni , largely because it was the smallest/cheapest option to dip my toes in:) I don't do much of anything in it right now, because I'm still learning to use it (currently at the "I have to think about each letter" stage), so unfortunately I can't say yet. I expect to end up coding with it, likely with a custom dictionary, but we'll see how it develops.
I might have read too much into your use of the term “safe” as being indicative that there was some danger or concern.
I agree with this sentiment:
> I said I spend not a lot of time typing. Therefore, a device that is aimed at improving typing speed, has a low impact on my productivity.
Though, setting aside that efficiency =/= effectiveness/productivity, I think the spirit of the article is that if a coworker is typing a lot, that may claim that their efficiency has increased greatly, not that every single person will see equal improvements.
FWIW: this is being typed with two thumbs on an iPhone because that’s as efficient as _I_ need to be right now ;)
Medical transcriptionists once used a specialized keyboard to quickly describe spoken terminology. "Shorthand" has existed for a while and I imagine is a dying art at this point [1].
I think most cases where you needed actual really fast typing were covered long ago and the number of careers or situations where a person needed it have been declining for a long time.
My point is more of it being not a bad thing to improve on.
Most of the cases where you needed actual really fast travel have been covered for a long time and the number of careers or situations where a person need to travel fast have been declining for a long time, but I think we can all agree faster travel times are better.
Side note: stenography and chorded words with something like Plover (similar to the above) is where really fast typing usually comes into play for. I have not looked into any of the above because the pain of changing my habits hasn’t been worth the benefits to me yet.
I’ve considered it when I had to do interview transcripts, but ultimately I didn’t want to make the investment. I hope future generations are able to learn on something more designed for contemporary use than QWERTY and classic keyboards - I know my wrists have thanked me for moving to a split keyboard for the ergonomics alone.
Even if you're not wrong, this is a disappointing attitude. There are so many reasons to want to improve user interfaces - reducing RSI, reducing error rates, increasing speed, etc. I love seeing new designs where people are trying to improve the state of the art even if I don't plan to use this immediately .
Most of the advantage in alternative layouts is improved comfort and less injury-prone finger movements. Faster typing speed is basically a nice side effect.
The act of coding itself is also not a constant flow of characters from fingers to screen. You stop to take a moment, go back, correct something, next line, pause to think, type out a line etc. I have never used a device like this but I'm pretty sure I type at roughly the speed I think, at least when I'm writing programs. General note taking, eg. jotting down ideas, might be different, where I do find myself thinking faster than I type.
I had the opportunity to work with a guy who studied CS back in the day when punch cards were still used. Sadly he left into well deserved retirement a few years later.
He typed slowly, not hunt&peck, but really slow compared to the other engineers.
Didn't matter. The guy was a wizard. Ever seen someone implement radix sort in assembly or debugging a microservice using nothing but nc and echo? Without looking up ANYTHING either in a book or online? That kind of guy.
Working with him, I sometimes felt like Mickey Mouse in that scene of "Fantasia: The Sorcerers Apprentice", when the Master came back, surveying the flood, and fixing everyting in seconds just by waving his hands imperiously :D
It's a trade-off between spending some time thinking about what should be written, and then typing a little - or spending all the time typing, typing, typing, and rewriting.
I don't think I've ever been in a job where I was limited by typing speed.
Then you should definitely consider switching keyboard layouts to reduce RSI. I did, last week. Going from 80wpm to 30 wpm is definitely a job impediment (in the short term). So many things are keyboard driven:
- communicating with peers over slack
- writing code / git commands
- writing email, comments in HN, documentation, etc.
Yes. I've love to be able to type fast enough to take notes so that I don't have to try to read my chicken scratch handwriting and figure out what the hell I was trying to write, especially when referring to notes where I don't have any recollection of what the contents were.
I never thought about RSI, but also I've started having pain/weakness in my right hand last month (that, thankfully, has mostly gone away). The doc said it was tendenitis.
I feel like excessive swipe-typing with my thumb may have contributed more than typing to that; but I also play keyboards and it was scary for a second to have that affected.
I got myself a vertical mouse; will consider using another layout (which one do you use?). I do type at 75-80WPM (including time to fixe typos), can that really cause RSI?
I don't know if I'll be able to pull off even 20wpm with another layout, but looks like it's the next step. Thanks for suggesting it!
In my experience, typing early and rapidly iterating and modifying, i.e. thinking on the page, is FAR more effective than spending tons of time in your own head trying to solve the problem elegantly before you ever type anything.
The exception to this might be spending time thinking about the very high level structure you want, since the initial structure you start with can lock you into pattern of trying to solve the problem that might not be the most effective.
There is some threshold where it absolutely impacts productivity. If you haven't seen this in action, you're lucky, I've ran into more than one Engineer who is otherwise very smart but somehow never learned to type.
For sure. If you're a hunt-and-peck typer, it makes meetings where we're waiting for someone to finish typing unbearable. If you're even somewhat competent at typing, then I don't think it's a big pain point.
For some reason I don’t like any of this automation tools. I find VSCode unbearable even without copilot. Too many things happen when I type. I prefer linting and that’s about all I want to write my code peacefully. I use vim in iTerm and it’s all I ever need. Jump off to Pycharm to debug if needed.
Oh boy..., I guess there are people who find this useful. I respect "To each their own" and "You do you".
I also like using Sublime Text with vim keymap. I prefer the low latency of editors over features of big IDEs. Sometimes, I do use PyCharm or CLion for debugging since that experience in vim sucks. GDB is terrible in CLI.
Since coding is 20% sitting in meetings, 50% reading code, 10% drawing on whiteboards or sticky notes, 15% drinking coffee, 4.5% fighting impostor syndrome and 0.5% actual typing, I think I am quite safe with my good 'ol QWERTY.