This question is geared more towards people that have been doing IT "for a long time":
Do you find that, as technologies abstract and simplify things, that said "simplification" negatively impacts your ability to adopt?
Because I've been working in IT since long before GUIs (among other things) became common, it feels like whenever someone tells me "try this IDE" or "try this (simple) language/framework", etc., my brain trips over that simplification. It's like it's incomprehensible that I don't have to write all sorts of plumbing to get a task done - that I can just include/import/etc. a library or module and then write one further line of actual code rather than dozens.
Top comments (2)
I guess my problem is that, having been burned by so many things make decisions on my behalf, my level of trust in "magic" isn't especially high. =)
Usually, said burning has been because of others' problems. "Tell me what's broken and how you think it ought to be functioning so I have a better chance of figuring out why you're experiencing a difference." Tends to force a "close-to-the-metal" habit-set on you.
I find higher abstractions can sometimes be tougher to use in the long term. Because the abstraction always breaks down at some level. In the end it is a trade-off that you have to decide for yourself.
For example, I use a garbage-collected language (F#). If I run into performance problems because of GC pauses, then I will have to start using tactics to avoid allocations. Like reusable pools of objects. This is basically managing my own memory but indirectly since the language doesn't provide explicit memory control. Despite this, I deem using a GC as a worthwhile trade-off for the kind of applications I normally write.
On the other hand, I avoid using frameworks of most kinds. Because long term I find them to cost more. Since all abstractions are leaky, and the bigger it is the more leaky. I eventually have to spend time learning how the framework functions under the hood, and then trying to puzzle how to invoke it in a way to accomplish what I want. All this instead of just solving my problem more directly without a framework. So I much prefer to create a solution by weaving together simpler libraries, even though a framework would be faster to get started. My perspective is shaded by the fact that I still have software in production that has evolved over the course of a dozen years.