5 ms·

I don't know about you, but when I'm programming I probably spend 95% of the time thinking, so making navigation faster won't affect my overall efficiency much.

I don't know about you, but when I'm programming I probably spend 95% of the time thinking, so making navigation faster won't affect my overall efficiency much. Come to think of it, I'm also thinking while typing and navigating so I'm not sure this would save any time at all. It might _feel_ faster though, which might increase the well-being of some developers.

haspok 6y ago
^^^ this If you are constrained by the speed of your typing while "programming", you are not really a programmer, you are just a secretary with a typewriter.
- thanato0s 6y ago
  I didn't write this book for everybody to type crazy fast, I wrote this book for people to try to stay on their keyboard. You're switching a lot between documentation, your browser, your shell, your IDE, your debugger, and all your tools when you're coding. What I'm describing in the book can really help you not always moving your hand between the mouse and the keyboard. You think it's not a problem? Well, you should still try to see if you're right. It won't cost you anything: I've many free articles on my blog, linking to other interesting resources too, so be my guest :) I'm sure you'll learn some stuff.
Uberphallus 6y ago
The "95% thinking" trope is fake or I'm really weird, because half of the time I'm navigating/comparing/reading code/docs/tests which would usually involve switching to mouse and looking through taskbars to find the particular piece I want. Sure, actual writing is 5%, but the 95% remaining isn't just thinking, so it also benefits from muscle-memory switching to docs/test/code panes. My dev env is mouseless (I use Vim and AwesomeWM instead, though) except for everything corporate (Gitlab, notably) and it always feels like a drag and slow AF. Only now I added vim-mr-interface and even with its shortcomings it's like night and day.
miguelrochefort 6y ago
I don't know about you, but for me thinking is almost impossible without writing, drawing, or interacting with some external medium. I can't just sit still and think deep thoughts. This only works for very shallow thoughts. I used to think this was a property of my aphantasia. However, in recent years, I've heard a lot of people claim that writing is thinking. In fact, most writing out there is an artifact of thought, and not designed to be read by others. Few people recognize that distinction, and that's why good writing is so rare.
- thanato0s 6y ago
  I'm writing for a long time and I agree with that. But I'll still continue to try producing the best thoughts / writing I can till I'm dead :D maybe I'll never write something good, but at least I tried.
kamaal 6y ago
The point is these things are wrong sold. The speed of writing code like you have already noted is already is not biggest bottleneck in software development. However what these kind of books/posts fail to sell is as much as software development is about building code to automate things, at some point in time one wonders if software development itself can be automated to a very large extent. The answer is writing code is a way of hand writing structured text. Therefore code should be generated like the very way we generate XMLs or JSONs. Compilers are a tool does that for a fixed set of syntactical things. Now is it possible to have some kind of means, methods and techniques for general code editing/generation. Note this has nothing writing code faster. But this has to do with human labor required in achieving a thing. Eg. How many steps does it take to delete 10 lines of code with mouse vs typing 10dd in vim? Scale this problem for 500 lines. And see how deleting with a mouse requires one to execute as series of steps scrolling, selecting, hitting delete vs 100dd. Now how many takes does it take to delete 1000 lines lines? Say selecting 100 lines at a time, scrolling, deleting. Basically 30 steps vs 1 step(1000dd) in vim. Notice how adding more lines to deleting in a notepad'ish editors increases complexity of deletion O(n) vs 0(1) in vim(ndd) See where this is going? Now take this one more example. Say you have three tabs. You have to copy 3 lines from the first tab, delete the current line in the next 2 tabs, and paste the copied lines from the first tab. Say you have to do this for 1000 times. Notice how you have to do 1 copy operation in first, shift across 3 tabs one at a time, while deleting lines and pasting them. If you had to do this, just imagine mental and physical labor into this. Now let me introduce you to this cool little thing in vim/emacs called a keyboard macro. You can tell the editor record these key strokes and play it for me n times. Congratulations now you just went K x O(n) to O(1). Let me make this even more attractive for you. Let's say for every line of editing in first tab, you had to make 3 edits in second tab, and for every 1 edit in the second, you had to make 10 in the third. Human's were not born for to do this kind of sisyphean tasks. We intelligent species were born to arrive at O(1) from every O(n^k) tasks life has to offer us. This is just one part. But there are many other examples like this. For example in Apache Pig, its common to write projections like $0 AS apple, $1 AS banana, $2 AS cherry... see no human should hand write code like this. It's not about speed. It's about wasted human labor. If there's structure to something it should generated. If there's structure to not just code but anything we do it must be automated. What needs to be taught is to see wasted effort and show us how to save it. Mouse or no Mouse, that's irrelevant. Every human should refuse to do work, that can be done with a computer.
ijoni 6y ago
Fighting your tools interrupts thought. A keyboard is a discrete mechanism: you can make mistakes using hotkeys, but the overall state space is infinitely smaller than the continuous state space of a mouse. That makes precision easier, which leads to a closer mapping between intent and action, which makes it easier to enter and maintain a flow state.
- Grustaf 6y ago
  I use the laptop trackpad and it feels incredibly natural, not like I'm fighting the tools at all. Two-finger scrolling, three finger swiping, incredibly convenient.

haspok 6y ago

^^^ this If you are constrained by the speed of your typing while "programming", you are not really a programmer, you are just a secretary with a typewriter.

thanato0s 6y ago
I didn't write this book for everybody to type crazy fast, I wrote this book for people to try to stay on their keyboard. You're switching a lot between documentation, your browser, your shell, your IDE, your debugger, and all your tools when you're coding. What I'm describing in the book can really help you not always moving your hand between the mouse and the keyboard. You think it's not a problem? Well, you should still try to see if you're right. It won't cost you anything: I've many free articles on my blog, linking to other interesting resources too, so be my guest :) I'm sure you'll learn some stuff.

Uberphallus 6y ago

The "95% thinking" trope is fake or I'm really weird, because half of the time I'm navigating/comparing/reading code/docs/tests which would usually involve switching to mouse and looking through taskbars to find the particular piece I want. Sure, actual writing is 5%, but the 95% remaining isn't just thinking, so it also benefits from muscle-memory switching to docs/test/code panes. My dev env is mouseless (I use Vim and AwesomeWM instead, though) except for everything corporate (Gitlab, notably) and it always feels like a drag and slow AF. Only now I added vim-mr-interface and even with its shortcomings it's like night and day.

miguelrochefort 6y ago

I don't know about you, but for me thinking is almost impossible without writing, drawing, or interacting with some external medium. I can't just sit still and think deep thoughts. This only works for very shallow thoughts. I used to think this was a property of my aphantasia. However, in recent years, I've heard a lot of people claim that writing is thinking. In fact, most writing out there is an artifact of thought, and not designed to be read by others. Few people recognize that distinction, and that's why good writing is so rare.

thanato0s 6y ago
I'm writing for a long time and I agree with that. But I'll still continue to try producing the best thoughts / writing I can till I'm dead :D maybe I'll never write something good, but at least I tried.

kamaal 6y ago

The point is these things are wrong sold. The speed of writing code like you have already noted is already is not biggest bottleneck in software development. However what these kind of books/posts fail to sell is as much as software development is about building code to automate things, at some point in time one wonders if software development itself can be automated to a very large extent. The answer is writing code is a way of hand writing structured text. Therefore code should be generated like the very way we generate XMLs or JSONs. Compilers are a tool does that for a fixed set of syntactical things. Now is it possible to have some kind of means, methods and techniques for general code editing/generation. Note this has nothing writing code faster. But this has to do with human labor required in achieving a thing. Eg. How many steps does it take to delete 10 lines of code with mouse vs typing 10dd in vim? Scale this problem for 500 lines. And see how deleting with a mouse requires one to execute as series of steps scrolling, selecting, hitting delete vs 100dd. Now how many takes does it take to delete 1000 lines lines? Say selecting 100 lines at a time, scrolling, deleting. Basically 30 steps vs 1 step(1000dd) in vim. Notice how adding more lines to deleting in a notepad'ish editors increases complexity of deletion O(n) vs 0(1) in vim(ndd) See where this is going? Now take this one more example. Say you have three tabs. You have to copy 3 lines from the first tab, delete the current line in the next 2 tabs, and paste the copied lines from the first tab. Say you have to do this for 1000 times. Notice how you have to do 1 copy operation in first, shift across 3 tabs one at a time, while deleting lines and pasting them. If you had to do this, just imagine mental and physical labor into this. Now let me introduce you to this cool little thing in vim/emacs called a keyboard macro. You can tell the editor record these key strokes and play it for me n times. Congratulations now you just went K x O(n) to O(1). Let me make this even more attractive for you. Let's say for every line of editing in first tab, you had to make 3 edits in second tab, and for every 1 edit in the second, you had to make 10 in the third. Human's were not born for to do this kind of sisyphean tasks. We intelligent species were born to arrive at O(1) from every O(n^k) tasks life has to offer us. This is just one part. But there are many other examples like this. For example in Apache Pig, its common to write projections like $0 AS apple, $1 AS banana, $2 AS cherry... see no human should hand write code like this. It's not about speed. It's about wasted human labor. If there's structure to something it should generated. If there's structure to not just code but anything we do it must be automated. What needs to be taught is to see wasted effort and show us how to save it. Mouse or no Mouse, that's irrelevant. Every human should refuse to do work, that can be done with a computer.

ijoni 6y ago

Fighting your tools interrupts thought. A keyboard is a discrete mechanism: you can make mistakes using hotkeys, but the overall state space is infinitely smaller than the continuous state space of a mouse. That makes precision easier, which leads to a closer mapping between intent and action, which makes it easier to enter and maintain a flow state.

Grustaf 6y ago
I use the laptop trackpad and it feels incredibly natural, not like I'm fighting the tools at all. Two-finger scrolling, three finger swiping, incredibly convenient.