| HN Mirror

So true. Whenever stuff gets "convenient" for me as a developer, I ask myself what the downside of this "convenience" for me is that will have to be endured by others. Often times it's inconveniences for the guys who have to operate the thing that I develop later (the single greatest things about this DevOps hype is that it made quite some developers experience the operational pain that their creations inflict first-hand, thereby making them less likely to take "convenient-for-them" shortcuts that make operations much less convenient). Sometimes it's inconveniences for other developers working on the same project. Other times it's inconveniences for developers maintaining the product later (which might as well include me, too).

Whatever the inconvenience is, I need to be able to stand in for them being an acceptable price to pay for my personal convenience. And that is much more likely to be the case if I carry the "inconvenience" part of the equation, while others get the "convenience" part - like the operations people, or the end user, or other developers. That's because I consider myself a professional who's getting paid good money to make other people's life easier, especially if those "other people" vastly outnumber myself or the few other devs on my project team. That is the essence of my job, and it's not intended to be "convenient" for me - developer convenience is therefore one of the least-relevant criteria by which I ought to choose how I'm going to do it.

Developers who highly value "convenient" solutions are bloody amateurs in my book, especially if they can't even envision the ways in which their convenience has to be paid for by others.