Digital Sanctum

Although the price of fuel has gone back down in the United States after peaking earlier this summer, the momentum behind striving for better fuel efficiency continues to grow. No doubt, a lot of the renewed interest in fuel efficiency as well as alternative energy sources like biofuel, wind power and solar energy, also relate to the premature escalation to war in the middle east. I won’t debate about the war or the politics behind it, but I will debate about what everyone can and should do to conserve energy.

Perhaps one of the biggest ways that just about everyone can conserve energy and therefore decrease demand for foreign sources of energy (oil), is simply by driving slower. I say slower instead of slow because I think it’s easier goal to set when you say you will drive not as fast instead of not driving fast. It’s all relative right? Semanics aside, driving slower requires no upfront investment like buying more efficient yet more expensive light bulbs for your home. All that’s required is some behavior modification and the discipline make driving slower a habit.
Read the rest of this entry »

I read Paul Graham off and on and find most of what he writes about interesting even if I don’t agree with all of what he has to say. His latest essay, “Six Principles for Making New Things”, is one that seems to echo a lot of what’s been said before about solving problems with software. In his own words the steps are:

I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

To summarize, find a simple solution to a problem and release early and release often.

There are parallels between the organization and operational philosophies of companies and what is considered “good” software design. Attributes that immediately come to mind about good software design that can be applied to a company’s operation are loose coupling, polymorphism, and reuse.

Read the rest of this entry »

Being a software developer, it’s easy to recognize the importance of having a great environment to work in. Most of the time I spend tends to be 80% or more on thought and the rest of the time translating those thoughts into actual code. I have politely explained this process by making the analogy of building a house of cards.

When you’re working on software (and other thought-provoking tasks) you invest time to work toward a point where you have to translate your thoughts or “purge” them into code or words. If you are interrupted during that crucial phase where you’re building your house of cards, there’s a good chance that part or all of your house will fall down. At that point you can sometimes quickly pick up where you left off if only a few cards were lost. Other times you have to file a complete loss with the “house of cards” insurance adjuster and rebuild from the foundation up.