To add to this, for the solution that takes you 30 seconds to articulate and 1 hour to code, let me guess---About 5 minutes of that hour is writing the business logic that solves the problem, and 55 minutes are things like: 1. Boilerplate: Headers and includes, function and variable declarations, comment blocks in the right place, class this, interface that; 2. Reformatting: casts, serialization, deserializating, data marshaling, transforming from one data structure to another; and 3. Refactoring: adding an argument to function X requires manual upstream changes in all 25 places that call function X, making data Y an enum instead of a bool requires identical changes in 50 other files. Crap like this is pure brain-off typing that takes the vast majority of the time you spend "coding."
I'd love to see better tooling that automates the crap and lets us focus on the actual business logic and value add.
You're exactly correct. Like reading my mind. You've itemized the exact things that take 90%+ of any code I write. I didn't immediately notice it - it became apparent only when I realized I'm writing almost the same, tiny, simple business logic for the third time, and it still takes way too long than it should.
> serialization, deserializating
I shudder when I even see these words. In the past two years, they've been the bane of my existence! A significant chunk of my coding time was wasted on countless little XML and JSON serializers/deserializers, associated error handlers, error messages, type recasting, etc. This is 100% because of bad tooling. I'd consider automatic generators for these, but they're external things that don't integrate well - which comes with more devops and maintenance hassle downstream than the time they save. If I were doing Lisp at work, I could at least macro my way out of this pain, but alas.
And the worst thing is, these things aren't just "brain-off" time wasters. In recent months I've noticed I'm getting slowly but surely burned out by this. I can see myself slowing down halfway to finishing a feature or a bugfix, out of sheer mental exhaustion from dealing with bullshit.
I'm not sure if I agree fully with its conclusion. I hope we'll figure better ways to eliminate glue code, or at least reduce it in size. Part of the problem is, it might be trivial to describe a data transformation between systems A and B in words, or even on a diagram, but it's still hell of a lot of work to put this in code. Again, accidental complexity abounds.
But beyond the data transformation glue code they're talking about, there remains the problem of boilerplate and glue code required by the programming languages and build tooling being not ergonomic enough to deal with concepts we have in mind directly.
I'd love to see better tooling that automates the crap and lets us focus on the actual business logic and value add.