Helping “Real People”

I have a note in my notebook, a quick quote: “talk about real issues, that affect real people.” That’s how you’re supposed to capture the hears of the people you’re trying to persuade. Putting that idea in the scope of the Human Rights Act is tricky for me, because so many of the rulings that have come directly from the European Court of Human Rights don’t affect “real people”, the British-every-man.

Taking a look through RightsInfo’s stories and you’ll read stories about a prisoner who was falsely accused being denied representation, or victims of slavery being forced to manage cannabis crops, or children fighting to live in their home whilst their parents are threatened with deportation. Can you put yourself in any of those shoes? Can you foresee yourself being in one of those situations?

You just can’t. For one thing, many people who are being protected by the ECHR in high profile cases aren’t even British. And these situations must happen so rarely, in such bizarre circumstances. Don’t feel bad about being unable to emphasise with the people in those situations. I can’t either. Most people won’t be able to.

We’re fortunate enough to have the European Convention of Human Rights though. During a time of experience, just after the worst war the world will ever see, where many were in horrible situations, these freedoms were decided. We don’t need to decide those freedoms now, completely out of context of the suffering they’re designed to protect against. We saw the horrors and we vowed never to see them again within our borders. That’s why we have these set in stone ideals, which don’t need to be subject to amendments.

We must protect anyone who falls below this standard of care. Be happy that these cases are rare. They’d be much more common without access to the ECHR through the HRA.

The European Court of Human Rights, miles away, in Strasbourg

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.