Typing speed? Not sure how much code people here write per hour, but I doubt typing speed is a real issue (the ratio of my staring at the screen thinking versus coding is probably 10:1).
Typing speed is important for the reason the article mentions -- micro-interruptions. Most of the time, you just have to type a few words, and the editor will complete the rest for you. Fine. But a lot of the time, you are typing a symbol for the first time, and autocompletion doesn't really help. It breaks your flow if you can't type this symbol quickly and correctly the first time. (It is also worth pointing out that I can type most words faster than it would take to cycle through potential expansion candidates, so I only use it for moderately-long identifiers. Abbreviation expansion becomes less of a time saver when you learn to type more quickly.)
Anyway, a few months ago, I decided I would learn to properly touch-type (and increase my typing speed). It was very difficult at first -- I couldn't type at all, and even simple programming made me really mad. A few months later, I can type significantly faster, and I make many fewer errors. (As an aside, I don't think touch-typing was really designed for programmers. All the important symbols end up under your pinkys, which is not very comfortable. So I compromise and type some symbols like ()- with my ring-finger. This probably reduces speed, but it doesn't hurt my hand.)
The common response to typing is "programming is not about typing, it's about thinking". Sure, that's mostly true. Nobody expects you to sustain 120 wpm typing for eight hours a day. But, it's very helpful to type quickly in bursts, to get your ideas in to code form as quickly as possible. Sketching out that idea in 2 minutes instead of 3 means that your brain has more time to think about the problem, and has to waste less of its time babysitting your fingers. I know I get mad when my typing speed is delaying me from trying an idea as quickly as possible. That's why I decided to do something about it.
I'm glad I spent the time to practice typing. It has made programming and writing more enjoyable, and didn't take much time or effort at all. The dismissive attitude of "programming doesn't require typing skills" is extremely naive.
The dismissive attitude of "programming doesn't require typing skills" is extremely naive.
Shrug... Well I say that because that's my experience. I've never really been concerned with micro-interruptions. I guess I'm surprised this bothers people so much (It's the macro interruptions that hurt me more). I've been in situations where I've been unable to type (or type quickly). I learnt and grew as a coder more in those times that any other - so a different experience really.
So, yeah, typing is great. It's a very handy skill to have. It probably helps a coder a lot, and it's a good thing to know. However, I don't think it makes you a better coder.
You're wrong. Learn to type well and then come back and tell us it didn't make you a better programmer.
If you don't know how to type, then you're wasting brain cycles looking for keys when you have to type, cycles that would otherwise be spent thinking up good identifiers and nice function names. Not knowing how to type also means you'll choose terse identifiers rather than clear ones because it's too much work typing longer names.
Typing well is a critical skill for a programmer and the only programmers who don't think so are the ones who can't type.
I "type" most words when I'm programming by hitting two or three initial letters, and then pressing M-/ to complete (emacs does that by scanning all open buffers for something that matches, usually quicker than anyone could type the whole word).
I don't choose terse identifiers, I choose long ones that I know emacs will be able to find completions for easily.
Typing faster helps everyone. Programming is more than just writing code. It's communicating with people, documenting bugs, documenting code, etc. If you're telling me you never run into a situation in which being able to type faster would help you, then I'm saying I don't believe you.
This very conversation is easier to have if you can type your thoughts as you have them whilst not being distracted by hunting and pecking.
What about the cost of not learning it? Like potential neck pain, slower thinking, over-reliance on code completion (it takes your brain some processing time to decide what will be long enough to produce the right completion but not too long to waste keystrokes), less ability to communicate effectively.
And the cost of learning it is laughable. You just have to practice a bit for 3 days to learn to get the right fingers on the right keys from memory. The key to learning quickly is that you try to reproduce some text on the screen while NOT LOOKING at the keyboard, and you go as slowly as you need to avoid looking up (well, down), it doesn't matter if it takes 15 seconds for one keystroke at first. The important thing is to try a recall from memory at all costs before you finally know you've really completely forgotten and then look it up. And you do like this for each letter. You'll reduce your latency and learn the whole layout quite fast. After that it's just a matter of practicing for a few weeks and you'll be up at a reasonable 30wpm in no time.
If you don't have to look at the keyboard then you know how to type. Don't get hung up on whether it's proper or not. When people say someone doesn't know how to type, it explicitly means they have to look at the keyboard.
however, as a programmer who does have to type a lot, using the correct fingers would help you in the long run because at some point you will have repetitive stress problems, so bit the bullet and do it. The cost is tiny and certainly nothing to fear or put off.
Do you really spend that much time typing? I spend most time thinking :/
Obviously there's a lower bound, if you have to look at the keyboard then you probably need to improve, but the importance of being able to touch type perfectly is overplayed.
Guess what, if you typed faster you'd spend even less time typing... or, you'd spend just as much time typing but would produce more. Or a bit of both.
It could be that those who don't think so are people who already type fast, and so never notice much of a difference.
I'm in the "typing speed makes no difference" category. However, I already typed 80+ WPM when I started programming (thank you, AIM and MUDs), so I really have no comparison for what it's like to type slowly, except for the couple weeks I spent learning Dvorak. It's really odd for me to look at this thread and see people talking about bringing their typing speed up to 60 WPM.
I could imagine that typing speed would be a problem if you're stuck at 20 WPM or something. I just assume that anyone who does anything significant with computers is at 60 WPM+ already, and at that speed, it really doesn't make a huge difference.
That reminds me of the reasoning behind wanting faster processors in our personal computers. From one (mistaken) perspective, you could argue that there is no justification for buying a faster processor because it will just be idle for more than 97% of the time you use it. The better argument is that we are justified in desiring a faster processor because the length of the CPU bursts is a much more important metric.
Learning vim (edit: or emacs) is another step in the same direction (less transition to the mouse.) I agree that raw typing speed isn't that important. What I like is being able to see what is in my mind show up on he computer without too much hassle, so I can focus on a) perfecting my mental model of how the system behaves and b) creating a new model for the system.
Programming isn't about typing. Therefore, you shouldn't be sitting there thinking "how do I type this"? Typing being second nature frees up more time for thinking.
There are at least two people who I'd dub "great hackers" who type essentially, two fingered. One of them suffers from horrible RSI (but, at one point, had the company hire someone to be their hands).
The other didn't grow up around computers/type writers (growing up in the 1940s/1950s in Soviet Union), didn't really heavily program until after graduate school and for the first decade mostly programmed by writing code on paper and having it punched onto cards.
Gah - when I was out of school, they could have paid me minimum wage and I'd be thrilled to take a job to be a great hacker's "hands." I can't imagine many better ways to see a master work.
There was a guy I worked with who was one of the most productive people on the team and a great coder. He could type fast, but not by touch - hunt and peck all the way. When he had his ergonomic evaluation, after seeing the way he typed, the evaluator recommended he try voice recognition software. He didn't.
I knew a guy who was wheelchair bound with no use of one hand and the other only semifunctional, able to peck out keys one at a time.
I can't claim he was a great hacker, but he managed to hold his own on the team and even outperformed some. If he can be competent with that level of impairment, I think it's got to be incorrect to claim all great hackers are great typists.
I believe that corresponds with comfortable familiarity with and proper use of one's tools.
I view a non-touch-typing hacker/coder much like a carpenter who drives nails using a hammer's handle. (The inevitable reaction from both camps: Hey, what's your problem? I'm using my tools to get the job done!)
Typing ability is an effect rather than a cause of hacking ability.
It's not so that you can type code quickly. The bottleneck in coding is always the thinking time, or you're using an overly verbose language.
Typing is important because hackers communicate with one another using a keyboard. I've worked with programmers who couldn't type quickly enough to have a comfortable conversation over IM. It's torture.
If you can't type, it's probably because you're not communicating enough. Hacking is not a solitary activity, and it's mostly not coding.
If the carpenter who used the hammer handle only had to drive one nail instead of the regular fifty, then that might be totally worthwhile (Naturally, this would never be the case for carpentry, but it certainly is for coding).
Not sure I can really argue against the analogy - because you can take it anywhere. e.g. A lumberjack can rip through a tree, but a good carpenter can cut a piece of wood so that it uses the grain, there isn't waste, etc, etc. In the context you're working in, being quicker is never as good as getting it right.
You could argue that a carpenters output is limited by their use of tools. If they can't nail or saw fast enough then no amount of carpentry imagination is going to help.
What I'm saying is that I don't think this is the case for typing and coding. A coder could type quickly and produce reams and reams of really bad code - this is happening every day. Another coder could type 1 wpm and still produce something of immense value every day.
"A coder could type quickly and produce reams and reams of really bad code - this is happening every day. Another coder could type 1 wpm and still produce something of immense value every day."
Huh, ok. Now, if you take the 1 wpm programmer that produces great code and teach him to type 50 wpm, what happens?
I claim there is no programmer in this world who wouldn't end up more productive (be it by a small or huge margin) if he learned to type faster. And given the ridiculously small ratio of effort to rewards at the lower stages (say, below 50wpm), saying it's not worth the effort is like saying buying more RAM or disk-space or bandwidth is not cost-effective today.
Yes, agreed. The play on words was amusing to me (odd sense of humor alert!) It seems there is a lot of ambiguity between the way you and the GP used the word.
Though, this topic got me thinking. Unless you are using speech to text, I think that how you interface with the computer is fundamental to the act of programming. I do not think that abstraction is essential to programming. Much to the chagrin of my abstraction-loving nature, consistent procedural code can be easy to read and follow. For higher-order OOP, an understanding of abstraction and encapsulation is very necessary.
I can understand the "that's not the bottleneck" argument. But the problem with going too far down that road is this: Imagine if you had to wait one second for your keyboard to respond to any key you type (and one second between keystrokes). You could still produce awesome code and be a great hacker, but can you look me in the proverbial eye and tell me that this would not handicap you in some way? Think about the commands you type really quickly on the command line without a second thought. Think of the messages you send off to friends really quickly.
Generalize this to the experience of using the Internet. Since great entrepreneurs are relentlessly resourceful, they can make great things come to pass using a 56k dialup connection, but I'm sure you wouldn't want a connection as slow as that. Why? If you want to think of it in terms of the argument you made above, then it's obvious that the bandwidth is unimportant because your connection is idle for the bulk of the time you spend using the Web.
The important thing is not thinking of this as a comparison between how much time you spend typing versus thinking. It's more about maximizing the responsiveness between you and your computer. The less friction there is during these small bursts of interaction, the better.
"Imagine if you had to wait one second for your keyboard to respond to any key you type (and one second between keystrokes)"
I've had this experience, while traveling I had a really slow internet connection and had to do some work via ssh to fix a server, it was hell...
You go through that experience one time and you learn that being able to automate as much as possible with tools like capistrano and sprinkle for server setup is crucial (it also started me on the path to keep my /etc configuration files on git...)
I personally touch-type maybe 50 wpm but that's for documentation, not code. If you are attempting to create code at the speed that you type, you are insane ... or you will be soon, when you try to debug it.
If someone was lucky enough to think faster than they could type, they'd be able to think twice before they added more code to a program - a good thing!
Just think. Is wpm a measure of a great writer? How could it be a measure of a great programmer.
I'm not sure what a "great hacker" is. Are they something like sysadmin or maybe someone who does security?
See my comment above. I spend a lot of time typing, even though I reuse a lot of code. (I write a lot of code: http://github.com/jrockway)
It's nice to think that code types itself, but it doesn't. If you have no ideas, then it doesn't matter how fast you can express them as code. If you have a lot of ideas, though, you don't want to wait for your fingers to slowly tell them to the computer. You want the computer to know quickly, so you can move on to the next task. That's why typing is important. There is no brain/computer interface yet, so you have to do it with your hands and the keyboard. Suboptimal, but them's the breaks.
What other things do you do regularly? Write emails, specs, contracts, documentation?
Of course you probably also do other stuff than typing on a keyboard. It's just that the keyboard often is the most efficient interface between you and your main tool, your computer.
I think typing speed is a good competency to improve to be more efficient in the next few decades.
I think that if you don't have to think about typing at all you don't have to schedule time-slices for thinking and editing. It's just a side-effect that your fingers work really fast for almost anything when they're autonomous: this is the thing referred to in the article.
For example, I often observe that I have two parallel processes going on: thinking and editing. I keep editing the file, correcting formatting, keeping lines beautifully cut and moving stuff around _autonomously_ while I'm still thinking about the _actual_ problem. It's like biting your nails when thinking over something: it just happens, you don't _do_ it. Doing stuff that you don't need to think about at all actually helps me in the thinking part.
To be able to do that you have to master the keyboard, both for writing text, writing code and moving around (and you need emacs to move around quickly enough, imho hehe:)). I wouldn't want to imagine synchronising my trains of thought over a mental mutex in order to switch between editing and thinking.
This means that there's minimal latency over your thinking and what gets into the program. If it's low enough, programming becomes fluid as you couple thinking and changing the source code in nearly real-time. I could guess that many poor souls who have spent way too much time over the keyboard have realised this.
The way I think of it - typing fast is an indication of familiarity with the environment.
You can't be a good hacker without having logged countless hours in front of the screen, banging out code, emails, etc...
I guess I wouldn't arbitrarily set the cut off at some fixed value like 60wpm, but if you are slow at typing and need to look at the keyboard, you probably don't have enough experience.
Agreed. The best programmer I ever knew had severe carpal tunnel syndrome and had to use Dragon Dictate. Yet he could do things that teams of other programmers couldn't.
Before I arrived he had made a network monitoring system more than 100x faster when the team responsible for it was on vacation. (The CEO reported that the events now flew by, whereas before you could easily observe the event stream crawling.) He later single-handedly implemented and maintained the router configuration system for an ISP that spanned the US and there was never a single (non-cosmetic) bug reported against it in the 10 years I was there, even in the face of changing requirements, new hardware, and the company constantly coming out with new connectivity services.
He had learned to program in the days of punched cards, and he would do all his thinking on paper before he started coding. He would then dictate the code, top to bottom, without any bugs.
There's more to code than just code. Most of us write a lot of emails every day, and hopefully most of us write a fair bit of documentation also :)
How efficiently you can communicate with the machine is critical in programming because of the above, not because you're somehow faster at typing code - your brain cannot generate code at 60wpm anyway. Typing quickly, though, certainly takes away barriers to trying new things and prototyping really quickly.
I agree, but in practice I feel annoyed by my typos, and not being able to type directly what I think. It's a nice feeling of skill, to dance across the keyboard, with a seamless brain-computer connection. Like playing a video game.
I've tried to learn touch-typing a few times, but it makes my hands sore in a worrying way.
Another resolution is typing more slowly, and not caring so much about typos, since it doesn't really matter.
Not to mention typing fast continuously is asking for RSI. I can type pretty fast if I try, but apart from the thinking vs typing ratio, I also avoid typing fast or continuously because I know that's asking for a relapse of my RSI. And whatever I gained by typing faster will be lost by orders of magnitude if that happens.
The argument for touch typing to avoid distractions I agree with, but not raw typing speed.
It's not a "real" issue, so much as a proxy. I've never seen a good hacker look at their keyboard, whereas there are plenty of people that get out of flow looking for a symbol.
If a person can't type, I simply assume they're a noob and don't want them on my team. I don't expect them to have a very different ration of thinking vs. coding though :)
I can see that - it's like musicians that don't rate musicians who can't play piano.
But - I guess I've seen a few counter-examples in coding - e.g. I used to know a mainframe guy who had arthritic pain. He coded very slowly indeed, but it flowed out of him flawlessly.... So I tend not to have that bias.
If I met someone who wanted to get into programming, I certainly wouldn't say "practice your typing" - I'd say, "read these books".
I probably wouldn't tell somebody to go practice typing either, but that's not because it isn't important. I would just take it for granted that they could already type.
Actually, I'd say 'read these books' and 'learn to type'. Half of development is communication - writing emails, comments, docs, whatever. Why wouldn't one benefit from entering text more quickly?
Anyways, there are probably a subset of slow typists that are good programmers. But I'd be surprised if they weren't the exception.
I used to feel this way, but then I discovered that the resident uber programmer at work is a two finger typist. He is brilliant; used to work at Xerox Parc and all that.
I think it's not so much a question of typing quickly as a question of wether you are able to type without thinking and looking at the keyboard... When you get to that point, typing is just like walking you don't think about it and think about your code instead.
Agreed. Typing speed is very important when writing new features, but reading and comprehension speed is much more important for when you are fixing bugs in a multimillion line codebase.
These things aren't really enough. They're more of "things you need to know be a computer hobbyist". I did put together a quick list once -- for an HN post asking what should someone learn as undergrad if they wish to be a web developer -- of things I'd prefer a back-end developer that I would hire to know:
Of course, knowing these things (or really, knowing anything) doesn't make you a hacker quite yet, it's a title one earns within a community by contributing to it. As cliche as it is, "how to become a hacker" covers this part:
Visual Studio is a very powerful editor. Everything that you can do in Visual Studio through menus you can do through the keyboard. In fact you can setup visual studio to use emacs shortcuts ( http://msdn.microsoft.com/en-us/library/ms165509(VS.80).aspx ) and I'm sure it exists for Vim and etc.
People who believe the tools make the hacker are naive at best and would probably think the person with the best shoes wins the race. Not true when it comes down to it, the person driving those tools, whether they can type 60 wpm or use Emacs, is the one who is responsible for the creativity and output.
I think the author needs to step back and see if his priorities are in the right spot.
"We haven't met a single great hacker that relied on an IDE, although we hear they exist."
The implication here is completely in the negative.
Further, it's like saying "If you want to be a hacker, use English measuring units because we've never any met any great hackers who use the metric system."
Just because a bunch of rails hackers don't use an IDE doesn't imply the contrapositive.
I hear they exist, I've just never met them. That could be my sampling bias. None of the people around me relying on IDEs are great hackers.
Instead of arguing about what might have been implied in what I wrote, I'd rather you introduced me to people you consider great hackers that use an IDE. Know any?
The people who I work with whom I regard as great hackers work almost exclusively in the real time embedded space (industrial automation systems) and don't have web notoriety.
It is about using the right tool for the right job.
What you appear to be doing is using the right tool for
your job, then concluding that everyone should use
your tool for their job.
Here is a great IDE hacker:
John Carmack, ID Software, uses Visual Studio
I work at a game startup making their first PS3 title.
The C++ engine team does development in Visual Studio
and the tools guys do python outside of an IDE.
Do you really think that is evidence that all
the tools guys are superior to the engine guys?
It doesn't, both can be great and both can be mediocre.
"One of my early mentors taught me that "it's not how fast you type but what you type" that matters."
Are you saying an increase in typing speed brings a proportionate decrease in thought quality? Otherwise you obviously end up more productive if you increase typing speed.
People who compare poor coders who type fast with great coders who type slowly are utterly missing the point. Typing faster is about self-improvement. It's about having more fun at coding while being more productive. If it also makes you better than the next programmer, then great, but it's not the point.
Well. I type 100-120 wpm, use Emacs, use primarily FAR or cmd.exe (bash in *nix), and prefer not to debug. I suck though.
Apparently, these four things are not enough to be a great hacker. What I seem to lack is the mental capacity to clearly see problem out of the box as my friends (great hackers) do so I have to use all the tools I can to keep up.
it's the kind of sober, relaxed look at a problem that I think separates great from mediocre. The relaxedness and calmness with which hackers attack problems -- most people I know and myself would be anxious and pissed off about a problem. Hackers on the other hand are comfortable and relaxed with problems, seeing them as something, that is fun to solve. They are like cats who play with the mice before they catch the prey; they are confident in their ability to solve the problem, and completely free of tension or stress.
I have that some of the time but very very rarely and I can say, no editor can even come to the performance-enhancive qualities of Zen-like centering.
Well, it's more "Core competencies of hackers in the C/C++/UNIX/Scripting/Web tradition."
Most of the great Windows hackers I know use Visual Studio. Most of the great Java hackers use IntelliJ. Of course, people in the UNIX/web tradition would probably not admit that great hackers exist in those cultures, but they've put out some pretty impressive software...
Also - I suspect that great UNIX/web hackers don't use IDEs because the IDEs for those languages suck. I work on a C++ web team. If you glance around our monitors, everyone has the same setup: 4-6 terminals, 3-5 emacs/vim windows open, and Firefox. The funny thing is, many of us are ex-Java programmers, and we all used either IntelliJ or Eclipse in our Java programming days. And would love to use something like IntelliJ for C++, but we took one look at the C++ support in Eclipse and ran back to vim.
As a data point, I have Firefox building under Eclipse/C++ reasaonably well. I had to hack the Eclipse project files to tell it where all the headers were (arguably more a fault of the Mozilla build system), but since then it's worked surprisingly well. I'm under the impression that Eclipse's C++ support had improved substantially in the last year, although I can't say for sure, since this was the first time I'd used it.
"We haven't met a single great hacker that relied on an IDE, although we hear they exist."
Sounds like GiraffeSoft folks don't use languages with type info and a graphical debugger. I certainly wish TextMate could handle static info and had a JVM debugger. I would love to code scala in TextMate.
The IDEs are too heavy. I don't like them. But if you want/need a debugger and type info for refactoring and exploration, you don't have much choice.
The other three items they list seem on target. The one about great coders don't use IDEs is highly dependent on what language and kind of code your writing.
Without getting in to what those preferences are, that being a different can of worms, I think it's likely that there are trends in the language preferences of great hackers. The existence of these trends means that tools that work well with the languages great hackers prefer will be more popular with great hackers.
The static analysis done by heavy IDEs isn't the only way to have large amounts of information about code available in the editor. Using Emacs with Slime, the editor has a huge amount of information about your code because it's communicating with the Lisp runtime that's evaluating it.
"We haven't met a single great hacker that relied on an IDE, although we hear they exist. " -- fcuk you. Really. Just an over generalization/stereotyping at its worst.
I am a good hacker, and yes I use an IDE (eclipse to be exact). I have to code java for living (mobile), and I think I am one of the earliest developers in java, and i used to use Textpad, and Vim at my early days. I guess, in your eyes that makes me a "better developer", but the truth is that some IDEs really make your life easier. Much easier.
In mobile you have to re-invent the wheel over and over again. From UI, to basic things as a string tokenizer, and it is impossible to memorize everything (some of your team memebers implement different functionalities). IDE's auto completions are very very useful. Also the refactoring facilities and debuging tools are really useful.
I do use Vim for programming in LUA (does it make me cool?), and I really miss a lot of these tools. Simple things like variable highlighting, jump to definition are missing, and it makes the code a pain to read (especially if it s not yours). If you decide to change a variable name, good luck, you have to do string search/replace, and the potential for errors is huge.
While a good programmer HAS to be comfortable and good in command line, just because they use an IDE doesn't make them less of a people.
And the best programmers I have had the chance to work with used IDEs. These guys implemented a LUA VM in J2ME from scratch, in a couple of months.
I have noticed that this really shallow and douchebag-y attitude comes from people that use mostly Ruby. It seems that in their eyes, if you don't use Ruby and textmate, you suck.
Also, I think the main point of what you quoted is that the additional level of abstraction does more harm that it does good when it comes to hacking, not everyday 9-5 in the office type programming.
As I mentioned a bit earlier in this thread, people are confusing programmer and hacker. The two terms are not synonymous.
This should just be titled "Tools used by people with great hacker egos but may or may not actually be great hackers", because these are not predictors of great hackers.
I confess I just didn't read this - 'core competencies' came up on my watch list as almost surely spam.
And if typing speed is more relevant than thinking depth then I probably made the right decision in that Gladwell blink moment.
In another recent HN post, several people had a similar reaction to "shop" as in 'work for a great ruby shop'...
Heres a partial list of non-sequiturs -
six sigma
isoN000{0}
skillset
core competencies
coder
java [ contentious, I know, C++ is borderline ]
loc - lines of code
metrics / kpis
candidate
coordinate
role
leadership
deliverables
Competency is particularly insidious - being merely competent rules out any kind of real craftsmanship, or "Xen and the art of Motorcycle maintenance" connection to the thing your doing. If your competent, you've checked a box, and thats the wrong reason to do anything.
I don't want to start a war but I'd say that this list is about the differences between a Windows VS Linux developer. The thing behind what is said is "get your eyes off of the nice UI. Look and type code".
Uses the tools listed in the article on windows. (well, windows equivalents anyhow)
I think the message was more of "Know your tools, know them well. Know them, and what they are capable of so that you may wield them to their fullest potential". For software, this involves reading the source when it's available.
Could that be because you exclude Windows hackers from your definition of "hacker"?
I know some folks on the Google Toolbar team. I don't use Toolbar, and neither do any of my friends. It's desktop software, and desktop software for Windows, so I mostly ignore it.
But their installed base is huge. I'd wager that if you added up the combined user base of every Web2.0 startup mentioned on this site, you still wouldn't equal the number of Google Toolbar users worldwide. Are they still hackers?
Could that be because you exclude Windows hackers from your definition of "hacker"?
No, it couldn't. The person out of the group of people that I know personally that I consider "hackers" uses Windows primarily, and knows a bunch of crazy APIs inside and out. He does whip out VS for some stuff, but the vast majority of his code is written in emacs.
I'm not saying the article is right all the time, but I think it's a pretty good rule-of-thumb.
My experience coinciding with the article is more of a function of "I really don't know very many people" than "I don't think there can be such a thing as a hacker that uses windows, or microsoft tools".
It was a genuinely better browser than the competition. The problem isn't that IE6 wasn't a good browser - it's that IE6 was a great browser in 2001. But in 2009 - it's not really up to scratch.
How do you define "great hackers" then? If you go with the ESR "A great hacker is someone who other great hackers consider a hacker" definition, you get a very inbred, circle-jerk culture. (Which seems to have happened in various corners of the free software world, BTW.) Of course a great hacker would use the same tools as you then...that's how you know they're a great hacker, after all. ;-)
Other metrics like "A great hacker is someone who writes lots of code" are equally ludicrous, because then only Java and Cobol programmers end up as great hackers since those languages are so much more verbose than everything else. ;-)
The benefits of knowing your tools extend even beyond your personal productivity. Such knowledge often presents opportunities to save the hides of other individuals.
For instance, I'm in a very, very large company (anyone in law, science, or journalism has used our products). I recently saw three separate requests for ~80 hours and $7000 of contractor time each to manually add serialVersionUIDs to serializable Java classes.
Eclipse, which we're paying* IBM to use, has a nice code refactoring tool that makes the entire process three clicks and about 30 minutes of twiddling your thumbs. I saved one and a half months of FTE time, and $20,000 by simply knowing what the tools we were already paying for could do.
*Yes, I'm aware that Eclipse is Free Software; we're using IBM's rebranded Rational Application Developer. Yes, I'd rather use Eclipse and Tomcat instead of RAD and WAS. No, I'm not bitter.
The thing behind what is said is "get your eyes off of the nice UI. Look and type code".
Hmmm. I'm currently working a project targeting handheld devices written on the .NET Framework, meaning I'm using Visual Studio. Currently, my IDE looks a whole lot like an instance of Vim or TextMate--no widgets outside of the top level menu displayed, and I typically use keyboard shortcuts for builds, navigating, etc, etc.
In fact you could condense all of these into "know your tools extremely well", and you can take it further to "optimize yourself/your environment relentlessly".
I've known great hackers who used Eclipse, sam, acme, Brief, UltraEdit and everything under the sun.
Working with someone who doesn't know their chosen tools (people who use menus to work their editor, hand edit things instead of using sed/awk/perl, etc) is extremely painful, and seeing someone profess to use a tool but not operate it well is a huge warning sign to me. Same with slow typists: pair programming with such sucks.
Great hackers create great works from within, not from their tools or their environment. Their core competencies are things like relentless self-improvement, not the use of a particular editor or a particular OS.
The author's list of core competencies (fast typing, command line, vim, Linux) sounds more like a list of cultural traits.
The point about text editors is absurd. One because comparing TextMate to vim or emacs is almost apples and oranges. And secondly because writing something Java without completions is going to be horrendously slow just because of all the arcane function and property names.
To me it's kind of a weird arbitrary divide to make. All the text editors mentioned offer IDE like functionality at various levels. They help you with various kinds of auto-complete, context sensitive help, etc. etc. Where is the line that when crossed makes it an IDE an not an editor?
To be fair to the author though, the phrase was "rely on an IDE", not "use an IDE" which is a little different.
I think a more valid way to look at it is that great hackers tend to use highly advanced editors and they totally own them from top to bottom - whether they are in an IDE or not. That might just mean that they have a completely customized eclipse setup and know every hotkey extension innately or (like myself) use powerful editor plugins like viPlugin to ratchet up the productivity.
I feel that this article is the sort I would not like to see on HN, because it can't teach anything to hackers. As seen by the discussion it elicited, it's just starting a write-only conversation with many elements of a flame war.
Glad someone else noticed that glaring oversight. If you haven't met a great hacker who doesn't use emacs/vim/textmate, then you need to get out more, you're a sheltered child.
"Let's not pick editor fights: the only 3 editors we know to be used by great hackers are TextMate, vim and emacs. The most productive hackers will often customize their editor heavily."
I think this is rather ignorant... eclipse >> vim or emacs. What's a hacker anyway? Presumably, they are talking about someone who writes code and IDEs make writing code easier.
I completely disagree with all four points. A hacker can only use TextMate, vim, or emacs? You kidding me? And who writes code at more than 60 wpm -- writing code is a thinking sport, not a race to the finish.
Diving into a large codebase can be important for certain hackers, but honestly this sounds like a skill moreso needed for corporate programmers ...
So if I learn these things, will I miraculously be transformed into a great hacker? Or will I have wasted my time, while others spent the same time launching several profitable web sites with Ruby on Rails?
I'd take problem solving ability and creativity over typing speed any day, but one area where typing speed seems to help is for live coding or instructing others...
well coding is not part of being a 'great hacker' according to this list... but the text editor you are using is part of it... Im not convinced to say the least, the word 'poser' comes to my mind, not sure why
I expected something that would include, at the very least,
Algorithms and Data Structures.
Software Construction is not the sole realm of the Hacker.
coder!=hacker
Coding is not the sole realm of Software Construction.
It is too bad that so many people totally mix concepts up like that, playing fast and loose with synonyms in that manner is like wearing a sign saying "I am an ignorant two bit tech person in a hurry"
Say, what about Cray, when he toggled an entire OS (that he designed) into a machine (that he designed) through the front panel switches, in Octal? AND IT WORKED.
