The Team is the thing

When I asked one of my colleagues what was more important under pressure - the team or shipping the product - he unhesitatingly answered 'the team'. Despite the enormous stresses working as an engineer places on timely delivery, that's a lesson I don't ever want to forget.

Over-focus

I'm a big proponent of mindfulness. Part of the reason I'm so in on the fad is down to a stay in hospital a few years back, and the rediscovery of the joy of living. Since then, I've meditated daily.

I'm also a big focusser. When I'm latched onto completing a task, I find it tough to walk away. Combined with a strong perfectionist streak, this means I can produce some really cool things. It also makes me much harder to work with.

I don't think this attitude is uncommon for developers. Developers are primarily creative animals: they like to build something (usually something worth building), and most like to do it with at least a modicum of craftsmanship. Creating things of value, things you can be proud of, is a fundamental human urge: one that's made ever stronger when you're building using nothing but thoughtstuff. In addition, we see focus as the mark of a virtuous programmer: multitasking is of secondary importance to your ability to ship a fix under pressure.

This doesn't seem right. A well-formed team of two will have far greater longevity than the hotshot solo programmer: the 10x virtuoso is fun to have around, but makes for a really tough working environment. For ages I've bought into the solo programming myth; that a truly great programmer is a solitary individual who loves to create things of beauty to their own particular standard. But programmers must be, first and foremost, team players. Scrums and standups and Kanban boards and Agile and storyboarding are various attempts to address this myth, and they're very powerful - but they need full buy-in from team members to work. To buy in, those members have to buy out of the paragon masterful soloist legend, and recognise their true value as a coherent entity.

So, I have resolved to bring far more mindfulness to my programming. I'll improve my context-switching, and respond immediately to others' needs, rather than replying with the 'one minute' tic I've developed. I will still 'flow', but not at the expense of my colleagues' needs. I know this will leave me less exhausted, and far more fulfilled, than I regularly feel at the end of the day. And I hope - rather, I know - it will make me a better engineer, too.