Strategically Shaping Projects

Published on Tuesday 13 August 2019 | 4 minute read

So today for day 17 of #100DaysOfCode challenge, I'm not going to code. On a dog walk this afternoon I was reflecting on my process for this challenge and decided that now would be a good time to get more strategy.

For the last 17 code-days, I've been making iterative changes to this website. On some days I followed a theme, like days 4 thru 8 when I was focussing on TDD. On others, I have also been distracted in making a package that I never did tidy up, a simple newsletter signup that I never did complete, and sinking hours of time into an API that basically serves no useful data.

It's all great learning. The exploration is really valuable and the reflective process of this journaling is what's helping me gain insights into my developer work flow. What I want though is to work more strategically towards visible outcomes. Visible outcomes = accountable working, and a great way to get feedback. Even my dashboard I kept as a private thing, and that is where a lot of my visible outcomes have been over the last few days. Hidden being a login 🤦‍♂️.

So today that's my coding task, to reflect on my process and come up with a better way forward. I think it looks like this:

  • Define mini sprints for myself
  • Work on a sprint for five days (a working week)
  • Work for a maximum of one hour on each of those five days
  • Have a viable product live on this website at the end of those five days

It's going to be a tough call. Sometimes, it does just take two hours of Googling to undo that stupid mistake you make (no, I didn't accidentally call composer update at gone midnight last night and update a number of dependencies to require a php version higher than the one I'm using... Note to self: git checkout {an-earlier-commit} -- composer.lock is your friend :)

However, my limiting my time it will sharpen the decision taking, force me to be more strategic, and help me keen balance in other parts of my life - at the moment I also have another full time job, my fiancée is away so I'm flying solo taking care of the household, and there is this awesome job that I want to apply for this week.

One more thing about the time limit: Setting an upper limit is cool because it keeps me wanting to come back for more. When you only have an hour a day to code you don't have any time to fall into that abyss of why-is-this-so-frustrating-and-hard, and it's def going to be easier the next day (the best debugger ever made is a good night's sleep).

With all this talk of keeping track of the time, then I think we have found our candidate for the first sprint: a time tracker. I personally already do this using Google Sheets. I want to know how much time I am spending doing what. When I'm doing a fixed price client project - how much time did it actually take me? And how much of that was time speaking with the client vs coding vs project admin and management? And of the coding - how much was writing tests vs features vs refactoring because I screwed up an earlier strategic decision vs foundering in the abyss of debugging bugs that don't want to be found?

This is all critical information for tracking learning, making competitive and well justified prices for projects, and getting that sweet sweet insight into my process so that I can refine, refine, refine.

With that decided, then as a start here's how the next five days might look:

\\ day 1: do a fat pen sketch[1] of what a minimum viable feature might look like, hash out some tests that will support it

\\ day 2: flesh out those tests into something that has the basics units working

\\ day 3: write some feature tests, and build out the features

\\ day 4: write browser tests to support the UI

\\ day 5: bring it all together, tidy up all snags

I feel like I'm probably being a bit ambitious with this to get it all done in five hours, but let's see how it goes and then refine for sprint two starting next week. As a final point for today, I'm going to SMART goal the sprint:

By the end of five hours, I will have a test driven time tracker feature that allows me to set the start and finish time of an activity that is selected from a dropdown menu. The cumulative time for each activity will be visible on my dashboard.

So there we have it. A plan of action. I like it. I've also said it before, but I'm going to cut back on the almost daily posting in favour of writing longer and more thought out entries that I post less frequently. I think that two times a week sounds good for now - that would give me about twice as long to think about and work on each.


[1] Shape Up by Basecamp is a super insightful bit of reading on how to manage projects. This idea of the fat pen sketch is lifted from here.

Made by Ed in Somerset. 2019.