> It’s difficult to type and think at the same time, so any time spent writing is a pause in thoughts, which can derail the flow.
I'm a competitive typist. I'm also a programmer. The main positive that I see is that typing no longer requires thought. I think of the code I want to write and it's transcripted onto the computer.
I would say that it's more advantageous to type _accurately_ than quickly. Typing competitions generally require 100% accuracy, which gives me a great amount of belief that what I'm typing is correct, without having to look at it / check it over and get side tracked from the code itself.
> The main positive that I see is that typing no longer requires thought.
I can't emphasise this enough.
Whenever I see even experienced programmers searching for the right keys or trying to correct their mistakes I just feel sad for all the lost productivity. It's also about not using the subconscious muscle memory which means a good chunk of conscious mental bandwidth is getting wasted on repeated task that could otherwise have been used for programming/creativity etc.,
By a sequence of happy coincidences I got trained as a touch typist before I could go anywhere near a computer. On a real mechanical typewriter. So by the time I was learning programming I was focused solely on learning it as opposed to fighting the keyboard. The benefit of touch-typing can't be emphasised enough, if it were up to me I'd make touch typing a mandatory skill training course.
I learned to touch type in 1986 on a manual typewriter in secondary school. I knew I was going to work with computers and figured touch typing would be a worthwhile skill. I was the only male in the class and copped shit from my peers for taking the subject as everyone else perceived it as a class for women looking to go into secretarial work. To this day I still think it is the best thing I learned at school and it absolutely amazes me that touch typing is no longer taught in school in this age of ubiquitous computing.
One of the best programmers I ever worked with was hunt and peck. I told him learning to type was a godsend. He did not care and continued to crank out tons of code. It was just painful to watch someone that experienced having to search around for keys. He was fine with it though...
I have the same mechanical background as you. It took me years to stop absolutely blasting the keys when typing though. It did speed up my word count doing that too.
For me having to stop and look for a key is a jarring thing. Usually because every manufacture wants their 'own touch' on the keyboard. Laptops being the biggest offender of this.
yep, it's why I've always been of the opinion those who say they don't need to do it because programming is more about thought than typing don't fully grok what it is about touch typing that makes it so beneficial to developers.
It's kind of a trite thing to say, but one of the most valuable classes I took in HS was typing. I won't say it was _the_ most valuable, there were plenty of other valuable classes, but typing was one of those classes that was considered a lazy elective but definitely should have been required (imo) and I consider myself lucky to have taken it.
I say programming is more about thought than typing and I stand by it.
The thing is, the level of typing you need to achieve to get to the point where typing is no longer the bottleneck in your flow is such a low bar. I have not worked with a single developer in my career where their ability to type has been a bottleneck for their work. I know anecdotes aren’t evidence.
Don’t get me wrong, I believe being a strong typist has a ton of benefits for a developer. It just seems like a baseline skill at a certain point for anyone in a software related field.
The funny thing is it's not at all hard to learn/develop. It's just about following typing lessons curriculum for 3-4 months ~40 mins/day. Even if you don't like it very much think of it as a one time investment in grunt work and get it out of the way and you are set for life time of repeating the benefits.
I don't. I spend a lot more time thinking, debugging, and designing software than I do typing it. I am a decently fast touch typist (about 90WPM), but I don't think it makes much difference in my day-to-day ability to output software.
Before I was able to get a job with computers, I had jobs as typists. I had one job typing (on paper with a typewriter) trust documents for banks. You had to produce the entire page without any errors, no whiteout or the ink-lifting correction stuff.
It was more discipline than other typing jobs, but paid off. I also never think about typing unless I'm having to recreate emacs or vi commands on a weird touch-screen keyboard or that time I learned Dvorak for a while.
As someone who has 100% accuracy, how do you avoid the kind of typos that result from incorrect finger synchronization, like 'teh'?
These synchronization errors have been the main source of my typos, unlike the kind of typo caused by individual finger imprecision, like accidentally hitting 'p' when meaning to type 'o'.
It occurs to me that because we use both hands, the way we type is inherently 'asynchronous'. For example, when trying to type('the'), the individual 'function calls', typechar('t'), typechar('h'), typechar('e') may be initiated (i.e. fingers begin moving towards their target keys) in that order, but there's no guarantee they are terminated (i.e. fingers hitting their target keys) in that order, because typechar('h') is performed with the right hand whereas typechar('e') is performed with left, so typechar('h') cannot "block" on typechar('e').
But if we were to make each typechar action wait for the previous one, it would be unacceptably slow as well. So it seems the only solution is to invest time in developing just the right muscle memory where everything is timed perfectly.
I‘ve been playing the guitar for very long, and it occurred to me that physical health correlates with my ability to synchronize both hands. Having a steady hand helps tremendously with that IME. I noticed e.g. when I quit drinking (even occasionally) that I got way better at this. While typing, I also started stumbling way less over complicated words at that time.
Practice did help too, but tbh, I practiced a _lot_ and it was frustrating seeing other players be so much more accurate than me while I had likely practiced just as much. Being healthy is just a competitive advantage.
It is sort of like learning a piano. You learn cords. You break words into chunks and work out from there. Now after this whole thread I am conscious of it (grr). Also there are two little nubs on most keyboards on the f and j keys to get you into position quickly. Feel for the nubs and type away. Miss them and it is jumble city.
Yes! The app that I used for learning touch-typing even had a metronome built in, and it encouraged you in the instructions to enable it when practicing.
This is something that's bitten me as I've gotten older. I used to be extremely accurate, but keep making this mistake... most often with space actually. So I end up writing 'th ebird' instead of 'the bird', for example. Also interested to hear OPs secret here.
Maybe not putting pressure on this muscle memory to perform accurately, so a lack of intentional practice. We're not really punished for typos with spellcheck and IDEs picking up a lot of the heavy lifting, so there isn't a lot of mental pressure to perform well here. Or it's simply aging related decline. It may even be a waste of time to worry much about it.
Speaking only for myself, it helps to think of those keys as a unit: as 'the', not 't' (then) 'h' (then) 'e'. If they're a single sequence of movements that I can turn over to my unconscious brain to execute, then my accuracy goes way up. Typing speed then is about coding more and more words into that "reflex space".
I don't know, exactly, but I think I've got most of the common words and key-combinations up to about five characters into that state, and a few longer sequences as well. (I have one long and challenging password I type frequently which I cannot accurately type letter-by-letter, but do just fine when I stop thinking about letters at all.)
If I wanted to type faster (I do ~80wpm on online typing tests) I'd practice more sequences, but I can't seem to think any faster than that when I'm doing moderately complex work. Typing latency doesn't hold me back; brain latency does.
Anyway, that's how I've developed that muscle-memory that you mention.
It works well enough for German as well, the letter frequencies aren't that different. (You just have to make some arrangements for the Umlaute etc, but they are in awkward spots on the German QWERTZ layout as well.)
I think the NEO and NEO2 layouts were designed with a variety of languages in mind.
Yeah, if the system I'm using has excessive latency (more of a 90s problem than today) precision means even when I do mistype, I'm "feeling" it and backspacing, not seeing them (since they haven't echoed yet.)
It's definitely about getting to the point where you're not thinking about typing, you're thinking about words/sentences/lines of code (or higher.)
I particularly noticed this when going from perl to python - in perl you were typing fewer characters, in python you could use more mainline english typing and not care that you were using more keystrokes...
> if the system I'm using has excessive latency (more of a 90s problem than today) precision means even when I do mistype, I'm "feeling" it and backspacing, not seeing them (since they haven't echoed yet.)
Perhaps I'm just overly sensitive but if the input latency from keypress to echoing is consciously perceptible then I consider that already unusably slow. I can't imagine using a setup like that regularly. Special case being something like a slow SSH connection, where I do have to just "feel" it and proactively correct mistakes, but I fortunately don't regularly have to connect to servers more than about 200 mi away.
yeah, I mean, when you get a certain adeptness at typing, you don't need to look at the keyboard OR the screen. I've answered verbal questions looking at the person, while finishing typing a sentence about something else (and used to do so pretty regularly when I worked in the office). The maximum tier is being able to backspace the correct number of characters back to the mistake.... hahah (not something I've really managed, that I can recall)
Lucky you. In my previous job I had to work many hours a day over SSH or even RDP on servers an ocean away (servers in the SF region, I worked remotely from europe).
>if the system I'm using has excessive latency (more of a 90s problem than today)
Hmm? If anything a lot of modern software is worse even from 80s latency, from extra processing going on in the editor, all the way to inefficient polling and scan rate in keyboards, USB latency, monitor refresh latency (next frame, 60fps = ~16ms wait if you're unlucky and press towards the start of a previous refresh) and so on. And that's not even accounting for extra layers like Electron.
Sure, https://danluu.com/input-lag/ has probably done the most thorough review of this. But in the 90s, remote work for me meant a lot of interactive sessions from Boston to the Bay Area, and this decade, it means "pull all of the code locally and build it locally" because terabyte SSDs are free and I still use emacs :-)
Until now I thought I was a good typist. As I tried writing a rebuttal I realized that while I don't "think" the motions, I do have to think about each letter, what case to use, the actual spelling of the word. VS just thinking the thoughts.
I did know a guy once who was one of our rockstar devs. While he was incredibly smart, I think his real superpower was how fast he typed. The words just appeared on the page. And if you were over his shoulder, his accuracy didn't decrease that much. When someone is watching me, I lose 50% accuracy.
For me typing is muscle memory. My fingers just do the thing necessary to produce words. I slow down to a crawl typing random strings of characters or new words/names because I don't actually know how to touch type I think. I just know what finger movements produce a word. It's kind of like how you don't think about how to ride a bike. It's just something you do in the same way that you don't manually breath although you could.
Typing correctly when someone is watching us more about not not letting someone's possible judgment distract you. When you are manually typing, it's just not as fast.
Heh, have you ever had someone ask you what keybinding did something, and you had to actually move your hand to recall it? (That may be more specifically a skilled-at-emacs thing, then entirely generic typing...)
At work I was given a generated password (not my login password for context) of random words with numbers replacing/inserted at random points which I quickly memorized and used several times a day.
After touch typing it through muscle memory for 6 or so months one day I misentered it a few times in a row, and I realized I had no idea what I actually had been typing the whole time (I knew the dictionary words, but the combination of numbers and where they appeared was the issue). Spent a while trying to zone out and let the muscle memory take over again but didn't work and finally gave up and asked for it to be reset.
Relatedly, I type both sides of matching pairs (parens, quotes, braces, etc.) and then left-arrow back into them to fill them with content. This is convenient to keep them balanced and because they are awkward to produce so I might as well do both in one motion.
When people see it they sometimes ask me what keyboard shortcut that was, but no, I just typed them and backed into them.
I feel this for my passwords. I can type my password without thinking about individual characters but if I need to recall it I'll have to move my hands.
Oh yeah I can agree with the muscle memory of it. I often cannot remember little nuances of syntax when instructing others what to type, but it just comes out if I’m typing it. I often have to go start typing it in a scratch pad to double check myself hah!
I also realize how much of what I use all the time is actually “ctrl-r <first few characters of commonly used one liner>” and have to go double check that when working with others. A blend of muscle memory and a search index of commands.
I tried to type your entire comment in my address bar as I was reading it to assess my own speed/process, and it's interesting that even though I didn't notice your typo
> "us" more about not...
I did type the same. So I did not really type what was in my head (my "inner voice" read "is").
Mildly chuffed to see there is someone else out there like this; I'm the exact same way. I don't touch type properly, don't use home row, but type at a pretty decent clip when it's familiar - even code. Slow down quite a bit in new territory.
What sometimes gets me though - I think one word, but type another. It's almost always the same starting letter or letters though. It's like the muscle memory kicks in, but takes the wrong fork in the road or something. Very odd.
This happens to me all the time! “Thought” instead of “though” comes up often, but I know I’ll just type in completely different words than I meant to as well. I am always reading back anything I send a minute later, just to catch the silly mistakes and correct them. It is probably annoying for the people reading the newly-sent message, when it shifts around while they are reading it. Sorry!
This! It's almost like my fingers have a mind of their own. Occasionally this actually gets in the way, for instance I want to type 'own' but my fingers decide to type 'one'. Do you have this as well?
In high school, I took two semesters of typing on typewriters. For our tests, Mrs. Beck would take the correction ribbons out. There was no point in trying to fix anything, keep going as fast as possible.
We went to a tri-county competition that used computers instead. I was the only one from my school that realized we could correct our mistakes during the competition. I sacrificed a bit of speed to get 100% accuracy and won the whole shebang. Mistakes were heavily penalized in the scoring.
> The main positive that I see is that typing no longer requires thought. I think of the code I want to write and it's transcripted onto the computer.
This. This is everything. Translating your thoughts to the computer efficiently is better than doing it quickly. It's not just for creating tons of code, it's for operating on your existing code without having to make space in your head for typing. Once typing happens automatically, your focus improves.
This is why I love vim style editors so much as well, because they more directly translate the act you want to perform with what you tell the editor to do. While someone who hasn't learned to use vim is scrolling around with arrow keys and holding down shift to select, or trying to point a cursor at the right place to double click I've entered the three characters ciw into my editor and its already deleted the current word, place my cursor at the beginning, and put me into insert mode to start typing the replacement.
I wouldn't even say I'm a super proficient vim user, there are people who are way more immersed in it than I am and who can leap around files at phenomenal speeds, but even just the basics I know are a huge help in keeping in the flow of thinking about what I want to do rather than how I'm going to do it.
Isn't the goal of touch typing that you no longer have to look at the keyboard? So you can still be paying attention to the screen while typing, i.e. you're not going to type 30 commands before noticing that something is off.
Touch typing you usually end up basically 'sending the commands' to your fingers before you put much though into it. So if you are off by 1 char or forget which mode you are in you can really destroy yourself. Most touch typing is also taught without you even looking at the paper/screen. The idea is your imagine what you want expressed and your fingers just 'do it'. I have done both of those things hundreds of times. I will do them again. As typing is just something I do not put much thought into until something is very wrong. At 90WPM you can get a lot of chars in before you figure out you have reallllly messed up.
When I start getting rusty, I fire up gtypist. It does key movement exercises (e.g. dedede dwdwdw dsdsds dadada) for many combinations of keys. It really helps. You do need to make sure you're following good typing practices however.
Its one of my top software role models. Minimal UI thats easy on the eyes and loads instantly, adaptive behavior thats ubobstrusive, really useful reports.
Undervalued skill! I think having access to quality typing skills enables a smoother interface to computers in general, which makes using them substantially more pleasant.
I don't quite type as fast as I think, but as I type this, I'm considering my phrasing more than I'm considering how to put the phrasing into the text box, so I feel like I'm experiencing a slower version of what you're talking about.
> access to quality typing skills enables a smoother interface to computers
100% agree! I actually studied the use of typing exercises in CS college students. Incidentally, the lowest performing students benefitted the most having those available.
It strikes me that touch typing prose is actually very different to coding due to all the symbols. Also unlike prose, a lot of time is spent editing or refactoring the code. How much would you say your typing competitions actually have an impact on your coding speed?
Don't forget there's a lot of prose in software development, too.
You can always tell which people are comfortable writing their ideas down, versus those that don't, by how they express themselves in emails, issues, documentation, or comments in the code.
Note that good IDEs help with punctuation, and you can touch-type those, too.
> The main positive that I see is that typing no longer requires thought.
What I find the most interesting in how I type (never really trained, it just "happened" over years), is that often when I make a typo I'm already correcting it before I register it with conscious thought. It's like the hand already noticed that something went wrong, so the backspace keypress has been dispatched autonomously without having to think about it or even observe the result.
> The main positive that I see is that typing no longer requires thought.
This is why I've been using keyboards with nothing written on the keys since 2004.
At the time, I was in high school and had no money to buy a professional keyboard, so I spray painted my cheap keyboard with black paint (fun fact: I'm still using that very keyboard to type this).
I've never looked at my keyboards ever since. I can type all letters and all symbols without thinking about it. As an IT person, I couldn't imagine how much brain energy I would waste if I were to look down and search for anything.
Yeah! Whilst usually a side show to real events there's a bunch of virtual and in person events.
Two years there was an event in the UK dedicated to typing. Last year the US. Virtual tournaments happen frequently throughout the year. The most famous one is likely the yearly event hosted by Keymash[0].
Octahedron is also a famous player in the scene. He hosts a Discord server for proficient typists and regularly puts on events.
How good is proficient? I just use a QWERTY keyword and my max is 143wpm, usually stable around 115wpm and after 10+ minutes of typing slows down to 100WPM. Is that proficient enough? Because I know of people who type at 200-300 WPM with their custom keyboards
Do people use steno keyboards for this (and why not)? The scores I'm seeing there are certainly impressive for ordinary keyboards but nothing close to the ridiculous records stenographers get.
Do they "require" total accuracy in the sense that the penalty for a mistake (or the time spent fixing it) makes it impossible to do well, or is a mistake actually disqualifying?
I love typing - it just makes a little ping in my little lizard brain. But if one of my jr teammates are typing out every single character of their code I will slap their ass and teach them about autocomplete and github copilot. So much faster to have jr type their code (as in define the types) and leave the typing (as in the writing) to the editor.
That still doesn't stop us from having typing (as in writing) races at the office which is a fun thing.
If rephrase that as “use moments of inefficiency to teach juniors how to use their tools better”
Showing someone how to use column edit, or macros, or automated method refactor, will change their productivity dramatically. It’s the role of leaders to teach and empower.
The article makes a good point about how little of software development consists of typing. This matches with my experience also, over several decades. There are so many things to optimize before "code input speed".
20 years ago, one of our guys hurt his arm and had his arm in a sling. The customer asked for a 50% discount on his rate - it was clear they saw software development as "fancy typing" rather than a process of turning business requirements into functional software.
The accuracy argument gives me flashbacks to the days of talk/ntalk/whatever conversations as a teenager, over 2400bps modems, cross country. I distinctly remember realizing I made a typo 3 words ago, while the cursor was several lines up, and being able to quickly backspace, fix it, and continue typing. It was so satisfying to finish my thought, and then watch as the cursor spewed out the words, the typo, go back, correct the typo, and continue on perfectly. This happened all the time.
My accuracy has only gotten worse as internet speeds have improved :)
> To be clear, at a steady state in a mature project, I get something like 125 lines of code into production per week.
I don’t think this is uncommon, but it’s wild to me that so many companies let their dev productivity degrade to this level. I work at a decent sized startup, 8 years old, fairly large codebase, and even junior devs who are pretty new to the company are averaging a couple hundred LOC/week shipped to prod, while the most productive devs are averaging ~1K LOC/week.
We spend plenty of time keeping the dev env fast, keeping CI (build, test and deploy) fast, minimizing risk even with minimal QA (strong test coverage, canary deploys with auto-rollback, strong alerting), and refactoring to reduce complexity. But even still, ~60% of overall dev time is spent on product stuff, and this other ~40% is SO worth it if it keeps devs ~10x as productive.
An environment where even strong devs only average ~125 LOC/week is just so, so unproductive, it’s crazy to me that companies let this become the norm. Prior to my current company (which I would consider very high productivity), I worked at a place where the productivity was more inline with 125 LOC/week (experienced, fully on-boarded devs were around 200 I’d guess), I can see how this happens, but it’s crazy to me that so many companies LET it happen.
There's a level of mature projects where you don't really do new features anymore. There's polish and some changes and focusing on more reliability instead. And in those cases, you need lots more testing and validation and not much stupid code. I had one leg in development and one in operations and had weeks where I merged 10 lines of change - and they were properly tested and important 10 lines and that was how long they needed take. LOC is a silly metric - don't let it become your dick measuring contest or expect it to correlate with level and you'll learn to appreciate the small, difficult changes too. (the lower my LOC got, the longer my documentation, diagrams and project proposals got)
LOC is far, far from a perfect measure of productivity, but ultimately if you do want to be shipping plenty of customer value (and/or tech debt reduction), it does take plenty of code to do so. Sometimes there’s 10 LOC which huge value, but if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow.
I also think that this:
> There's a level of mature projects where you don't really do new features anymore.
Is fine for a product that’s basically “done”, but who’s paying you to work on those? More common is that the product would benefit a lot from improvements, but the company/dev team has basically lost so much velocity that they can no longer ship them.
> Sometimes there’s 10 LOC which huge value, but if over the long term the most productive devs at a company are only shipping on the order of 100 LOC/week, progress is gonna be really slow.
To me this belief is a big red flag. The most productive developers I've worked with have all been among those on the team with the lowest LOC count. Writing lots of code is easy: Ignore good practices, don't think through how to generalize components, and reducing boilerplate, and in the process of doing so create a codebase where getting anything done without high LOC changes becomes progressively harder.
In my last job, I spent many weeks on a component that ended up at ~2KLOC. In the same time period, we had several people writing thousands of lines of code each of views and controllers for a number of database tables.
Once my component was done, it dynamically synthesized the starting point for 10x the number of tables let us cut weeks of developer time off the work involved for each model where we now just had to fill in some config and write the occasional custom component to make things nicer. It also let me spend the following week deleting many thousands of LOC of code the rest of the team had written that had been rendered entirely redundant, so my average LOC produced for that period was net negative and cut months off our delivery timeline.
Sustained high LOC count is to me a warning sign. If the code is easy enough to write that you can churn it out at high tempo, odds are there are patterns that can be generalised and wrapped up in higher-leverage components that you're ignoring.
You're talking about LOC per feature or project. GP is talking about LOC averaged over the whole organization, over all features and projects. I actually think you're both right.
> Is fine for a product that’s basically “done”, but who’s paying you to work on those?
Most companies that are actually profitable. There's a massive amount of space in between "done" and startup level expansion. There are good, mature projects which need some improvements and TLC, without expanding their scope every day.
And because they're already large and most of the simple issues have been addressed, you start getting the interesting problems that take many more times as long to investigate and understand as they take to fix.
Eh, a lot of the biggest, most successful/profitable tech companies are still rapidly developing new products, features, etc. For example, Google, Amazon and Apple are all still innovating pretty fast.
Lots of others have basically stopped shipping new products, new features, performance improvements, UX improvements, etc. But I think that’s frequently an undesirable state the company has gotten into, they’d love to be productive but have lost the ability.
> For example, Google, Amazon and Apple are all still innovating pretty fast.
I'd dispute that in general. And definitely if you mean amount of innovation per employee. They try random new things that either lives in its little corner, or gets killed in a couple of years. They sure have lots of churn and likely lots of lines of code flying around, but innovation...? There's two projects from Apple from the last decade that I'd call innovation. Amazon marketplace is static and AWS just gains new features that are mostly expected / business as usual. Google kills as much as it creates all the time.
I really don't think those are great examples of moving fast.
The idea that constantly making new stuff is what makes you great is a developer-centric ideology. With products from a mature company like Google, customers mostly just want the existing stuff to work.
Whenever anyone talks about lines of code as a productivity measure, I’m reminded of this story about Bill Atkinson (arguably the most brilliant developer on the original Macintosh and Lisa teams) [1]. Just to note, this event occurred years before the Macintosh released, when the code was far from mature.
Yeah, at a CA, fair enough. But there are tonnes of B2B or B2C SaaS type products, that do need new features, bug fixes, performance improvements, UX improvements, etc., but aren’t getting them quickly because dev productivity has declined so far. Typically environments with confusing architecture, slow local dev flow, slow CI, poor test coverage and tonnes of manual QA required, etc.
I had a similar reaction. If I'm healthy, I can routinely ship 1-2k LOC per week.
I sort of regret that at times, because I think we could be just as productive (in terms of useful product) with many fewer LOC, but we are stuck with the constraints we live in.
OTOH, I've worked (incredibly frustrating) jobs where the infrastructure is dysfunctional such that the write-compile-test cycles are on the order of tens of minutes, and these have made my LOC/week plummet. In those cases, I've recommended to management that we fix the infrastructure to get down to sub-minute cycles (ideally a few seconds), but usually these have been shot down due to their extreme myopia.
So, assuming that's a growing startup, if all engineers keep committing 0.5/1k LOC/w with number of engineers doubling every year, what will your codebase grow to in 5 years' time?
Let's say you have 20 engineers now (low for 8 year old startup). That's 1M LOC/annum. Next year you add another 2M. Where does this go?
The most I've ever done was nearly 500 lines of C++ in a single day, around the year 2005. The domain was capital markets. The code complied the first time and ran with only a few bugs. The code was spread across several functions, but no classes or other abstractions. Only business logic and I/O operations. Written on vi. Not even vim (no syntax highlighting). On a telnet session to a server about a 100 meters away. There were no meetings that day. Never been able to replicate this feat since.
Many mid-large size companies have meetings, code reviews, paperwork, sprint planning that take up most of the workweek. really depends on the domain. If your team is developing a medical device, no way in hell should you push 1k LoC/week. maybe 1k Lo Documentation. My guess is the 125 LoC/week is a maintenance coder role.
Author here. This is a topic that fascinates me to no end, and I have a million questions for you that are off-topic here. Do you mind sending me an email to a@xkqr.org so I can reply with the things I'm curious about?
(Anyone who wants to discuss it can send me an email and I'll try to hook everyone up to the same email thread.)
Writing the same CRUD component for the n+1th page, that is not at all fundamentally different than all the rest, is very different than, say, a compiler/render engine, etc. There are days when my only contribution is a single, slightly modified line of code.
That was a reference per project, how many engineers have only a single project they maintain? I’ve had between 5-160(way too many to realistically maintain) at every point in my career but it never got to 1. I think the lowest was 3 for a month period inbetween sunsetting one project as the contract had ended and then getting assigned a new project because I had the spare capacity
It's easy to spew out 1K LOC/week of low effort code for simple projects. It takes far more skill to produce 125 lines of high-quality code in a complex one.
My most productive recent change had a negative LOC count, and will have a big impact.
It's entirely impossible to make an assessment of whether or not 125 lines is good or bad in this instance without knowing more about the type of project etc., but that it is a mature project is already a strong indicator the number quite possibly should be fairly low.
To put it into networking terms, the brain-finger output is a leaky bucket. The brain fills the buffer, and the fingers commit at some interval. The buffer is fairly small, and overflows are simply forgotten. The buffer has both time-based and size-based eviction policies. The faster you can type, the less you might forget.
Just flush the buffers more frequently and problem solved. The brain-finger output is never the bottleneck, as the brain part itself takes a lot of time before outputting anything.
I guessed that this would be arguing something similar to the "tests should be very fast" argument. There, the point is that anything that causes you to context shift is bad. The feedback loop of code/test/break/fix is everything.
But I think after reading that the argument was more akin to webpage load times. Sure, a few extra seconds isn't measurably a lot, but there's a feeling of responsiveness that matters to our psyche, even if according to wall time it's not a big deal. This I find more plausible. I've seen code. I know how damn lazy we can be. People seem to be willing to spend hours of pain to avoid writing tiny helper structs, or writing helper methods, or giving functions/variables names with multiple words.
Still, 80 wpm seems like a lot off hand. That's coming up on regular speaking speed. I wonder if I could test the difference on myself to see if it bothered me; maybe add something that slows my typing rate to 80?
I'm a pretty fast typist (also guitarist - maybe related?), and I did a speed test with my coworkers for shits and giggles not long ago. I got 110wpm with 100% accuracy although it was a fairly simple prompt. Some semicolons, commas, and quotations, but nothing crazy. I would definitely say it feels like I am typing nearly (but not quite) as fast as most people speak. The benefit for me is honestly handicapped by the fact that most people can't type that fast so I don't save any time when actually communicating with others since I have to wait for their response either way.
That being said, I don't think I would code anywhere near that fast. Maybe years later when I'm far better at it than I am now. I probably type around 60-70wpm if I'm writing some basic SQL where I know what I'm looking for, I would guess.
When I was in college, it definitely was helpful being able to type quickly so that I could workshop ideas and phrase structures in papers more or less in real time. I honestly almost never wrote drafts, I'd just revise as I went along in that fashion.
Most people typically speak in the 130 - 180 word per minute range, although this can vastly change based on context. Preprepared speeches, arguments and monologues generally have a higher pace than a usual conversation between two people.
With far more people doing remote work now than pre-2020, IM is another way in which typing speed is very important for productivity, and this likely has a teamwide effect too --- if most of your team can type nearly at the speed of thought, then everyone waiting for the slowest member to share his thoughts on some discussion gets irritating rather quickly.
Yes, I know there are audio calls, but with IM it's much easier to be doing more than one thing at once, and talking into each other isn't a problem.
Not to sound rude, but that's an incredibly obnoxious take. Async communication is one of the biggest features of remote work, not a bug, and you decide to get irritated because not everyone likes to communicate exactly the way you do? Please.
Text based communication is not always asynchronous, ESPECIALLY in the context of remote work. Many people prefer text even for live back-and-forth conversations in order to avoid the overhead of voice/video for a variety of reasons, such as being in a noisy location, having slow internet, carrying multiple conversations, skipping the overhead of greetings/equipment setup.
All email is asynchronous, and some instant messaging channels can be treated asynchronously, but some of it is definitely live. If you are not treating some conversations that way, it is you who is being rude and forcing the way you like to communicate onto others.
Language barriers are another reason. Most of the time I can communicate in English just fine, but if I am to contact a tech support guy/gal from India I very much prefer text chat :-D
> Async communication is one of the biggest features of remote work
Sometimes on a Slack thread with 10 people it becomes more like a traditional (synchronous) conversation, especially for a P1 or near a deadline. Typing fast helps me here.
I don't really agree with the premise of the article, but my sustained typing throughput sits around 140wpm, and for 10s bursts can hit 170+. This is WAY faster than I can talk.
But I don't think this typing speed provides me the advantages the article professes - as others have noted, I am much more gated by the time I spend thinking before typing than I am the typing process itself. Dropping to 80wpm is going to influence the amount of garbage I throw out arguing with people on the internet far more than it would doing anything actually productive.
To the point of having to pause thought while typing, I don't find this to be particularly true. I'll still be thinking of how exactly I want to word something as I'm typing it, and will make minor adjustments on the fly.
I have a tendency to stumble over my words or forget what I was saying mid-sentence (yay ADHD). Once you have to move the cursor backwards, typing will always be faster than speaking.
The biggest issue I have with dictation currently is that as I'm speaking it'll type out what it thinks I'm saying and then revise that what I actually said as it goes. This results in me getting distracted reading the words appearing on screen and losing my train of thought.
I find that my typing is much better because I can constantly re-parse the sentence as I am writing it. With speech, I have to memorize what I've said instead, and that causes a lot more screwups.
yes, same. And the more time passes, the more this skews. My thoughts flow naturally into words when I'm typing, but if I have to speak them I forget what words I want to use very easily, and sometimes I'll have to pause for several seconds to recall what I want to say. It almost feels like spoken English isn't my native language anymore, and typing is.
Yeah, honestly to describe talking, it's as if I'm just throwing out things out there cluelessly, hoping all of what I've said makes sense, while when I'm typing everything just comes out according to my natural thought track.
In my opinion, latency is a super important concept that got forgotten once we moved every application to web interfaces.
I remember the 90s and the 20s, when everything happened locally on the local hardware. It was quite easy to type fast, move the focus around in the various forms using tab and shift-tab, move from tabs and windows with ctrl/alt-tab; and there was keyboard shortcuts for most things.
I remember being able to execute complex operations between multiple applications using only my keyboard and without having to use any brain power between each step.
Now most things are moved to cloud applications and we interact with them with web browsers. Keyboard shortcuts are (mostly) gone, and each click or operation triggers a request on the other side of the world with a high HTTP latency, and that prevents the brain from chaining them for free.
I remember being able to do almost everything using my keyboard. Now good luck interacting with a web console without switching back and forth from keyboard to mouse for 50% of the steps.
I guess that's also why many developers (including myself) still love the CLI environments.
> I remember the 90s and the 20s, when everything happened locally on the local hardware
I think there's a bit of rose tinted glasses here. You could literally see windows and icons being drawn on the screen in the 90s. Even text UI were slow to draw on screen. We have it good today.
Regarding keyboard shortcuts we are good too. I barely use a mouse nowadays. I use Vimium for Chrome to "click" on elements in pages, i3 keyboard shortcuts to jump to specific applications or workspaces, and the mouse emulator on my keyboard (olkb) to click or use the scrollwheel on the odd thing that doesn't want to work with a keyboard. Luckily many programs have adopted the command palete (most editors, vscode, gimp, etc) so it's easy to quickly invoke commands without memorizing arcane shortcuts.
> and each click or operation triggers a request on the other side of the world
Heck, each keystroke does this on a lot of websites, usually the culprit is some kind of overly ambitious search function. My biggest pet peeve is trying to type something via phone keyboard and losing half the word because it's ignoring inputs made while it's waiting on some http request. I notice the worst offenders are retailer websites (Menards, Target, Walmart, etc)
The author is missing the point. If your editor doesn't have abbreviations, snippets, completion, etc., you're doing it wrong.
If you can type above ~80 WPM (which basically just means you can touch type), then using the proper tools your effective WPM is easily above 150 and thus totally irrelevant.
Or put in other words, once you can touch type, you are far better off improving your tools and workflows than practicing typing. In a competition you might train your legs, but in real life you get in a car.
The sad reality of large software companies. At this point I wouldn't be surprised if there are engineers who spend their entire career without getting any of their code into production before each of their projects are cancelled.
Agree with this, if one is thinking in terms of typing letters out you're working at entirely the wrong level of abstraction and with the wrong primitives.
I often use the example of ".toString" being meaningful whereas ".tosling" is nonsense (unless you have defined it elsewhere). I'm not even sure if that's the correct capitalization of the to string method in JS, but I shouldn't have to care. If my tools can't tell me which one is valid to use in the current context, then the tools are bad and I should look for better tools. (This may not be universally applicable and maybe Lisp is the promised land etc etc. But raw text input speed is a silly metric to prioritize and leads to a local maxima in programming)
Auto correction systems are a relevant external factor, in some typing contexts. For example, one (probably bad, but who's to say??) habit I've picked up recently is to cheese [0] the Googling of things - saving a massive zero.point.bugger_all seconds per time - by fat-fingering my search queries in a rush, without bothering to spell words correctly. What did Samuel L Jackson say, exactly? - why, "thta movei abotu bible speehc", of course - first result [1], done! None of this pesky 'stopping to think about what order the letters go in' business!
I completely agree with this. I've been working on my own 30 day challenge to boost my typing speed, and the reason is similar to what's stated in this article: it's about latency, it's not the seconds saved.
It's mentioned in the article, but I mostly think of it as: the faster one types, the shorter the iteration time. When you can type roughly as fast as you'd normally speak, it's a totally different experience than t-y-p-i-n-g each word of a sentence.
I kinda agree, but I've also been humbled time and time again by older devs who literally hunt and peck with two fingers. I even asked one how she fixed so many nasty bugs each week while barely knowing how to type. her response: "I think deeply about problem, then type correct solution first or second time".
You can type quickly and still think deeply about the solution or whatever. Typing fast won't help when you're stepping through the code one line at a time, and it won't help when you're just sitting there with your eyes closed at your desk waiting to find out what to do next. But it is still helpful when you're talking to people in Slack.
Sure, I think the depth of thinking or problem solving is clearly important.
But, I don't think your claim is in tension with the article's claim that being able to type fast lowers a barrier (or provides a benefit) that's more than simply the "time it takes to literally type".
Any latency in any system high enough to interrupt your thought process hurts. Unfortunately it's one of those hard to market things that people don't know they want, so it's (rightfully?) never prioritised.
Eh, I don't know if I agree. For me the bottleneck is my brain. I spend far more time thinking than typing. Being able to type faster would only save me a small amount of time compared to being able to think faster.
I guess to steelman it, it's like investing in a faster 3D printer so you can iterate on your CAD faster. There's some value there I suppose.
You are talking about a throughput part of problem only not even a word about latency. If you are going to not think about what finger will press "A" key then your brain the bottleneck is going to be less like a bottleneck. Not touchtyping while typing means misusing your limited neocortex resources instead of just utilizing your muscle memory.
When you say "Doing X fast is about Y" it means that Y is the key to doing X fast.
The headline here is misleading; it's supposed to be "The Benefit of Typing Fast is the reduced Latency, not the Throughput".
If you wanted high throughput, what you could do is type at 20 wpm, and do so continuously all day without taking a break: minute after minute, cranking out twenty new words.
Your daily throughput would be higher than that of many a 160 wpm typist who only wields that skill in short bursts throughout the day.
The benefit of typing fast is that in those moments when you need something banged up, you see the result faster: the latency from starting to type to completing the intended change is lower with faster typing.
I find the most beneficial thing about being able to touch type as a programmer is that you don't need to concentrate on the task of typing. That way you don't lose your train of thought so easily while working on something.
> It’s difficult to type and think at the same time
I'm pretty good at typing, but not anything special, at around 90-95 words per minute. I type while thinking all the time, although usually the thinking is the slow part.
Other have mentioned speed and accuracy, but one thing that has been a huge advantage to me is being able to type confidently enough while not looking at the keyboard or screen (or only checking infrequently). It is pretty helpful to be able to have a conversation looking at the person while taking notes, rather than saying "let me write that down" every 5 seconds, interrupting the flow of the conversation.
This post and this comment section both feel to me like they’re from a parallel universe where no one knows that LOC isn’t a measure of quality but a cost. You want to keep it as low as possible while solving the problem at hand. As a matter of fact, you can often increase the quality of the product by removing code.
Typing fast won’t make you a better programmer. It will only encourage you to type before you think. It is amazing how much can be done with how little code if you give your brain a chance to actually process what you’re doing. I highly recommend it.
I feel obliged to point out that the post explicitly says that the benefits of fast typing for them has nothing to do with being able to produce more LOCs/sentences.
> It’s difficult to type and think at the same time
Maybe for the author. I think best at the keyboard. As others have noted, once you reach the point where the typing is both quick and unconscious, words just kind of happen.
Obviously at a gross level one's typing speed isn't the bottleneck in coding; you need so little ASCII on screen vs. with prose. However, being able to get even "bad" out quickly can help you rough out an algorithm quickly. The ability to get the code onscreen at the speed of thought is very, very valuable.
I love it when there’s a blogpost I’ve been meaning to write for years, and someone else comes along and does a good job writing up the same point, and with better framing.
After I practiced and increased speed from 250 to 380 char/s, the effect was that I started writing in IM larger messages and explaining things more thoroughly. This became much easier than earlier.
So I'd agree, that you may write down things quickly or write a lot more in a minute. For coding this means you easily write comments, for messages or articles means you can write a lot more in one moment, which means you write a lot more elaborately.
Touch typing is something I should've invested in much earlier, can't imagine how I ever coped without this ability. Another thing that really helped me is the "Alternative finger positioning" described here: https://typingsoft.com/typing.htm It feel much more natural not having to bend your wrists. Is anyone else also doing this? Whenever people ask me how to learn touch typing I look for native Linux or macOS app that teach this technique, but I haven't found any yet...
Back in the day I heard stories of how some of the better ACM ICPC world final participants turned out to be rather slow typers. But the idea was that they figured out what to do before they type, and their own clarity of thought allowed them to type correct code without having to backtrack. It helped that most of the time the solutions are pretty short.
I consider myself a pretty good problem solver of contest problems, but often I have to type code the same way people use pencil and paper to go through drafts, so I can't relate that well.
Like any skill it's about cultivating a set of "hardwired co-processors".
The more skilled you are, the more of these tasks can be handled in parallel, for example typing and reading, thinking.
Or, for example, walking and chewing gum at the same time.
It's like how a learner driver needs to focus on the task fully, while an experienced driver only seldom needs conscious thought to execute the process.
Or a pianist sight-reading and playing the notes, while also interpreting the piece on a higher level. It's all about parallel processing
I agree that latency is important, the way in which you can type out things without spending extra time in delays can be a huge productivity boost,
One sort of analogy we can give is driving a car with good response time, even if the car is not having a good top speed, the acceleration we get when we push the pedal is enough to think we are going fast.
But throughput can also have a dominating factor, but its reliant on other areas, like typing out an already prepared article.
For operations that require thought, latency is important
I mean, maybe? The absolute largest obstacle any of these examples will have to overcome, though, is all of the amazing stuff that was done in the past. And all of the amazing things that are done today with long feedback loops.
Like, I get it. This seems to be a low hanging fruit that you should consider. But it seems somewhat likely that you will draw the line below stenography. We don't even teach shorthand to people anymore, and that would fall into all of these arguments, as well.
The amazing stuff often has certain level of challenge, excitement, and reward behind it that compensates for the long feedback loops. It's not necessary for sure, but it sure is nice!
Right. My assertion would be that, if you internalize the work, you can do far more mentally than you can physically. As such, if you can work a lot of the exploration and experimentation mentally, you can't beat that feedback loop.
Now, integrity of signal is obviously a problem there. If you have a problem in your mental execution, you are likely to miss it. So, you do have to do some physical experimentation. But, for prose and the like, you don't have to type as you think.
My limiting factor is _command_ throughput in my brain; coming up with the words I want and how to spell them massively slows me down. I really wish I could figure out how to go faster (~80 WPM) because I'm essentially limited by the speed my internal narrator dictates to me, which is close to realtime speaking speed. This is less of a problem while coding, but I still think it's quite relevant.
I type no more 25 wpm with at least a 10% error rate, but I don’t have to think about it at all. But I have never been slowed down by typing latency. I spend half my day researching and half my day spacing out and the remaining 2/3 of the day in meetings and still get more done — with fewer lines of code — than the average developer.
I am a touch typist since 30 years. I don't feel like I am thinking while I am typing. Typing happens automatically. Much like it works for musicians with sufficient practice. After a certain point, things become automatic, and you no longer consciously think about each and every key you press.
Well, easy test is to use high-latency device. Only prints one letter every 100 ms. You will still spend negligible time typing to thinking. Will you be worse programmer? I think so. Input device is for transmitting thoughts. Should be seamless, blend to background. If ever becomes foreground, you lose flow state.
Standard qwerty people, how do you get around the arrow keys? It seems to be the only thing that reliably throws me off-cadence, when I have to reach to the bottom right to move around in code.
On the other hand, I would have a very difficult time dictating what I want to write, because... well I almost feel like I speak too fast! My voice goes faster than my thoughts.
Why don't the schools, regular ones, teach proper ten finger touch typing? But then, will it still be a common vital skill in let's say 20 years? (I think yes)
What is your definition of seriously? Dvorak has 70% keypresses on the home row, with the best left/right hand alteration approach possible, with ability to switch to Programmer version of it if needed. I don't know what real-world tests can leave all of these features unnoticed. Dvorak layout is a magnum opus of the guy who was willing to arrange the letters in a best possible way for human, while qwerty is a clever trick to fool a customer for the sake of selling typewriters.
From what I've seen, differences in key arrangement has effects on:
- Different keyboard layouts have very little effect on speed. Querty vs Dvorak vs a completely random layout will have little difference in typing speed after learning it for a reasonable amount of time.
- Learning time is probably reduced by using a more intuitive keyboard layout. This was one of the key points in August Dvorak's studies while researching the layout, and found that Dvorak was significantly easier to learn for new typists.
- Hand and finger movement is reduced by placing more commonly used (mostly optimised for english) keys on the home row. More words can be typed using only the home row keys on Dvorak and especially Colemak than on Querty, which also likely reduces rate of misspelling. This can also be an improvement for typists with RSI or other injuries.
Different layouts have different goals, as you've said Dvorak has a great approach for altering between left and right hands for commonly used letter pairs. Colemak optimises for inward finger rolls, which I might learn as they're very satisfying to type in the rare occasions they appear on my default of Dvorak. Layouts like Engram aim to reduce use of the middle column between the left and right hands.
While I can't unequivocally recommend alternate keyboard layouts to every person that types regularly, one thing I can say is beneficial for any layout is simply to remap Caps lock to Backspace for reduced finger movement. Think about how often you use Caps lock and then realise it's wasting valuable space on the home row, while usually requiring the typist to move one hand off the keyboard every time they want to correct a mistake.
If its that much better, but no one uses it, who the hell cares. You can espouse all the features you want, but if testing shows that it doesn't really matter to anyone, meh.
What is your definition of anyone? I am teaching Dvorak to some really young students, whose habits are not malformed with Qwerty. They are extremely thankful to me, no one is willing to return to Qwerty, time to gain a touchtyping skill is 10 hours from zero to hero. So, my "anyone" reports that Qwerty does not matter to him. Probably your observation is based on the fact that an old dog can not learn a new trick.
the preceding knowledge acquisition before starting programming takes the overwhelming majority of typing. this includes web searches, asking questions in forums, IRC,.
...
Is this the right place (/s) for me to complain about a regression in iOS 17.1 and 17.2 (beta) where typing too fast will randomly switch to other apps? [1]
It’s such a frustrating experience that I’ve noticed my communication has gone down noticeably in the past two weeks.
Not in measuring WPM / typing speed but... You need one heck of a quick editor to be able have suggestions showing up and selecting the suggestion be quicker than just typing the darn thing. If you know what you need to type that is (which is another topic btw).
I've got my editor setup with a very quick way to pick up suggestions (which I optimized to minimize both the number of keypresses needed to pick a suggestion and the finger travel distance [it's configured to use the "stronger" fingers first, no pinkies, and it's configured so that the most likely suggestion is on keys in the hands home position]).
Even that way, it's still typically faster to type the whole thing.
And don't get me started on slow as molasses IDEs that exhibit noticeable delays when showing suggestions.
To put it simply: even if you count auto-complete as a word, it's highly unlikely you'll be anywhere near close to 80 wpm (which ain't even that quick).
Not to deny your particular experience - but The Humane Interface (Raskin, 2000) talks a bunch about how doing comparisons between keyboard and mice (and hybrid interfaces) was difficult because user's self-reported experience of the time interacting was inconsistent with actual measurements - there's some cognitive editing of the boring parts, or something like that :-)
> Someone writing code can think of how to structure the code
Then, just think about it, and not type it out like a caveman prematurely.
Also, no one on Earth has ever written continuously for 5 seconds outside of typing competitions. You don’t have 5 seconds of coherent text buffer available in your mind even for natural text, let alone codes. So that +3 seconds is complete nonsense.
I'm a competitive typist. I'm also a programmer. The main positive that I see is that typing no longer requires thought. I think of the code I want to write and it's transcripted onto the computer.
I would say that it's more advantageous to type _accurately_ than quickly. Typing competitions generally require 100% accuracy, which gives me a great amount of belief that what I'm typing is correct, without having to look at it / check it over and get side tracked from the code itself.