Posts Tagged ‘training’

21
Aug
2014

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 jobs@red-badger.com

Best,

Albert

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

14
Aug
2014

The Launch of Badger Academy

by Cain Ullah

Back in January this year I went away for a 10 day retreat. The initial intention was to get away from work completely. No phone. No internet. No work. However, unexpectedly it ended up being incredibly conducive to coming up with a whole plethora of creative ideas. Some were non-work related but lots of new ideas were very much work related. (See this blog post I have written on Founders Week: The Importance of Taking Time Out). One of these ideas, in its rawest form was how we can source and develop young talent and turn them into very highly skilled developers, designers, project managers or whatever else. This has resulted in the quiet launch of Badger Academy this week.

A little bit of context

At Red Badger, a huge amount of investment goes into recruitment. Finding the best talent out there is difficult. As a company we hang our hat on quality, quality being the #1 Red Badger defining principle. As a result, we’re very fussy when it comes to hiring people. This I am in no doubt, will hold us in great stead for the future, so we are determined to maintain our standards in staff acquisition. But it poses a problem – how do we scale the business to service our ever increasing demands from a rapidly growing sales pipeline, without reducing quality?

I think the answer is to improve our ability to develop from within. So, we are hatching plans to invest heavily in developing young talent to become senior leaders in their field. We realise this will take time but Badger Academy is the first experiment that we hope will fulfill the overall objectives.

A Blueprint for Success

In the summer of 2011 when we were a much, much smaller business, we put out a job ad for a summer intern. Out of the 60 or so applicants, one Joe Stanton stood out head and shoulders above the rest. By the time he joined us, he had just started his 2nd year of Uni so worked with us for 8 hours a week. He had bags of talent but obviously lacked experience and as a Computer Science degree student, was being taught vital foundational knowledge stuff that you’d expect from a Computer Science Degree. However, he had no knowledge of modern web application engineering practices such as Behaviour Driven Development.

At the time, we had much more time to spend with Joe to ensure that he was doing things properly and with our guidance and his astute intellect, he developed his knowledge rapidly. He then had a gap year with us during which he was deployed and billed on real projects before going back to part-time for his final year of University. He graduated this summer and after a bit of travelling around Europe, he joined us permanently. On his first day, he was deployed onto a project as a billable resource having had almost 3 years of industry experience. He has hit the ground running in a way that most graduates would not be able to.

Joe has been a resounding success. The problem is how you scale this to develop multiple interns especially now that as a company, our utilisation is much higher. We can no longer spare the senior resources to spend the sort of time we could with Joe at the very beginning.

JoeGrad.png

Joe Stanton – The Badger Academy Blueprint !!!

The Evolving Plan

When I was at the aforementioned retreat, my ideas were based around a project that we were just kicking off for an incredible charity – The Haller Foundation. We were embarking on a journey to build a responsive mobile web application to help farmers in Kenya realise the potential of the soil beneath their feet (For more info, search our previous blogs and look out for more info once the Haller website is officially launched later this year). What was key in my thinking was that we had planned for a mixture of experience in the project team which included two intern software engineers (one being Joe Stanton) that were working 2 days a week whilst completing their final year at Uni. We were delivering the project for free (so Haller were getting a huge amount of benefit) and we were training and developing interns at the same time. Win-win.

So, this formed the basis of my initial idea – The Red Badger Charity Division. We would use interns to deliver projects on a pro-bono basis for registered charities only. The charity would need to understand that this is also a vehicle for education and thus would need to be lax on their timelines and we would develop interns through real world project experience in the meantime. Although a great idea, this wasn’t necessarily practical. In the end, the Haller project required some dedicated time from some senior resources and cost us over £20K internally to deliver. A great cause but not a sustainable loss to build a platform for nurturing talent upon.

So, over several months after my retreat (7 to be exact) in-between many other strategic plans that were being put in place at Red Badger, with the help of my colleagues, I developed the idea further and widened its horizons.

Rather than being focussed on just charity projects (charity projects will remain part of the remit of the Badger Academy), we opened the idea out to other internal product development ideas as well. We also put a bit of thinking into how we could ensure the juniors get enough coaching from senior resources to ensure they are being trained properly.

Objective

Badger Academy’s primary objective is to train interns that are still at University who will be working part-time with a view to them having a certain level of experience upon graduation and hopefully joining Red Badger’s ranks. However, it may also extend to juniors who have already graduated (as a means to fast tracking them to a full-time job), graduates from General Assembly or juniors who have decided not to go to University.

It will require some level of experience. i.e. We will not train people from scratch. But once Badger Academy has evolved, the level of experience  of participants will vary greatly. In the long term we envisage having a supply chain of interns that are 1st years, 2nd years, gap year students and 3rd years, all working at once. Youth Development.png

Above is a diagram I drew back in April 2014 when initially developing the future strategy for Badger Academy. This has now been superseded and developed into a much more practical approach but the basic concept of where we want to get to still remains the same.

So what about the likes of General Assembly?

Badger Academy does not compete with the likes of General Assembly. We are working very closely with General Assembly, providing coaches for their courses and have hired several of their graduates. In fact, General Assembly fits in very nicely with Badger Academy. It is the perfect vehicle for us to hire a General Assembly graduate to fast track them over a period of 3 months until they are billable on projects. A graduate from General Assembly would generally not have been a viable candidate for Badger Academy prior to doing the General Assembly course. Like I say, all candidates need a certain level of experience beforehand. Badger Academy is not a grassroots training course.

Implementation

It is imperative that interns and juniors are trained by more senior resources. As a result we’ll be taking one senior resource for one day a week off of a billable project to dedicate their time to training the Badger Academy participants. To reduce impact on specific projects, we will rotate the senior coaches across multiple projects. We will also rotate by the three University terms. So for autumn term at Uni, we will have 3-4 senior coaches (all from separate projects) on weekly rotation until the end of the term. The spring term we will refresh the 3-4 coaches and again for the summer term. This way, everyone gets to teach, there is some consistency in tutors for the interns during term time and project impact is mitigated.

Summary

There will be a set syllabus of training topics for each discipline. As this is the first week, we have decided to build the syllabus as we go. Our current interns are both software engineers so we can imagine us getting pretty quickly into engineering practices such as testing strategy (E.g. BDD) but also other disciplines that are vital to delivering quality products such as Lean/Agile methodologies, devops and all of the other goodness that Red Badger practices daily.

This is an initial blog about our current activity but is light on detail. As this develops, we’ll formalise the approach and publish more insightful information of what this actually entails.

What we need to not lose sight of, is that this is an innovation experiment. We need to learn from it, measure our success (as well as our failures) and adapt. This is part of a long term strategy and we are just at the beginning.

Disclaimer: Red Badger reserves the right to change the name from Badger Academy. This has not been well thought through!

2
Apr
2013

Retrospective, Firestarter Event – Day Two

by Jon Sharratt

So as day one closed we were ready to get our heads down into hacking some code and try to produce something we could release.  We broke up the responsibilities for UX, creative and technical tasks to the relevant roles.  As I mentioned in day one we had chosen a technical set that was mostly familiar.

A problem did arise in the fact we had decided to go with Backbone.js and Marionette, not a problem with the framework itself but the fact we were not so familiar with its inner workings.  I have to say that it wasn’t the best choice to go down with for the event i.e. a single page application route using a technology we had little experience with at the time.  

It was challenging but we did make some great progress in the morning.  Authentication was up and running with Facebook along with the ability to post content.  Haro did some sterling work in getting MapBox integrated into the application to display hotel details in around the Las Vegas area.  The hotel data itself was to be added manually (I had collated the hotel details the night before in a Google Spreadsheet) but obviously this wasn’t the most ideal solution but for now it would suffice.

 

As lunchtime came about we decided to get the team together and go to the local pub for some well deserved fish and chips.  After a few pints and a bit of banter with team we got back to it and continued hammering out as much as we could.  Sari got her magic wand out and managed to come up with some branding in no time at all, working with Samera the UX was also really taking shape.

 

All in all were coming to the end of the afternoon and it was apparent as much as we tried we were not going to get a completed application out of the door this time.  This was mainly due to trying to create a one page application with new technologies as previously mentioned.  I would safely predict that if we had gone down a standard web application with the technologies we have used many many times before in projects we may have got it out of the door.  Having said that we now have good knowledge of Backbone.js and Marionette to allow us to judge when or when not to use it in future projects.

The event itself to me was a success and I have mostly gotten what I wanted to really jump start the application to get something delivered.  The biggest downside I had after the event was losing the vision of delivering a true Minimum Viable Product.  This is something I need to work on for future events and any ideas I want to deliver in the future, “it’s all about delivery” and at the moment the phrase “close but no cigar” comes to mind.  

It really rams home what / why people say single member teams rarely succeed due to not ever ending up shipping their products.  An example of integrating yelp! really steered me off track and I have ended up adding more features that I could of left out to deliver grazr earlier.

 

 What I need to do right now is literally get the last bits of functionality delivered and delivered fast, I am in what I would call a “lingering phase” and if left to linger too long grazr will rot away.  It needs to be out there for the world to see, it is the worst position to be in as I can’t even say “I tried and failed” as no users have even tried the product at the moment it is just that “I tried”.

I intend to follow this up next week with the launch of grazr, and hopefully some statistics on what happens with users I send it out too.

If you are interested in one page applications the guys over at airbnb are doing some very interesting things with Backbone.js to allow client and server side rendering of templates for single page applications (see blog post here).

The full technology stack we ended up using was as follows:

  • Node.js
  • Backbone.js
  • Marionette
  • MongoDB
  • Heroku
  • Jade Templates
  • Grunt
  • LESS
  • Bootstrap

Watch this space (no really I mean it)…. 

3
Dec
2012

Rapid Prototyping Incubator – Training Shaken Up

by Jon Sharratt

Thoughts

So as the year is closing out and we head towards 2013 I started to think about what I might be able to do in regards to the £2,000 training budget that we get here at Red Badger.  

At Red Badger we are a growing company and to start schemes such as Google’s one day a week (20% time) to innovate is not particularly viable (not yet anyway …).  The other point about having one day a week to work on your own products is that you may not have an idea or products that you feel you can really work on.  I feel it turns the time into being a little be wasteful and really only focuses on things you can do in your discipline.

So rather than forcing the issue and trying to find a training course that ‘could’ be a good fit and not getting much value.  I have formulated an idea around the ethos of how we have run some of our previous rapid prototyping projects such as BBC Now!.  

Additional to this I recently discovered show on Bloomberg called TechStars where start ups spend three months in an incubator scheme to raise investment and get their company off the ground (Episode 1).

The new Red Badger scheme is formed from mixing rapid prototyping with an incubator type event…..

Idea

I put forward the idea to the guys here at Red Badger to allow any employees to embrace and innovate internally by allowing investment in our own ideas when we have them.  The application process being that we can book any internal resources to develop our ideas using the training budget as a catalyst investment over the two days (in a rapid prototype format) and end up with a (M)inimum (V)iable (P)roduct.

The event itself is to be a very informal affair and a great laugh with a specific focus on delivering the MVP.  Beer, food, crank on the tunes and start developing!

This is great for many reasons as it allows any person of any discipline within Red Badger to get their ideas off the ground and test the market.  Red Badger can then see if these ideas are worth investing more time after the MVP is in the wild and being tested by users, they also then have ownership for any successful ideas that get off the ground and prove value.  

We are a consultancy here at Red Badger and my opinion is that this scheme lends itself very much to bringing our team together, company culture and aspirations as a business.

It is important to note that the ideas can be absolutely anything, not limited to that of internal or improving Red Badger processes.

Future

I want this to be a very transparent process to show successes and more importantly failures of running this type of event.  This scheme in its own right is an ever evolving process and has never been done before so there will be plenty to learn.

The first project that has got approval is scheduled to go ahead at the beginning of the New Year.  I will post up the planned agenda for the event in the coming weeks.  I would be interested in any thoughts and ideas people might have with a scheme such as this (good or bad).

 

29
Feb
2012

Devising a Training Budget

by David Wynne

We go to quite a lot of effort at Red Badger to find the right people to employ, people who will invest themselves in our company and what we’re trying to achieve; all very noble.  But as with all good relationships, it’s not just about the take but also the give – you get back what you put in.

Part of that giving back often comes in the form of training, be it a book, a conference or even a traditional course.  The question is; how much do you spend on each employee and who get’s to say when it get’s spent?

One of the great things you get to do when you start your own company is to put in place the policies you always wanted when you were an employee working for someone else.  I’m sure many people ultimately decide to start their own company because they think they can make a better fist of it than their current or past employers.  Whilst that all sounds fantastic in practice, one of the other things you have to do when you start your own company, or indeed just run any company responsibly, is to make decisions that are in the interest of company long term security.

We strongly believe in ensuring that we hire the best people and then help them stay the best.  We also believe in hiring managers of one so figured we’d delegate the training budget management to each employee; with some ground rules of course!

Here’s the email we sent to our team:

We’d like to set out and agree an open and fair approach to training, such that each employee can self-manage any training courses or conferences they are interested in attending.  To enable this we have decided to set a nominal budget allocation for each employee so that they can judge when and what they would like to attend in regards to training.

We propose to set this at around £2,000 per calendar year, per permanent employee.  Our thinking is that this could fund attendance at a lot of smaller events and courses or the ability to attend one large conference per year.

Some things to note:

  • In the case of attending a conference, the price of your ticket and travel will count towards your training spend.
  • This amount is not a hard fixed amount and can be increased to cover more expensive conferences if circumstances allow.
  • This is not a prompt to figure out how to spend £2,000, but intended to illustrate what you can expect Red Badger to contribute to your training each year so everyone knows where they stand and all are treated fairly.
  • You still need to discuss conference/training attendance with us before booking.
  • The ability to attend events will depend on project resourcing.
  • If you attend a conference/course we would expect you to share your experience and learning with the Red Badger team (e.g. lunchtime brown bag sessions) and with the wider community via the Red Badger blog.

As with all things, this is an iterative process which we will tweak and improve over time with experience.  I’d love to hear what other companies do and any feedback on whether this deal sounds great/ok/crap.

@dwynne