I conclude that they either have never been blessed with the opportunity to use proper tools, or that they think that you have to suffer for your art to be truly skilled.

I rather enjoy not suffering from repetitive stress injuries myself, so variety is good.

“You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.”

- Miyamoto Musashi

The main difference is really between an IDE massively focused on one language and a general purpose editor which is inevitably less integrated.

But I basically agree in that I think it basically doesn’t matter. Especially as far more time is spent reading code or thinking about it (or inserting it) than on editing operations. The only things which I think are really useful to have are jump-to-definition (and return) and fast easy to access search.

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.

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.

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.

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.

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.

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

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.

Your post has me looking back at the opt-in samples of my experience and realizing that when they were opt-in, I never considered them to be "pair programming". It's always just been "healthy onboarding" or "healthy collaboration". My current org's obsession with enforcing PP for its own sake as a measured performance metric has conditioned me to squirm when I hear the term, but that's just a branding/emotional response problem. Thank you for the beautifully articulated check.

That's just bad, imho, I would have the same response.

And thanks a lot for the kind words, much appreciated!

“This could be a blog post.”

You can't imagine how many times I thought this too, and yet here I am 10-15 years later still writing comments... Ha, it's never too late I guess.

If you wanted to set up a little blog beforehand in case people want to follow you, I can wait. whistles

As for the blog, I'd rather do it once and for all (I have a cleaner / LTS mindset), so that will require a little planning (e.g. domain and URLs, as I hate dead links with a passion). I just don't have the time now, hopefully before year's end. So don't wait on me!

And thank you so much for the interest. It may be pride but I'm very grateful. Have a great one!

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.

The candidate who most impressed me this way used Visual Studio.

It would definitely seem a little odd if someone used no keyboard shortcuts at all (like, edit->copy, edit->paste), but even then I can't imagine really dinging someone for it if they get through the problem at a reasonable pace.

There’s nothing like doing so that will make you appreciate auto-indent, auto-closing braces, and efficient keyboard navigation.

Poor inference => Poor programmer

I mean, if you're too conservative to use modern technology, this doesn't seem like the right field to work in.

That said, the vim guys do seem to get good work done somehow...

That's just flamebait.

I like vim and Emacs. There are good reasons to use either of them (or e.g. their bindings in "superior" tools).

Still, the quoted "must use vim/Emacs!" is just stupid. The point is that the work needs to get done.

That kind of attitude ("why aren't you using <insert personal preference bloated point-clicky IDE released 6 months ago>?") is just as obnoxious as what is in the article.

I wish people hated me for what I actually say, not what they imagine my attitude is :)

i’ve screened, interviewed and hired several engineers. the only time something related to tools like this came up was when using a specific tools was critical to the role.