Posts Tagged ‘Red Badger’


Give it 5 days – Facebook Relay and GraphQL

by Albert Still

Relay schema screenshot

Me and Alex Savin have been rebuilding Red Badger’s blog with Relay and GraphQL. Relay is a front end Javascript framework that works with React to consume a backend GraphQL server. Relay deals with querying a GraphQL server and passing the data to your React components as props. And making mutations on the server while giving you optimistic update and error handling capabilities. But it will soon also be handing in-memory/client state and isomorphic universal app features. Then it will become a competitor with Flux, Redux and Red Badgers Arch. Furthermore a React / React Native / Relay / GraphQL set up could become all you need to deliver the ultimate single page web, iOS and Android app.

A blog by Basecamp co-founder Jason Fried called “Give it 5 minutes” was referenced in the React docs when it came out because React challenges conventional wisdom such as having HTML in your JS. Unfortunely with GraphQL and Relay it’s more like give it 5 days. There is a lot to learn and some of the example code is long in comparison to the short neat examples we saw with React. But power through and you will see the light of Relay and GraphQL. However do bare in mind the libraries are young and there will be some time consuming and confusing error messages along the way.

The libraries

Before Relay came out we only had one library to play with which was graphql/graphql-js. I wrote a blog on this library where I made a GraphQL sever for querying data on any movie in The Open Movie Database. Now since Relay came out on August the 11th we have 3 more libraries to play with!

  1. graphql/graphql-relay-js – A small library to help us construct a graphql-js schema supporting Relay. There are 3 core assumptions Relay make about your GraphQL schema. You can think of these as additional specs to the pure GraphQL specification.
  2. graphql/express-graphql – Express middleware that makes it easier to create an endpoint that will receive a GraphQL queries. It accepts queries via a HTTP POST or GET and returns a JSON response.
  3. facebook/relay – the Relay library itself which runs in the clients browser with React

And fortunately relayjs/relay-starter-kit which ties React and all four of the above libraries together to help us get going quickly. Also if you want to play with example Relay apps check out the 3 official Facebook ones in the example folder in the Relay repo. And the very recently released utility library graphql/graphiql is absolutely sick, it’s a React component that lets us render an in-browser GraphQL IDE to test out our GraphQL server.

The magic

Native app speeds with caching – no need to refetch the same node attributes again over the network!

When you visit our /blog index page our SPA application using Relay & React Router (great blog post about doing this here), Relay makes a GraphQL network request asking for 15 posts and a small subset of the post fields(aka attributes) we need to render the multiple PostPreview components. These fields are specified in the PostPreview’s Relay container. For example it asks for the title and the published at date but not the posts body. Now what’s cool is when you click on the post and view the actual post page, Relay makes another request this time asking for more Post attributes such as the body. But this time it does not ask for the attributes Relay already has in it’s store, even though the Post Relay container specifies them. This is because a Post in our GraphQL schema implements the node interface and has a globally unique id which Relay asks for and uses as a key in it’s cache. Overall this is nice feature we get for free that makes our app more performant and gives us native navigation speeds! 

Continuous scrolling made easy

One of Relays features is it declarative like React. Watch here how I declare the post’s index page displays 15 posts initially, then fetch 5 more when the user gets to the bottom of the page. Furthermore I use React’s setState(function|object nextState[, function callback]) and Relay’s setVariables([partialVariables: Object, [onReadyStateChange: Function]]) callbacks to display a loading message to the user! Very easy to do!

It lets your front end developers move faster

A GraphQL/Relay set up separates your back and front end team and allows your front end developers to move fast and provide awesome UX. When a view needs an extra attribute you simply add it to your components fragment and your done. No need to make changes to traditional ad-hoc backend server endpoints.  

We are hope to open source our Relay blog soon so people can reuse it! Cheers.


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


Staggeringly Smooth – the Fortnum & Mason E-com Release

by Roisi Proven


It would be difficult for me to overstate the importance of launching a brand new version of an international e-commerce website. This was no mere reskin, we have been rebuilding the Fortnum & Mason website from the ground up. We started with the decision to use Spree Commerce for the storefront, and have been continuing all the way through to building them a bespoke CMS using our very own Colonel.

Because the Fortnum brand values customers above all, they felt it was of the utmost importance that the customers help drive the direction of the site. As a result, we decided it was important not to rush a release. We have spoken already about our approach to deployment, allowing us to deliver rapidly and regularly, but in order to get to that stage, we needed to be confident that the core of what we were delivering was sound. 

The First Step

The first thing that we had to do before we could make a plan, was to figure out where our weaknesses were. If we knew the elements that were most likely to fail, we could work pre-emptively to fix these areas before going live to the world. What has always been apparent to us is that with so many 3rd parties to rely on, no amount of automated or manual testing was going to truly expose our pain points.

So, as soon as the site was fully transactional, we made the decision to do a highly controlled soft launch prior to Christmas peak. A selection of Fortnum’s trusted customers were contacted, and given a password to our still very much unfinished site. By communicating to these customers, and making them a part of our development, we hoped to not just get a more robust test of our site. We also aimed to gain feedback from these key users which would inform the ongoing development.

The Slow Burn

And so the feedback came. However, it came slowly. Too slowly for our liking. So, further down the line towards the middle of January, we had a meeting with the team over at Fortnum. We came up with a plan to run both the old site and the new site in parallel, directing traffic in ever-increasing quantities to our site. So was born.

The need to login to get access to the site was removed, and people started using our site. For the first time, we weren’t just inviting people to use the site, we were allowing them to get there on their own, initially via a marketing email, and later by directing a percentage of traffic from the old site to the new. In doing this, we were making sure that when the time came to release to 100% of the public we wouldn’t see the dip in sales and conversion that so often accompanies site re-launches.

Running two sites at the same time came with it’s own problems. There were moments when we wondered if we should have held off on introducing users to the new site, despite the fact that we knew releasing to customers early with the intention of learning from them was hugely important. However, how well it worked was undeniable. Major issues were uncovered, but instead of affecting hundreds of customers, it would affect one or two. If a couple of people encounter an issue, you can contact them personally and make sure they still feel of value. If hundreds, or even dozens of people are affected, it becomes a great deal harder. Also, if there were any issues that we needed more time to fix, it was very easy to direct all users back to the old site.

“Release” Day

The 17th of February rolled around. This was the day we had all been waiting for. For the previous fortnight, around 40% of Fortnum and Mason users were being directed to using the Qubit system to redirect them. We had encountered issues, some minor and some not so minor. We had managed to maintain our development momentum along with fixing these issues. Using Kanban, we had a clear view of work in progress and bugs that needed fixing urgently, all the while maintaining a focus on throughput – getting features shipped into live.

At 8am we made the call to change the DNS records. The old site drifted away, and became We pulled up our analytics and collectively held out breath.

It just worked.

A part of everyone was waiting for the other shoe to drop, for complaints to start flooding in or for orders to start failing. A bigger part of us knew that our gentle filter of customers over the previous weeks and months had prepared us well for this. Of course there were still small issues, a customer struggling to pay here, a missing product there, but overall there were no alarming issues.

Ongoing Positivity

The new Fortnum & Mason, complete with Feedback banner


As the website bedded in over the next couple of weeks, we continued to see minimal issues and an increasingly positive impact. We have already seen an overall growth of 89% year on year, with the conversion increase coming in at an impressive 20% up. We have also seen an 18% reduction in customer service calls, with a particular drop in calls related to issues with payment.

As we finish up our first couple of months being fully live, the mood across Red Badger, and across the business at Fortnum, has been hugely positive. We are immensely proud of what we have achieved, and we don’t feel that we could have had such a successful release if we hadn’t ramped up slowly in the way that we did.

We are looking for a great Agile Project Manager to join Red Badger- if we sound like the kind of place you’d like to work drop us an email – we’d love to hear from you!


Death by meeting (strippers need not apply)

by Harriet Adams

Over the years, I’ve worked with a number of FTSE 100 companies. To this day, I still have no idea how anyone gets anything done, considering most of their 9 – 5 is either in meetings, preparing for a meeting, or talking about the actions from those meetings in another meeting.



Utterly bewildered, I’d go along, often spending hours going over the same topics for the output to be:

  • We need another meeting to discuss further because we’ve run out of time
  • We can’t make a decision yet because [insert name] isn’t here
  • We don’t have enough information to make a decision

URGH. If there’s something that frustrates me it’s inefficiency. What’s the point of inviting all these people unless we reach a decision or a series of next steps? And why on earth am I here?!

It’s almost like the more people involved, the better and more important the meeting is perceived to be.


Funeral strippers

A couple of weeks ago, I read an article about the Chinese authorities clamping down on “funeral strippers“. Supposedly, the more mourners you have to your funeral, the more well-off your family appears. Therefore, in order to achieve higher levels of attendance and seem more wealthy, some families have resorted to hiring strippers to attract the crowds. 

On paper, it may seem a bit of a stretch as a comparison, but all too often we are big-headed and assume that what we need to discuss is particularly important. The entire team (and often innocent bystanders) are invited to pointless, boring discussions with no tangible output. Everyone joins, drawn in by the promise of something exciting, feels awkward throughout, and ultimately leaves feeling dead inside.


Upfront contracts

I learnt a technique on a training course a while ago about Upfront Contracts – something I try to enforce before every conversation and every meeting. A UFC should consist of the following.

  1. Purpose. What’s the point of the meeting / conversation?
  2. Agenda. What are we going to be talking about? Are we all in agreement that this is the right agenda?
  3. Timing. How much time do we have in total to reach a decision?
  4. Output. What do we all need out of the meeting, and at what point do we decide that it is over?

What this doesn’t consider, however, is the quality or number of people in attendance. This goes back to the Lean Start-up concept. Who are the influencers that will enable you to progress? What’s the minimum amount of input you need to reach a way forward?

This is a very important point, as inviting the wrong people may lead to the same problem, despite having a clear set of objectives.


Another one bites the dust

In fact, sometimes meetings aren’t necessary at all. Again, referring back to Lean Start-up, sometimes it’s necessary to pivot to be more efficient. A good example of this at Red Badger was during a recent project. Retrospective discussions were being held at 4.30pm every Tuesday afternoon but it became clear that the team were mature enough to raise issues in a reactive manner, and add them straight to the Kanban board.

By removing the meeting entirely and only running it when there were three items for discussion on the board, the team were able to be more productive but continue to make important changes to the process when it was necessary.


Making peace 

I’m not saying that ALL meetings are unnecessary. Quite the opposite.

But next time you have an important decision to make or need to arrange a meeting, think about the following.

  1. Is this meeting absolutely, definitely necessary?
  2. What is the purpose of the meeting and what do you need the end result to be?
  3. Who are the main influencers in reaching this point?
  4. What do we need to talk about to get to this result?

If you ask yourself these questions and make the answers clear to everyone who joins, you’ll make decisions faster and avoid disrupting the team.

In Layman’s terms, you’ll be slicker and quicker (with no stripper).


January London React Meetup

by Roisi Proven


January 21st saw the first React meetup of the year, and we packed as many people as we could squeeze in to the Red Badger office for another round of talks from teams around London who are using React within their organisations. This month we had Jof Arnold, VP of Product from, Gary Champers, a Software Engineer at Football Radar, and Christian Moller Takle from Billeto.

Jof Arnold – from Backbone to React

Jof has been a long term attendee of our React meetups, and we were excited to have him step forward and share his experiences with us.

After a painful experience with using purely Backbone, Jof and the team at discovered React. There were elements of backbone (isomorphism and Backbone models) that he and his team felt they needed to keep, so they worked to merge Backbone with React to get the best of both worlds. Although it’s not necessarily the “correct” way of using React, it is a way to use React with Backbone without rebuilding everything from scratch. 

Gary Chambers – Go Reactive Building UI with Rx and React

Gary came over from Football Radar to join our roster of external speakers for this month.

Football Radar have a very data heavy system, and publishing hundreds of events a second then trying to publish them all to the DOM didn’t work out. After investigating alternatives to their current solution, they too came across React, this time using it in conjunction with Rx. Rx is a library for async dataflow programming, or in other words, a methodology for “data first” thinking, which Football Radar needed. He then went on to discuss how you can translate Rx into Flux, to really get the most out of React.

Christian Moller Takle – Whirlwind Tour of Functional Reactive Programming Using Elm-lang as a Base

Last but not least we had another of our React meetup regulars. Christian built upon the other talks, and took the stand to give an engaging, and very technical, talk.

Elm is a functional programming language that is “not scary, just different.” Christian spoke about Elm language and put a functional programming spin on the core tenets of React. Using Elm, Christian showed how, as in React, you can improve your UI development by modelling your UI as data, and discussed the common concept of the virtual DOM.


Here at Red Badger, we love hearing about new ways of using React in conjunction with existing technologies, so this set of talks really gave us a lot of food for though. I think several of our developers are particularly interested in delving further into Elm.

As ever, this Meetup was massively popular, and our humble Red Badger office now fills to bursting point at every meetup. As a result, we have been speaking with Facebook, who have kindly agreed to let us use their offices near Euston for the next React meetup. So expect bigger, better things, and lots more beer and pizza!

Sad you missed it? You can watch the full meetup over on YouTube


Consumers in the driver seat

by Olga Loyev

Empty carI love math. So when it comes to analytics and stats, my brain smiles and my eyes spark, which is one of the things that attracted me to work at Red Badger. We are agile by nature and methodical in practice. We take analytical approach to problem solving and it is an integral part of the solutions we provide to our customers.

I’m a project manager for the Red Badger team at BSkyB where we recently delivered their new Help Site along with the supporting custom CMS to improve user’s ability to find the right content available and enhance their overall experience on the Sky Help site. As part of the the new solution we also added custom events tracking (things like clicks on links, buttons, page views, etc) that feed stats into New Relic Insights so we can closely monitor user behaviour to understand consumer’s requirements. The data we get back serves many purposes: from helping to prioritise work to highlighting outages to understanding customer demand and responding accordingly.

One example that stands out in my mind is what we saw recently on just another normal rainy day in London:

  • 80% of all unique visitors going to a specific article were clicking on “still need help” indicating they haven’t found the information they were looking for

  • 10% of all unique clicks on “still need help” across ALL articles were coming from that specific article. In comparison, the next article where most of “still need help” clicks were coming from accounted for only 5%

  • Daily top 10 most common search terms from the next action after clicking on “still need help” were referring to a specific issue the users were looking for help with

Notifying the stakeholders, we quickly found out that the information regarding the issue needed to be approved by the legal department before it could be published on the help site. Understandable, as it’s important to make sure product information is correct and consistent across different channels.

Fortunately, as soon as demand for this information spiked, we were able to immediately respond to the changing customer requirement and adopt the content to meet those. We shared the stats above with the legal department as soon as the spike occurred. The data highlighted the urgency of the request which was approved to be published within 15 minutes. The editors were then able to instantaneously publish the latest draft of the article which they already had prepared (thanks brand new CMS!) with the info customer was seeking. The published copy appeared on the live site 60 seconds after.

Within 12 hours, the percentage of all unique visitors to that article who still needed help after viewing the content dropped 50% from 80% to 40% with numbers levelling out to expected average by end of next day. Shazam! The power of numbers used for good!

Stats and analytics are powerful tools and should be at the forefront of decision making; driving the delivery of features (and in this case, content) based on real time user requirements. Put your consumer in the driver seat to best meet their online needs and bon voyage!



Silicon Milkroundabout – From both sides of the fence

by Roisi Proven


On Saturday May 10th, I nervously walked through the doors of the Old Truman Brewery for the first time. I’d heard good things about Silicon Milkroundabout, but had always been too nervous to give it a go myself. However, job dissatisfaction paired with the desire for a change drove me to finally sign up, and I was assigned a spot on the Saturday “Product” day.

I have to say as a first timer, the experience was a little overwhelming! The hall was already starting to fill up when I got there at 12pm, and there was a maze of stalls and stands to wade through. The SMR staff were very helpful, and the map of the hall I got on entrance made navigating the maze slightly less daunting.

I’d done my research before I got there on the day, and I had a little notebook of companies that I knew I needed to make time to speak to. There were 5 I felt I HAD to speak to, and a few that I was drawn to on the day, based on their stand or the company presence overall. At the top of my shortlist was Red Badger.

In May, RB had a small stand near the door, not in the middle of things but easy to find. I had to do a bit of awkward hovering to get some time with one of the founders, but when I did we had a short but interesting conversation. I took my card, filled in the form, and kicked off a process which led to me getting the job that I am very happy I have today.

Fast Forward to November, and my Saturday at Silicon Milkroundabout looks a whole lot different. This time, I’m not a candidate, I’m the person that people are selling themselves to. A different sort of weird! The Red Badger stall looks different this time around too. Where before we had a small table, this time around we had an award-winning shed.


That awkward hovering I said I did? There was a lot of that going on. Having remembered how daunting it was to approach a complete stranger and ask for a job, I did my best to hoover up the hoverers. I had a few really interesting, productive conversations during the day, but just as many were people who just wanted to compliment us on our stand or our selfie video. It was great to get some positive feedback for all of the team’s hard work on the run up to the weekend.

The biggest difference was, given the fact I was standing still, I was able to fully appreciate the sheer amount of people that came through the doors, and the variety of roles that they represent. The team at SMR have done a great job of keeping the calibre of candidates high, and it does seem like there is a candidate for almost everything the companies are looking for.

Here at Red Badger we’ll be combing through the CVs and contacts that we made over the weekend, and will hopefully be making contact with a several potential new Badgers soon. For anyone that met us this time around, thanks for taking the time out to hang in our shed. For anyone that missed us, we’ll see you at SMR 9 next year!


Improving Performance with New Relic APM and Insights

by Roisi Proven

In any kind of tech development, knowledge is power. When working on an ecommerce site, knowledge is essential.

The more information you have about your application, both during development and when it goes live, the more value you will be able to provide your client and in turn to the client’s customers. When in a development environment, it’s easy to provide yourself with a breadcrumb trail back to an issue, but when your code moves into a staging environment, the information you provide can end up being a lot less useful. At one point, this was as useful as it got for us:

With no way to know what this “something” was, and after a few awkward problems where we very quickly reached a dead end, we made the decision to introduce New Relic APM into our workflow.

New Relic APM helps you monitor your application or website all the way down to the code level. We have been using this in conjunction with New Relic Insights, their Analytics platform.

With New Relic we have been able to track VPN downtime, monitor response times and get stack traces even when working in a Production environment. So the above vague message, becomes this:

This monitoring enables you to increase confidence in your product in a way that isn’t possible with simple manual or even automated testing.

In addition to the APM, we’ve also been working with New Relic insights. It behaves similarly to Google Analytics. However, its close ties to APM’s tracking and monitoring, means that the data is only limited by the hooks you create and the queries you can write in NRQL (New Relic’s flavoured SQL language). It feels far meatier than GA, and you can also more easily track back end issues like time outs, translating it into graphical form with ease (if you’re into that sort of thing).

Being a new product, it is not without its pitfalls. In particular, NRQL can feel quite limited in its reach. A good example of this is the much publicised addition of maths to NRQL. That a query language didn’t include maths in the first place felt a bit like an oversight. However, this has been remedied, and they have also introduced funnels and cohorts which should add a lot to the amount you can do using Insights.

As a company Red Badger has always valued fast, continuous development. While traditional BDD test processes have increasingly slowed us down, by improving our instrumentation integration we hope to be able to improve our speed and quality overall.


London React October Meetup

by Chris Shepherd

Last week saw the fourth London React User Group and yet again the turnout was fantastic for such a young user group.

There were three talks this time and the first, “Learning to Think With Ember and React”, was by Jamie White who runs the Ember London User Group. Red Badger's own Stuart Harris had previously done a talk on React at the Ember User Group that had been well received, so it was time for them to come and talk to us. Jamie talked about how it was possible to combine Ember with React and it was interesting to see how flexible React is and how it's so easy to fit into a variety of existing workflows.

Next up was Rob Knight with his talk, “Diff-ing Algorithms and React”. Rob covered something that I think a lot of us now take for granted with React: how it updates the DOM through the use of a virtual DOM and efficient algorithms.

Lastly, Markus Kobler's talk, “React and the Importance of Isomorphic SPAs”, showed how to use React to avoid poor SEO and slow loading times. These are usually considered the pitfalls of building Single Page Applications.

If you missed the talk then you can watch it on YouTube below. To be informed about the next meet up then sign up here.

Hopefully we'll see you there next time!


Computer Science students should work for a start up while at uni

by Albert Still

Don’t completely rely on your grades to get you a job after uni. A CS degree will prove you’re intelligent and understand the theory, but that will only take you so far during an interview. We have to talk about apps we’ve built with potential employers, just like you would want a carpenter to show you pictures of his previous work before you hired him.

While studying CS at university I worked 2 days a week for Red Badger, even in my final year when I had a dissertation. Some of my class mates questioned if it was a good idea suggesting the time it takes up could damage my grades. But it did the opposite, I got better grades because I learnt so much on the job. And when you see solutions to real life problems it makes for a better understanding to the theory behind it. And it’s that theory you will get tested on at university. 

What I’ve been exposed to that I wasn’t in lectures

  • Using open source libraries and frameworks. Theres rarely a need to reinvent the wheel, millions of man hours have been put into open source projects which you can harness to make yourself a more productive developer.
  • GitHub is our bible for third party libraries. Git branches and pull request are the flow of production.
  • Ruby – the most concise, productive and syntactically readable language I’ve ever used. Unlike Java which the majority of CS degrees teach, Ruby was designed to make the programmers work enjoyable and productive. Inventor Yukihiro Matsumoto in a Google tech talk sais “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language”. Ruby is loved by start ups and consultants because they need to role out software quickly.
  • Ruby on Rails – built in Ruby it’s the most starred web application framework on GitHub. It’s awesome and the community behind it’s massive. If you want to have a play with it I recommend it’s “Getting started” guide (Don’t worry if you’ve never used Ruby before just dive in, it’s so readable you’ll be surprised how much Ruby you’ll understand!).
  • Good habits – such as the DRYYAGNI  and KISS principles. The earlier you learn them the better!
  • Heroku – makes deploying a web app as easy as running one terminal command. Deploy your code to the Heroku servers via Git and it will return you a URL to view your web app. Also its free!
  • Responsive web applications are the future. Make one code base that looks great on mobile, tablets and desktops. Twitter Bootstrap is the leading front end framework, it’s also the most starred repo on GitHub.
  • JavaScript – The worlds JS mad and you should learn it even if you hate it because it’s the only language the web browser knows! You’ll see the majority of the most popular repositories on GitHub are JS. Even our desktop software is using web tech, such as the up and coming text editor Atom. If you want to learn JS I recommend this free online book.
  • Facebook React – Once hard JS problems become effortless. It’s open source but developed and used by Facebook, therefore some seriously good engineers have developed this awesome piece of kit.
  • Polyglot – Don’t just invest in one language, be open to learning about them all.
  • Testing – This was not covered in the core modules at my university however Red Badger are big on it. Simply put we write software to test the software we make. For example we recently made an interactive registration form in React for a client. To test this we made Capybara integration tests, they load the form in a real browser and imitate a user clicking and typing into it. It rapidly fills in the form with valid and invalid data and makes sure the correct notifications are shown to the user. This is very satisfying to watch because you realise the time your saving compared to manually testing it.

Reasons for applying to a start up

  • They are small and have flat hierarchies which means you will rub shoulders with some talented and experienced individuals. For example a visionary business leader or an awesome developer. Learn from them!
  • More responsibility.
  • They’re more likely to be using modern front line tech. Some corporates are stuck using legacy software!
  • If they become successful you will jump forward a few years in the career ladder compared to working for a corporate.
  • Share options – own a slice of your company!
  • There are lots of them and they’re hiring!

Where to find start ups

A good list of hiring startups for London is maintained by the increasingly successful start up job fair Silicon Milk Roundabout. Also Red Badger are currently launching Badger Academy, they’re paying students to learn web tech! This is extremely awesome when you consider UK universities charge £9,000 a year. If your interested in applying email



There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

C.A.R. Hoare, 1980 ACM Turing Award Lecture