I don't think that keyboard only coding is even faster, I can beat top competitive programmers on speed and I use mainly the mouse to navigate and select code. It is possible keyboarders could be faster than me if we have to write huge amounts of boilerplate code, like 1 line of code a second, but otherwise using a mouse shouldn't be a disadvantage.

Tip for more productive mousing: Disable "mouse acceleration" or "enhance pointer precision", it makes it harder for your body to adapt to the mouse. I can move it to where I look at the screen in an instant with almost no adjustment needed at the end since when that if off world space and screen space aligns. Of course I learned that skill to select and order units quickly in RTS games, but it works just as well for selecting and manipulating code.

What kind of code are you writing that requires or benefits from a mouse? For selecting code I can imagine it helps. A touchscreen is just as good. But for writing it?

I haven't used a mouse to drive coding since a C++ course in high school almost 20 years ago. The only thing I use it for is selecting and copying code.

For navigating and writing code it's all emacs, tmux, terminals and unix tools.

> A touchscreen is just as good.

A touchscreen is a nightmare for manipulating small text.

> For navigating and writing code it's all emacs, tmux, terminals and unix tools.

Well, if you never leave emacs/vim and related workflows, you never know anything else.

For writing code, yes, keyboard is best. For navigating, debugging and other things a TUI does not cut it. And I spend a lot more time reading and thinking about code than actually writing it.

A particular example that stands out in the Linux world is GDB's CLI interface. It sucks. Its TUI is better, but still bad compared to a good GUI.

> navigating, debugging and other things a TUI does not cut it. And I spend a lot more time reading and thinking about code than actually writing it.

as an emacs user, I find it extremely painful watching my colleagues clicking around in eclipse to navigate the code base[1]. It feels just so inefficient and slow.

[1] I assume eclipse actually has keyboard shortcuts, but they do not seem to be used by my eclipse-using colleagues.

Slow? It is definitely faster to use a mouse to click a word in a text than use the keyboard to get to it. (I have no idea about how Eclipse does it, though).

Otherwise we would be playing RTS games with the keyboard. (I am a competitive RTS player, so I can almost instantly hit any point in the screen, which helps; a good mouse also helps a lot).

> For navigating, debugging and other things a TUI does not cut it. And I spend a lot more time reading and thinking about code than actually writing it.

Pure TUI is not optimal, but it still beats available mouse-based interface. At the very least, moving around the code is much faster with incremental search than with scrolling and spotting.

I'm still waiting for a code reading program that supports drawing on top of the code and that would otherwise behave like an infinite desk with (searchable, linkable, annotateable) code printouts on it.

> At the very least, moving around the code is much faster with incremental search than with scrolling and spotting.

A GUI does not necessarily imply scrolling to find something.

I use it all the time to cut, paste, copy, find and replace selection, indent or dedent specific lines. I can get by just fine using for example vim, but I am much faster with a mouse based interface since mouse based selection is much faster and more flexible. Sure keyboards have some shortcuts for specific kinds of selections, but with a mouse I can select exactly what I want in a fraction of a second.

The only real advantage to a keyboard only interface is the ability to automate steps, but I feel if you feel a need to automate your code writing then it would be better to refactor the code to require less boilerplate.

Labview code is something you usually don't write. It's common enough in research when working with hardware.

https://en.wikipedia.org/wiki/LabVIEW

addendum: It also allows you to create visual spaghetti code with the data pipes, which is much closer to real spaghetti than the text-based version.

At least an order of magnitude? That's interesting, considering that even mediocre code jockey can make $100k a year, that must mean you make at least a million a year?

That's not a terribly unreasonable claim for a consultant on a particular job. The issue is you can't usually fill your schedule with such jobs.

That sounds perfect to me, I'd love to just work 2-3 months out of every year and call it good.

Do you happen to have any insight as to what kinds of specialties allow for these kinds of lucrative short term opportunities?

My biggest problem with my erstwhile career was that the only good opportunities I've ever heard of were only full time.

In the software world? Not sure, I mostly do niche environmental consulting, engineering, modeling, etc. and have a reputation for solving weird problems for people in a variety of industries.

Typically the lucrative work I'm talking about happens when I just negotiate a flat fee and it doesn't take me that long. Companies often like that because it limits their risk compared to my hourly rate.

But honestly most consulting in most fields should have this type of negotiating opportunity. As long as it's not a field with some sort of existing convention of hiring lots of "independent contractors" that probably should be employees.

As for time in... It takes a lot for maybe a year or so to get enough reputation that you aren't hustling for clients. But now they call me and I decide whether or not I can take them. I get a lot of last minute rush gigs which are usually the best money if I want to take them. Often I don't, and I throw out a "fuck you go away" number and then they jump at it anyway.