Hacker News Reader

Comment by kafkaIncarnate | Hacker News Reader

I'm one of those 20 year VIM guys. After about 2 years I had a config that I haven't touched since. I could easily go without it, too, and frequently find myself on servers that I forgot to copy it over and didn't even notice. I usually only notice when I start trying to paste things (pastetoggle).

You need to learn VIM itself, not the configuration. Just leave the config alone unless you are trying to do anything with tab spacing, or shut off some annoying feature, really. My config is ~40 lines long and just sets some basic things, and uses zero plugins.

I think the problem is that people are focused too much on tooling than work/coding. This is true of almost every developer that I've noticed. Leave the tool (mostly) alone, just use it. Tooling creates so much wasted time.

View on HN

This is my experience as well. I've witnessed colleagues and other developers boast about their vim configurations and plugin ecosystems (and supposed gains in productivity) non-stop ever since I started working as a software engineer professionally.

Yet here I am with an almost out-of-the-box configuration, not a single plugin and my productivity/output is usually considered (far) superior to those of my peers.

I've never understood this widespread obsession with tooling. It's virtually never been the bottleneck for me in any software project I was involved in. The main obstacles I've found are usually of social and/or organizational nature, followed by sometimes (far off) the involved technologies. Tooling isn't a concern.

I don't see the connection between the two things that you seem to be making: namely between having a bare setup and an increased productivity.

We only have your word for it and it doesn't look factual to me at all.

F.ex. in Spacemacs the ability to fuzzy-find file names and file contents has saved me a lot of hours in the last several years. I absolutely don't see how I would work faster on those 1000+ files projects if I didn't have that functionality.

Want to elaborate on that point in particular? How does a naked editor help you in this scenario? Or will you claim that you know what's where in every single file in the projects you're working on?

Sorry to be a bit flippant but IMO you and your parent ventured way too deep into the "let's pat each other on the back about how minimalistic our environments are and how productive are we as a result" territory. Or "those crazy youngsters making their lives harder for no reason at all, am I right?" one.

I never said anything about not trying new tools, I'm talking about obsession, and it's become an addiction in some people. This is younger people than me AND older people than me. To the point that they aren't USING the tools they are learning, just learning how to use it in such depth that they paralyze themselves. It's not just one tool, either, they'll learn all the tools out there, find ways to solve problems in 10-20 different ways, then not solve anything applied or practical. When it comes to debugging they are just paralyzed because they don't know how the programming language works, just the tool.

It's perfectly fine if you are using the tool and have found a happy medium, which sounds like you have. You found a tool, you used it. You didn't spend years tweaking the tool, learning how to make it look pretty, then move on to another tool and bend that tool to basically be a clone of the first one you used.

I never said anything about a "bare" setup. I'm saying you should find what works for you and use it.

I shouldn't have to teach people who know how 900+ WMs/DEs/IDEs to work what a hosts file is, why setting 777 on every file to solve any problem is a bad idea, or how software licensing works, but I have to do it regularly and it causes clusters to crash, deadlines to be missed, and bills not to be paid because they're too busy customizing their fancy redundant solutions to problems they aren't solving. Or installing a big 10 server cluster to solve something that can be done in 10-20 lines of code on a laptop instead with an off the shelf product that costs $100,000/year for one task and then ditch the product entirely.

I don't know why you took this personally...

As for editors vs OS, yeah I mean you have an OS already installed, right? Why create an overlay that does the same thing? Emacs has a web browser in Lisp, why? elinks/lynx/wget/etc exist to do exactly that on the terminal if you have to do a terminal based solution (downloading ISOs on a server, for instance). Or even just use Firefox on your desktop rather than trying 900+ browsers and never concluding which one will work for you, constantly switching back and forth and back and forth...

All I'm saying is use the tools. Customize it as needed, but don't become addicted to customization for customization's sake.

Oops, I really did project hard, didn't I? :D

Sorry!

> To the point that they aren't USING the tools they are learning, just learning how to use it in such depth that they paralyze themselves.

Yeah, I've met those. And I completely agree that what they do is unprofessional. At one point you should just sit on your arse and do what you are paid for!

> I don't know why you took this personally...

Same reason why many others do -- I projected. :) Apologies.

> Emacs has a web browser in Lisp, why?

I am sure many would chime in to say how they love never leaving Emacs or how back then good email clients and web browsers weren't a thing -- but I am with you here, I think the effort and tool duplication must absolutely stop already.

There aren't very many of us the programmers in the world (I mean those who get sh1t done) and we shouldn't spread our efforts in meaningless individualism.

> All I'm saying is use the tools. Customize it as needed, but don't become addicted to customization for customization's sake.

Yep, 100% this. I actually do my very best to customize very little. I spend a great amount of effort [every now and then] to find the canonical way a tool [is expected to] work/works and just do a very thin layer of customization on top of that, versioning it with GIT and overall making sure I can nuke my $HOME from orbit, clone a few repos on a new machine, issue a few installation commands and be on my merry way.

Sorry, I guess I wasn't quite clear. I didn't mean to imply that a bare setup leads to better productivity.

The point I was trying to make was that constantly playing around with your tooling (configs, plugins, etc.) leads to very marginal productivity gains at best, especially considering the significant amount of time many developers invest into it. This is based on my observations and thus purely anecdotal.

Pick the proper tools for the job at hand once, learn them. Make minor adjustments if absolutely necessary, but don't get obsessed with tweaking.

The true potentials for gains in productivity lie in many other areas IMO; organizational/social/collaboration matters in your org, actual engineering skills, and so on.

> The point I was trying to make was that constantly playing around with your tooling (configs, plugins, etc.) leads to very marginal productivity gains at best

Oh I completely agree, the problem is that is expected in many areas -- especially the JS stack (hence why tools like `esbuild` started emerging eventually).

I agree that many devs just "pimp" their setup all the time and that's not productive. Yep.

Sorry if I vented too hard; it did seem like you're one of those guys that scream "real men use vi!" but since you are not -- my apologies for the not very constructive comment earlier.

  > You need to learn VIM itself, not the configuration.

But then he gets a text editor, not an IDE.

Signed, Another 20 year almost-no-config VIM user.

Reply on news.ycombinator.com