Regardless of the programming task, it is usually hard to find the best way to do it, and not trivial to implement it correctly. This is demonstrated by the fact that most code sucks.
Regardless of the programming task, it is usually hard to find the best way to do it, and not trivial to implement it correctly. This is demonstrated by the fact that most code sucks.
Aren't higher level abstractions supposed to make programming easier?
And yes, for the vast majority of programmers programming is easy thanks to existing high level abstractions, and it's usually the business domain that is hard.
I think that because everyone starts with few visible abstractions, they get the sense that adding abstractions adds ease. Removing or changing them is often just as valuable.
Simple repeatable solutions are better and more maintainable than constantly abstracting things to a higher level. I write systems and code with operations and developer ease in mind, not some academic idea of abstraction.
I'll be quite honest, if this is the same sentiment behind my experience at work (convoluted tangles of conditionals everywhere, 100+ line functions doing simple things - just to name a few), abstraction isn't just some academic idea.
I work with people who follow the path of least resistance and leave everyone else with the path of most resistance when we have to figure out what the hell is wrong with their code and fix the glaring oversights and errors they left behind.
Just like true developers write all their code in notepad and real developers etch bits on disk with magnetic needles.