I’m looking for two very talented developers to come and join me at hibu to work on yell.com. With over 22 million users a month, Yell.com holds a prominent position in the UK’s online industries. Over the coming months, we are looking to push the boundaries of our user interface to maintain and improve our usage and user satisfaction. As part of the Technology team, with your help we will use the latest technologies to design exciting new interactions for desktop and mobile browsers. It’s a tough challenge, and to do it, I need some great people to join my team.
Here are the two job descriptions: Front End Developer and UI Developer
I’m looking for people who are adaptable and are willing to learn new technology quickly. I’m after developers who will do the right thing for the long-term, over fixing a problem quickly. I want developers who are familiar with new technology, and how it can be applied to get the absolute best performance out of the web browser, and importantly, I need someone who can appreciate the differences in browsers and know how to get the best out of them, no matter how big or small the screen size is.
In return, you will get freedom to implement features as you see fit, and access to the tools that you need to do your job. The role is based in central Reading, just by the mainline train station (25 minutes from London Paddington). The office itself is large and spacious, with a great restaurant/cafeteria on the 10th floor with some of the best views over the city, and pretty decent coffee throughout the rest of the building. There’s a whole host of other benefits (including competitive salaries, naturally) that you’ll be told about if you join us.
Hibu’s canteen, with table football table
Could this be your desk?
One Reading Central, hibu’s offices
The view from the canteen over Reading station and Caversham on the greyest day of the year
If you want to apply, or know more information, contact me, tweet me, or just apply. Please note, you have to be eligible to work in the UK or hold a valid work visa to get either of these roles.
These roles are currently open, I will update this page whenever they are filled, or if more roles are available
I was lucky enough to be asked to speak at Remy Sharp’s Side View conference in Brighton this weekend, a part of the full frontal conference event. I tried to give an overview of the state of the web on TVs and how our current attitude to responsive web design works, or rather doesn’t work, on big screens. Here’s the slides and abstract.
The Responsive Web Design trend was triggered by the need to make the web presentable on small, handheld devices. Now, the Internet is encroaching on every aspect of our lives, and it won’t be long before it takes over large screens too.
How much of manufacturers’ internet TVs claims are true? Will the next generation of consoles bring the Internet to the living room, or will Chromecast be the gateway to the large screen future, and where do web developers fit in?
Lets make a web site that is suitable for the sofa
A video of the talk will be made available through sponsors Treehouse soon.
The most common question I got after the talk was, “What inspired you to do the talk, did a client ask you to do some TV work or something else?” The answer is simple, I just wanted to know how it was and tell people about it. I know that members of the Opera developer relations team have done much of the research into the web TV for the opera web TV product, and I’ve always wanted to hear them talk about this subject and wondered why they didn’t do those talks – the technology to make it happen exists. So I did my own research into the problems, and now I understand why they don’t talk about it much. The whole web on TV experience is a mess, the technology promises a great user experience that doesn’t live up to expectations, and almost actively discourages the browser usage in favour of pre-loaded app experiences.
Now that the research is done, I an going to look for better answers. Luke Wroblewski is doing this, as is Ethan Marcotte, and in this industry, when heavyweights like those start to investigate, there is clearly a problem to solve, and probably a mindset change to happen to enable our industry to grow and embrace this technology.
I hope you like the talk, let me know what you think on Twitter and in the comments
It’s official, from the end of November I’m going to be working for hibu as the UI Tech Lead for yell.com
I’ve had a great start to my career – over my 6 years at PA I’ve worked for the biggest employer in Europe (twice), the world’s biggest medical charity, oil giants, financial regulators, one-man-bands, governments, utility companies, major pharmas and worldwide hotel chains. I’ve gotta say, there’s no feeling like you’re making a difference in a company, and I’ve had some great results over the year;. I’ve even managed to carry 15 iPads in my hand luggage through Istanbul airport. With all of that comes trade-offs, and a pretty long commute, and it’s time to leave that behind.
So, I’m really looking forward to be able to focus on this product and make it great. I’m going to continue to be an organiser for London Web Standards so I’m not abandoning the city completely, but you’ll also see me at Reading events like Breaking Borders, Reading Geek Night and Berkshire Digital.
Here’s to the next step.
I gave this talk at Berkshire Digital’s Pecha Kucha night. I talked about automating development processes to improve the speed at which we can iterate. The full transcript is below
Hey everyone, my name is Steve Workman, I’m a web developer living in Reading and I work for a company called PA Consulting in London. I’m also an organiser of the London Web Standards group, and have been for a few years now. Most of my work is to do with making the web better, and faster for everyone, but I also like making life easier for my team of developers, and for that we need automation.
Let’s face it, the world as we know it wouldn’t exist without the invention of the assembly line. Whether that is 20 people sharing out tasks in an order or a completely automated production line, this way of working, an individual dedicated to a single task, passing the results on to the next stage, increases the speed at which we can get a product, and it is the enabler of what we know as mass production.
And by mass I really mean millions of items per day, which was a pipe dream in the early days of the Industrial revolution, like in this classic picture of the steel works in Barrow. Much of the work done here involved a lot of labour, only involving machines for large jobs. For true mass production, you need automated machines, or as we know it in technology, computers.
For this talk I thought, what can I give as an analogy for mass production that is relatable to everyone and I know quite a bit about – well, my wife works for a large chocolate manufacturer – problem solved! (note, picture above may or may not be for her role).
This company makes 3.2 million bars per day on a single line, for the UK region alone! To do this kind of scale with industrial revolution techniques you would need an entire city full of people, though this line runs with a shift of around 20 people.
And it’s not like it’s an easy job, making chocolate is a very complicated process that takes hours from raw materials to bars, and whilst people may think that it’s like stage 13, pouring chocolate into moulds, the whole process is much bigger and complex than this – which is why it must be automated to work on scale.
I think there is a lot that the web industry can learn from this kind of manufacturing. Automation allows developers to perform labour-intensive manual tasks like deploying an application into quick scripts to save developers huge amounts of time, and make the whole process much more reliable.
In my own personal experience, back in the early days of iPhone development, we didn’t have an automated process, and code was strewn around a number of different laptops, making it very difficult to track down code and sometimes it would take us about a day to build and deploy the app. It now takes about a minute to do everything.
We took on the principles of the manufacturing line to make what we do better. Developers need a factory, and that is their server room. If a developer has to walk over to another computer to make an automated process happen, it’s not an automated process. For me, this is where my application servers live, and this is where my build server lives. This is my factory
We have developers – they are the farmers, harvesting source code and creating the raw materials to make our wonderful chocolate bar of an application. Developers have to supply quality raw ingredients, quality source code, to make a great application. Developers have coding standards so they know how they should write their code to make it work as part of the recipe
Developers normally store their code in source code repositories, like they are sending their over the information highway to the loading depot, where all the ingredients will be combined to make this lovely application. The two most popular of these are subversion and git – subversion being more like a traditional factory, and git being an at-home 3D printer.
Then we have our recipe, the instructions on how to combine all of our ingredients together. Traditionally this does things like compiling the code, but it’s also about applying performance enhancements that you wouldn’t want to develop with. It’s like taking cocoa beans and turning them into cocoa liquor so they’re the right size for your process. This recipe is called a build script.
Over the years, build scripts have evolved from the original, and still widely used, Apache Ant, a simple worker that you specify tasks to run, then there’s maven, which also handles a project’s reporting and documentation from a single, central piece of information. More recently, we’ve got Grunt, a build script that encourages plug-ins so you can enhance it and do whatever you like. It’s like instantly summoning a new machine from a third-party company to do a complex piece of work for you.
Then we have our control room, and for me this is a piece of software called Jenkins – it takes the ingredients from the loading bay and runs them through the recipe. Other bits of software that does the same job are available, but Jenkins is free as in free beer, and the icon is a butler, which is a big plus in my book.
Jenkins watches for what is going wrong. Like modern factories, you set thresholds for quality, and you can monitor when things are starting to go wrong, and keep it in check, to bring it back within its quality spec. You wouldn’t want a chocolate bar with a gritty, high particle size, and I wouldn’t want an application that was over 2MB to download on the page, so you can monitor this and get those warning signs sent to you via e-mail, sms, or chat.
The important bit is to make sure that your combined recipe is actually up to snuff. In the chocolate world, about twice a shift, the operators unwrap and check up to 150 bars out of the tens of thousands that have been made, simply to check its quality – and that’s attention to detail.
In software, we try to automate this as much as possible, and give ourselves traffic lights to say when things are working well and when the quality is off – something doesn’t work. When it doesn’t work, it looks like this – some nice green tests, then a big chasm as tests fail and everything breaks. These are needed to trigger the factory alarms and shut down the process. The last thing you want is this poor quality product getting out into the general marketplace – and these tests and alarms stop that.
Obviously, the quality of your checks matters a lot, and the better they are, the less likely you are to produce bad code and a bad product.
The massive advantage that software development gives us is that your workers are other computer programs, tiny little ultra-fast robots that never tire, never go on a coffee break. They can perform practically any task you want to get your lovely app into ship shape. Say, when it’s done, you wanted your app to be submitted to a service like TestFlight so you can automatically send your app to testers.
But just because the little robots are very fast, doesn’t mean they’re indestructible – in reality it means they fail faster, and often without much warning. That little robot that sent the app to TestFlight won’t have anywhere to send the app to if TestFlight changes their API. These programs need maintenance, and it won’t just be because of third-party services that your robots will fail – your app itself will change and need to do different things over time, so you have to keep tweaking the program to make sure it runs like the well-oiled machine that it should be. In the chocolate world, people with the toolbox, those in the reliability team, have one of the most important jobs in the factory – to keep it going so that chocolate can reach consumers as quickly as possible and in as good a quality as possible.
All of this is really important so you can keep innovating, keep shipping, keep distributing and gather feedback from your users as fast as possible. Innovation and ability to react are two of the defining characteristics of startups and lean organisations. Keeping your factory running as fast as possible is vital, and something software houses should invest more in.
So, keep shipping, keep those little robots moving, and importantly, buy chocolate