I've wondered for a while what my WPM is when writing code. It's slower than plain english text, partly because there's so many more characters in code than in plain english. So something like this lets me see the difference between regular typing tests (e.g. typeracer.com) and coding -- and presumably, which languages are either more familiar to me, or more syntactically sluggish.
Their pricing page shows that it has what appears to be a nice set of features to actually help you get better (note to site owner: might be an idea to put this on the main page).
Despite that I can't imagine myself typing code just for the sake of typing code. Seems to me this would make more sense as a plugin for an IDE. Watch my every keystroke as I do real work and show where I am constantly having to correct myself, and offer ways to prevent that.
I'd definitely pay for a "typing analytics" addon to my OS, or maybe my editor, though I think that is needlessly restricting things. It depends if there are mistakes and advice that are specific to writing code versus just general typing.
Either way, it could watch for bad habits and common mistakes, show aggregating stats, etc.
This is pretty cool. One thing that bugs me is that the code isn't formatted the way I write. For example, my muscle memory does not involve typing a space inside parens - "function ( selector )". I miss those every time.
Nice UI! For programmers trying to improve their general typing speed I reckon it could help, but for me it creates an almost uncanny experience.
In the JS test I found it incredibly difficult to type out `/^(?:parents|prev(?:Until|All))/`, because my mind interprets it somewhat like its AST -- i.e. I see a delimited regular expression with an uncaptured group nested within another uncaptured group. I focus on the operators then on the contents. But by the time I've done this I end up typing it out slower than if I was just transcribing character by character. And so I started to wonder if this is something it's "okay" to be bad at...? I mean, if I focused on it character by character, word by word, then I may gain speed, but I would be totally ignoring the meaning of the characters -- and I would also stop being a programmer.
Maybe my mind just needs to become more attuned to reading code... maybe this experience reveals that I do not read code often enough. Intriguing.
I wonder what things would look like if they were to let you type, free-form, and not consider it complete until your code matched that of the sample. That way, you could use copy and paste, or bang things out and then fix them later rather than in-line. (e.g., let me type keywords and then later realize I forgot a 'self' in a Python method.)
I was thinking all of these things too as I was trying it. I think there is something fundamentally wrong about this. I don't think the words per minute for a programmer's typing is important. As you say, to get the higher score, you must simply type as you read character by character, but this is not what programmers do. I don't see much value in this because of that. If our jobs were to transcribe code that someone had written out by hand then this might be something worth its disk space. If we find code that we want to copy exactly without trying to understand its meaning, we have a clipboard for that.
i also had this thought, but i realized the value in this is not necessarily understanding the code that you're typing but rather getting better at typing characters in context and in certain sequences. for instance, i realized that i am terrible at typing } and ], but i assume that's because i have an IDE that does autocomplete for those chars. other typing programs i've used are just transcribing sentences, but in programming there are so many other characters we use in the middle of typing things.
The problem is that nobody writes code like that (char by char, like prose). You often jump back and forth between statements and parens, and code from inside out.
... and thus some developer starts pondering an alternative editor for source code... usually culminating in a design of some sort of an "node" editor ;)
Seriously though, were there any useful ideas developed regarding code input besides code macros with variables?
Any hints?
I write code like that. I tend to have a good idea of what the code should be doing, and write it out, char by char, like prose.
I also avoid IDEs and prefer text editors. In the twenty-five years of programming, I've not found an IDE I like, and I suspect I'm a langauge-maven than a tool-maven (http://osteele.com/posts/2004/11/ides) (as long as I can type, I can try out a new language; I don't have to wait for a specific IDE to come along first).
Edit: add a link about language-mavens vs. tool-mavens.
I like how it can help dive into interesting open source code, as well as the look and feel of the app, but two things are holding me back:
- Like @padolsey, I do need some time to understand what I'm typing; I'm not sure practicing typing and learning from someone else's code are compatible
- More than code formatting, which has already been talked about, programming environments also have a direct impact on what characters need to be typed
So even though that tool stems from a blending of two great ideas (increasing code output, and learning from the best), I'm still pondering whether these two would be best left apart:
- Reading (and contributing to) someone else's code to learn from it
- Optimizing your coding environment to increase your output: great IDE/editor, clever shortcuts and auto-completion, custom snippets…
This tool is perfect. - I'll recommend to you that you're marketing it all wrong. - I'd make this into a tech-interview/learn a new language site. Before I crack any book for any language, I download gists of the code and start typing it out.
Imagine, python/c the hard way in this? What is a namespace? What is an import? Inline explanations of what you're doing would go a long way.
Dare I say it, this could be the first Learning-Development-Enviornment I like. You're doing yourself more harm by only letting people use those 16 languages.
Additionally, in the process of mimicking code, the only thing I could do was think about what I was writing - and in some cases I discovered that I would have done it differently than some of the libraries I use every day.
All this does is make me realize how much I take my IDE for granted. In no example that I tried did I even get past the first line before I missed using IDE autocomplete or shortcuts. It got under my skin that I had to type out each character.
Take the Scala example. I would NEVER type "@SerialVersionUID" with correct casing. I'd maybe type "@Ser" and then auto complete. Or "@SV" and then auto complete. I can't recall the last time I typed an entire type name. Or finished braces using Enter + "}" instead of CTRL-SHIFT-Enter.
I have to somewhat disagree, I think autocomplete is one of those IDE features that is no doubt quite useful but I think its contribution to developer productivity is greatly exaggerated... frameworks that are well designed for instance are far more important contributors to developer productivity...
so my question to you is, what if a tool has a framework that allows you to get a lot done with significantly less coding but lacks autocomplete, would you not consider it?
Full disclosure, I am the founder of a browser based IDE software company so my take may be biased, but I have also written enough code to kill a horse :)
We currently don't have code completion though it is on the product road map. Our middle-ware however almost completely eliminates writing code for doing C.R.U.D operations, sending email, uploading files, doing configurations and using http restful services... I think such advantages greatly outweigh the lack of code completion.
I do concede though that maybe in your specific case, code completion is a major productivity booster.
Except it isn't just auto complete he is describing. It is also code generation. The example he gave would come with an auto import. Other examples would include class and method generation, exception handling, parenthesis matching and test stubs.
I don't disagree at all that all the features you describe are nice to have. They do indeed make the programming experience more pleasant and add some utility. What I am arguing against is elevating those features over more effective productivity boosting solutions that may not have quite the same dazzle.
Intellisense in general is kind of expected now in any IDE; it is like the buttons in your car to slide down your windows (old enough to remember the handles :) ), they are nice and expected but you wouldn't base your buying decision purely on that.
Your disagreement is kind of out of place here; no claim was made of where the productivity boost of autocomplete ranks against other development factors. Besides, whether or not you use autocomplete is orthogonal to your framework choice.
* no claim was made of where the productivity boost of autocomplete ranks against other development factors
No, but it can be inferred.
I agree that code completion and framework choice can be mutually exclusive; my general point is that a developer's decision to use a tool should consider other productivity factors, not just the expected ones.
I don't think so. We ought to be able to describe our own experiences without making a claim about productivity in general. It seems clear to me that peeters was doing exactly this, and not implying that his experience ought to be indicative of others.
The guy literally said that this app made him realize how much he takes his IDE for granted and then he provided examples of what he meant. I don't see what there is to disagree with there or what could be inferred .
Having frameworks is great. But you still have to type code to use whatever those frameworks are. Having intellisense is critical for any IDE. How do I know what methods exist in your framework without intellisense? Without intellisense you might as well be programming in a text file.
Learning to type quickly is a valuable skill. But with programming, is typing speed a common bottleneck? It seems akin to learning how to turn a steering wheel more quickly or how to hammer faster.
I think it really depends on your process. If you're efficiently pragmatic, then maybe your work environment includes an IDE with tab-completion, project skeletons, lots of snippets, and plenty of experience tying together existing frameworks and other tech to achieve your goal. On the other hand, some people actually want to do that sort of dirty work (even in verbose environments) because they get an overview of every single thing that's going into their program as they build it. They'll be a little slower than the first person but potentially have a much better grip on the underlying architecture of what they're working on which is incredibly valuable as you move forward and make decisions. So for these people, faster rote typing could be beneficial.
There's a neat part of the article that might better demonstrate what I'm talking about.
---
> Because I was young, super-anal, and wasn't on SSRIs back then, I once asked Carmack why he didn't use libraries for common functions that he could share between engine revisions. Carmack's a super-nice guy, but on this one instance he used the "Well, I think my methods work pretty well..." defense. I never suggested coding style changes again.
> But, really, for him it made no sense to share code, because, like a bee, it was just as fast to write new code. The template was in his head, he types really REALLY fast—why bother importing something?
> Don't take this to mean his code was spaghetti—it was actually some of the easiest-to-understand code I've ever worked with. It has an almost indescribable quality of "obviousness." Like, you know when a really good teacher explains something, it seems obvious? That's what his code was like. I mean, OF COURSE there's a loop where you service the pending events and call a refresh on the UI layer.
I do agree with you speed typing might not be the most valuable skill to a programmer. Being able to type without a lot of typos is a lot more usefull since they can create hard to find bugs.
Typing speed is rarely (I was going to say "never") the bottleneck, IDE or no IDE.
The bottleneck in programming lies in designing something that works correctly, understanding someone else's design or legacy code, designing test cases, debugging problems, addressing performance issues. It is a brain-bound problem, unrelated to motor skills.
I have never thought "this project would have succeeded if only everyone on the team had been a faster typist!"
I admit I'm a terrible pair programmer, so my experience may not be representative, and while I sometimes get frustrated when the person with the keyboard fails to hit the right keys (and to be fair this person is sometimes me!), almost always the main source of frustration is when can't agree on something or when one repeatedly misunderstands the other.
On the other hand, when we are on the same page, slow typing is seldom a problem.
I've known people to make the same argument against learning a good text editor. My reply in either case is the same: maybe I spend more time thinking, but being able to quickly turn my thoughts into code helps me stay in flow, so I keep thinking, instead of getting bored and checking out what's on reddit and HN.
As in, my typing is reasonably fast, but I don't think I need to practice programming-style typing to increase my productivity. The logic, design, and debugging is where my time is spent.
i don't wanna go that far and say that but... I saw this AND belt.io. and im just not seeing any reason for either... like i've tried thinking for a while and have thought of NO USEFULNESS for either tools.
Why would programmers need a separate tool for programming practice? Isn't the act of programming itself the best form of typing practice? I don't see a market fit for this for the stated purpose.
Also, the UI when you make a mistake is confusing, I didn't realise I had to backspace and correct it. While that seems obvious in hindsight, I actually opened it in a different browser to make sure I wasn't just hitting some bug before reading the comments here and realising.
Implementation's good, but the concept and idea is completely useless at least for Objective-C/Cocoa. All the symbol names of the Cocoa are strictly designed to be used with auto-completing IDE support, not bare editor. That's why they're fine to go such long names. The IDE is a required part for development just like Smalltalk.
And a lot of other language/libraries/frameworks are also silently presume auto-completion support. Even on C/C++. I highly doubt usefulness of this even on other languages.
Maybe it would be more important to be familiar with specific auto-completion IDE behavior rather than training yourself to type faster.
78 comments
[ 4.3 ms ] story [ 147 ms ] threadDespite that I can't imagine myself typing code just for the sake of typing code. Seems to me this would make more sense as a plugin for an IDE. Watch my every keystroke as I do real work and show where I am constantly having to correct myself, and offer ways to prevent that.
Either way, it could watch for bad habits and common mistakes, show aggregating stats, etc.
In the JS test I found it incredibly difficult to type out `/^(?:parents|prev(?:Until|All))/`, because my mind interprets it somewhat like its AST -- i.e. I see a delimited regular expression with an uncaptured group nested within another uncaptured group. I focus on the operators then on the contents. But by the time I've done this I end up typing it out slower than if I was just transcribing character by character. And so I started to wonder if this is something it's "okay" to be bad at...? I mean, if I focused on it character by character, word by word, then I may gain speed, but I would be totally ignoring the meaning of the characters -- and I would also stop being a programmer.
Maybe my mind just needs to become more attuned to reading code... maybe this experience reveals that I do not read code often enough. Intriguing.
Probably less about typing, then, though.
Seriously though, were there any useful ideas developed regarding code input besides code macros with variables? Any hints?
I also avoid IDEs and prefer text editors. In the twenty-five years of programming, I've not found an IDE I like, and I suspect I'm a langauge-maven than a tool-maven (http://osteele.com/posts/2004/11/ides) (as long as I can type, I can try out a new language; I don't have to wait for a specific IDE to come along first).
Edit: add a link about language-mavens vs. tool-mavens.
- Like @padolsey, I do need some time to understand what I'm typing; I'm not sure practicing typing and learning from someone else's code are compatible
- More than code formatting, which has already been talked about, programming environments also have a direct impact on what characters need to be typed
So even though that tool stems from a blending of two great ideas (increasing code output, and learning from the best), I'm still pondering whether these two would be best left apart:
- Reading (and contributing to) someone else's code to learn from it
- Optimizing your coding environment to increase your output: great IDE/editor, clever shortcuts and auto-completion, custom snippets…
Imagine, python/c the hard way in this? What is a namespace? What is an import? Inline explanations of what you're doing would go a long way.
Dare I say it, this could be the first Learning-Development-Enviornment I like. You're doing yourself more harm by only letting people use those 16 languages.
Additionally, in the process of mimicking code, the only thing I could do was think about what I was writing - and in some cases I discovered that I would have done it differently than some of the libraries I use every day.
Take the Scala example. I would NEVER type "@SerialVersionUID" with correct casing. I'd maybe type "@Ser" and then auto complete. Or "@SV" and then auto complete. I can't recall the last time I typed an entire type name. Or finished braces using Enter + "}" instead of CTRL-SHIFT-Enter.
The UI is well made though.
so my question to you is, what if a tool has a framework that allows you to get a lot done with significantly less coding but lacks autocomplete, would you not consider it?
Full disclosure, I am the founder of a browser based IDE software company so my take may be biased, but I have also written enough code to kill a horse :)
We currently don't have code completion though it is on the product road map. Our middle-ware however almost completely eliminates writing code for doing C.R.U.D operations, sending email, uploading files, doing configurations and using http restful services... I think such advantages greatly outweigh the lack of code completion.
I do concede though that maybe in your specific case, code completion is a major productivity booster.
Intellisense in general is kind of expected now in any IDE; it is like the buttons in your car to slide down your windows (old enough to remember the handles :) ), they are nice and expected but you wouldn't base your buying decision purely on that.
Who are you arguing against though? Nobody ever made that claim, or as far as I can tell, even implied it.
No, but it can be inferred.
I agree that code completion and framework choice can be mutually exclusive; my general point is that a developer's decision to use a tool should consider other productivity factors, not just the expected ones.
I don't think so. We ought to be able to describe our own experiences without making a claim about productivity in general. It seems clear to me that peeters was doing exactly this, and not implying that his experience ought to be indicative of others.
There's a neat part of the article that might better demonstrate what I'm talking about.
---
> Because I was young, super-anal, and wasn't on SSRIs back then, I once asked Carmack why he didn't use libraries for common functions that he could share between engine revisions. Carmack's a super-nice guy, but on this one instance he used the "Well, I think my methods work pretty well..." defense. I never suggested coding style changes again.
> But, really, for him it made no sense to share code, because, like a bee, it was just as fast to write new code. The template was in his head, he types really REALLY fast—why bother importing something?
> Don't take this to mean his code was spaghetti—it was actually some of the easiest-to-understand code I've ever worked with. It has an almost indescribable quality of "obviousness." Like, you know when a really good teacher explains something, it seems obvious? That's what his code was like. I mean, OF COURSE there's a loop where you service the pending events and call a refresh on the UI layer.
The bottleneck in programming lies in designing something that works correctly, understanding someone else's design or legacy code, designing test cases, debugging problems, addressing performance issues. It is a brain-bound problem, unrelated to motor skills.
I have never thought "this project would have succeeded if only everyone on the team had been a faster typist!"
On the other hand, when we are on the same page, slow typing is seldom a problem.
Also, the UI when you make a mistake is confusing, I didn't realise I had to backspace and correct it. While that seems obvious in hindsight, I actually opened it in a different browser to make sure I wasn't just hitting some bug before reading the comments here and realising.
Sorry, but it's probably worth about $25 to me, not $600.
And a lot of other language/libraries/frameworks are also silently presume auto-completion support. Even on C/C++. I highly doubt usefulness of this even on other languages.
Maybe it would be more important to be familiar with specific auto-completion IDE behavior rather than training yourself to type faster.