Yeah, people's strange fetish with programming really fast (e.g. "I use Vi because I can type faster in it, a mouse slows me down!") is completely out of touch with how I program professionally day to day.
For most code that I write there is a modicum of research (e.g. online docs, requirements, etc), some time spent thinking about how it should be laid out, and a whole lot of frameworking (e.g. putting the code into the agreed upon structures or interacting with the structures, which is often an internal research stage also).
The only thing I can imagine trying to write really really fast, is someone reproducing from memory various Computer Science 101 algorithms for funzies (you'd always use standard libraries in prod' anyway). Aside from that programming speed seems the opposite of how programming works.
Yet it is constantly talked out (e.g. "I purchased a $150 mechanical keyboard to type code better," "I use Vi/emacs because a mouse/IDE slows me down," "I code on the terminal because it has less distractions," etc).
>"I use Vi because I can type faster in it, a mouse slows me down!"
I use vim (or emacs) because the regex search/replace and macros mean that when I need to edit the same thing 5,000 times in a data file I don't need to fire someone in India for a week to hunt them down.
Typing speed has very little to do with it, but avoiding the mind numbing tedium of going from underscore variable names to CamelCase or vise versa is a godsend.
>I code on the terminal because it has less distractions,
I code on the terminal because when I use tmux I can have the equivalent of 30 IDE windows open each looking at a snippet of code I need. Until I have have a monitor wall I can carry around with me that can display a few dozen different windows there really is no comparison.
It's not about speed, it's about keeping in your head what you're doing. For example, there is a function call in a source file to fn_ive_never_seen(), in an IDE the best you can hope for is for it to dig up where it was defined, and maybe the header file if it's some C type language.
I can open a new window on the terminal, grep the whole source base for this function, see where it is used, where it is defined and with sed edit all those definition to take an extra variable I need by just stringing together a few commands in yet another window.
Again, it's not about speed, it's about getting a computer, which is very good at being pedantic, to make sure that every last mention of something is changed the way you want it to be changed.
I thought the same thing until I learned Vim. It's not about typing faster, it's about being able to make changes almost as fast as you think them up, and staying in flow instead of getting bored and frustrated.
Writing raw code makes up a TINY proportion of what I do professionally day to day. Writing long code in a single stretch (e.g. without researching, checking other parts of the codebase) almost never ever happens (because code isn't created in a vacuum).
Also I am well versed on Vi's functionality. I choose to use an IDE.
I thought people bought mechanical keyboards because they were easier on the fingers? The keys often require less activation and you can prevent the bottoming out you get with the cheap keyboards.
For most code that I write there is a modicum of research (e.g. online docs, requirements, etc), some time spent thinking about how it should be laid out, and a whole lot of frameworking (e.g. putting the code into the agreed upon structures or interacting with the structures, which is often an internal research stage also).
The only thing I can imagine trying to write really really fast, is someone reproducing from memory various Computer Science 101 algorithms for funzies (you'd always use standard libraries in prod' anyway). Aside from that programming speed seems the opposite of how programming works.
Yet it is constantly talked out (e.g. "I purchased a $150 mechanical keyboard to type code better," "I use Vi/emacs because a mouse/IDE slows me down," "I code on the terminal because it has less distractions," etc).