Great Tiny Teams

I am in the middle of my forth week of being apart of my tiny team. There was a development-facing team restructuring at Altmetric where we decided to have fixed teams of just two or three people. That’s a fairly small number, but there’s a few reasons we’re feeling more productive.

Our teams have gone from one team with everyone working on the same queue of work (the sprint); to two teams – one person handling support work and interruptions, whilst the rest focus on the sprint; to three tiny teams.

The tiny teams are working very well.

Self organising teams are lovely but your developers probably don’t have the communication skills for it. I don’t think I’m offending too many people by lumping us all together and saying that. Toes get stepped on, work is duplicated without realising, and interfaces accidentally end up clashing. We’ve JIRA boards to keep all that clear, but only really get updated when someone is prodded to.

None of this can happen in a tiny team of two people. Sharing progress becomes more concise, since updates are more frequent, and so quicker and clearer. There’s hardly any need for tools for developers to keep up-to-date when you’re sitting next to the person you’re sharing the work with.

Another problem, which may stem from developers’ social skills again, is in our bigger groups of four or five people finding a pairing partner is much harder. Should you interrupt Johnny to pair with, or wait for Shaun to be free? That choice is taken away when there’s only two of you. If you’re in need of a pair then you’ve only one place to turn.

The same indecision disappears when it comes to code review. You have to review your partner’s work, no one else will. Whereas before you might shy away from reviewing an overly large pull request, you’ve now got to sit up and understand it.

Those are just a few of the reasons I’m excited about tiny teams at the moment.

Finding meaning in poetry

I have read my first book of the year, and it has turned out to be a poetry book.

I found myself relistening to a lot of Bo Burnham recently, and discovered he had a whole new set of work I’d not heard. In what, Bo reads from the poetry book he’s written. I bought it pretty quickly as I had recently finished another book.

I’ve never read much poetry – what I have I don’t remember – and so, I’m not sure how ordinary this particular book is. I do quite like, at least, I’d say, about two-thirds of the material in it.

There’re some pieces which are funny, some which are making a point, and some where the point isn’t all that clear.

Sometimes, I’d read one of the poems, wait before turning the page, and think. The conclusion that I often come to is so unusual that it can’t be the intended meaning. Maybe, that is what separates poetry from books – giving the reader license to draw their own meaning.

On the other hand, maybe the author totally knows what they’re doing – how they’re driving you to self-reflect. Maybe, that’s what makes a good poet.

New Year’s Philosophies

My New Year’s Resolutions never pan out. The only time I think about them past the first week of January is the last week of December when I looked back at the blog post to check if I’ve accidentally completed any of them (nope).

This year I’m choosing to do New Year’s Philosophies instead. I’ve two that I’m thinking of in particular:

  1. Try and leave this world a little better than you found it.
  2. Produce more than you consume.

I’ve had these two ideas in my head for a very long time, and sometimes I act on them. I want to make sure that this year they’re always in the front of my mind.

The first one is an old Boy Scouts expression, and they say “leave the campground better than you found it”. But this applies to everything. The code you’re working on, the table you’re sitting at, or the bus stop you’re waiting at.[1] Around the home this should mean you’ll never have to dedicate a whole day to tidying – it should just happen. At work the aim is incremental tech debt payments, rather than six month projects. And why not pick up that coke can that someone carefully placed next to the bin?

The focus is on iterative improvement with low time cost on everything.

2014 has been a huge consumption year for me. I don’t know how to get these stats out of Steam, but I’m sure it’ll tell you I’ve spent hundreds (maybe thousands, literally) of hours gaming. I’ve rewatched a lot of House, BS:G, and Breaking Bad, completely watched all of Silk, Orphan Black, Utopia, Vikings, Modern Family, Damages, series three of Great British Bakeoff in one weekend, House of Cards, and a lot of Homeland. Hours and hours and hours.

I’ve produced very, very little.

So those are the philosophies I want to keep front of mind the next twelve months: iterative improvement in all aspects, produce more than I consume. Seems simple enough…

[1] At which you are waiting, blah blah blah.

Symfony Live London 2014

Symfony Live London was last Friday which was great, and I’d recommend it to anyone in the Symfony world.

I’ve said for a while that Symfony is the lead in the Clean Code area of PHP, so it wasn’t surprising that many of the talks were about that, rather than Symfony itself. I stuck with track one all the way through, and all of the talks could be considered talks more about clean code than Symfony. Many were about writing code that works easily with Symfony but not for it. Matthias’ talk could have just as easily been called “The Framework Trap”, to go along side Jakub’s.

One of the disappointing aspects of the conference for me was that it felt a lot like receiving lectures at university for some talks. “Here’s, academically, how you fix this problem in a controlled, greenfield environment.” The best talks I saw looked at specific issues, like Konstantin’s. He was telling a story here, rather than teaching. Teaching by storytelling has been the way humans have learned for thousands of years, and there’s not nearly enough of it now.

I’d love to go to a conference dedicated to people telling stories about working on their (possibly legacy) projects and making them better. Some of the talks should be able how they did that and completely failed – losing months of dev time and ultimately ending up with a worse product. Technical discussions on how they realised they were crowbarring a design pattern that didn’t fit (emphasis on how they realised). MyBuilder could come and tell their story. phpBB could tell us how their move to Symfony was. I’d pay for that.

Dangling underscores

A pull request at work sparked a bit of conversation[1] about using underscores in JavaScript to describe a function as being private. It was this code specifically:

Because our logic isn’t as separated from our database as we’d like, many of our API tests touch the ES database. In order to avoid futsing up our actually data, we just want to make sure it’s only ever talking to indexes starting with “test_”.

My suggestion was that we should refactor this so that we don’t need to be exposing what should be a private method.

The argument was that this is a private method; it’s convention in JS to just use this underscore syntax. But that argument really just comes down to “that’s the way it’s always been done.”

This was fine back in the dark days of JavaScript, but we’re much more organised these days. And as our industry grows more mature it’s our responsibility to keep up with it.

Leaving something public really limits how much you can change later – regardless of it being an “underscore private method” you’re still letting others see it, and you’ve no way to know that it’s safe to delete that method once you’ve changed your implementation.

Even if you know that’s not a concern,[2] it’s still a good habit to get out of. And a free one at that.

[1] Which had nothing to do with the feature set being added, as always seems to be the case: comment on the low hanging fruit, rather than the structure or flow of the code.

[2] In this example, the proxy probably won’t be used again and has no need to be extended.