Notes

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 evaluation 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: “Be liberal in what you accept, and conservative in what you send”

[Read More]

I’m pretty passionate about automating tasks. I don’t think people should spend time doing things that computers can do, especially when automating those things is easy. I have, in the past, slid down expansive, deep ratholes writing a program to automate some grunt work or another. Sometimes the time to write the program takes longer than doing it by hand, but I believe the time was still well spent because of learning during the automation or because of how unlikely it is that the grunt work will really only have to be done once.

I’m a software developer. There are tools I like and have successfully built applications using but I also enjoy learning new tools and languages.

My goal is to use the best tool for the job. Most of the time the “best tool” is not a choice based entirely on the merits of one platform over another. If I want to hack my WordPress install, I have to use PHP. If I want to use Lucene for something, I have to use Java.

I once presented my vision for how a group could automate enough of a bunch of content publishing tasks to allow the people that created the content to take care of publishing site refreshes rather than requiring the involvement of engineering folks and doing code-and-content pushes.

The person I was talking to responded, “Are you trying to engineer yourself out of a job?”

It was a startling moment because our new product development was usually gated on engineering effort – freeing up our time to focus on product development and making the content creator’s job more rewarding by allowing them to make and publish content on their own seemed like a win for everybody. Of course I wanted to engineer us out of the job of pushing content so we could focus on improving the code.

The future audience weighs heavily on me when I’m writing things to post to the Internet. I assume virtually everything I post to the Internet could eventually be read by anyone I know now or may know in the future. I am fortunate that I went through the most pronounced part of my angry, stupid new Internet teenager phase in a forum with less robust archiving than Usenet.

It should matter less to me but it’s hard to post something that says anything at all when all I can think of is how will this seem years from now to people I don’t even know yet.