Live data from Hacker News

Show HN: I wrote an entire book to build a mouseless dev environment

themouseless.dev

151–160 of 221 posts

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#151

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.

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

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#152

I never got the hate of mouse in the dev community. Isn’t most of work browsing code and Googling things? Making a mouse a way to navigate way more efficient than a keyboard? It seems retrograde.

if you want to sculpt, better get to know the chisel.

The keyboard is inevitable for writing (if that's what we talk about), so if any, the mouse may be dispensable. And reducing moving parts can help to improve focus.

P.S.: when approaching the cliff, 'retrograde' may be the thing.

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#153
post #26

Earlier quoted context omitted.

We're all mortals :). Like other endeavors of growth, a good approach is to regularly make a small effort to learn a little more about something (like your tools, which includes keyboard shortcuts). As one simple example, if you have a URL somewhere and you want to quickly open it in a new window, you just use the keyboard shortcuts to copy (which hopefully everyone knows), switch to browser (alt-tab or cmd-tab or ev…

While all true IME the ever growing stack of libraries, frameworks, languages, and infra tools one must learn leaves little breathing room for modest gains in text wrangling. Most of my time isn't spent slicing and dicing snippets or juggling windows. Rather it's thinking, planning, a bit of experimentation, reading, repeat. And powerful, built-in auto complete with visual IDEs like IntelliJ or PyCharm make them hard…

Even still, cmd-opt-b when your caret is on a name jumps you to the code where that thing is implemented. A few shortcuts like that make navigating so effortless that you are free to focus on the code and libraries.

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#154

Earlier quoted context omitted.

For most of us mortals, typing is not the bottleneck when we are writing code, an article or whatever. In any case, keyboard-only interfaces make the assumption that you know all of the shortcuts for each program you use. And boy they are inconsistent. They also offer zero discoverability for someone that did not read the manual (see the vim jokes). I like software that offers both good pointer UI + robust keyboard s…

I don't think vim could speedup your typing speed (unless you are using macro/`.`). I think the benefit of vim is mostly about code navigation, and this is the bottleneck (at least for me) when writing code: jumping around definitions, from and to different region, without having to reach the mouse and click on different buttons. Good pointer UI + robust keyboard shortcut is quite good, but sadly most of the GUI appl…

Home row cursor movement is one of my favorite things about vim. Same with w, e, b, ^, $, and the c or d commands used with them. I think just knowing a small few navigation keys and a small few modification keys, your capabilities are multiplied.

That’s why I use the vim plugins for vscode and jetbrains IDEs. Best of both worlds.

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#155

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.

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.

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#156
post #43

Surprised to see no mention of Acme here. As much as I love keyboard-based tools, I must begrudgingly admit that from a scientific standpoint it is much quicker to use a pointing device because there is no recall associated with the action, you intuitively drive the device. However that said, there is appallingly little effort to actually utilise this power. Anyway, this is a roundabout way of saying that I don't thi…

Relevant article from the Plan 9 wiki: https://9p.io/wiki/plan9/mouse_vs._keyboard/

And a quote from there: "The basic summary is cursoring around required a higher level of mental planning to organize the interaction, which apparently obscures the perception of the passage of time--think of being deeply engaged in something and being surprised when you look at a clock-- whereas the use of the mouse was done at a lower, mechanical level that left the mind free for higher things, such as complaining about the mouse."

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#157

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.

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.

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#158
Nobody has mentioned keynav[0] yet. "It lets you move the pointer quickly to most points on the screen with only a few key strokes."

With some software or web pages you're better off with this kind of workaround than installing browser plugins or configuring the software, especially if you use them infrequently.

Another tip: use ' in firefox to search for links when the focus is not in a text area. For instance, typing |'comment| (without the pipes) here selects a link containing "comment", and you can circle through other matches with F3 / Shift-F3 just like regular searches.

[0]: https://www.semicomplete.com/projects/keynav/

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#159

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.

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.

Re: Show HN: I wrote an entire book to build a mouseless dev environment

#160

"I don't want to try i3 or Vim. What's the point using less of the mouse? Such a waste of time!" That was me, 6 years ago. My colleagues were pushing me to try the tools they were already using for years. They are very good developers, so at the end they convinced me to look at them. I had to admit I was wrong. I fell in love with these tools. From there, I built my system step by step, configured it as I wanted, acc…

Your video was a little too long for my taste. You maybe could create a shorter video showing the full speed of productivity gained by getting rid of the mouse. I imagine some workflow every programmer does all the time: - read code - check docs - write code - test and look at logs I use the keyboard for 80% of my work and regularly people (including devs) are in awe of the speed of my movements. I would even go so f…

Thanks for your wishes :)

That's a good point. To me, the speed is not the first appeal for this kind of system, but more the flow as you say, and it's difficult to demonstrate that on a video :D but I'll think about that for sure.

Post reply on HN