As you program in Elm, you follow a delicious breadcrumb trail of extremely readable compiler error messages until the program compiles and everything works.
I’m always delighted to hear about developers being kind to other developers by paying close attention to the usability of their tools.
Remember when Rails came along? Remember the tons of repetitive crap that came with doing web development before DHH came along with his incredibly thoughtful open source project that was “optimized for programmer happiness”? (I sometimes think of DHH as the Patron Saint of Dev Tool Usability.)
It’s funny how we computer geniuses go about producing so many tools for other computer geniuses that are incomprehensible to said geniuses.
I think in the current zeitgeist of software development is an appreciation and understanding of the importance of usability, design, and all the details that make software (or websites) pleasant and easy to use. But, tragically, that appreciation for usability tends to go out the window when we are producing software for other software developers.
Think of the last time someone on your team was assigned to automate some task for the rest of the team. Every run of that script came with caveats about which error messages it produced were important and which ones you could ignore. Oh, it’s blowing up because you did X first. You’re supposed to run the script, and then do X.
I think we get lazy on the usability of things we make for other developers because we know they’ll figure it out eventually. We’re so used to diving into the most arcane topics and surfacing days or weeks later with an understanding.
It’s just nice to see those rare instances where a developer went the extra mile to produce something for other developers that was not just powerful, but with special attention paid to the friendliness of the thing. Because, you know, we’re people, too.