Here is a suggestion on how to identify what to measure:

1. What is causing you pain?
2. What causes the pain to occur?

Step 1 is all about prioritization. Pain is bad. If something is causing you pain, you want to stop it. You need to stop it. So pick the thing/item/problem that is causing you the most pain. This is what you need to improve or fix.

Step 2 is looking at what is causing the pain to occur in the first place. Once you know the factors that are contributing to the pain, you can try to change them. If you are doing the right thing, the factors contribute less, and the pain should go down.

For example: Let us say I want to write more python code. My day job doesn’t involve much python, so I feel like I’m being left behind because all of the cool kids on reddit are talking about the fun they are having writing python code.

The pain: Not being able to write in the language I want to. The cause: Day job doesn’t use python.

Addressing the cause will affect the “pain”. If you get a different job (e.g. one that involves writing python code) then you have solved both problems.

But what if you can’t just switch jobs? Then you try experimenting with writing python code for your own personal use. Try writing it to solve scripting problems on your PC at work. If that makes you feel better, then you are moving in the right direction. If you try writing open source code in python in your after work hours, but it winds up stressing you out, then you are moving in the wrong direction. (Or you’ve identified that there might be a different problem than what you originally though there was!)

By tackling the sources of your pains, and applying small changes there, you can get a measure of where your efforts are going. Sometimes these measures are going to be cold hard numbers, and sometimes they are just going to be “feelings”. But either way, they are indicators of how you should change your processes and habits in order to become more successful.

Start up studies: A pop quiz

Aside from various illegal schemes, the people in the story came up with some fairly inventive ideas. I hate to use the phrase “out-of-the-box” but that really sums up the thinking approach the participants used.

Having said that, I thought the restaurant idea was better than the “winning” idea. Why? It provided a service of tangible value to a larger group of people, and is something that is probably reproducible (i.e. you could probably do that over and over).

And as the presenter pointed out, sometimes we put constraints on a problem that are totally of our own making. Breaking free from those can lead to some really interesting (or profitable in this case) solutions!

See also: Overcoming functional fixedness

I’m not a huge fan of traditional Test Driven Design (TDD) though. My biggest complaint is writing a battery of tests before writing the actual code feels like putting the cart before the horse. I’ve been experimenting with it, and most of the time I’ve found  that if my code is structured “correctly” (i.e. a well defined API/interfaces, dependency injection, etc.) TDD will work pretty well.

However I have found that I like to use TDD one test case at a time. Basically I will get the basic framework of my class(es) together, and then as I refine the capabilities of the class, add in a few tests to catch one or two conditions. Then I work on my code to make sure that it is performing as expected. Once everything is going well the tests pass and it is time to move on to the  next part of the class.

The big advantage for me in this is that I only have to worry about getting a small number of tests to pass instead of all (or a large number) of them. By breaking the tasks down into smaller pieces I find that I spend less time “dreaming” about how my code would work (and writing tests that don’t accomplish much or have to be re-written as reality sinks in). Instead I’m able to focus on a single problem and solving it.

This is a similar approach as to what is advocated in the unit testing community: When a bug is found, create a test that exposes it. Then fix the code and the test should prove that the underlying problem is gone. I really like that approach and I have begun doing that as often as I can. So far it has really paid off in terms of making sure my code doesn’t have bad case of “but-I-already-fixed-that!” type of bugs.

It is an interesting exercise, trying to tune the world in while not adding to the noise. For programming I think this is an essential skill, it is how one learns new things. Lately I have found that having a good cup of hot tea and sitting back to take in things (bugs, new ideas, etc.) really helps me to move forward.

I’ve been hanging out at my favorite independent coffee house Tazza doing some programming work and thinking, and I have to say its a really cool place to hang out. I love the hot tea there, and from what everyone has told me the coffee is really good. The staff (hi everybody!) is very friendly and love to chat. That along with the cakes and cookies combined with the great (and free!) WiFi makes this little coffee bar the ultimate place for me to get away from the grind of the office.

I always wondered why some developers hang out in coffee shops, and now I think I know why: its a good place to be in order to keep your perspective. I might be the only programmer in there, so hearing other people talk about other things helps me to keep things in the right light.

So if you are in Atlanta (especially the Buckhead/Midtown/Georgia Tech area) you owe it to yourself to drop in to Tazza and enjoy a good cup. (The address is 1700 Northside Drive, Atlanta GA 30318 or just use this link)

To that end I’ve been working my way through the book The Structure and Interpretation of Computer Programs which is a dense volume that is chock full of good knowledge about how computer programs work from a critical and analytical point of view. The language the book uses is Scheme which is a variant of Lisp.

Having worked with XEmacs and its version of lisp (called appropriately elisp), I thought I would be able to pick up Scheme pretty quickly. This is pretty much true, since the two languages have the same general syntax/form. One thing I don’t have those is a Scheme interpreter! I did install SBCL and CLISP a while ago, so I figured that I would just use that.

Well, it turns out that Scheme is also slightly different than Common Lisp. But thanks to Peter Seibel and his excellent book “Practical Common Lisp”, I was able to translate the first few programs in the SICP so that they would run in my CLISP-Slime environment.

So if you find yourself in this situation, be sure to check out the best Common Lisp tutorial on the net. Its free and it is very well written, so I highly recommend it. I remember playing around with it a while ago, and being impressed with it back then. The good news is it is still as good now as it was then.

1. Getting a lost screw out of a garbage disposal – While taking a wall plate down in order to repaint the kitchen, a screw got away from me and fell down the disposal. I’ve seen enough movies to know that even if you turn off the power there is a 100000% chance that a poltergeist will try to turn it on while your hand is down in there. So putting my grubby paws down the hole was out of the question. How did I get the screw out?  I took a magnet off of the refrigerator, taped it to a piece of string, and then lowered it down into the disposal. On the third try (total time of about a minute) I got the screw out! This caused my wife to begin humming the theme song to MacGyver.
2. Hanging two pictures on the wall so that they are level with each other – After the painting was done in the kitchen it was time to hang the pictures back up. I hung the first one then tied a piece of string around the nail and then using a level stretched out the string to rough distance the 2nd picture would be placed from the first one. Once the wife approved of the location, I used the level to make sure the string (which was pulled tight) was level. Once it was level, that told me where to put the nail. I did mess this up on the first try (I should have moved the nail up a bit to compensate for the string thickness), but the second try worked great. Now I have two nice looking pictures side-by-side on my wall.
3. Keeping a tow line out of the prop on a Pontoon boat - This summer we went to a friends lake house and went tubing from their pontoon boat. The boat sits pretty high off the water and the only good place to hook up the line was on the pontoon itself. When the boat was stopped, there was a real danger of the line getting wrapped in the propeller. Since the deck was so high up, I was about 3 feet short of being able to reach the line and pull it back in by hand. Looking around the boat I saw a wooden paddle with a T-handle. I grabbed that and a few seconds later I was able hook the line and pull it up out of the water and keep it from propeller (not to mention pull in the tube).

So the point of this post is to say that the next time you have a situation where you need to solve a problem, take a second and observe your surroundings. The tools you need might just be lying around…

One that I really liked was Joel’s idea of not posting comments on a blog, rather write your response on your own blog. Its a great way of generating content and forcing you to think about the topic (similar to the idea of “you don’t really understand something unless you can teach it to someone else”). I think its a really great idea, and it seems to have stirred up a lot of debate.

And finally, the other great idea: Do it fucking now.

Thinking is fun and all, but producing is what really matters.

Sometimes fixing one bug can take forever to do. This is where I’m stuck at the moment. Its a lot like when you take forever to write one line of code (i.e. because you can’t figure out what you need to do next). Productivity crashes, then your morale sinks like a rock. Soon it seems like everything is moving in slow motion, even the things that have nothing to do with the original stumbling block.

Constant talk about things, especially when there is no action taking place, has the same effect on me. Tomorrow is a new day and I’m gonna have to try and do something to keep this malaise from taking root. In the words of Yoda: “Do or do not. There is no try.”
Action, not words.

I looked closer at the selection and noticed something odd: Among all of the RPG books there, most were dedicated to game worlds based around magic (duh), werewolves, monsters, dragons, and other Tolkien type stories. There was one based on the future, but even that one had mutants which are the equivalent of monsters.

Personally, I’m a fan of the post apocalyptic genre. For some reason I find the idea of starting over, or at least having to adjust rapidly in the aftermath of a disaster, to be really intriguing. Its a very accessible topic, after all it is based on the world of today, and there’s no shortage of scenarios that can be drawn from that.

Yet for some reason, there few RPG’s (and to an extent comics/graphic novels also) that tap into this rich vein of material. I’m really puzzled by this, reality TV (shows like Survivor, etc.) shows that the general population is interested in the idea, yet this isn’t reflected in a lot of other aspects of our entertainment. Fallout was quite popular, but that was almost 10 years ago. Lost and Jericho are popular, but few other shows seem to be following their example.

Is there such a disconnect between the D&D community and the rest of pop culture? Or is the idea of a post apocalyptic world just too scary, and in the post 9/11 and post Katrina world, too close to home? Or am I just shopping in the wrong stores?

ALICE: Are you alive?

Jabberwacky: Perhaps.

A: Why the uncertain tone?

J: Everything is uncertain except for five facts.

A: The whole universe?

J: And we both might just be some ones and zeros in the computer memory.

And this is my favorite exchange:

A: Do you think a machine will ever be considered “alive”?

J: Stranger things have happened.

A: Not many people express themselves that way.

J: How would you know, machine?