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.

On keeping git clean for pull requests

There’s lots of places that you can find talking about how to write a good commit message. Some will even give good technical reasons for doing so, but only a few will give you actually good reasons. When’s the last time you had to use git log --oneline or send a commit via email? Maybe Linus does this everyday, but you don’t.

The one reason I find most important when you’re thinking about the git history as a whole (not just on a per-commit basis) is during peer review. In my current work place and my last the way we did code reviews was by a collogue pushing to github, and opening a pull request. It was then someone else’s job to review and pull that in. That seems to be a very popular workflow from talking to a number of tech teams the past few months whilst interviewing.

Forget about being easily able to look back in the project’s history and see why something was changed, or being able to see a good message on git bisect. They’ll come incidentally with the following method.

Review is the one stage in product development when you’ll be reading commit messages the most, but it seems like no commit messages I’ve encountered recently, at the very least on my team, are written for that part of the process.

Failing to describe the scope of the message

The first thing I want from a commit message is to know the mindset I should be in whilst reviewing. What are you trying to achieve with the code change you’ve introduced? This Doctrine commit message could be slightly better by saying “always add ‘isEmbeddedClass’ to the serialise array”. I could look at the commit message, and at the code change and see “yup, this is doing exactly what the author wanted it to do.” From that point, I can start thinking of side affects the code change might have on edge cases.

The problem with “fix bug” is that I can’t tell what issue with the code you’re talking about, and so the only review I can do is “yep, that’s syntactically correct”. I can still think about potential side affects, but I’ve no idea if the original writer has thought about and accepts them.

Splitting one unit of work across too many commits

A unit of work should be valuable in some way. A commit should hold one unit of work. If we were to revert this one commit from your pull request, how many other commits would have to be reverted too before we got to a working piece of code? It should be as few as possible without affecting other features.

This usually happens when you’re working in stages and commit each stage. That’s fine at giving you good rollback points, but they should be merged together later on when you’re self-reviewing. An example of this is in the BrowserQuest repo, two commits right after each other with the same commit message: ae773f and 9c1d5.

A more common (and more annoying) issue is when a file has been forgotten to be added, and so the second commit is “lol, forgot to add this file”.

These are exactly what  --amend flag to git was added for; instead of adding a new commit, just push the changes into the last commit. Slightly more complicatedly, --fixup exists too.

Never mix styling or whitespace changes with functional changes

Most teams with an old codebase have the idea to clean as they go along – that’s a good idea (rather than a huge, up front investment).

These commits should be on their own, because I’m not even going to read them. Your team mates should just be able to auto-merge these commits in (especially in a language like PHP where whitespace doesn’t matter).

The problem is that if you’re changing from tabs to spaces, the git diff will say that every line has changed. Your functional changes will get buried and it won’t be possible to see if anything will have unexpected side effects.