Hacker News Reader

Comment by the_third_wave | Hacker News Reader

I think the benefits of working with KISS tools - the opposite of 'everything but the kitchen sink' in Emacs parlance - is that it significantly lowers the cognitive load. This may sound odd when comparing a rather bare-bones vi + tools setup with a bells-and-whistles IDE like Visual/Android/whatever Studio but it just ends up working that way for me. I already need to keep enough state in my head for the project I'm working on so I'd rather not have to worry over the state of whatever tools I'm using.

As an aside, I feel the same about the unbridled growth of tooling around certain languages (Javascript being a prime example) and environments (Android comes to mind). Maybe it is just because of the way I started out with 8-bit assembly where a macro assembler was a luxury which could not entirely be trusted to do the right thing but I know I'm not the only one.

View on HN

Agreed, I like (trying) to understand as much as I can about how my environment works so if/when something breaks I only need to learn the last 30% in a crisis, and I'm already familiar with the core. It doesn't always work, sometimes there is just too much.

It's usually useful, at least in some abstract way to the team. It felt essential when I worked alone and was accountable for everything.

> I think the benefits of working with KISS tools - the opposite of 'everything but the kitchen sink' in Emacs parlance - is that it significantly lowers the cognitive load.

No. You're wrong. Not having the right tools raises the cognitive load. You just think it's simpler because you are severely restricted in the complexity of the programs you can create with just your brain and the documentation.

IDEs expand the complexity of what you can build and make you more productive building programs of any size, because features like autocomplete and refactoring take thr cognitive burden off you.

You forgot to add "for me ...". You also implicitly defined IDEs as "the right tools". After that you imply that those who do not use "the right tools" (in your definition of "right") are "severely restricted in the complexity of the programs [they] can create".

In other words, you state that your way is the right way while my way is wrong.

Notice I did not state that my way is the right way for everyone? What makes you think yours is?

It's one of those "the mouse is objectively faster than the keyboard, no matter how much it feels otherwise" things. So much of the taxing minutiae of programming is automated away by a good IDE that, unless you're working on a very small project, the time and effort saved is worth it.

That argument can easily be turned around by adding a short phrase:

As long as you're working on a fairly standard type of project much of the taxing minutiae of programming is automated away by a good IDE that, unless you're working on a very small project, the time and effort saved is worth it.

In other words, that IDE which may assist you while you're building yet another CRUD project gets in the way when you're, say, developing a driver for a sensor on an IP camera based on a reverse-engineered example.

I feel like this is reductive and a better way of looking at the question is that for any given situation you have to figure out where to most effectively allocate your available cognitive load budget.

Sometimes, all the things the IDE lets you not think about is hugely more helpful than the additional cognitive load of modeling what the IDE itself is doing in your head.

Sometimes, having the thinnest possible layer between you and what you're running is hugely more helpful than the additional cognitive load of handling the things the IDE would've turn for you in wetware.

As ever, it's trade-offs all the way down.

Absolutely agree. The myriad of overlapping tools were the biggest problem for me when learning javascript.

Reply on news.ycombinator.com