Notes

It was Monday, November 18, 2013 around 10:00 a.m. and I was standing in a humid Florida parking lot in the midst of a large crowd of people. We were all waiting to get on one of the many buses that had gathered there.

We all had good reason to be waiting in that parking lot. The buses were going to the NASA Causeway where we would get to see a rocket launch a spacecraft on its way to Mars.

Suppose you’re building a service that depends on several other services to work. You write a bunch of code and carefully include error handling code and have a plan for what happens if each service your new service calls fails. Naturally, you want to test your code. These services are invoked over a network. Perhaps they’re web services but they may be some other network protocol. Suppose further your code is nicely factored so there’s a “client” class that presents the network service as a library API to the rest of the service.

You’ve got a choice to make. You’ve carefully written down the various attributes you care about and how well each choice lines up with those attributes. You’re having a hard time making a decision because with the information you have now they all look very similar. One of the following is true:

• You’re missing attributes with which to evaluate the choices, attributes which would differentiate the choices for you
• You’re incorrect about how well the choices match your evaluate criteria
• There really is no difference between the choices given information you can have now (ruling out somehow getting future knowledge)

Don’t discount the possibility that the situation is the last one. Due diligence is important but don’t block forever waiting for some flash of information that will never come. Don’t discount the opportunity cost of not making the decision and moving on to the next thing to do – sometimes that outweighs any potential cost caused by picking the worst possible choice among those you have selected. Never spend more energy on a decision than the cost of being wrong.

In my learning programming post I wrote about some approaches for learning to program and linked to a bunch of resources. Some of my insightful friends pointed out that most programming teaching doesn’t cover debugging and that lack leads to a lot of frustration. This is particularly hard on those working alone or with other people that don’t know how to debug.

Debugging is the art of figuring out why a system doesn’t work. The skills of debugging apply not just to errant programs but to any system that needs diagnosis.

I’m interested in how people learn to program. Over the past few years, friends or relatives have asked me about resources for learning to program for themselves or for people they know. I’ve collected and refined that advice here. It’s hard to know what approach will work for someone to learn to program. It’s hard work so it’s important that each step be interesting and rewarding enough to keep going particularly when there’s no external force such as formal courses.

RFC 761 section 1.2.2.

2.10. Robustness Principle TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

RFC 1122 elaborates with section 1.2.2.:

1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]: “Be liberal in what you accept, and conservative in what you send” Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue.

[Read More]