Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    2021 – 2023

    Mid-Senior HTML5 TV Developer

    Accedo

    Two years building Channel 5's My5 app for connected TVs: performance on slow hardware, a navigation model that finally made sense, a full rebrand, and a knowledge-sharing culture I helped start.

    • React
    • Redux
    • TypeScript
    • JavaScript

    3 min read

    Why I joined

    Accedo was my first role after university. I was settling down in Kent and wanted a London-based role that would keep pace with where I wanted to go, and thanks to the extra year at Elanco I could skip the junior roles to get there. It was also a step up in responsibility, the first of several. Accedo builds video apps for broadcasters and streaming services, and TV was a new kind of front end for me: a web app with a remote instead of a mouse, a ten-foot interface, and hardware that can be many years old. It was a chance to take everything I’d learnt about the web and apply it under much tighter constraints.

    The role

    As a mid-senior HTML5 TV developer I worked on the My5 app for Channel 5, delivered to a range of connected-TV platforms. Day to day that meant features across sign-in, playback and search, performance work for low-powered devices, CI/CD pipelines in Jenkins, and build tooling for individual TV platforms.

    Over time the role widened. I ended up leading delivery on several pieces of work, onboarding and mentoring newer developers, and putting a lot of energy into how the team worked, not just what it shipped. In the second half I was also acting as a developer advocate: community developer engagements, knowledge sessions and hackathons, building more of a developer community spirit.

    What I built and led

    The technical story is in Smart TV Apps on Low-End Devices. The highlights:

    • Performance on slow devices. Keeping navigation stacks shallow, deferring off-screen content, and replacing a global “slow device” delay with per-platform tuning so fast TVs didn’t pay for slow ones.
    • A back-navigation model. On a TV the back button is the navigation. I designed explicit history-stack rules, drew them as diagrams, and agreed them with testers and the client before writing code.
    • The video player refactor, from class components to function components and hooks, with tests pinning down the subtle state-ordering changes it surfaced.
    • A full rebrand of the connected-TV app.
    • How the team worked. Weekly developer sessions, engineering-wide tech talks that I set up and ran, a testing workshop, structured pull requests and review feedback, Pair Programming, and written decisions (Architecture Decision Records).

    Juggling several open pull requests at once is also where my worktree habit came from: one directory per PR, so switching was a cd rather than a stash and a reinstall (Git Worktrees: A Desk per Branch).

    Results

    At CV level: optimised memory and performance on slower devices, major performance improvements to key functionality, a full rebrand delivered, and better developer processes, including pair programming and structured code review. The back-navigation rework ended a long-running source of bugs and confusion. And a knowledge-sharing culture that started in one project team spread into talks for the wider engineering group.

    What I learned

    • Profile on the worst device you support. Your laptop lies.
    • Agree behaviour with diagrams before code. Arguments about “what should back do?” disappeared once everyone was looking at the same picture.
    • Process is part of the product. Better reviews, shared knowledge and protected time for tech improvements made the team faster than any single feature did.
    • What I wanted from my career. I wrote my first proper career plan here. The target was to become a strategic technologist: leading technical decisions while still writing code, with depth in my own domain and breadth across the wider picture. A mentoring session from this time gave me a leadership checklist I still use: empower people, lead by example, build a coaching culture, and be consistent without micromanaging.

    Why I moved on

    I genuinely enjoyed the people at Accedo. By my second year I was leading delivery on several projects and spending a lot of my time mentoring, which I valued. What I realised was that I also wanted peers who’d stretch me. For a while I had a counterpart I learned a huge amount from, and when they moved on, it felt like time for me to move too.

    Like every move I’ve made, it was also a step into more responsibility, with a title to match. I’d been talking about Sky’s culture for years, and the role on offer was exactly what my career plan pointed at: a React lead on the network side, leading the front end of a platform that integrated many microservices, with exposure to lots of teams and to back-end work. More breadth, more ownership, and a title that matched the job. That became my next role: UI Lead Developer at Sky.

    Case studies from this role (1)

    All experience