Badger Digest June 2015

by Alex Savin


Badger digest is back! Here you’ll find a sneak peak into the most discussed topics on Red Badger internal Slack channels for the past month.

Title image credit: Tiago Cabral



  • HTTP/2 Picks Up Steam – it is now enabled by default for all apps on iOS 9
  • The Code Climate Platform launch
  • How to write a Git commit message

When a commit merits a bit of explanation and context, you need to write a body

  • The Web is getting its byte code: WebAssembly. Also, an important tweet by Brendan Eich.
  • The most important part of your CSS – Dominik Piatek on sensitive subject of grids
  • Empire: A self-hosted PaaS built on Docker & Amazon ECS
  • Unit testing React components without a DOM
  • Update on our very own Arch framework


#Project management

  • Why is UK productivity lower than in many other countries? Podcast episode by BBC Radio 4.



  • That’s Real-Life Responsive Web Design: Meet The Brand New Smashing Book 5
  • Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
  • SurviveJS – Webpack and React. Go from zero to Webpack and React hero.

A tweet for thought

Current state of browser support for high quality image formats.


The most important part of your CSS

by Dominik Piatek


There is a bit of CSS that you will write or more likely use from a library that will influence your whole project. It is crucial and it’s quality and adequacy can make or break your productivity as you develop. That CSS is the famous (or infamous!) grid.

Laying out things on the web has always been a struggle. You only have to dive into HTML email to see how terrible it was because table layouts are still a thing there. As graphic design practices trickled through to the web and tables were starting to get filled with data instead of layouts, some people discovered that we could abstract some of that CSS into grid systems. And rightfully so – controlling width is one of the most used CSS properties. It was, all in all, a great success. Our grids maybe were not as advanced as in traditional graphic design, but they were a fantastic abstraction that saved us a lot of time.

Then came along responsive design. It demanded a lot more from our humble grid. But as older, buggy browsers were pushed out and using things like box-sizing, inline-block and negative margins became common (and reliable), the grid adapted.

It’s quite trivial to write a grid these days; but it’s not trivial to know when to use inline-block or floats. It’s not trivial to polyfill our good ‘ol grid with flexbox either. Twitter’s Bootstrap grid might not be ideal for your project; you’ll know it when you are going to have to change it all the time. The breaking point will come when you will not use the grid because you will be afraid of the side effects that can cause and you will make little, impromptu, error-prone grids on the spot.

All this should tell you one thing: the grid needs special attention from the developer, from the outset. You can see this by the emergence of tools like Gridset and efforts on bringing the cassowary constraint solver to the web. On most projects, laying out is a massive part of writing HTML & CSS. The better your tools and your understanding of them, the smaller your headaches later.

So what should you do when assessing a grid? Some key points should be:
– how can you safely extend the grid? (ie. what do you do if you need different gutters somewhere down the line?)
– what are the limitations of the grid (ie. how many columns can we have? Can the grid be used in any container? Is there some patterns that should be avoided)
– does it use floats, inline-block (do we need to care about extra white space), flexbox, something else?
– how is responsiveness handled? how can it be extended?
– will it work with other frameworks that we are using?
– how does it fit into the naming scheme used for our CSS?
– what browsers does it support?

If you create your own, setup a test page and run it through Browserstack or similar. Make sure your new rad idea works across the browsers you want consistently. The big benefit of doing this is that you don’t have to settle for the general case of the grid, you can make allowances that your project requires.

Realising the above, I’ve created a library that lets you create grids on demand called Taco Grids. Currently written for the Stylus CSS preprocessor, it’s an experiment in using a flexible tool for creating easily extensible grids. You can read a bit more about Taco in my previous blog post or jump to it’s home page to look at the docs and example usage.


Arch framework – update

by Alex Savin


Arch framework official logo by Sari Griffiths, Clementine Brown and Blanca Tortajada

Arch is an isomorphic single page app framework built on top of React and Immutable.js. It was announced and open sourced at the  React London meetup in April by Viktor and Tiago. Many of us at Red Badger are really excited about Arch, its performance, flexibility and openness. Last week we had a first of its kind Arch hackathon at the HQ, and here are a few updates we’d like to share with you.

Official Twitter handle is reserved – it’s ArchFW. Follow it to get quick updates on development and future events (especially if you’re in London!). It is also one of the quick ways to contact team, ask questions and get feedback.

New dedicated organisation is now available on Github – Arch-js. It contains all Arch -related repositories, including Core of the framework, command line client and example apps from the original announcement talk.

We invite you to join the discussion under the core repository. Post issues you encounter, or comment ongoing topics. If you have an idea on missing example app that would enable you to try the framework, feel free to add it here.

Crash course into Arch and functional web programming is now fixed and available for brave new users. You’ll find even more chapters on Arch internals, concept of immutables, cursors and isomorphism in the docs folder. We also have reserved domain archjs.org for the upcoming webpages.

And don’t forget the talk from London React meetup by Viktor and Tiago with introduction to Arch and apps with centralised state.

What’s next? Few things:

  • More sample apps, in ES6 and Livescript
  • Designing more powerful routing DSL
  • Default support for unit tests
  • Improving command line client

Arch is now properly open sourced with BSD 3 license. We hope you’ll like it.


Smooth Sailing- Designing businesses to deliver value

by Sinem Erdemli

“Improving experience starts with every customer interaction. Your customers see you as a one entity.” -Jiri Brezovsky

This is a quote from his post Stop wasting money on a “beautiful” interface it’s about the importance of improving the overall experience, rather than creating beautiful UI. It’s a brilliant and valid point, one which we at Red Badger think about a lot.

Even though a beautiful design, a high quality piece of software or sky-high conversion rates may seem like the ultimate goal of running a business, especially on a day to day basis, there is one crucial bit that shouldn’t be overlooked. That is to deliver value. 

I just want you to get the job done

As a customer, I don’t care about how well your metrics are doing, whether or not you’ve met your sales goals or when the next software update is due. 

I only care if I can get what I want from you or not. How much do I need to give [time, money, effort] vs. how much I get out of it. 

In the end, if I want to get my hands on a new computer I want to decide which one is for me, where and how to buy it, and how to set it up and who to get in touch when something goes wrong. All of that should be easy peasy, but is rarely so. 

The times they are a-changin’

Businesses have complex structures, they exist on multiple channels, partner with numerous 3rd parties and carry ways of working from the day they were established. 

A business runs with the help of multiple ‘departments’ ranging from marketing, sales, merchandising, customer services, online, suppliers, logistics. There’s also a big board of stakeholders to please with the outcomes.

“The problem [with designing in silos] is that customers don’t just care about individual touchpoints. They experience services in totality and base their judgement on how well everything works together to provide them with value” -Andy Polaine et al.

Each and every department has different targets and end-goals. They are usually focused on just one channel or a single touchpoint of the customers overall experience of a customer. The problem arises when the links between these individual touchpoints are left unattended, when they don’t appear on the targets because they are not tangible enough to make it to the boardroom. As a consequence, your customer’s experience with your business ends up being nothing but a broken, inconsistent and painful journey. 

When you think about it there is only one simple relationship to focus on, whether you’re in the boardroom, at the shop floor or in the office developing the website; and that is the one between you and your customers. 

 Love thy customer

value transaction

When it comes to deciding whether or not to come back, or to ‘recommend the service to their friends’ customers will not think about one interaction in isolation. They will think about how easy it was to use the website, how the staff treated them on the shop floor, they will consider the call they received by customer service team when their package was late all together. Overall their decision will depend on how easy it was to reach their end goal, the whole reason why they chose to get in touch with your business in the first place. 

Keeping the bigger picture in mind at all times will allow you to have meaningful conversations when you’re collecting requirements. It also will give you a reason to talk to each other, regardless of your position in the business. 

Stop and ask why how who

Before you get in your productive autopilot mode, stop and have a think about what the greater goal is.
are you doing what you’re doing?
-How might you make it better for the person at the other end?
-Who else might have an effect of the delightful experience you’re trying to create? 

Go speak to your colleagues, your stakeholders, customers. Involve as many parties as you can. Make sure you, as a business, are giving the same message, have the same tone and same level of delightfulness for your customers throughout their journey with you. 

Then and only then will your efforts count for something. Don’t forget, your profit, sales, conversion rates can only improve if you love your customer, try to make their journey with you as happy and valuable as possible because your customer will love you back. (and will most likely recommend you to a friend, if that’s what you’re after)

further reading

servicedesigntools.org has plenty of methods you can use to think about your business offer as a whole. I would recommend checking them out. Or have a read through Andy Polaine’s book Service Design, it is delightful and one of the best you can find around. 

let’s spread the love together

If you crave consistency in experiences and want to help businesses create value with beautifully designed high quality software get in touch. It doesn’t matter where you’re coming from, as long as your intentions are well:) 


Yosemite by Cocoaconf: Zen and the Art of Tech Conferences

by Robbie McCorkell

Half Dome peak

It’s 4am and the jet lag has woken me up far earlier than I would have wanted. I open the curtains and am greeted with pitch blackness so I pick up my phone and check on the twitterverse with whatever limited phone signal Yosemite has to offer. By 6am the light is beginning to creep over the High Sierras and I’m itching to get outside, so I throw on my running gear and escape. The air is saturated with the sweet smell of pine but it’s too cold to stop and admire, so I start running in any direction.

After a few minutes I notice the lack of noise around me. There is nobody around for as far as I can see or tell, and I seemingly have the entire national park to myself. The only noise penetrating the forest is the sound of early birdsong and the rushing of a waterfall, so I follow the latter.

When I arrive at the base of Yosemite falls the place is deserted. It would be only later the same day that I discover this area is usually packed with tourists taking photographs and admiring the view. But for now it’s just me and the tallest waterfall in North America. I stay at the falls for a while, it’s difficult to leave, but as the morning mist begins to fade I make my way on and start running in the direction of Half Dome peak with an extra spring in my step.

But why was I here? This wasn’t in fact some idyllic spring holiday I had taken, but an Apple conference. They called it ‘Yosemite by Cocoaconf’.

Yosemite Falls

CocoaConf is a touring training conference for Apple developers based in the US, and has been going on since 2011. Since Apple started naming its operating sytem OSX after Californian locations it seemed obvious that somebody at some time would organise a pilgrimage to one of these, but to my knowledge nobody had. CocoaConf just happened to be the only conference ambitious enough to attempt this with OSX Yosemite. Who knows whether this will become a theme for the next versions of OSX, but we all hope they pick somewhere nice. On two separate occasions during the conference I heard someone say “Thank god they didn’t name it OSX Oakland”.

The theme of this conference was unlike any I had been to. Sometimes feeling more like a spiritual getaway than a tech conference, the talks at Cocoaconf Yosemite were more focused around self improvement for you and your company. Talks ranged from tips on managing your team and projects to learning how to avoid burnout, to the history of the Gregorian calendar; all of course within the context of Apple and its products. 

There were also some more technically focused talks in the mix including Christa Mrgan’s excellent walk through designing interesting looking apps for iOS8, Andy Ihnatko on the history of wearable devices and expectations for the Apple Watch, and Andrew Stone’s wacky talk on the lifestyle of working for Steve Jobs at NeXT in the 80’s.

Mountains and sky

However, the focus of this event was not to learn or discover new technical skills. This conference was more focused on bringing together a set of likeminded people to discuss the platform they love to build upon, trade war stories from their careers, and share ideas. Whilst sharing ideas with people of different backgrounds can lead to new and interesting revelations, I came to realise that sharing ideas and philosophies with likeminded people can often strengthen and expand those you already have.

Every person I met seemed to be at the top of their field, working for large companies and startups alike, all with their own perspective on building apps for the Mac and iPhone. And whilst meeting people in the industry was great for professional networking, I was also very pleased to meet some familiar voices in the world of podcasting including Guy English, Serenity Caldwell and Jason Snell.

In addition to the location and talks at Yosemite, the third main attraction was the attendees themselves. The conference had a very small audience of approximately 80 people, and every one that I met had fascinating backgrounds and views. Networking of this kind was made even easier by the included daytime activities that had been organised to help attendees explore Yosemite valley. For example, a guided photography walk around Yosemite falls with TED conference photographer Duncan Davidson allowed me improve my photopraphy skills and trade shots with fellow attendees and speakers alike. Unlike most conferences, networking was never the primary goal but instead happened entirely by accident through a mutual enjoyment of the location we found ourselves in.

Footbridge in the woods

I would usually look for a more technically focused conference so I approached this one with an air of skepticism. But I found all of the talks to be fun, interesting and dare I say it, inspirational. I would almost go as far to say that in comparison to a traditional conference where there is no guarantee that I might come home learning anything new, I gained more value coming home from a conference that made me see the work a do a little differently and with a boosted enthusiasm. And what better place to feel inspired than one of the most beautiful national parks in the world. A wonderful experience for someone in any industry.

Needless to say, I came home from my time at Yosemite hungry for more. One day I’ll go back and explore all the High Sierras have to offer in full. But for now I encourage anyone to consider attending a conference not quite as focused on a particular language or technology, but on your profession as a whole. You might find it will help you to see your work differently for months or years to come. And who knows, you might just have fun in the process. 

View looking back at Yosemite

Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.

Nerdy Babelfish – The Importance of Communication in Tech

by Roisi Proven


Here on the Red Badger blog, we certainly don’t pull any punches where technical discussion is concerned. In a lot of posts, we assume a high level of knowledge when it comes to our readers, and avoid going overboard with explanation in order to get to the core of our discussion without being boring.

I for one think that this is a great thing. We want to attract the most intelligent, highly skilled people to interact with us, and we can’t do that if we over-simplify things. I feel hugely proud to be a part of a company that has the courage to push forward with new tech, no matter how complex it may seem at first glance.

However, for the less technical people in the team (I include myself in that) it can present a bit of a dilemma. For testers and project managers especially, who bridge the gap between technical and operational, knowing how to explain things is crucial. When you work with a team of such highly skilled developers, you have to be able to not only keep up with them, but make a very complicated thing highly digestible from a business perspective. 

From Code to Conversation

To me, good communication skills are vital if you want to work in tech of any kind. Just because one person understands everything there is to know about a system, doesn’t mean the person fixing the bug you write does. Similarly, your client will likely have a very different, non-technical focus to the project. As a result, you need to be able to distill a sometimes mind-bogglingly complicated technical problem into a form that even the least technical Product Owner can understand.

Let’s take something that, for anyone in web development, will be very familiar. Deploying code from a local environment into a live environment. This will obviously vary depending on how your business functions, but the core steps are the same. You write your code, spinning up a local environment to check your work. You write some automated tests to cover your work, and then submit a Pull Request on your repository for review by another coder. This code will then be tested further and deployed on to your live environment, usually running the tests through a Continuous Integration tool such as Circle or Travis. Simple right?

Or maybe not. Here is a top level breakdown of concepts and terms in the paragraph above that may leave non-technical people scratching their heads:

  • Deployment

  • Local environment

  • Automated tests

  • Pull request

  • Repository

  • Continuous Integration tool

That list is just the tip of the iceberg, as I’m sure if we were to go into more detail about the the build process we would lose people even further. So when I’m explaining how long a build will take to a customer, there is absolutely no point in me explaining it like this. 

From Conversation to Code

This process can most definitely work the other way around as well. If a client adds a bug of their own to the database, or requests a new feature, it can be easy to dismiss it because it seems frivolous or insignificant. This is because, as technical people, our priorities are different. We want to have something that runs smoothly and looks beautiful, and woe betide anyone who asks for something that we feel may compromise that.

A notable example of this for me, is some of the tracking and 3rd parties that I’ve seen requested for integration into various projects. If you look at them in a purely technical way, they are by and large quite undesirable. They may risk slowing down your site, or perhaps cause conflicts with already implemented features that will take more work to fix.

This won’t matter to your client. What matters, invariably, is the continuing success of the business. If the implementation of a 3rd party could hugely improves customer engagement on their site, arguing with them about milliseconds is unproductive and may become needlessly combative.

So What Can You Do?

On both sides, the point at which communication breaks down is the point at which people stop asking “Why?” From the tech side, why am I making this change? Why is doing it this way better than doing it in a way that may seem faster? There’s no need to get technical with those answers.

Going the other way, we should be asking why we are implementing, while still staying empathetic to the overall needs of the client. Yes, to a developer certain 3rd party integrations may seem painful, but if they have sat down prior to starting the work and learned a bit more about the situation surrounding the task, the work will feel more meaningful, and you may even be able to suggest a better alternative.

Through all of this, you should always try to put yourself in the other person’s shoes. I will never sit down and have a conversation with someone without first spending some time thinking about how they might take the news I’m going to give. Often it’s not about the words you say, it’s about the delivery. So I can boil a build deployment right down to “the feature you want will take us 3 hours to take through our internal process” and as long as I’m delivering that with meaningful information such as timescales, the complicated stuff isn’t going to feel so important.

Once you put tech jargon or business jargon aside, it really is just two people having a conversation about something that they both really care about. As long as you remember that the person sitting across the table from you wants the same thing, the rest is easy.


Want to work somewhere where you don’t need to be afraid to stand up and give your opinion? We’re hiring! Join Us


Red Badger is 5!!!

by Cain Ullah

Time goes so quickly when you are having fun. It seems like yesterday that Stu, Dave and I put £10K each of our personal savings into Red Badger and started working from our bedrooms. That was on 24th May 2010, 5 years ago, and Red Badger has come a long way since then.

In the last two years, Red Badger have been growing more than 100% year on year in terms of revenue, profit and employees. We have some great current clients in Sky, Tesco, Fortnum & Mason, Lloyds Commercial Bank and Financial Times and are doing some really interesting, cutting edge work.

Sometimes you get so busy in the now that you forget to look back at where you have come from and what you have achieved and I have to say that I am immensely proud of where Red Badger are at today. It has been an interesting journey with plenty of mistakes but we have learnt and adapted as we have grown and have achieved good success to date.

Two big reasons for Red Badger’s success are the amazing team and culture that we have built up and the fact that nearly 50 employees and 5 years later, Red Badger is still built on the same core values as it was on day one.

First I want to discuss our core principles and then we will get to our employees and culture.

Core principles

When Stu, Dave and I started Red Badger, we were not seasoned entrepreneurs. This was our first crack at running a proper business. However, we were seasoned consultants and were battle hardened enough to know what we didn’t like about how other businesses were run and how we thought we could do it better.

To illustrate to some of our more recent employees that they were living and breathing a vision from 5 years ago, I recently pointed out this blog post that I wrote just 1 month into Red Badger’s existence, based on a term I coined ethical consulting. It was an incredibly simple blog based on one idea – we didn’t ever want to have an incentivised sales team because of the problems we felt it caused when it came to delivery. We wanted to do sales differently to the traditional way in which other companies operated. Our sales process would follow some guiding principles upon which we wanted to base the rest of the company: Quality, Value, Transparency, Honesty, Collaboration. When this blog was released, it was met by some with disdain and dismissed as being naive but still to this day, we do not have an incentivised sales team and have done perfectly well without one.

Strong opinions weakly held

A favourite mantra of Stu’s and one that ripples through Red Badger is “strong opinions weakly held”. We believed strongly in our core principles but were willing to listen and adapt if someone showed us a better way. If having no incentivised sales team hadn’t worked, we would have admitted it didn’t work and changed it. However, all three founders had a vision for how Red Badger should be run and to date it has worked and we have a great company built upon a strong foundation. A key learning is to never be afraid of trying something different if you believe in it. If it doesn’t work, or someone shows you a better way then try something else.

Doing the right thing

5 years on, our core values remain the same. We want to do the right thing. We want to provide quality and we want to provide value to our clients. If doing the right thing is at your core, increased revenue becomes a consequence.

At our last company day in the Summer of 2014, Dave our COO presented the following slide to all of our staff re-iterating that doing the right thing is paramount and the rest follows.

Screen Shot 2015-05-25 at 14.31.05.png

Doing the right thing – Company Day presentation slide.

We hang our hat on quality and don’t take on new business unless we know we can deliver it to the best of our ability.  This has held us in good stead.

Looking at our current 5 concurrent clients, 2 are new but 3 we have been working with for over 12  months; Sky we have been working with since September 2013. All of these client engagements started with projects of no more than 4 months but through doing great work, the clients have continued to want to work with us for as long as is feasible.

We ask for no commitment. We just do great work by doing the right thing and as a result, end up winning lots of repeat business to supplement the new business efforts.

Core values are incredibly important but of equal importance is building a strong culture.


Of course, none of any of the successes over the last 5 years would be possible had it not been for our employees. We have built up an incredibly dynamic, talented team that are all simply a pleasure to work with. We put a hell of a lot of effort to create a great culture at Red Badger. We want Red Badger to be the best place that anyone could ever want to work at. A lofty goal but one we constantly strive for.


Great culture starts with recruitment. No-one gets to work at Red Badger unless we think that the existing team would love to work with them. This is a monumental effort. In the last month alone we have had 227 candidates pass the first screening stage and are currently hiring at a rate of approximately 4 per month. However, the effort is most definitely worth it in the long term. You don’t get it right 100% of the time but it is important to us to not hire the wrong person in haste because we are in a hurry to resource a new project. We’d prefer to turn the work down, be patient, hire the right people and focus on building a great culture.

Building a culture

Once you have the right people, a lot of work goes into maintaining culture and creating an environment which is great to work in. A lot of this is to do with trust. As a Director you have to let go and trust your employees to get on with it.

In Dan Pink’s “Drive”, a fantastic book about what motivates us, he talks about three key elements: Autonomy, Mastery and Purpose.

In a nutshell, these mean the following things:

  • Autonomy – the desire to direct our own lives

  • Mastery – the urge to get better and better at something that matters

  • Purpose – the yearning to do what we do in the service of something larger than ourselves

These three elements are really important in creating a great culture.


Red Badger trust our staff to do the right thing. We don’t micromanage them, we have flexible working hours, we trust them to run projects how they see fit and we even give them a £2K training budget per year to spend on what they like. The key thing is for them to be in control of the decisions that they make day-to-day. The more autonomy you provide your staff, the more productive and happy, they tend to be.


We also try to provide our employees with the best possible environment to collaborate and share knowledge. We explore various ways of doing this, including a monthly company meeting back at the office where everyone takes it in turn to present on key bits of knowledge, be it a demo of a client project or some thought leadership. We encourage them to innovate. We don’t take predetermined solutions to our clients but cater solutions specific to the requirements and if this means using technology that we haven’t before, that’s fine. Our staff are always driving the evolution of how Red Badger do things because they are passionate, smart people who love what they do and we don’t get in their way. To see a good example of this keep an eye on our tech page and see it evolve over time.


Every year we also have a company day during which, we get our employees to do a workshop on our vision and purpose. The outcome of the workshop is a whole bunch of post-its written by our employees on why Red Badger exist, how we realise the why and what the tangible outcomes are. We then use the outputs of the workshop to drive our value propositions and service offerings. By doing this, all of our staff feel part of a common purpose because they have been instrumental in building it.


Why?, How?, What?

Some favourite statements written by our employees from the workshop include:

  • Why – “To make the internet a better place” / “Fix the nonsense”

  • How – “Best people, best tools, best methods and processes and always innovative consultancy”

  • What – “The place you go to find great software and deliver value to clients”

We hired an island!!

More important than anything is that we have lots of fun. We do lots of social events inside and outside of work. Many of our employees would consider themselves best of friends. Part of our culture is to also share the success of Red Badger with our employees when we do well and being fair with how that is distributed. This summer to commemorate our 5th birthday and to thank all of our staff for their continued contribution, we have hired an island and will be taking them all away for a full weekend of relaxation, fun and plenty of drinking. A just reward for all of their efforts and something to be really excited about!

2-Manor_Beach__stay-with-us (1).jpg

The location of our 5th birthday party

The Badger Way

Core values, culture and great employees are key to the success of the business. By getting those things right it has allowed us to get incredibly efficient in delivering value to our clients. We have built up what we call the “Badger Way”. It is an ever evolving process through which we help big corporations to transform their business with a core focus on enterprise scale web applications. Our focus is on three key things:

  1. Help clients to focus their efforts on being customer driven

  2. Build a solution that delivers the best possible technology to meet the client’s requirements

  3. Help clients to be much leaner in their approach

You can read more about the “Badger Way” elsewhere on our website in existing and upcoming ideas and blog posts.

The Future

Who knows what the future will hold but our intention is to continue in the direction in which the last 5 years have gone.

Red Badger has always set out to work with large corporations for a number of reasons, but most importantly, they have the most complex problems to solve where our ways of working can provide the most value. We thrive on complicated and we want to help large corporations feel like startups, implementing lean ways of working, cutting edge tech and delivering great customer experience to their customers.

We will look to continue to grow sustainably. As Red Badger has grown there has naturally been some growing pains. The key is not to ignore them and to make sure you are always listening to your employees.  We are putting all of the right things in place to fix them.

The three founders, Stu, Dave and I are committed to our core values. We are determined to continue to hire amazing people, maintain a great culture and we want to continue to do the right thing.

Scaling excellence will not be easy but I think that Red Badger can continue to do things a little bit differently and in growth, succeed where others have failed by providing the best quality and value to our clients and have fun in doing it.

An infographic showing some of the highlights of Red Badger’s history to date.


Red Badger offers an annual £2,000 training budget. Sound good? Then come join us.


The term “Agency” is overused

by Cain Ullah

What is an Agency?

-noun, plural a.gen.cies – an organization, company, or bureau that provides some service for another.

 ”Agency”, is a pretty broad term. If I say I own an “agency”, in the literal sense, I could be in recruitment, window cleaning a taxi driver or a million other occupations. Red Badger are in digital. We build enterprise scale web applications for the likes of Tesco, Sky, Lloyds and Fortnum & Mason. In my industry, most would classify Red Badger as an “agency”. We are a member company of the Society of Digital Agencies (SoDA) after all. But “agency” in my mind is an outdated term and is used to describe too many things.

When most of my peers, colleagues or competitors are talking about “agency”, we are specifically talking about professional services companies that are in marketing/advertising and/or the digital space. Have a look at this list of companies in the Econsultancy Top 100 Digital Agencies (Formerly NMA Top 100) to get an idea of what the industry would define an “agency” these days. There are a number of categories in this list, Full Service/Marketing, Design & Build, Technology, Creative and Media. The categorisation of companies in this list seem dubious at best and service offerings of many of them are very different, despite being placed in the same categorisation. The lines between marketing, advertising, brand, web, agency, consultancy, software house and product startup seem to have become far too blurred, all of which have been thrown into the “agency” bucket.



The term “agency” for me has it’s origins in marketing/advertising like AKQA of old, but as we have moved into the digital age, companies like AKQA have had to adapt their service offerings, adding in a strong technical capability to their armoury. AKQA were once an advertising “agency”; they now call themselves an “ideas and innovation company”. AKQA still have an “agency” arm to them as they still do a lot of brand / campaign work associated to a typical advertising “agency”. Digital or not, a campaign is not built to last. However, they now also do full service delivery of longer lasting strategic applications that have a long lasting effect on their clients’ business operations; look at AudiUSA.com. I would argue that this type of work is not that of an “agency”.

With the transition of some traditional marketing/advertising agencies to digital agency, technical companies such as Red Badger have been thrown into the “agency” bucket.

This has been something Red Badger has struggled with. We don’t see ourselves as an “agency”. As I said previously, for us, the term “agency” has its origins in the marketing space, with work largely focussed on campaigns or brand, be it digital or not. We also don’t see ourselves as “consultancy” because the connotations of that are associated to big cumbersome Tier 1 Management Consultancies such as Accenture and McKinsey.

What’s the alternative?

Red Badger deliver enterprise scale web applications for large corporations. They are highly complex, technically advanced solutions that can take upwards of 12 months to build. However, we also take User Centred Design as seriously as we do the Tech. Everything we build is user driven, beautifully designed and simple to use and we have an expert team of creatives to ensure this is the case. Finally, we wrap both the tech and creative teams into incredibly efficient Lean processes, running multi-disciplined, cross-functional teams, shipping into live multiple times a day. This is not the work of “Agency”.  So for now, as a slogan to describe Red Badger, we have settled on “Experience Led Software Development Studio”.

Why does it even matter?

The overuse of the term ”Agency” can cause issues. With the ambiguity of what a modern “agency” is, comes hand-in-hand confusion of what different “agencies” do. For big corporations, the sourcing strategy for a supplier has become equally confusing because they don’t know what they are buying.

When does an “agency” become a consultancy? Or are they the same thing? How do you differentiate from a digital advertising “agency” and a software house that builds digital products? I’ll leave you to ponder on that yourselves.

Some examples of companies that might be in the “Agency” bucket but have started to move away from describing themselves as such include some of the following:

  • Red Badger – “Experience Led Software Development Studio”

  • AKQA – “Ideas and Innovation Company”

  • UsTwo – “Global digital product studio”

  • Adaptive Lab – “We’re a digital innovation company”

Companies are starting to cotton on to the fact that the term “Agency” is confusing and those that provide full service application development are starting to distance themselves from the term and the brand/marketing/advertising stigma attached to it. Surprisingly, companies such as SapientNitro and LBI still describe themselves as an “agency”.

So the question I suppose, is do you class your company as an “agency” or is it altogether something else? I think it might be time for a new term that is not “Agency” or “Consultancy” that is more interesting than “Company”. Suggestions on a stamped addressed envelope to Red Badger please!!


What I Learned about the Future of Internet From Fluent Conference

by Alex Savin


By the year 2015 I imagined the internet to be something close to how it was envisioned in Gabriele Salvatores’ Nirvana cyberpunk film. You’d plug yourself into cerebral cortex, put VR goggles on and off you would go flying into the cyberspace.

Funnily enough, there was a glimpse of that during the recent O’Reilly Fluent conference in San Francisco. But all things in order.

Fluent isn’t a conference to attend if you want to get deep knowledge on a certain subject. 30 min long sessions are great to get a drive through the topic, to give you understanding on what it is. What Fluent is perfect at is to give you broad overview on stuff you had no idea about. 5 simultaneous tracks of talks, one extra track of meetups, one more for workshops and as a bonus there is ongoing exhibition hall with companies and live demos of hardware and software.

There is optional extra day for just workshops – which actually was good for getting deep into a subject. We went full contact with ES6/7 new features, intricate details on type coercion in Javascript, and did a good session on mobile web performance with Max Firt.

O’Reilly also brought some heavy weight keynote speakers. Paul Irish (creator of HTML5 boilerplate and Chrome web tools dev), Brendan Eich (creator of Javascript), Eric Meyer (author of pretty much every book on CSS), Andreas Gal (CTO at Mozilla) among others delivered a comprehensive overview on where we’re now and what to expect in a next few years. I’m going to cover a few interesting trends spotted during the conference.

Rise of the transpilers

This was mentioned directly and indirectly during many talks, including creator of JavaScript himself. Future of Javascript is not meant for humans, but instead a something you’re compiling into. Many new features in ES6 and 7 should make this easier for compilers. If you had any doubts so far on things like LiveScript, ClojureScript or even Babel, it’s time to stop worrying and start implementing transpilation into your build pipeline. Especially since Babel might as well become a language on its own.

React is hot

In all the honesty I missed all React related talks during the conference, of which there were quite a few. Later catching up with other attendees I got my confirmation that all of the talks were indeed mostly of introduction into React, Flux and ways of injecting React into your app. What was interesting is that each time I’d mention React and Red Badger working with React for the past year and a half, I’d become centre of attention, with people asking questions on how we do things. After describing our (now pretty much standard) setup with apps being isomorphic, hot components reload in place, immutables for state handling and ability to deliver app to no-JS clients, people would often say that Red Badger lives on a cutting edge. I couldn’t agree more.

Many people would also ask – how come it’s year and a half already – isn’t React just being released? The important part here is that lots of people are hearing about React now for the first time, and are really excited.


Eric Meyer made a great point during his keynote dropping a (deliberately) controversial slide that Web is not a platform. Right now lots of web developers assume JavaScript support as a given on any client. This is something Eric tried to address. Web is not a platform, there are and will be lots of clients with support (or lack of) for any sort of tech stack. When you take CSS off the webpage, it suppose to stay functional and content should still be human readable. Same goes for JavaScript, and any other tech we might introduce in the future. Assuming that you are targeting a broad audience, it’s always a great idea to implement your app isomorphically, with gradual degradation of user experience, in case client doesn’t support some of the tech we’re relying upon.

Be conservative in what you send, be liberal in what you accept.

All of this goes very well with the React and what we’re currently doing with it. If you have modern device, browser and JavaScript support, you’ll get single page app experience, with blackjack ajax, client side routing and visual effects. If not, we’ll gracefully degrade to the server side rendering – which will actually improve performance on older mobile browsers instead of forcing JavaScript on them.

Importance of the progressive enhancement was echoed by @obiwankimberly during her talk on second World Wide Web browser and CERN’s efforts to revive it. Line Mode Browser was the first browser ported to all operating systems, and was used by many people around the world. Most of us might not consume web in text only mode anymore, but the idea of progressive enhancement goes all the way to accessibility, screen readers, and those people who rely on text-only representation of the Web.

HTTP/2 is here

Or simply H/2. Not only the spec is finished, H/2 (in its SPDY incarnation) is supported in 80% of all modern browsers.

For the transition period you can setup your web server to fallback to HTTP/1 in case client is not ready for new hotness. IIS doesn’t support H/2 at all, but there’s nothing stopping you from getting Nginx proxy in front of it with full support for H/2.

Why H/2 is important? Few things:

  • Multiplexing. Each HTTP request requires quite a bit of time to initialise, thanks to something called “TCP three way handshake”. Even with fibre connection this consumes precious time and patience of the user. In addition to that, HTTP’s known bottleneck is slow requests that block all other requests. With H/2 you can retrieve multiple resources during a single connection, practically streaming data from the server. No more need for concatenation of CSS / JS files, image sprites, inlining CSS / JS. Even domain sharding is obsolete now.
  • Security is not optional. It is not part of the official spec, but Firefox and Chrome require you to encrypt all communication when using H/2. Which means, you have to use HTTPS. This has one interesting consequence – if one of the web proxies on the way of our request doesn’t support H/2, such request will still get through, since it is just a stream of encrypted data.
  • HTTP headers compression. All headers are now nicely packed together using something called HPACK encoding.


It seems that people at Mozilla are sharing my passion to see Internet with users immersed into it. If you have Oculus Rift and latest Firefox nightly, you’re all set to check out something they call WebVR. Idea is simple – WebGL graphics rendered by the browser into your virtual reality goggles, as well as you being able to look around and interact with the experience.

To boldly go where no man has gone before.

On the second day of exhibition they enhanced the VR experience by sticking LeapMotion sensor with tape on the front of Oculus, which allowed people to see their hands and fingers inside the simulation. That’s something that makes experience truly immersive – we like to move our hands around and seeing them interacting with stuff.

Another possible use for such technology is spherical panorama viewing, be it still picture or video. YouTube already supports such experiments, and one can only imagine this expanding in the future. I believe Mozilla VR department is spot-on about VR experiences delivered with the browser. There are still lots of questions, most of VR territory is completely unknown (UX in WebVR, anyone?), but it feels truly exciting to live during times when such things are coming to life.

Internet of Things

This whole IoT concept was pretty abstract to me, until IBM did a live on-stage demo of a cloud based AI overlord, speaking in a nice voice and doing neat tricks.

I can monitor and command your devices. Typically I monitor vehicle fleets, cool things like power boats, medical devices, and perform real time analytics on information as well as historical data storage and visualisation. I can see you’re wearing heart monitor today. – Sarah, the AI overlord.

During a very short keynote by Stewart Nickolas he let Bluemix cloud based app to scan the room for controllable devices and sensors, and then asked Sarah the App to take control over one of the robotic spheres on stage that she discovered. Interesting part starts where you can imagine Sarah taking over fleets of vehicles, smart sensors and making decisions for us, humans. IBM is building a platform to unleash apps out of cloud into the real world.

On conference

Fluent was by far the biggest and extremely well organised conference I ever attended. Here are a few observation on how they did things.

  • Wifi. As usual on internet conferences with 1k+ attendees, it’s hard to provide reliable wifi signal in a single room. Biggest problem was keynotes, since everybody would be in the same place, actively posting things. In addition to bringing more routers into the room, they also quickly realised to ask audience to pause Dropbox syncing and whatever other cloud backup apps you might have on laptop. That actually helped a lot.
  • Speed networking sessions in the mornings were actually more fun than expected. Not only you get to meet bunch of mostly interesting people, it also puts you into the right mood of the conference and makes you a bit less introvert.
  • Game of code. During first two days you could do your part in collecting stickers by performing various quests and attending events. Each sticker contained few lines of JavaScript code. Once you’ve collected all 12 stickers, you’re suppose to figure out the order of those lines, enter them into browser console of the Fluent Conference website, and, if successful, get a confirmation ID for a prize.
  • Info board. In the main hallway they placed a huge paper board where anyone could leave messages, post job ads or distribute stickers. Often people would pin business cards next to the job ads.
  • After lunch desert location was used to great effect to direct flocks of attendees. In a last two days it was moved to the exhibition hall, so you could munch on a desert while checking out Mozilla VR experience.


All keynote videos are now available on O’Reilly YouTube channel. Few of my personal favourites would be:

I also compiled a video for the whole San Francisco trip – was my first time in California after all.

Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.


Join me as a new voice in the tech community

by Winna Bridgewater


A glimpse at the weekend workshop I led. Photo by Alessia D’Urso, Girls In Tech UK Board Member.

London has a staggering number of events for coders. It’s awesome.

The only thing is, I’ve gone to a lot of events, and I can count on one hand the number of times a technical discussion—about a tool, an industry standard, or the craft of code—was led by a female. For the majority of the events I attend, I am one of only two or three females in attendance.

I decided that this year, if I want to see more women presenters, I need to step up. I need to talk at an event.

Getting Inspiration

As if the universe was listening, two events came up this spring that got me more excited and less nervous about going for it.

First, Ladies Who Code London ran a workshop on public speaking, and it was hosted here at Red Badger. Trisha Gee and Mazz Mosley were wonderful. Their message was simple: it gets easier each time you do it, and there are ways to work through nervousness. They also emphasized that the audience is rooting for you–everyone in the room wants to see you succeed. Pretty nice, right?

Then I had the chance to attend the Women Techmakers Summit, an evening celebrating International Women’s Day that was organized by Google Women Techmakers and Women Who Code London. There was a series of speakers and panelists, and every presenter had a powerful message. The speaker whose message stayed with me most was the keynote, Margaret Hollendoner

Margaret said she sometimes makes her career sound like it was all “right place at the right time” luck. But she told us it wasn’t that simple. Every opportunity was lucky in one sense, but the opportunity wouldn’t be there without her hard work. She also emphasized that deciding to say “yes”  required confidence and bravery.

Margaret’s presentation gave me another nudge: get past my fear and present at an event.

Saying Yes


Only two days after the Summit, I got an email from Lora Schellenberg about Spring Into Code, a weekend workshop on Web Development offered by
and Girls In Tech. Lora asked if I was available to teach–the original instructor had to back out, and they were looking for a replacement.

It sounded like my lucky chance, so I agreed.

Then I got all the details. I was going to be the only teacher for 12 hours of instruction over two days. I’d be teaching at Twitter headquarters to an audience of 100 people.

I felt pretty panicked, so I knew it was time to make some lists.

Why I should not do the workshop
  1. I’m not an expert in web development.
  2. I’ve only been doing this stuff professionally for a year and a half.
  3. I won’t be able to answer all their questions.
  4. 12 hours is a long time.
  5. 100 people is a lot of people.
Why I should do the workshop
  1. I’m not an expert in web development. I still spend most days learning new things. I know what it’s like to feel confused and lost. And I know how to recognize and celebrate small triumphs.
  2. I did set that personal goal.
  3. Those nice ladies did tell me the audience will root for me.
  4. That other nice lady did say you need to take advantage of luck that comes your way.
  5. If I’m going to teach 100 people for 12 hours, this is the ideal audience. Eager learners who, by choice, agree to a weekend in front of a computer taking in as much as possible.

I decided to go for it—butterflies, sweaty palms and all.

There are so many things I could focus on under the umbrella of Introduction to Web Development. I decided my main goals would be:

  • Make techy code stuff seem less scary.
  • Make people feel ok about asking questions.

Saturday morning arrived, and I had a rough start. I spent the first session working out how to use the mic and the two screens floating on either side of me. My notes weren’t loading like I hoped. The Internet was down. My demo wasn’t working even though it worked mere hours before. I was shaking.

After the first demo fell flat on its face, I knew I needed to stop. I took a few minutes to get everything running properly. I got water. I took some deep breaths. Those minutes felt like ages, but it was worth it. When I started up again, stuff finally started working.

The first day flew by. A few folks came by during breaks to say they were enjoying themselves. At the end of the day, lots of people came by to say thanks. Were my silly jokes working? Did my missteps when typing—forgetting a closing bracket, leaving off a semicolon, incorrectly specifying a source path—help people understand that breaking and fixing things is what this job is all about? During the second day, people from all over the room were asking questions. Tables were helping each other debug and understand what was going on. Breaks came and went with people staying at their seats to try things out. I couldn’t have hoped for more.


I have so many ideas about what I’d change if I could do it again. I missed some concepts. I glossed over others. But I did it, and I had an amazing time.

If you’re tempted to give a talk or run a workshop, please go for it. It’s scary but great, and you have a wonderful community rooting for you.

Red Badger is always looking for ways to connect to the tech community. Like that sound of that? Then come join us.