Why you need to get your developers hacking
I think it was Christmas 1985 when I was given my rubber keyed ZX Spectrum. It came fully loaded with 48KB of memory, enough to store about a tenth of the picture of it below. Despite this, it was the premiere UK games console of its time. Yes, it took about 5 minutes of screeching to load a game up and even then sometimes a small glitch in the cassette tape would cause it to fail, but I loved it.
One thing that separates it from today’s consoles is that you could program it yourself. I didn’t have many games to begin with, but there were magazines available with code printed in them that you could copy. Naturally, I would then make mistakes — debugging these mistakes actually made me into a programmer. This then led to me writing my own games, most of which didn’t work exactly as I’d imagined, but I learnt plenty. I don’t think anything I studied at school or university was more useful to my career in media technology than this little machine.
Fast Forward to today
Fast forward the odd decade and I’m a Product Manager in Supply Chain & Distribution at ITV. We take the assets and metadata for finished programmes, ingest, archive, process and deliver them automatically and provide tracking of these processes to our users. Like all product teams, we’re driven by business needs, but we also have a healthy culture of addressing tech debt and innovating in both technology and process. For quite a while now, we’ve set aside 1 day in every 2 weeks for innovation and learning, with a hack day and a personal improvement day.
“As a junior developer and recent joiner, it’s a great way to meet and work with people across the wider team. It’s also a useful opportunity to familiarise yourself with new technology outside your regular day to day”
What is a Hack day and why have them?
If you’re a software engineer, you’ve probably taken part in a hack day, or possibly a large “hackathon” with other companies. It usually involves teaming up with other engineers to try to solve a specific problem within a day. It’s a fun way to meet other engineers and to learn about tech you may not have known much about. In the same spirit as me tinkering with Spectrum Basic, failing can often be more instructive than succeeding.
(Hack days)…“allow for the prototyping of features that might shape out new projects/improve our existing workflows (a simple example is the subtitle search work), but also get ourselves familiar with new technology”
It’s more unusual, I think, for a team to have dedicated hack days internally. When this was first suggested, I was quite cynical about the benefits — value, value, value is the Product Manager’s mantra. Where’s the value in the developers playing around for a day when they could be building the workflow for BritBox, for instance?
The answer is that the hack days give the developers a chance to collaborate across teams, innovate and also to fail. The learning they get from this is then used to apply new tech and concepts in the products themselves. There have been several hack projects that have become part of our product set, for instance a chatbot that allows our Ops team to see where content is and, recently, a search tool for subtitle text, but this is not the main aim. Being able to spin up cloud infrastructure makes this much simpler than in my coding days. I dropped my cynicism and remembered my old Speccy days.
How hack days helped save the day
Then last year, for a very good reason, we had to take the broadcast and international ingest services in house. The clock was ticking to get this done to keep ITV on air. Trust me, this was a LOT for the team to take on in a short time and it was critical to the business. This could have needed a LOT of technical discovery work to figure out how we were going to deliver. Sure, we still needed to do some of this and it wasn’t all plain sailing, but some of it had already been proved, or discarded, as hacks. The first time we used AWS Lambda functions (AWS is Amazon’s Cloud platform, Lambdas are functions you can create without needing to explicitly spin up a server first) was on a hack day, for instance, and this workflow is heavily lambda based. And it kept ITV on air.
“I like doing a hack that becomes unexpectedly useful to the business. I quite often start a hack not knowing it’ll be useful but once we have a hack together, it demonstrates quite well to non-developers what is possible with just a day’s worth of effort.
We have plenty of ideas for future hack days as well. Here’s our Trello board.
Our Five tips for a good hack day:
- Anyone can come up with ideas, but let developers pick their own projects, you want them to have fun and learn at the same time.
- Have a kick off and a wrap up, but don’t make everyone demo if they don’t want to. Time pressure keeps focus, but pressure to produce a demo can be a distraction and fear is not fun. Just saying “I tried this and this is what we learnt” is fine.
- Keep the time as sacred as possible, don’t interrupt it with team meetings.
- Keep it relevant to what the teams generally do, but remember the code from most hacks should be throwaway. If something ends up in production, that’s a bonus.
- Encourage developers to work with their colleagues from different teams, but don’t make them. This means more sharing ideas, as well as getting to know the others, which can be tricky in a larger team.
“We can work on whatever we want! I tend to stick to things that are clear solutions to problems we have, but in general it is a great way to improve on things. With code, sometimes it is better to show something than to talk about something. Also a great way to collaborate outside your team”
(from a former developer) — “I love getting to write some code! And experiment with new tools without the usual constraints.”
