There’s tons written about the world of startups and even freelancers, but almost nothing written about the world of software development services. The underbelly of the startup world, shops which get hired to do a lot of the dev work. I’ve decided to start blogging a bit more about it, mostly adapting emails i’ve sent to my team . Hopefully they won’t kill me for using them as an example. The joy of being a consultant is that you’ve got more freedom over your time, the downside is that eventually your time is logged and billed to a client hourly. That means rather than just reporting what you’ve done in a sprint retrospective, you’ve got to keep a log. At Cubox, we use minutedock , it’s nifty and comes from New Zealand, a country which like Uruguay, is small, was invaded by the british, has the southern most capital in it’s hemisphere, and has way more sheep than people. When developers are billing their time, they need to track what they were doing. It’s hard for clients to know if you spent the day playing call of duty, or fixing some complicated bug. The time logged in minutedock is provided to clients in our invoices, as written. It is the primary way in which everybody knows what you were working on, how the project is advancing, and if there are problems. When clients are worried about how much things cost, they use these items to dispute payments. All entries in the time log need to be detailed. They need to say specifically what you were doing and what value it provides to the client. Remember these may be read weeks, or months after you wrote them, by somebody who does not understand the code or architecture of the application. All work we do should have an associated ticket in pivotal tracker, if it doesn’t exist when you start to do the work, add the ticket. It’s how we track things, it’s how our clients know what we’re working on. All time logs in minutedock should have the full ticket title. If you’re working on a sub-part of that ticket you should include that information. Examples of from the logs; The good, the bad, and the ugly. GOOD – “Implement Connect Flow Header to Confirmation step, routes modification for testing, style changes, copy modification” GOOD – “Clean up validations of Deal/PurchaseOrder. Fix bug with Purchase order and refund” GOOD – “Updating rubydeps for ruby 1.9 to create a dependency graph” GOOD – “#meetings discussing high-level architecture, services, jobs, and the implementation of the customer FSMs” GOOD – “Fix purchase order creation for new customers WIP” GOOD – “Fixing template error in collect_address_data partial” BAD – “We have a bazillion pending tests. See to that.” BAD – “Analytics, resque, etc.” BAD – “Changes in coffeescript models” BAD – “Changes for KM and GA” BAD – “oauth” BAD – “Pairing with pablo” BAD – “Pairing with pote” BAD – “Js client” BAD – “Meeting with Clark” BAD – “Fixing Mixpanel gem bugs” BAD – “Fixing sign up issues” BAD – “integration tests” BAD – “Improve site usability” UGLY – “” (Thursday Feb 2 – 0:45) The good ones are clear and descriptive. They include more text and i can understand what was worked on even if i wasn’t following the project day to day. The bad ones are vague, sometimes not related to the work at all. Often the bad ones are like 12 hours ‘oauth’ or 8 hours ‘integration tests’. Sometimes the bad ones include abbreviations which aren’t explained or documented anywhere. Very few programmers are judged by the quality of code itself. Ironically enough, we judge programmers by the window dressing around their code. That is, those blog posts, talks, readme files, and application as a whole which is judged. Star programmers are known for what they built and how they communicated it. When doing contracting, as we do at cubox, a big part of that communication are the tickets we write when we log our time. It feels dumb, and less important than the real work. What’s more, it’s a written language, not code. It’s important, and it’s how we’ll be judged.
View the original here:
Logging consulting hours – The Good, The Bad, and the Ugly