4 ms·

The speed of operating your tools definitely has an impact on your development velocity. Invisible interruptions like switching from keyboard to mouse add up.

by 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.

by fouc 7y ago

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.