anthony galvin

When I started off in web development, back in the last century, everyone was a generalist. And generally people didn't really know what they were doing. Which was fine, we made it up as we went along, learning little bits along the way. For most engineers working with the web, the problems weren't that complicated. Tying to get your blink tag to render on various versions of IE and Netscape Navigator. Infuriating for sure. But in the grand scheme of things not that complex.

Fast forward 25 years or so and complexity abounds. Or it can do. Especially for bigger organisations working with bigger teams on (hopefully) bigger problems. In the front-end world new frameworks have supercharged the user experience of many web based products and services. With the added complexity and learning curve that a power tool demands. App development, for a while the home of the 'native' developer also has a plethora of cross-platform and alternative authoring options. These promise (though don't often deliver) a simplified development environment. Away from the front end, contributors to languages such as Grails, Python, GoLang and node.js add more and more features. Promising better, more powerful tools, with an ever improving developer experience (I said promise).

So where does this leave engineering teams and hiring managers. In a medium sized tech company nobody can know the entire architecture and tech stack. At least not with any mastery beyond some boxes on an investor presentation. It takes a team to deliver and in most organisations lots of different skills.

When hiring engineers, I always enjoy learning about how they solve problems that I don't see everyday. I meet a lot of candidates. It's fascinating how peple deploy so many different tools and technologies in such a variety of combinations. Sometimes people describe themselves as "full stack engineers" - which isn't a phrase I love. Full stack invariably means some back-end and some front-end engineering experience. But it doesn't mean the entire stack. No one person at TodayTix Group is able to deliver with mastery across every part of our architecture. We don't expect any one person to do so.

But we still hire full stack engineers. Teams taking on a problem need to be able to solve that problem regardless of the technology or tool that it touches. Which is why we have cross-functional teams with a mix of skills, experience and perspectives. Good engineering practices and process can go a long way regardless of the technology in play. The best full stack engineers (or multi-stack engineers for want of a better label) can bring multiple points of view. Arguably good engineers are generalists. However, complex problems often need someone to focus on a specific area, and in tech companies that specialism can get very, very specific. Which can be good for the organisation and very rewarding for individuals, at least for a while.

When I say a while, I have a specific example in mind. When I joined TodayTix Group I inherited a migration project. The goal was to integrate an acquired business. Moving off a legacy main-frame system that was decades old. Many of the project team had been maintaining this system for decades as well. They were true specialists. Day to day work for the team was a combination of being a care worker, therapist and engineer. But their decades of deep specialism hadn't equipped them or the company for the future. This wasn't the fault of the team. A failure of leadership had stymied technology strategy. A failure of people management and career coaching. Aligned with diverging company and individual priorities. The longer the business stuck with the mainframe the less incentive it had to develop the engineers supporting the system.

In a career as an engineer it makes sense to focus on the challenge at hand, to specialise in technology and tools that benefit you and your team. The path to being an experienced engineer is to build experience. Learning a new framework isn't experience. Solving some real customer or business challenges with it is experience.

But focussing on a single tool without taking the time to check-in on wider developments in your industry and chosen field is limiting. Ideally your manager should be taking some time to help you get this kind of perspective. But that's not always the case - especially if you're not a full time employee, work for yourself or work in a smaller organisation (and unfortunately in some bigger companies too!). If that's the case it's important to find other ways to do this. To have someone who you can chat to about career development, technology changes and what that means for you.

The goal for more experienced engineers is to be a general specialist. Someone with a variety of experience in different technologies, with knowledge of one or two technologies that are current. Like gardening career development is easier if you do it a little and often - not go on a training course once every 10 years.

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.