7 ms·

> Listen: do not use the mouse! And use Vim or Emacs. Professional programmers only use keyboards and this kind of editors. Sure...

chrisseaton 7y ago
Where does this kind of nonsense attitude come from? I use GUI editors, use the mouse, don’t use magic keyboard shortcuts, and I manage to produce software like everyone else.
- fouc 7y ago
  The speed of operating your tools definitely has an impact on your development velocity. Invisible interruptions like switching from keyboard to mouse add up. That said, even though I use vim/keyboard mainly, I still have embarrassing habits like opening a new vim for each file and cd'ing & ls'ing around to find the files.
  - chrisseaton 7y ago
    If I can do the job and produce results as fast as needed why do you care about how fast I’m switching between mouse and keyboard? And we’re not typing programs in from magazines like in the 80s here. My bottleneck is nearly always thinking time. Typing time is irrelevant.
    - fouc 7y ago
      I guess it depends a lot on the sort of programming that you're doing. But there's still a lot of activity around the challenging bits that don't require a lot of thinking. Things like organizational/cleanup, some types of refactoring and testing, dealing with git and other commands.
      - drewrv 7y ago
        For some people/tasks, these are the exact types of things accomplished faster in an IDE.
    - alasdair_ 7y ago
      >My bottleneck is nearly always thinking time. Typing time is irrelevant. I don't agree. Code is communication. Imagine you had to sound out every letter of every word while speaking - it wouldn't just be slower, you'd lose your place or simply not bother saying certain things.
      - chrisseaton 7y ago
        And yet... I still manage to produce award-winning breakthrough software.
    - ashkankiani 7y ago
      It depends on the type of work you're doing. I've been using vim for many years and I am frequently limited by my typing speed when it comes to some things like scripts. When it comes to work that doesn't require deep thought, it matters. I'm much more likely to achieve a task that someone else might dismiss "because it requires too much typing." It also helps a lot with refactoring, which is mostly a mechanical process. I'm much more willing to do large refactoring than some others due to the fact that I'm very good with my editor. Point is that you're right, but you're also describing a subset of problems which require deep thought, and not fully considering the benefits that might be had from the alternative.
  - levythe 7y ago
    Frankly, typing the code is the least important part of software development.
    - K0SM0S 7y ago
      Indeed. Probably like, what, 10-20% of our time? Maybe 25%-30% on a good week? I'll even argue the opposite: there are many ways to write code slowly that yield better results. - sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie. - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
      - fstopmick 7y ago
        > - sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie. This is precisely why I never learned to type faster. The time between my thinking and typing is spent auditing my thinking. > - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better. Ehhh. A lot of programming is creative and imposing my creativity onto someone else (or having someone's styles/preferences imposed upon me) usually doesn't help much. Any time I've pair-programmed (~6 years of professional programming) my productivity dives down to 1/3 while my quality sometimes increases marginally. It's a low ROI in my experience which is why I'll never advocate for it. But I'll play ball if the org I'm working for embraces it. There are social/team-building/ other nontechnical benefits to consider as well (although I'd argue that tasks built specifically for these purposes would be more efficient).
        K0SM0S 7y ago
        “The time between my thinking and typing is spent auditing my thinking” Apparently this isn't limited to code for you, what an eloquent way to put it. I'm definitely stealing this, thanks! ;) “creative” I hear you loud and clear, I tend to be the same. But pair-programming has its uses, imho, which become more obvious as a lead tbh. One fundamental premise for me: voluntary participation only, it's usually bad to force it on people. Briefly and imho, there are two kinds: "true pair" as equals (or close enough), and "asymmetric" (more like mentor-mentee). Let's tackle the latter first: - To onboard a new team member, it's invaluable in helping them build confidence fast, learn the codebase, and integrate the team's standards and "best practice" — more to-the-point and pleasant than reading a bunch of docs: have a co-worker tell it to you, like it is, on-the-fly and on a need-to basis. Saves loads of time searching in the dark. Typically short-term (first few weeks). - Transfer: it dramatically raises the operational level of the mentee. It effectively 'multiplies' the mentor's superiority, 'spreads it' throughout the team so to speak, as other people pick up the good stuff directly from the mouth of the lion(s). This can be long term, depends on who you've got. I love when juniors are free to pair-prog with a willing senior, you get them out of the green zone in months as opposed to a year or more. The benefit compounds over time, if you're building a team, it's really second-to-none (no bootcamp, no code review, no nothing comes even close). You do 'lose' one member for some time, few hours per week, but it's often a welcome walk in the park for the senior, and a really good time for the junior. It's everything you can never get in school, because it's ad hoc training both for the job and the company/team's culture/standards. Now for pair-prog 'as equals'. Again, as a free association between two people who choose each other. The idea here is that in terms of human brain you've got twice the 'RAM' (attention, memory, etc) and twice the 'CPU' (raw 'intelligence'). So it works ideally like a distributed system (not a failover/HA!) where each person focuses on different aspects. There is typically not much room for 'style' or 'creativity' insofar as it's decided before we write, through discussion. When one writes, the other should not interject for small details like “why not inlining here? why this name and not that name?” unless it's not just preference but mistakes or architecture etc (“did you know you could avoid all that and just write <some idiomatic thing>?” — or “this is correct but here's how we'd rather write it: ..., because it's more readable / idiomatic”) The point is to share the thought process, and then have one set of eyes writing while the other thinks. It's thinking even slower, using two brains if you will, not at the same level — one, writing, is bound to think 'closer' to the code, while the other, watching, is free to roam-think around, look up some other file, specs, etc. Even write docs as we go, which may save time later (there is no 'rule', I only care for what actually works in practice and everyone's different so...) E.g. I don't like pattern-shoving but finding one is a common 'eureka' by the observer. (I'd typically want a common 'pair' machine + both bring their own laptop, if doing this in person, so that each is free to do stuff. Sometimes we just off the pair prog to go faster (when human goes monkey because we have to). What I find is that: - explaining my 'plan' before anything is written helps make it clearer, and spot mistakes early on. - others generally have half the good ideas seen in the final code. - working with someone who knows a language/framework/whatever tool better makes me better with it; but it works both ways, as explaining/teaching also makes me better. - as you said, some tasks are well-suited for this exercise, others not so much (it's usually obvious once we start). And it's really that, an "exercise" more than anything else. It's slow, like 2-3x slower, but you feel very solid. I don't have numbers but I'd say easily 50-75% less mistakes in the final code, and most importantly code that's almost certainly readable by others. It gets really good when domain knowledge is much wider, e.g. I know http server stuff, and you know microservices well... you can see where this takes us quite naturally — hence, again, free association, let people talk, get to know each other's forte and weaknesses, and work in complementarity. Sorry for a long piece. I just found so much benefits in pair programming that I have to share this stuff. More than skill, it builds self-confidence and awareness. You're not the same after pair programming for 'some time' on a regular basis (and by 'you' I don't mean the programmer, I mean the entire person). Because you've realized everyone's just as limited and capable as you, and suddenly there are much less artificial barriers in your mind. “I can do this” — why? because you've seen others do it first hand, picked up from them, saw them do the same with you, and eventually we feel more like humans just trying our best instead of doubting our every commit.
  - deleted 7y ago
    [deleted]
  - hilbertseries 7y ago
    The bottleneck for writing code is very rarely how fast you can type it.
  - gen220 7y ago
    I know it’s a bit against the spirit of this thread, but at the risk of not being taken seriously. If you’d like to do that a little faster, you can use `fd` piped into `fzf` as a fuzzy file finder. Once it’s set up properly you’ll never go back! NERDTree might also be helpful. IME, Vim is mostly nice because of the satisfaction derived from these incremental improvements.
  - stjohnswarts 7y ago
    Meh, I spend a lot more time thinking than I do typing. I do prefer Vim keystrokes, but my editor these days is VS Code with vim keystroke extension installed.
- cryptozeus 7y ago
  Its implied for 10x dev ha ! I agree with you, nothing wrong with using mouse.
- rb808 7y ago
  You're obviously not a professional lol. Did you get paid this month? I'm the same IDEs all the way.
- thrower123 7y ago
  I tend to see this attitude most from people that insist on using a tiny under-specced laptop, rather than a desktop with multiple screens and a proper desk. I conclude that they either have never been blessed with the opportunity to use proper tools, or that they think that you have to suffer for your art to be truly skilled. I rather enjoy not suffering from repetitive stress injuries myself, so variety is good.
  - patrickskim 7y ago
    Tools make not the master. “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.” - Miyamoto Musashi
- dan-robertson 7y ago
  To be fair, emacs is a gui program with real mouse support and images and menus and buttons. But it doesn’t really do popups and most people hide the menu bar and toolbar. The main difference is really between an IDE massively focused on one language and a general purpose editor which is inevitably less integrated. But I basically agree in that I think it basically doesn’t matter. Especially as far more time is spent reading code or thinking about it (or inserting it) than on editing operations. The only things which I think are really useful to have are jump-to-definition (and return) and fast easy to access search.
  - Izkata 7y ago
    Likewise, there's gvim, also with buttons/menus/etc.
alecbenzer 7y ago
Lol this was so out-of-place given that most of the other advice was pretty reasonable. It would definitely seem a little odd if someone used no keyboard shortcuts at all (like, edit->copy, edit->paste), but even then I can't imagine really dinging someone for it if they get through the problem at a reasonable pace.
otras 7y ago
This reminds me of one of the worst things about interviews I’ve had (with big companies and small): typing code into a shared Google doc for phone screens. There’s nothing like doing so that will make you appreciate auto-indent, auto-closing braces, and efficient keyboard navigation.
closeparen 7y ago
The kernel of truth in this is: have mastery of your tools. All else being equal, someone in a Vulcan mind meld with their editor comes across as more impressive than someone tripping over it. The candidate who most impressed me this way used Visual Studio.
crtlaltdel 7y ago
bwaaahahahahahaha i’ve screened, interviewed and hired several engineers. the only time something related to tools like this came up was when using a specific tools was critical to the role.
BurningFrog 7y ago
Personally, I'm biased against people who use 40 year old editors written for a completely different world, when we have modern and far superior tools. I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in. That said, the vim guys do seem to get good work done somehow...
- rgoulter 7y ago
  > if you're too conservative to use modern technology, this doesn't seem like the right field to work in. That's just flamebait. I like vim and Emacs. There are good reasons to use either of them (or e.g. their bindings in "superior" tools). Still, the quoted "must use vim/Emacs!" is just stupid. The point is that the work needs to get done.
- throwaway87378 7y ago
  > I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in. That kind of attitude ("why aren't you using <insert personal preference bloated point-clicky IDE released 6 months ago>?") is just as obnoxious as what is in the article.
  - BurningFrog 7y ago
    I said nothing of the kind. I wish people hated me for what I actually say, not what they imagine my attitude is :)
mxcrossb 7y ago
Why do good programmers fail technical interviews? It’s because people like this are doing the interviewing...
patrickskim 7y ago
Professional writers only use keyboards. Better typing => Better writer Poor inference => Poor programmer
stjohnswarts 7y ago
I agree. One of the best coders I ever met had only used Visual Studio for the past 20 years. He knew the guts of Windows and X86 hardware unlike anyone else I've ever met and he is SORELY missed (retired last year) where I work even we've mostly moved over to Linux based apps. He was also pretty decent at the Linux kernel, but still edited code in his beloved Visual Studio even then :) . So no, vim and emacs do not make you a great programmer.

chrisseaton 7y ago

Where does this kind of nonsense attitude come from? I use GUI editors, use the mouse, don’t use magic keyboard shortcuts, and I manage to produce software like everyone else.

fouc 7y ago
The speed of operating your tools definitely has an impact on your development velocity. Invisible interruptions like switching from keyboard to mouse add up. That said, even though I use vim/keyboard mainly, I still have embarrassing habits like opening a new vim for each file and cd'ing & ls'ing around to find the files.
- chrisseaton 7y ago
  If I can do the job and produce results as fast as needed why do you care about how fast I’m switching between mouse and keyboard? And we’re not typing programs in from magazines like in the 80s here. My bottleneck is nearly always thinking time. Typing time is irrelevant.
  - fouc 7y ago
    I guess it depends a lot on the sort of programming that you're doing. But there's still a lot of activity around the challenging bits that don't require a lot of thinking. Things like organizational/cleanup, some types of refactoring and testing, dealing with git and other commands.
    - drewrv 7y ago
      For some people/tasks, these are the exact types of things accomplished faster in an IDE.
  - alasdair_ 7y ago
    >My bottleneck is nearly always thinking time. Typing time is irrelevant. I don't agree. Code is communication. Imagine you had to sound out every letter of every word while speaking - it wouldn't just be slower, you'd lose your place or simply not bother saying certain things.
    - chrisseaton 7y ago
      And yet... I still manage to produce award-winning breakthrough software.
  - ashkankiani 7y ago
    It depends on the type of work you're doing. I've been using vim for many years and I am frequently limited by my typing speed when it comes to some things like scripts. When it comes to work that doesn't require deep thought, it matters. I'm much more likely to achieve a task that someone else might dismiss "because it requires too much typing." It also helps a lot with refactoring, which is mostly a mechanical process. I'm much more willing to do large refactoring than some others due to the fact that I'm very good with my editor. Point is that you're right, but you're also describing a subset of problems which require deep thought, and not fully considering the benefits that might be had from the alternative.
- levythe 7y ago
  Frankly, typing the code is the least important part of software development.
  - K0SM0S 7y ago
    Indeed. Probably like, what, 10-20% of our time? Maybe 25%-30% on a good week? I'll even argue the opposite: there are many ways to write code slowly that yield better results. - sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie. - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
    - fstopmick 7y ago
      > - sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie. This is precisely why I never learned to type faster. The time between my thinking and typing is spent auditing my thinking. > - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better. Ehhh. A lot of programming is creative and imposing my creativity onto someone else (or having someone's styles/preferences imposed upon me) usually doesn't help much. Any time I've pair-programmed (~6 years of professional programming) my productivity dives down to 1/3 while my quality sometimes increases marginally. It's a low ROI in my experience which is why I'll never advocate for it. But I'll play ball if the org I'm working for embraces it. There are social/team-building/ other nontechnical benefits to consider as well (although I'd argue that tasks built specifically for these purposes would be more efficient).
      - K0SM0S 7y ago
        “The time between my thinking and typing is spent auditing my thinking” Apparently this isn't limited to code for you, what an eloquent way to put it. I'm definitely stealing this, thanks! ;) “creative” I hear you loud and clear, I tend to be the same. But pair-programming has its uses, imho, which become more obvious as a lead tbh. One fundamental premise for me: voluntary participation only, it's usually bad to force it on people. Briefly and imho, there are two kinds: "true pair" as equals (or close enough), and "asymmetric" (more like mentor-mentee). Let's tackle the latter first: - To onboard a new team member, it's invaluable in helping them build confidence fast, learn the codebase, and integrate the team's standards and "best practice" — more to-the-point and pleasant than reading a bunch of docs: have a co-worker tell it to you, like it is, on-the-fly and on a need-to basis. Saves loads of time searching in the dark. Typically short-term (first few weeks). - Transfer: it dramatically raises the operational level of the mentee. It effectively 'multiplies' the mentor's superiority, 'spreads it' throughout the team so to speak, as other people pick up the good stuff directly from the mouth of the lion(s). This can be long term, depends on who you've got. I love when juniors are free to pair-prog with a willing senior, you get them out of the green zone in months as opposed to a year or more. The benefit compounds over time, if you're building a team, it's really second-to-none (no bootcamp, no code review, no nothing comes even close). You do 'lose' one member for some time, few hours per week, but it's often a welcome walk in the park for the senior, and a really good time for the junior. It's everything you can never get in school, because it's ad hoc training both for the job and the company/team's culture/standards. Now for pair-prog 'as equals'. Again, as a free association between two people who choose each other. The idea here is that in terms of human brain you've got twice the 'RAM' (attention, memory, etc) and twice the 'CPU' (raw 'intelligence'). So it works ideally like a distributed system (not a failover/HA!) where each person focuses on different aspects. There is typically not much room for 'style' or 'creativity' insofar as it's decided before we write, through discussion. When one writes, the other should not interject for small details like “why not inlining here? why this name and not that name?” unless it's not just preference but mistakes or architecture etc (“did you know you could avoid all that and just write <some idiomatic thing>?” — or “this is correct but here's how we'd rather write it: ..., because it's more readable / idiomatic”) The point is to share the thought process, and then have one set of eyes writing while the other thinks. It's thinking even slower, using two brains if you will, not at the same level — one, writing, is bound to think 'closer' to the code, while the other, watching, is free to roam-think around, look up some other file, specs, etc. Even write docs as we go, which may save time later (there is no 'rule', I only care for what actually works in practice and everyone's different so...) E.g. I don't like pattern-shoving but finding one is a common 'eureka' by the observer. (I'd typically want a common 'pair' machine + both bring their own laptop, if doing this in person, so that each is free to do stuff. Sometimes we just off the pair prog to go faster (when human goes monkey because we have to). What I find is that: - explaining my 'plan' before anything is written helps make it clearer, and spot mistakes early on. - others generally have half the good ideas seen in the final code. - working with someone who knows a language/framework/whatever tool better makes me better with it; but it works both ways, as explaining/teaching also makes me better. - as you said, some tasks are well-suited for this exercise, others not so much (it's usually obvious once we start). And it's really that, an "exercise" more than anything else. It's slow, like 2-3x slower, but you feel very solid. I don't have numbers but I'd say easily 50-75% less mistakes in the final code, and most importantly code that's almost certainly readable by others. It gets really good when domain knowledge is much wider, e.g. I know http server stuff, and you know microservices well... you can see where this takes us quite naturally — hence, again, free association, let people talk, get to know each other's forte and weaknesses, and work in complementarity. Sorry for a long piece. I just found so much benefits in pair programming that I have to share this stuff. More than skill, it builds self-confidence and awareness. You're not the same after pair programming for 'some time' on a regular basis (and by 'you' I don't mean the programmer, I mean the entire person). Because you've realized everyone's just as limited and capable as you, and suddenly there are much less artificial barriers in your mind. “I can do this” — why? because you've seen others do it first hand, picked up from them, saw them do the same with you, and eventually we feel more like humans just trying our best instead of doubting our every commit.
- deleted 7y ago
  [deleted]
- hilbertseries 7y ago
  The bottleneck for writing code is very rarely how fast you can type it.
- gen220 7y ago
  I know it’s a bit against the spirit of this thread, but at the risk of not being taken seriously. If you’d like to do that a little faster, you can use `fd` piped into `fzf` as a fuzzy file finder. Once it’s set up properly you’ll never go back! NERDTree might also be helpful. IME, Vim is mostly nice because of the satisfaction derived from these incremental improvements.
- stjohnswarts 7y ago
  Meh, I spend a lot more time thinking than I do typing. I do prefer Vim keystrokes, but my editor these days is VS Code with vim keystroke extension installed.
cryptozeus 7y ago
Its implied for 10x dev ha ! I agree with you, nothing wrong with using mouse.
rb808 7y ago
You're obviously not a professional lol. Did you get paid this month? I'm the same IDEs all the way.
thrower123 7y ago
I tend to see this attitude most from people that insist on using a tiny under-specced laptop, rather than a desktop with multiple screens and a proper desk. I conclude that they either have never been blessed with the opportunity to use proper tools, or that they think that you have to suffer for your art to be truly skilled. I rather enjoy not suffering from repetitive stress injuries myself, so variety is good.
- patrickskim 7y ago
  Tools make not the master. “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.” - Miyamoto Musashi
dan-robertson 7y ago
To be fair, emacs is a gui program with real mouse support and images and menus and buttons. But it doesn’t really do popups and most people hide the menu bar and toolbar. The main difference is really between an IDE massively focused on one language and a general purpose editor which is inevitably less integrated. But I basically agree in that I think it basically doesn’t matter. Especially as far more time is spent reading code or thinking about it (or inserting it) than on editing operations. The only things which I think are really useful to have are jump-to-definition (and return) and fast easy to access search.
- Izkata 7y ago
  Likewise, there's gvim, also with buttons/menus/etc.

alecbenzer 7y ago

Lol this was so out-of-place given that most of the other advice was pretty reasonable. It would definitely seem a little odd if someone used no keyboard shortcuts at all (like, edit->copy, edit->paste), but even then I can't imagine really dinging someone for it if they get through the problem at a reasonable pace.

otras 7y ago

This reminds me of one of the worst things about interviews I’ve had (with big companies and small): typing code into a shared Google doc for phone screens. There’s nothing like doing so that will make you appreciate auto-indent, auto-closing braces, and efficient keyboard navigation.

closeparen 7y ago

The kernel of truth in this is: have mastery of your tools. All else being equal, someone in a Vulcan mind meld with their editor comes across as more impressive than someone tripping over it. The candidate who most impressed me this way used Visual Studio.

crtlaltdel 7y ago

bwaaahahahahahaha i’ve screened, interviewed and hired several engineers. the only time something related to tools like this came up was when using a specific tools was critical to the role.

BurningFrog 7y ago

Personally, I'm biased against people who use 40 year old editors written for a completely different world, when we have modern and far superior tools. I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in. That said, the vim guys do seem to get good work done somehow...

rgoulter 7y ago
> if you're too conservative to use modern technology, this doesn't seem like the right field to work in. That's just flamebait. I like vim and Emacs. There are good reasons to use either of them (or e.g. their bindings in "superior" tools). Still, the quoted "must use vim/Emacs!" is just stupid. The point is that the work needs to get done.
throwaway87378 7y ago
> I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in. That kind of attitude ("why aren't you using <insert personal preference bloated point-clicky IDE released 6 months ago>?") is just as obnoxious as what is in the article.
- BurningFrog 7y ago
  I said nothing of the kind. I wish people hated me for what I actually say, not what they imagine my attitude is :)

mxcrossb 7y ago

Why do good programmers fail technical interviews? It’s because people like this are doing the interviewing...

patrickskim 7y ago

Professional writers only use keyboards. Better typing => Better writer Poor inference => Poor programmer

stjohnswarts 7y ago

I agree. One of the best coders I ever met had only used Visual Studio for the past 20 years. He knew the guts of Windows and X86 hardware unlike anyone else I've ever met and he is SORELY missed (retired last year) where I work even we've mostly moved over to Linux based apps. He was also pretty decent at the Linux kernel, but still edited code in his beloved Visual Studio even then :) . So no, vim and emacs do not make you a great programmer.