Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: