comment 0

Movebubble Sprint: Day 2

Today promises to be a quieter day – no meetings scheduled, outstanding support issues largely resolved, and half the development team out at a React conference.

My main goal for the day is to get ahead of the game a little by knocking off at least one of the two API-related tickets which need to be completed to support the new property suggestion feature; if I can get those done early in the sprint it frees me up to help elsewhere and pick up other stuff

Before I dive into that though there are the two standups and the routine morning coffee. Between standups, I also check that yesterday’s efforts to finish off the A/B testing framework ran okay. There can be a delay of a couple of hours after setting up SQL replication for RavenDB before the data fully catches up and as a result I was unable to verify the cohorts before leaving the day before. It turns out we’re allocating 31% where we should be allocating 30%; I fix the off-by-one error and inform the other team that the test framework is good to go.

Once I have my coffee, I start development at around 10.10. I’m able to dive pretty much straight into code – it’s a simple API endpoint to return a subset of our property data sorted in one of four ways. As such, I don’t need any time to think about design and there aren’t any events or triggers to worry about, so I’m in the zone quickly and confident I can bash out the code and associated tests by mid-afternoon.

I’m largely uninterrupted. Laura has a couple of questions about our system messages – she’s only been developing for a few months and is new to C# in particular, so this is expected. As a startup we don’t have a training budget so we handle training in a task-driven manner – Laura picks up tickets like other members of the team and then asks questions when she gets stuck. I tend to help with the backend ones; for front end questions it’s usually Valerio (of the Space Monkeys), Jack (our CTO) or Jordi. In my first job they had a similar approach to training and I was told it usually took around 18 months to become a ‘fully productive’ developer, so I expect this to continue for some time. Already though I have noticed that the frequency of the questions has reduced, which is a positive sign.

Otherwise, it’s nearly lunchtime before I’m pulled out of my zone. Adrian, the lead developer for the Space Monkey’s team, is using our app to find a property for himself, and has noticed some odd behaviour in our chat feature. As soon as he shows me I realise this is related to a configuration error which I pushed on Saturday and fixed the day before. I assure Adrian that the code he’s just pushed should fix this; though I am a little chagrined that I hadn’t realised users would be affected in the way he demonstrates.

Then again, there was a time when any bug that ended up in our live environment had me panicking. In particular, a couple of the mistakes I’ve made over the last six months have had fairly major, if temporary, affects on the usability of our app. However, I’ve come to accept that an inevitable side effect of attempting to do several things at once at double speed is that mistakes get made.

We could slow down and push back, but from a business perspective it’s helpful to be able to maintain the development pace we have, so while bugs which make it production still disappoint me, my reaction is no longer one of self-castigation. Rather, I am constantly asking the question ‘how can we improve the process to prevent this without compromising on development speed’? Not all of the ideas I have relating to this get actioned, but I do feel we are making progress.

By the time we’ve finished discussing and investigating the problem, it’s nearly midday, so I decide to grab an early lunch. Today it’s Hopper meal deal – £4 for a sandwich and a coffee – and I take my laptop to the lunch table so that I can write up yesterday’s blog account.

The first draft takes around an hour – punctuated by 20 minutes of helping Laura debug some irritating quirks of Nuget and Visual Studio – and I’m back at my desk at around 13:30. Writing is not a standard lunch activity for me, it’s just the first chance I’ve had to write up the previous day as I spent the previous evening play football and starting the latest season of Suits which has finally made it onto Netflix and which has become something of a ritual with my wife (complete with our own theme music dance).

I dive back into code and bar one more 10 minute session answering Laura’s API-related questions I’m again able to sink myself into my work, to the point that I’ve finished my ticket and written all associated unit tests by 15:20. However, I’m not able to merge my ticket just yet as the build is broken. Laura has merged her finished status message work, but as she’s not yet fully accustomed to the workflow she has forgotten to check that it builds correctly and run all the tests. I take the opportunity to tease both her and Jordi about this (since Jordi did exactly the same thing on Friday) with a mock ‘appreciation’ – a Slack channel where we post messages when we think somebody has done good work. Jordi, seeing his name mentioned, sends me a worried message from the React conference, wondering what he’s done – I assure him that it’s just banter.

There’s some kind of issue in our dev environment – apparently we’ve fired off 50,000 test emails and used up our Mailgun allowance – but I let Jack and Adrian sort it out as I look down my todo list for something to do while I wait for the build to be fixed. I’ve got some outstanding documentation tasks – nothing critical, but I’ve been trying to formalise our sprint process and get it all on the wiki as I feel like we’ve been guilty of making stuff up a little over the last few months. The idea is that everybody on the team should know not only how we run a sprint but why we do it like we do and that we’re actually able to extract useful metrics relating to velocity, scope creep and our ability to meet deadlines. We haven’t really been keeping those metrics up until recently but I would like that to change.

So I spend 50 minutes updating the wiki space that I started a couple of weeks back – I add a document relating to our technical preplanning session and a table for tracking velocity metrics and support load. Once the build is fixed I save my progress and then go back to development; merging the previous ticket into master and then adding a new branch for the next API ticket. I could have started on this an hour earlier, but as both Laura and I were working in the same space I preferred not to branch off before merging her code as there were a number of conflicts to be resolved.

From there, I’m pretty much on the home straight. I get another hour and a half of development in, finishing at around 18:45. I would normally aim to finish work before this on a Tuesday – other than Friday, it’s the only night of the week when neither my wife nor I have a regular engagement in the evening – but a long lunch coupled with the fact that I was enjoying some uninterrupted development team mean that I’m quite happy to spend a bit of extra time in the office. Today I am the last to leave. I’ve also nearly managed to complete the second API ticket – just a couple more tests to write in the morning – which will put me a day or two ahead of schedule already.

All in all, a good, productive day.

Leave a Reply

Your email address will not be published. Required fields are marked *