I just found myself wishing that I hadn’t deleted some dead code, because I wanted to use the same technique I’d used earlier. Now, if someone else had been in my position, and refused to delete it, because they wanted to be able to look at it later, I would have suggested that they learn to use their version control system better. So what did I need to learn to do? That’s right: learn git better.

After googling, I found that with the -p flag, git log can be made to show patches. I ran git log -p admin.py, since I knew which file used to contain the code I wanted to look at. It brought up all the changes made to that file, including when I created it, in my pager. I searched for get_urls, because I wanted to find where I had set up a custom admin view in django. It came right up! I copied it and pasted it back into the file. Problem solved.

I’ve always had the type of job where I’m given a set of responsibilities and some tasks. Many of these tasks are things that have a quick-and-dirty way of doing it, and could be expanded to just about anything.

Clients haven’t always been the best at communicating which tasks are most important. Often, I don’t think they know which are most important.

Sometimes, I have a hard time focusing. That’s why I’m trying a new strategy.

I’m going to try doing many of the tasks in a quick-and-dirty way and see what my clients ask me to improve. Just like a blogger or a twitterer might put out a bunch of posts, and if they get positive feedback, try doing similar posts to engage and expand their audience, I’m going to try doing a bunch of little projects to see what I get the most positive feedback from.

Now, like a blog/twitter audience, clients can be fickle, and lose interest in something they seemed really interested in, so I have to always be adjusting to demand, just like a successful blogger.

The information that helped gel this idea was in a marketing video by Giles Bowkett where he introduced the concept of Test-Driven Decision Making. That’s the concept I’m using here.

Note: After letting this sink in, and participating on the Year Of Hustle forums, I think I was just making excuses. When I’ve had success “prototyping”, I was doing it with the intent to ship. I could have released my idea and repurposed it later. I think shipping is the habit I should be trying to form, and that it will help me hone my skills better than prototyping without the intent to ship (i. e. dabbling).

Some ideas just aren’t ready to be shipped out. They need more time to germinate. Ideas that aren’t ready to be shipped, though, are often ready to be prototyped.

I had one idea where the plans for building it felt complete, but I wasn’t sure what my goal would be with the released product. I wanted to do more than impress people with pretty graphics. A few weeks later, while I wasn’t thinking about the idea, I thought of a goal, and while I was trying to think of a way to achieve the goal, I realized my idea would be a great way to achieve it. I also came up with another feature for it, that I think will help it stand out.

It would be nice if I’d already prototyped it, and had it sitting in a private repo on GitHub. There was nothing stopping me, except I was hung up on making things I could show people. If, at the time I knew what I wanted to write, I’d shipped other smaller things recently, I might not have run into this stumbling block.

I’m not sure whether it’s shipping that makes prototyping work, or the other way around, but I think developers ought to have a steady diet of both.