Guys, could you please take a look at the project I am working on: http://keybr.com I thought it could be a good touch typing trainer web application.
Programming's Dirtiest Little Secret
81–90 of 106 posts
Re: Programming's Dirtiest Little Secret
#82Guys, could you please take a look at the project I am working on: http://keybr.com I thought it could be a good touch typing trainer web application.
Re: Programming's Dirtiest Little Secret
#83Earlier quoted context omitted.
Can you convince me you're just as fast if you have to look at the keyboard? I bet you'd be faster if you didn't need to.
Can you convince me that the quality of a programmer has anything to do with speed? (At least, to the degree that keyboarding skills would make a measurable difference. I'm not arguing that it's ok to spend all week building a single function.)
Image if you had to stop and think to use the mouse.
Re: Programming's Dirtiest Little Secret
#84Earlier quoted context omitted.
Can you convince me that the quality of a programmer has anything to do with speed? (At least, to the degree that keyboarding skills would make a measurable difference. I'm not arguing that it's ok to spend all week building a single function.)
When you don't have to think what you're typing, your mind is free to think about the code. The more you think about your code, the better you are. Image if you had to stop and think to use the mouse.
Besides, I don't really think about kicking a soccer ball, but I certainly look at it when I do.
Re: Programming's Dirtiest Little Secret
#85Guys, could you please take a look at the project I am working on: http://keybr.com I thought it could be a good touch typing trainer web application.
Re: Programming's Dirtiest Little Secret
#86If you need to type that much, to where whether or not you can touch type matters . . . you are doing something wrong. Saying touch typing matters amounts to stating that programming is actually carried out ON THE SCREEN YOU ARE TYPING ON and I could not disagree with that more . . . programming takes place in the mind of the programmer, typing on the screen is a byproduct. I can't wait to see how his argument holds…
programming takes place in the mind of the programmer, typing on the screen is a byproduct As he says in the article, the actual programming is not what requires much typing. It's communicating with others on IRC (or e-mail, whatever you kids use these days), typing documentation, writing blog posts, etc. that require typing skills. I will agree with him on this. I don't type much when actually programming, but I do…
IRC, email, are secondary in importance.
Documentation and code comments should be concise.
"succinctness = power"
Does this sound familiar to anyone?
Re: Programming's Dirtiest Little Secret
#87Guys, could you please take a look at the project I am working on: http://keybr.com I thought it could be a good touch typing trainer web application.
Re: Programming's Dirtiest Little Secret
#88He should not try to hard so be funny. He is not succeeding, he's just drowing his point in superfluous words.
Re: Programming's Dirtiest Little Secret
#89Accoridng to Mythical Man-Month average programmer produces 2000 LOC per year. Other data I've seen backs this up. Typing speed is not really a problem.
Umm, nice rationalization. But that's 2000 lines of debugged, documented code. It takes a lot more typing than just 2000 x 80 characters. The article basically describes why. Plus he's not talking about "average."
Re: Programming's Dirtiest Little Secret
#90Incidentally, Steve brought up an interesting topic. Musicians practice by playing fast, then slow, then medium. Fast, slow, medium. Over and over. That seems like a good way to write software. You first try to implement your idea as quickly as possible, stopping to think only when necessary. The goal is to not spend too much time overthinking the implementation -- you want to find out if your idea is worth executing…
That's exactly where I thought he was going... I just recently started writing software >40 hours a week, and have been constantly torn between "getting things done" and "doing things right". The best way to program well might very well be a variation between the two modes.
1. Make it work. 2. Make it right. 3. Make it fast. 4. Make it small.
#1 first, then if you have the need, #2. If you have a need, #3. If you have the need, #4.
It's a lot easier to make it right once you've made it work.