anthony galvin

Feels like every few months I end up sharing this link. Email has been around for 40 years and it's still catching us out.

Some thoughts on technical leadership and coding.

The other day someone in the team asked me if I still write code. Which got me thinking about how, especially in agency land, senior technologists often don’t. Faced with the growing need for Technical management and client facing technologists, many larger digital agency environments have a fork in the road where people can pursue a less hands on route.

Over the years I’ve worked with lots of senior folks who continue to be practitioners. People from an engineering background who are still, at least some of the time working with software. This isn’t unusual in other fields - nobody expects the top brain surgeons to do all the operations, but they are expected to do some. The same is true for lawyers and in agency land often true for strategists and UX / design folks.

That’s not to say that management and leadership aren’t skills in themselves, skills that require practice and a significant time commitment. As an engineer the way you scale and produce a better output is (or at least should be) by having a team. The team is your unit of awesome.

There’s code, and then there’s code. On the projects I’m involved in the amount of real technical output I contribute varies significantly. Often the things I’m doing are prototypes, setting a direction - more like someone doing a sketch that communicate an approach or a style. It’s not about being ‘the best developer’, firstly because defining best is difficult (fastest, fewest bugs, most code, least code, best collaborator etc..) and also because that’s probably not your role on the project.

Sometimes it’s just about chipping in with a bug fix, picking up a few tickets and helping when the deadline is looming and JIRA is looking a bit unpleasant. It’s fairly unlikely that I’m going to be picking up lots of dev work across any of my client work, but it is an aspect of how I go about solving problems in my  day-to-day work.

That’s not to say it’s easy to stay on top of the ever changing technology landscape, but for me it’s not a binary choice between management and coding. They are part of the dynamic of technical leadership, and it’s important that you make time to develop your skills in both areas.

A little while ago I wrote about some of the tools I’ve been using, but my most frequently used tool, isn’t really a tool, but a programming language which has become my default way of solving problems with software. Javascript.

The benefits, convenience and inevitability of Javascript have been well documented - to the point of ’overwhelm’. It’s not just the ubiquity of the language that’s making it the tool of choice for agencies, start-ups and corporate teams alike (though as someone who helps build agency teams, being able to double down on a single language for front-end and backend development is pretty handy). For me it’s the quality of the tooling (with the likes of PM2 and Gulp becoming part of my standard toolkit), and also the community that supports, builds and shares around this common eco-system.

It’s easy to find people who decry the rise (and rise) of JavaScript. When I started my first web job 17 years ago, it was impossible to imagine that you’d be able to get JS to run consistently in a couple of browsers (with a touch of document.write) never mind power an in cabin airline experience and more. With the rapid adoption of the latest versions of JavaScript, and the continued evolution of the language, I’ve got a terrible feeling I’m going to be writing more and more javascript for a while to come. 

What does work sound like.

What should work sound like.

If you walked the floors of a successful, creative digital agency with your eyes closed could you tell if ‘things’ were getting done.

I noticed that @crashposition had a couple of playlists called “Music for coding and thinking” - which got me thinking about the way developers use music.

One of the 12 items on the Joel Test is a quiet working environment, without distractions. For many developers, what this means in practice is a quiet environment where they can put on some oversized headphones to filter out interruptions and side conversations - and create their own carefully controlled musical accompaniment to coding.

In most cases developers are trying to create or maintain ’flow’. Flow is for many coders the thing that gives them most satisfaction - the point where almost effortlessly working code seems to shoot from the brain through the keyboard and onto the screen without interruption. Coding downhill, with your feet off the pedals.

For many developers a day with good flow is a ‘good day at the office’.

Flow can be deceptive - extended periods of head down development without collaboration or an alternative viewpoint can result in a spaghetti code pile up of insane proportions. I’ve worked on plenty of projects where someone sat up all night writing code poetry  - 'fixing everything’ - because they were in the zone - only to leave the team saddled with the Object Oriented equivalent of doggrel.

Collaboration is a key attribute of a good developer, something that is especially true within an agency environment, but also true for anyone who isn’t just a 'lone wolf’ developer. Which means how effective is 'headphones on, head down coding’? Finding the right channel and balance of communication is important - traditionally IRC has provided the right level of persistence and real time for most developer discussion, but increasingly new tools such as HipChat and Campfire are finding ground. This seems to be especially true with more distributed remote teams.

So what to listen whilst coding, or rephrased, is there a musical shortcut to achieving ‘flow’. If it was that simple then I’d have one playlist or a couple of tunes to listen to on loop that would instantly transport me to the land of easy coding. If only it was that simple.

I’d started drafting these tips for the R/GA tech blog when Bobby Schultz beat me to it with his post “The 5 pillars of remote collaboration”. Despite this I thought I’d post my thoughts here anyway.

It is certainly not a recent trend for organisations to be looking to work with remote software teams. Whilst previously this was primarily motivated by a move to reduce costs and offshore development, increasingly there’s also a desire to harness technical talent irrespective of location. The growing R/GA network means that we are often reaching across offices to staff projects teams and leverage talented technologists. 

Here are a few tips that help those projects along.

1. Daily stand-up has to run like clockwork
Even if you’re not running an agile or adaptive planning process it’s important that everyone is committed to making ‘the daily’ a success. This is your most important meeting of the day. It needs to be professional, effective and run to time. Time is important, on projects with a wide geographical span as someone is going to be getting up early or staying late to contribute to the daily, so everyone needs to respect that.

2. Keep an open line of communication for all developers
Informal communication is essential between the development team, what my colleague @philhawksworth calls a 'back channel’ for open discussion, questions and banter. This is where 'the culture’ of your team is going to be fostered.

3. Use video
Make all calls video calls, even though we can get by over the phone the psychology of video calls helps to re-enforce relationships. Where there are a group of people in a single location use a dedicated meeting room computer and gather round a single large screen so that remote workers take up a disproportionate amount of space in the meeting room.

4. Have a robust, repeatable build and deploy process
Whilst continuous integration and continuous deployment may not be appropriate for all projects, when working with remote and distributed teams a bullet proof build and deploy process is essential. If you’re running a semi-automated build system everyone should be able to run a build regardless of location - without this you’re going to start having bottle necks and some users are going to be more equal than others. With an automated build process all developers are have equal ability to break and fix the build. 

5. Be location agnostic
If at any point the team start thinking about people who are 'offshore’ or 'in New York’ then that’s the start of a problem. Everyone on the project may not be equal, but the source of the inequality should not be location. 

This doesn’t mean that you shouldn’t  be sensitive to different locations and cultures - if it’s a public holiday in London, then it’s a public holiday in London. These things tend to equal themselves out and there are no surprises - you don’t often get short notice public holidays. The key thing is that you’re being equally sensitive to location and culture regardless of location.

6. Let remote people lead parts of the project
This sounds slightly counter intuitive when working with a group of remote developers or a distributed team, but if you want to embed a location agnostic culture don’t be precious about having all parts of the project led from the largest or main location. If you’ve got a fantastically talented front end tech lead on the project who is based in South America and you’re in Chicago, then there’s few reasons not to let that person lead the front end development.

7. Make time for a 1:1 
If you’re leading a project and you have remote developers, make some extra time to have a one-to-one session with each individual. You won’t be to recreate that hallway conversation you might have if you were on the same corridor, but once you get a cadence to these conversations, it’s amazing how productive they can be.

8. Face to face buys you time
There’s an internal saying @RGA “that face time buys you 6 weeks”. Whatever the number for your team take advantage of any face time you can get, both from a work perspective but also from a social “let’s go to the pub point” of view. It’s worth it’s weight in something heavy and valuable.

Last week R/GA London had it’s first Make Day - two days of creative and technical exploration, in some ways done just for the joy of being able to make things. I was astonished by the diversity and quality of the work that people produced. Russell, has posted a round up of the different projects, which ranged from a (working) face recognition system running on Windows 8 (which isn’t even publicly available) to some marmalade. For my part I worked as part of team building a “tea and coffee roulette web app / game”.

The concept itself was pretty simple - make a webapp that would allow you to join a tea round, the twist being that the last person to set a preference and complete a simple task would have to make the drinks for everyone else. A quick 10 minute brainstorm and one whiteboard diagram later and we were underway, with @sanderkuypers doing the visual design and the rest of us (@benoitgrelard, @loopdream and myself) quickly began hacking together some working software.

From a tech perspective we decided on a web app (ie, a mobile application that isn’t device specific and can run in the browser) as the best way to get something working with our dev skills. From a front end perspective you can get quite a lot of motion data from some devices (such as an iPhone) via JavaScript, which meant we could build a ‘shake the sugar’ task for the race element of the game. Last one to a hundred shakes makes the tea.

To speed up getting to this device data and creating the UI we used the jQuery JavaScript framework. In the background the game engine was built using PHP and CodeIgniter to handle user registration and keeping everything in sync. We had thought about using node.js to handle socket connections to the devices, but with time limited we settled on using Pusher (a hosted socket service), which had us up and running in about 20 minutes. Behind all this sat a simple mySQL database for keeping everything together.

By the end of the two days we had a working game, that looked great and actually worked - user and device registration, automated email (warning users that the game was about to start), a countdown, simple game (track and field style) and notification to the winners and users - all in real time (via web sockets).

Apart from being a break from our usual client projects and lots of fun it was good to build something a little different - although we didn’t stray too far from our core competency, we did try a few new things. Russell and the management team set some pretty loose (open?) goals for make day, but as the project progressed it was clear that one of the main motivating factors of our team was to deliver working software - which is a pretty healthy team ethic.

I’ll post a link to the source code and a working example once it’s online.

– Follow Up –

Dave suggested that one of the factors for the (relative) success of the project was that the team comprised a variety of skill sets. Whilst this is true, it did come about pretty much by accident.