3 ms·
For the longest time I was a proponent of limited tooling. In many cases its good to know what you're automating or simplifying because I often found myself in
by Frost1x 5y ago
For the longest time I was a proponent of limited tooling. In many cases its good to know what you're automating or simplifying because I often found myself in situations where I may have environments I need to do things where I didn't have my tooling to lean on.
In the past, this was possible without too much pressure on cognitive load. In modern code bases with all sorts of libraries and layers of abstraction ontop of abstraction ontop of abstraction ad infinitum, it's just not feasible anymore. I got to a point in certain development ecosystems where not relying on tooling started to really hinder me. Self reliance was no longer a strength and a point occurred where I simply had to lean on more and more tooling or I'd be lost.
I still think if you have tooling that does something, you should understand what it's doing and how it's doing, at least once, then let it do every subsequent need for that task. It's good not to have black boxes in your ecosystem. Unfortunately even that is becoming difficult because of the number of layers of abstraction in some ecosystems (especially web development).
I've never been a fan of black boxes that I simply trust and don't know their tradespaces, then hope for the best.
- dolni 5y agoI think one could make the case that IDEs enable the type of complexity you're referring to. I don't know that I view that as a positive. A lot of software development is about managing complexity. IDEs allow developers to be sloppier. In the same way that faster CPUs have resulted in less optimized software over the years, IDEs have resulted in more complex software.
- luckylion 5y agoI'm not sure it's about sloppiness, some things are more complex than others. I believe IDEs are tools that allow one to handle more complexity. They have resulted in more complex software, but maybe that's because they've enabled us to write more complex software (and more of it). Like an architect that uses CAD to create plans for a large building -- sure, they could do that with a pen on paper as well, but it would require a lot more people and a lot more time.
- jeffterns8 5y agoThat can be said about languages, libraries, plugins, any tools you choose to make use of. It's just about sticking to good practices and understanding what you're using instead of choosing to be a bad dev. That shouldn't require excluding everything that has the potential to be used improperly.