anthony galvin

In the rush and push of the working week it’s easy to forget the tools and tricks that hold things together. Recently a colleague asked about a little workflow trick I’d been using and I realised I’ve never jotted down and shared a list of my day-to-day toolset, so I’ve posted the list below.

This doesn’t include the pure developer tools I use such as Sublime Text or Vagrant but hopefully the more general ones that might be more generally useful (I’ll post a geek tools list another time).

Workflowy
The reason I find Workflowy so useful is that in many ways it mirrors the way that I think. Infinite lists of bullets, searchable, taggable and sortable. And also shareable, so that you can turn a list into a collaborative workspace.

Twitter + IFTTT + Instapaper
This isn’t a single tool, but a neat little workflow trick. When I’m pushed for time or on my daily commute where I can’t always get a good data connection I often see interesting and useful articles on Twitter. When I tap the ‘favourite’ icon in Twitter, IFFT jumps into actions and pushes that article into Instapaper for me to read later.  

Google Drive
It’s not the elegant toolset of the drive apps that make it essential (though simplicity helps), but the simple power of cloud based functionality. It’s on all my devices, I don’t have to back it up, it’s pretty secure (with 2 factor authentication enabled), doesn’t run out of space (for a small fee) and I can quickly turn some private thoughts into a shared workspace. Remind me again why I want files on a local hard drive?

Tweetdeck
Some people “don’t do social media” and I respect them for it, they must be really smart. For me Twitter is often where I get lots of professional tips, articles and background info. In short it makes me look smart, arming me with facts and figures. Tweetdeck is my way of filtering and making sense of the thousands of tiny fragments of information that are flying through my feed every hour.

Slack / Skype / Hangouts
This could be called “not email”. I’m not loyal when it comes to the ever more commoditised world of realtime chat. If you’re on Skype, prefer Google Hangouts or Facetime then jumping on call is good with me. In a world where it’s about working with the best people, no matter where they are, video calls are unavoidable - but they’re not the only answer. Recently we’ve been using Slack on some global projects and the power of asynchronous group chat and file sharing on projects that run across multiple locations and timezones is invaluable. HipChat is pretty good in this space, but if you’re not tied to the Atlassian stack then Slack is probably an answer.

Pop App
Need to test an app idea really quickly or show someone ‘how it might work’. Then draw a few screens on a piece of paper and then fire up Pop App and in few minutes you’ve got a tappable, sharable prototype.

OmmWriter
Even the cut down writing interface of documents in Google Drive can be distracting - especially mid-afternoon when my notifications are firing at a terrifying rate. OmmWriter cuts the notifications and keeps it simple, perfect for focussing on getting the words just right.

Trello
In many ways Trello is the same as Workflowy (above), it’s a fancy, collaborative, list environment. But it’s the interactions and card like system make it different and a great way to create Kanban style boards to keep you (and your team) organised.

A few weeks ago I left R/GA after nearly 4 years, working first as a Technical Team Lead and then as a Technical Director. I’ve learned 1000s of tiny lessons and quite a few big ones over the last few years. Here’s some key ones.

1. Multi-discipline collaboration from day 1
Complex (digital) projects require talented people from many disciplines. Casting the right team can be a challenge, but once on the ground (usually at R/GA in a war room), collaboration needs to be rapid, open and without (too much) ego.

2. Code scamps (aka prototypes) are essential
Just about working software is the best way of explaining an idea. If you can sketch in code, getting something up and running no matter how hacky then you’re moving forward. The things you learn by doing this early are nearly always invaluable as long as you’re prepared to throw away more than you keep - being over invested in the scamp is going to get in the way of iterating.

3. Really good QA helps produce really good products
The internet is everywhere and on everything (Brad Frost, also ex-rga has some great slides about this). I’ve worked on projects where the QA engineer is testing on 20 devices. Obviously there are real benefits in test automation, but there’s no shortcuts - at somepoint somebody is going to need to tap through your app on all the devices, again and again and again.

4. Work smart and work hard
The industry has a long hours culture and sometimes working hard (late) is the way to a briliant product. But it’s not the only way. From a technology point of view investing in smart work; automation, auto-scaling, developer tools that work is way better than just staying late.

5. Access to tools and permissions matter
The battle for better tools and services is constant. If you constantly put a barrier in front of getting things done then you kill the speed at which innovation can happen and in an agency environment slow projects die a slow death. If it takes a 48 hour helpdesk response to get the CI box back online or multiple paper based forms to spin up a cloud service then the velocity of your crack innovation team is being severly hampered.

6. Location doesn’t have to be important
There’s a clamour to have EVERYONE IN THE WAR ROOM ALL THE TIME. But collaboration doesn’t really work like that. Clearly facetime matters, and at the right stage of the project it really is worth having everyone sat in the same room. But having highly motivated, talented people pulling in the same direction is way more important than having them sat in the same office (or even timezone).

Today is my last day at R/GA. It’s been an intense and entertaining 3.5 years. Everyone says, “the people here are amazing”. But it’s true R/GA people are talented, hardworking and (borderline) alcoholics.

I remember a couple of days after I started having to be part of a sprint review for a major web app project. There seemed to be hundreds of people on the call from all over the world plus a ragtag bunch of us in London. The review went OK, but it seemed like madness - the ambition of the project was unbelievably high and I couldn’t work out how we were going to deliver the work or get the various random people on the phone to agree about anything. I really wasn’t sure that I’d made the right decision to leave my cosy client side tech role.

But somehow we did it. The work was hard but the results were awesome, even if perhaps the client didn’t quite understand what we’d built - which is probably true for most of my R/GA projects.

What I will remember most fondly are those times when we aimed high, put our foot on the gas and delivered something that seemed almost impossible on day one.

There’s way too many people to call out individually but a big thanks to Patrick and the tech team here in London who’s hard work and talent made me look good on a daily basis and in particular the project teams on Pearson and Getty.

Thanks - it’s been fun.

This is a slightly extended version of my ‘all London’ email to the fantastic folks at R/GA London.

Recently I was asked to take a look at an API as part of an advertising awards entry that we were making. As with most awards entries the assessment I was making wasn’t just about the functional elements such as the available methods, approach to content negotiation and compliance with open standards, but also the way the API was presented. Was there good documentation and tools as well as an active an easy to engage developer community.

All those elements were there, but there was something else less tangible and probably more important that I was really looking for. What did the API really say about the brand? This assessment is more subtle, but gets to the heart of how and why an organisation is choosing to expose services to third-parties.

- How does the sign-up process work
- Can I have a limited number of API calls without having to sign-up, so that I can test if this is for me 
- Which programming languages are the code examples available in (the choice of languages can say a huge amount about the brand)
- How often is the API updated, is this a live project
- Is there an easy way to submit bugs or feature requests
- Which developer tools are being used to share code and examples (can I do a pull request on GitHub?)

The most important area to understand is the value that the API is offering to developers and third-parties, and by extension what is the expected return value the business can hope to receive.

Empowering developers though your API is a form of co-development with people you might not know so well. Choosing the playing field (the services) carefully is an important way of shaping the development direction.

There’s clearly an assumption within some organisations that “having an API” (public or private) is enough, but just showing up is no longer a winning strategy. The way companies engage the developer community is a pure expression of branding through doing (show, don’t tell). If done in the right way it empowers others to realise your brand expression through their own art, copy and code. Which seems like something that is worth investing in.

In Evan Davis’ provocative documentary Mind The Gap, he argues that a key attribute that makes London such a successful city is the way that a huge mass of people with diverse talents are able to combine to produce ever more effective and powerful alliances. This effect, known as agglomeration, is a key reasons for the success of start-up communities such as silicon roundabout.

Digital agencies increasingly require the effects of agglomeration to innovate on behalf of clients. Brands are looking to ‘innovate to differentiate’, working with agency partners on ever more complex campaigns, co-creating connected products or pushing the web through responsive builds and smarter mobile development.

These kinds of briefs require an agency to line up diverse teams, with previously ‘non-standard’ skill sets. This isn’t just a production problem. The ‘mad men era’ copywriter+visual creative team isn’t an atomic unit in the world of prototyping, hardware hacking and auto-scaling cloud based solutions. Small project teams need to be comprised of specialists from a wide range of disciplines who quickly need to form productive teams. These teams need to live in the medium. Presenting ‘mobile first’ creative in a PSD is clear warning sign for agencies and clients.

So how do agencies find a way to crunch together multi-discipline teams at short notice. The 3 martini lunch era is a distant relic, and ever more efficient agency businesses are loath to run ‘a large bench’ of specialists. Conversely keeping control of freelance costs exerts financial pressure in the opposite direction. Staffing an effective and innovative team in 2014 is a challenge.

One strategy is to develop a t-shaped skills culture, where people continue to have a strong specialism (and craft) but also have a wide exposure to complementary skills. An agency of designers who code and hardware hacking project managers.

Agency frogger is seen as a threat to business continuity for agencies, but recruiting talent who have been exposed to a wider variety of projects and environments is a potential shortcut to a more diverse and flexible team. Encouraging staff to share, talk and present at events inside and outside of the industry is another way of exposing teams to external influences.

This isn’t an easy problem, but it is one that agencies need to solve to avoid producing out of date, commoditized work that is no longer effective. In many ways the type of skills required are the same, but the tools and landscape have changed. A digital agency that continues to show copy in Word and present ideas using PDFs is already suffering from having the wrong teams in place. The future is already here, it is just unevenly distributed.

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.