Your insecurity does not matter

June 8th, 2006

In a recent chat with two of my now ex-colleagues (our employer having been brutally, swiftly and completely obliterated about 3 weeks ago), we talked about schedules, project management and milestones, and why they don’t work. I said it is because people don’t like to feel insecure. And they have the false believe that schedules, project management and milestones will redeem them from this feeling.

This insecurity, however, is natural. You are insecure because you don’t know and you think you are supposed to know. But still, my friend, you DO NOT KNOW. And that is just how it is.

Insecurity also does not matter, in that it does not hinder or otherwise impede creativity and productivity. What does hinder and severely impede creativity is your superflous thoughts and interpretations of a small, natural bodily sensation.

So here is a suggestion, the Cyclic 4-Step Model of Creating:

(1) Explore the unknown, feel and accept your insecurity as part of the process

(2) Find a safe harbour

(3) Make sure you can come back to that safe harbour at any point in time easily

(4) Go to (1)

Can you see how tests can help you there? Can you see how agile development facilitates exactly this? Do you think I have forgotten the word “Goal” or do you think it is irrelevant for this process?

Doodle Up Front

April 13th, 2006

I find it very helpful to jot down a few squares and arrows when thinking about a new system or a new layer of a system that I am building. These squares and arrows will look very much like UML, but probably not be 100% compliant. The point is, they are really somewhat of a doodle. While thinking of classes and responsibilities and associations, I draw them. Eventually, I will find this one little class that I will start writing tests for.

This kind of UML-doodling is helpful for starting to brainstorm about a system, or communicating ideas to a fellow programmer. On the other hand, I like to have a neat diagram of all my classes handy, in case I get lost and I forgot what I was doing two weeks ago. And for this, I use a tool. I currently use Dia, which is good enough for my current needs. The important point is, that I use it AFTER I have implemented the system I am drawing a diagram of. If I would use the tool too early, I would just get lost in trying to make the diagram neat, and in playing around with the options of the tool. In short, I would find perfect excuses for procrastinating on the implementation, which means on writing the first test. So I doodle up front, get my hands dirty, and I make myself some neat documentation after the fact, if I (or my peers) need it.

test by test - Some Instructions on Programming and Life

March 26th, 2006

I can not begin to tell how much I love a little book called “bird by bird - Some Instructions on Writing and Life” by Anne Lamotte. It has influenced my life and my work in more ways than I can list here, and this is also not the subject of this post. The idea of this post is to relate a chapter in this book called “Short Assignments” to my work.

What are short assignments? Ms Lamotte skillfully describes what happens to her when she sits down to write something. We hear about mental illnesses pulling up chairs around her, trying to be quiet but their “weird coppery breath” will remind her of their presence, always. We hear about the thoughts that begin to flood her mind, that tell about how her well of creativity has run dry, how she comes to the conclusion that she can not do anything else and thus will starve, and how her breath gets shallow. Finally, she finds the one-inch picture frame on her desk, that she put there to remind her of the idea of short assignments. All she has to do for now is write down as much as she can see through a one-inch picture frame.

When I sit down to program, sometimes my breath starts getting shallow. I, too, have my selected audience of mental illnesses, only they are not even trying to be quiet, they talk to me about how I should not be here in this high profile company in this high profile business, and that I should go back where I came from. They also eloquently read a list of programmers that have achieved so much more, while still being younger than me. Sometimes they throw in pictures of said programmers with nice cars. During that period of mental terror, I robotically switch through source files, or my email, or some webpages, until, after about 2 minutes or so, I notice this little doodle I made yesterday before I left work, an UML-ish diagram, sketching out a set of classes and their relationships, for the next tier of a system I am developing. On there I spot a box, about one inch wide, with a class name written inside of it, along with a few public functions. I notice the class does not depend on anything. And I suddenly realize, again, that all I have to do for now is write only as many tests that will establish the functionality contained in this one-inch box.

A few months ago I read a few pretty much life-changing words in David Allen’s “Ready for Anything”. They go something like this: You can not do a project. You can only do the next small physical action in a long list of actions that will eventually produce the result. I suggest you read that again. This is huge. Is this not liberating? You can not do it. You can not write a complex software system. You do not have to resolve the huge tension that seems to exist between nothing and the end result of a big project. You can only resolve the tension between now and a few minutes later, while you look through your little picture frame, and write your test. For me, this is the mode of work that makes me most productive, focused and passionate. I make it my primary activity to ask myself the following question, over and over again: “What is the smallest thing I can do now to advance the given assignment a little further?”. Or, more to the point: “What is the smallest thing I can test that will tell me a little bit more about the system I am developing”.

When I have neglected to pose and answer this question for a certain amount of time, I am becoming less efficient, I am stressed, and irritated. There are a few things I watch out for, to notice this as soon as possible (because after all, it does happen):

I have changed too many files since the last checkin: More than, say 5 files checked out already make me a little nervous. It means I am working on something that is probably too big for my current short assignment.

I start to comment out tests: It is ok to comment out a test to work on a single other one that has to be fixed first. It means I went too fast, but there is a threshold. If a test stays commented out for a long time, I probably became obsessive with some other aspect of the system, and I am most likely pressing my frame against my eye very hard to spot the “dead angles” that unnecessarily bother me.

I have “ok to fail tests”: I run my tests, and there is a list of tests that are “ok to fail” at the moment, and they “will be fixed as soon as….” This is not only tedious, as I have to check the failing tests and check if those are the “ok to fail” ones or “not ok to fail” ones. Again this indicates a burst of compulsive obsession with something I have spotted at the corner of my current 2-inch vision.

Luckily, my body faithfully reminds me of what I am doing. My neck gets tense, my stress level rises, my breath becomes shallow and I become a miserable person. Until an angel dutyfully and gently taps me on the shoulder and hands me my one-inch picture frame.

The beautiful thing when writing tests is that you usually don’t have to look back. When I look through my one-inch picture frame, it helps to not have to look back. How else would I be able to focus? It helps to feel safe and not threatened. It helps to stand on a solid foundation. In my daily work, testing and test driven develpopment provides me with exactly that. If I remembered to look through my one-inch picture frame often enough, I have built up a system test by test, layer by layer, every layer as solid as the next. It is like building my own staircase, and I can safely and faithfully step on to the very next step that I have just built, and I know it will not break down. This bundles all my abilities and experience to a narrowly defined problem, and I can rise to excellence in ways I never thought possible, because I am simply not bothered with anything else. When you were last in the flow, how many thoughts were in your mind?

There is, of course, a caveat to all of this. In order to work in little tiny steps, you must disconnect emotionally from the outcome of your big project. You must also make peace with the fact that you are not doing anything special. So many people want to build that cool engine, or that cool AI or that cool system that does whatever, and they want do feel like they are doing exactly that. With attempting to do that, there comes recognition from your peers, overtime, stress, tension, broken relationships and probably an unhealthy diet. But it is special. All those things are making it special! Your suffering is your special invitation to the party. On the other hand, writing a little test that might test one or two functions of a new, say, string class does not sound all that glamorous. And it is not. It is nothing special. If you connect emotionally with your activity and with the outcome of your work, that is, if it means life and death for you if you write the 3D engine of your game over a year or two, or just a small test over 30 minutes, you will have trouble with what I have written here. The fact of the matter is, we all do nothing special. And it certainly does not make us special. All we do is little things, and we string them together, and sometimes something interesting appears. Everything else is a delusion.

For those of you who are now angry, or just delusioned, maybe this quote from “The 15 Seconds Principle” will comfort you:

You must be more interested in producing pleasurable and specific actions in present time and less concerned with past failures or future results. Your mission is just to live and create with relaxation, energy, focus and faith. In this masterful state, there is no past or future. There is just creating in the now.

30 Minutes, first thing in the morning

March 15th, 2006

I used to have the habit of coming into work, and as the first thing make some coffee and grab something to eat in the kitchen. I would hang out there, chatting with whoever was available, for a varying amount of time. I started noticing that, when doing this, it became harder and harder for me to convince me to do some work, and remarkably hard to snap out of this mode for the whole day.

I think the problem there was that my body and mind got into “day off mode”. When I have a day off, I lazyly go about making breakfast, check news, read my blogs, all those “lazy day off things”. Which is perfectly ok, when I DO have the day off, and it is fine to go into that mode. At work, this is a problem, and my emotional state quickly makes friends with all the guilt feelings of not getting anything done, or dramatically less. In this mode I am also much more prone to procrastination and goofing off.

So fairly recently I am doing this: I come into work, grab a water, and do 30 minutes of work as soon as my computer is started up. I look at my lists of tests to write, or I have left a failing test from yesterday, or even a not-compiling one, and I start to work. Two factors are important: Quickly find a point to pick up from yesterday, and timebox it to 30 minutes, so your mind can not really convince you that you will be working forever without even grabbing a coffee.

After this little routine I grab some breakfast, some coffee, and chat with people, but usually the coding part of my mind has started up sufficiently, and I can’t wait to get back to the problem at hand. Remarkably, it is equally hard to snap out of THIS mode the whole day.

Testing Practice: Use your eyes, when necessary

March 7th, 2006

Imagine the situation: You have a third party system, and you would like to query it for some information. You are not sure yet how this information will look like, and it will also change over the course of exploring and discovering said system in your test. Let’s also say, the output is a somewhat lengthy string, with lots of details that you are not even interested in. You just want to confirm that you got the right answer. It would be tedious to immediately use an automatic check for that, because everytime you change the way you interface with the system, it might give you a different string, and you have to adapt your test. So here is what I normally do: I use my eyes on the early results of my queries to the system, i.e. I print out the results on the console or whatever output device. I do that until I can visually confirm to the best of my knowledge, that the result is what I want, or that the result indicates correct operation of the system. Only then I take the result, and write some automatic checks for it. Maybe a simple string compare, or maybe I look for certain substrings. Don’t delete the code that displays the results, though. You might need it again, when things change, and you need your visual checks again. It helps to have a flag to turn verbosity on and off. It does not need to be fancy at all. Just comment out the line that turns verbosity on when you are done.