Over the last few years I've noticed that writing code is pretty easy but robustness and graceful failure are what really set the best programmers' work apart.
To my fellow novice programmers, I recommend reading Joel Spolsky's great post called 'leaky abstractions', written in 2002.
Completely true, and a sad mistake I made in the writing. I tried to clarify the main point, which I think isn't lost to the mistake, in a small comment on the blog itself.
I suppose the overarching principle here is communication between programmers. If I was the programmer building some system depending on an API with some opaque behaviour I'd get really frustrated: "Why does the connect method just not work sometimes and block??!!?".
It's just considerate to other human beings to let them know (using a suitable means) that an API call has failed (for whatever reason) and quickly. Opaque loop-and-retry-until-we-succeed makes problem diagnosis stupidly difficult. Anything that makes the audience programmer's feedback cycle slower and impedes problem diagnosis is both counter-productive and irritating. Simply communicating "I CAN FAIL AND HERE IS WHY..." is a Really Good Thing.
In my experience (read this with an 'anecdote' filter turned on) teams that communicate everything to the point of superfluity generally work better. This extends to your code, particularly APIs.
4 comments
[ 2.9 ms ] story [ 18.7 ms ] threadTo my fellow novice programmers, I recommend reading Joel Spolsky's great post called 'leaky abstractions', written in 2002.
One mistake though: TCP sits on top of IP, not UDP.
It's just considerate to other human beings to let them know (using a suitable means) that an API call has failed (for whatever reason) and quickly. Opaque loop-and-retry-until-we-succeed makes problem diagnosis stupidly difficult. Anything that makes the audience programmer's feedback cycle slower and impedes problem diagnosis is both counter-productive and irritating. Simply communicating "I CAN FAIL AND HERE IS WHY..." is a Really Good Thing.
In my experience (read this with an 'anecdote' filter turned on) teams that communicate everything to the point of superfluity generally work better. This extends to your code, particularly APIs.