Clint Hill

I wanted to document the last two projects a little …

Accomplishments

The first was a website for a property management company. This should go live today or tomorrow and I’ll probably post it here. This site took a while to get through because of conflicting timelines and deadlines. Fortunately the client was extremely patient. I’m proud of the work. The site design is really nice and the work was pleasing.

The second was a website for a payment gateway. It should be live in a day or two as well. This project was good for me. It forced me to step back into .NET and made me learn a domain I hadn’t completely understood yet. Going back into .NET, specifically C# was good because I was able to bring some Ruby mentality to the code. I noticed that I wrote fewer lines of code and only wrote code I absolutely needed. This isn’t Ruby idiomatic per se, but it’s the style I learned best from Ruby – not C#. I also noticed that my design process was much more fluid than in the past. I didn’t sit down with UML diagrams first to mock up the design, rather I sat down and started writing.

Lessons

I call these lessons because it’s true, I did learn. But it’s not new lessons as much as reminders. I know all of this stuff. I just need to be more disciplined.

First I learned that I shouldn’t write notes in too many different places. I found I had too many places with notes and sketches. This was problematic because when I’d get to writing code I may only have one piece of info in front of me, even though I had a couple of pieces of info somewhere else. There were quite a few times I’d post products for review and whole requirements were missed simply because I was looking at the wrong note. I did a great job of note-taking but a pretty poor job of note-reading. Right now I have four notepads and two clients and the notes are scattered amongst all of the notepads. The result is that going forward I will put each client project into it’s own Moleskine. This way I can deal with only one notepad at a time for each client.

I learned I should stick to my guns. The second project was requested to be done in 40 hours. Given the requirements I read at the time it seemed doable. And I agreed to do it – even though I quoted more than 40 to finish it. In fact I folded on that twice. My original quote was 60-80 hours. Then it turned into 30-50. I conceded to the client’s wish and agreed to try and do it in more like 40. Turns out we are really closer to 60-80 when it’s all said and done. Funny thing – I don’t feel bad for having missed the deadline as much as I feel bad for agreeing to do it in that short amount of time. Software requirements change and timelines should change with them. Looking back on the work I did it is much bigger than 40 hours, and the original requirements I was provided represent half of the whole project.

The last thing I learned was to take my time in the first week of a project. I need to really absorb the whole product before I dig in. I still need to write code early, but I shouldn’t do it to simply fulfill one or two of the requirements. I should do it with the whole product in mind. There were a number of times where in the middle of writing code for a feature I would realize that there were actually two or three features hidden in the one I was working on.

Pretty good work for the last few months. And from now on I’m going to focus my notes, stand my ground on expectations and take the time to think out the whole product early and often.