DevelopingChris

I really like pen and paper for my todo lists. Which is ironic because my handwriting is dreadful.

I was meeting  a friend for coffee and they asked why I needed a notebook, and I showed them my system. He thought it was good enough I should share it.

I’ve tried many systems, GTD, 7 habbits, AutoFocus. If it can be done with fancy stationary, I’ve probably given it a shot to see how it goes.

My system is the best of those previous 3 that I can see. I use a medium sized notebook, 5″ x 8 1/2″, I really like the feel of acid free paper but that really doesn’t matter.

I write out everything that I can think of that I need done in the middle of the page, as a running list. No priority, no filter, just stream. This becomes the master list. A good master list is made up of actionable statements. “Mortgage” is not a thing to get done. “Call mortgage officer at x bank about mortgage rates” is a good item.

So now we have a master list of things to work from. Flip the page and write the date on top. Scan over the master list and pick 3 things you can take action on in the next few hours.  Write them on this page. An action can be to delegate it, complete it, make some progress and then postpone the rest, or cancel it entirely.  To denote the action taken I use the Franklin planner style. For complete a check mark, fairly normal. For delegation, the initials of the person, and a circle around it. For started a dot, if completed check through the dot, if postponed and arrow pointing right. To cancel something I draw an x.

Now tomorrow rolls around. Now you need to track which page you are on, I use a paper clip, ordinary metal that I can get at anyone else’s desk if I need one. Flip the page, put the paper clip on that page, write the date on the top, pull over any deferred items first, then write in  the next 3 things you can do from the master list.

If anything new is added to your plate while running this course, just add it to today, not the master list. The master list is just a jumping point. If you find yourself procrastinating or you need to break things down, just flip to a blank page, start a master list, and get more granular and start over. As long as you move your paper clip, you won’t be confused by this exercise, and you can get back on track quickly.

Other hacks, that I’ve come up with to make this even better include, writing phone calls from the bottom up on the page. All others from the top. Usually phone calls need knocked out all at once, so its easy to whip out the smartphone and tick off 4 things quickly.

I would love feedback on how you do this kind of thing.

So we used TFS at work. It wasn’t the worst implementation of source control ever, but there was pain. You know contractors with locks on files from 7 months ago, who have moved on. Difficult to do continuous integration with, due to workspacing and having to have multiple copies of things just to do work on hotfixes.

So we are staring down the barrel of a big project, one that means an extended separation from the current code base. We need a sound branching strategy and we need it yesterday.

When I’ve needed this in the past, I’ve used Subversion, up until a few years ago when I discovered git. It was touted as fixing the many branches problem in open source development communities, a bigger problem than mine. So I’ve been using it on windows and linux for the past few years for every little piece of code I touch. Also I keep my home documents and our image library in git, because synchronization of backups is simpler.

So we have a problem, and a solution, but I couldn’t think of a very good strategy to bridge the gap short of writing a translator. It turns out after consulting stackoverflow, this was a solved problem.

There is a git plugin which connects to TFS and pulls down changesets applying them directly to the git snapshot store, with versions in the comments as to where and who did it in TFS.

There were a few small problems when doing the conversion. Git-TFS, depends on a c# based object model for the git CLI. This c# wrapper is not very good at managing memory on handles to shell calls. So I actually ended up forking the code and debugging it while it converted to make it work in batches and then dispose of its space and keep going. Secondly I had to run in a very minimal mode on my box so that enough memory was available. The final problem was a very large installer of a third party library stored in our binaries repository. The solution was to delete it and remove it from history in TFS, and then all was good.

Other things to look out for. Really really long paths. we had a file that was generated by a microsoft code generator whose path from the base of our solution is 230 characters deep. So if you put it more than a few directories deep, git cannot perform file operations on it, because its too much for the operating system, windows 7. The solution is to keep it close to the root of your drive, which is hacky, but the other option is to fix something that isn’t broken.

Now we have a nice git repo, with 7000 commits, that is ready to go.

On a side note, we used the Turnkey linux version control server. Which meant that we had a linux box, up and running a central server with backups, in vmware, in only the time it took to download the virtual image. If you have a server 2008 box handy this isn’t a necessity, as you can run the central server on iis 7.

Last night we held the first meeting for a new software craftsmanship group, in Columbus Ohio. The turnout was tremendous, rivaling some of the more established groups in town. In total, we had conflicting counts between 26 and 28. That was not the point but just shows that the interest in the subject is greater than I anticipated. We met at a restaurant on the north end of Columbus, we over took the back half.

We all had dinner and discussed what about the craftsmanship movement brought us to the meeting, and then discussed some technology specific things at each table. Due to the rapid expansion in attendance we didn’t have the room to pair and really practice like I was hoping. So, that’s the priority for the next event. We had a good amount of diversity in the room: ruby, python, J (jpl), .net, java, android, iphone, collars, T’s, beers, and sodas.

All in attendance were in agreement, that it’s a breath of fresh air to have a group that is more relaxed about format. Having a “nerd dinner “, even though it wasn’t planned that way, turned out awesome. Typically user group meetings seem so “sit and listen” that its hard to get as much participation as I’m hoping for. Everyone seemed to pick up on the vibe and treat it as dinner with old friends, you know your 27 best ones, and look beyond all the usual religious battles that happen on the open internet.

For the next meeting of the group, Matt Yoho has stepped up and would like to host. It will be on more tech friendly turf for pairing.  The initial thought is to choose a kata ( maybe bowling kata), and everyone pair on it, and then do a quick retrospective on how it went. This is the group I’ve wanted to be a part of for a long time. I’m excited to do it again. We’re starting a google group and other communication tools, to keep a posted status without tweeting daily.

Trying new languages is considered a good habit by most software craftsmen. At the same token, generally most professionals agree that you can’t practice aimlessly you have to have driven, deliberate practice. Just programming doesn’t  make you better. Programming with a goal, and making bugs and or hard things to maintain is good practice. Realizing that you need to then practice those things which you found difficult and then making that your sharpening of the saw effort is the real goal of practice.

In an effort to both learn more python, and get better at writing code in general, I have decided to practice python and math by combining them to make the project euler algorithms.

I think that the python koans were a great experience in learning what the language could and could not do. However solving problems and getting in the thick of them with the language really teaches you how to figure things out in that language.

As promised I’m going to continue to write about deliberate practice, and its role in craftsmanship. One way that I am deliberately practicing is using the project Euler problems. These problems provide a good problem domain to play around in, without getting caught up on the concepts in which to practice principles and self disciplines of the craft.

I’m using a language I have not used as much as others I know, python. I really enjoy python, this lets me use it in the “trenches” as it were. The second piece of the practice which I need right now is TDD. Its not that I don’t believe in TDD or haven’t done it, its that I know I can get better at it such that its my main mode of operation, and not an after thought when I have time.

The TDD reason may push me into practicing in a different language as the testing tools for python are more primitive than other languages, although testing is not difficult the test runners and tooling is just rougher, in my immediate experience. Given this practice it may not be a problem.

I’ll post an article with my progress and the metrics I’m using in my practice. My initial goals for the practice are, get through the first 10 euler problems, in python, with test coverage.

A lot of people, myself included, are thinking about how the software industry can instill learning and getting better industry wide.

The Software Craftsmanship movement seems to be the next iteration of this thought.

Its a thought process that there should be a very small gap if any between, getting it done fast, and getting done right.

There are a lot of concrete principles that people are associating with this movement. Single Responsibility, Open Close… However, that is a very narrow way to look at it. Especially if we expect all people in all languages to aspire to be craftsman of software.

To me it all comes down to how you assess where you are in terms of quality, and what needs worked on. Then working on those things in order to achieve a higher level of quality. If tested code is better than untested code, and you haven’t ever tested, or testing is very hard for you to do in a crunch, maybe you just need to practice testing more?

Deliberate practice, the kind that professionals in other fields use to be at the top of their game, is very much a part of this mind set. I’ve heard a lot of people echoing this sentiment without putting their finger on it directly. Analysis of where you are in terms of where you want to be, and identifying things you can practice to get to where you need to be.

So I am going to be writing a few articles on my thoughts of how I’m doing this, and maybe others can benefit from deliberate practice in the same way.