Steve Worsley

✨Senior front-end developer @AutoTraderLife. Interested in design systems, learning and development, and the inevitable heat death of the universe.

Thoughts of the Month - Issue 1

As a way to decompress 💆‍♂️ from work I write a few notes on the way home. I’ll add some details and related links then they get posted to Twitter @iamsteveworsley and collected here for discussion. ⚡️


Updating a design system, consuming pattern/component libraries and consuming micro-frontends sure is tricky. More places it can fall over but hopefully with the code split the impact of the issues will be smaller.


Anyone else find it hard to provide an immediate and useful update on your work? Or say what you've been doing over the past week if asked out of the blue? Read more


Lift and Shit: performing a Lift and Shift but leaving the re-platformed code in a worse state than it was originally created. Occurs when a lift is rushed resulting in sudden pain and fumbling of the shift. Disappointment is akin to receiving a damaged parcel through the post which you can’t return because the seller has shut-up shop and retired to a farm to start a greenfield project to breed rare Yaks for their wool.


A challenge I’ve found with design systems and pattern libraries is finding the time to get competent with the varieties of tooling - beyond just using them as and when needed. Particularly Fractal and Storybook.


Interesting projects, a desire to help people and fear of missing out make it hard to say no. I had so much on during the run up to Senior it became extremely stressful. So part of my PDP refresh will be around focus, working on one or two discretionary effort style things and saying “no thanks” more often. Read more on speed and velocity


I’ve not come across AHA before (Avoid Hasty Abstractions) 😆 but I’ve certainly come across some bat-shit abstractions and probably a few I wrote my self. 🙈 The Befuddlement Ratio - Every click through you perform in your IDE your intelligence decreases in percent the number of characters used in the abstracted function name.


See you next time! 🤩

Notes: Adopting Typescript at Scale

Brie Bunge takes us through Airbnb's approach to adopting Typescript. This is worth a watch to get a grasp of the process even if you're not using Typescript.

Checkout the video here: https://youtu.be/P-J9Eg7hJwE

Adopting Typescript at Scale


  • What doe scale mean in this context? Hundreds of developers at Airbnb now use Typescript as their primary language for front-end development.

  • 2m lines of JavaScript needed converting, over 100 internal npm packages. 1300 engineers 200 of which work on the front-end.

  • The idea was raised at the front-end working group meeting where they talk about new technologies, make and discuss proposals.

  • These are deliberate decisions about what they commit to as a team.

  • They used pilot teams first who were then sent a survey to see if they should keep using it.

  • There are types maintained in a public package for packages which aren’t typed with Typescript. Sharing is caring.

  • Codemods can help you do large refactors.

Impact of introducing Typescript:

  • Fewer bugs - externally it had been reported to reduce number of bugs by 15%. After analysis of recent bugs Brie found that 38% of those bugs would have been preventable with Typescript.
  • A better developer experience.
  • End to end type safety as types can be used across front and back-end.

If you want to do something similar:

  • Gather evidence and support
  • Gradually introduce change
  • Be inspired to make the change you are passionate about

Notes: How to Write Learning Objectives Using Bloom's Taxonomy

I'll admit that Course Design on a Shoestring Budget doesn't sound like comprehensive learning resource but I was able to digest and then explain what I'd learnt from this video suprising well!

Checkout the video here: https://youtu.be/4DgkLV9h69Q

How to Write Learning Objectives Using Bloom's Taxonomy


Bloom's taxonomy covers lower to higher order learning. Each level building on another. This includes:

Lower order:

  1. Remember
  2. Understand
  3. Apply

Higher order:

  1. Analyse
  2. Evaluate
  3. Create

A advanced course might be tailored to higher order domains and students will be expected to have foundational knowledge.

That’s not to say a course tailored toward higher learning won’t have aspects for lower order domains.

To create a learning objective:

  • Start with a stem sentence e.g. "After completing the lesson, the student will be able to..."
  • Determine a learning outcome
  • Combine with a verb from Bloom's wheel tool

It's quite a short video so it'd be worth just watching the whole thing.

Hey you! What are you working on?

"Steve! What are you working on?"

"Sausages! Lemon drizzle cake! It's currently 30°C with a light breeze on the western peninsular so slap on that sunscreen pop pickers!"

Anyone else find it hard to provide an immediate and useful update on your work? Or say what you've been doing over the past week if asked out of the blue?

For me I like the room to take on board a question and provide a thoughtful response so a question like this out of the blue can throw me. Then I trip myself up because I think I'll sound like I'm lying or have been up to something I can't explain - which is completely irrational. It's then tricky to provide the right amount of detail for the context on the spot.

Trouble is I can't recall seeing someone doing this well. I've noticed that team leads have the same problem but they're almost expected to have too much on their plate. They're also likely to be ones asking the question.

It may also be a sign of too much context switching. Or just getting old - sometimes I can't remember what I've done over the weekend. Or an irrational fear that I'm working on the wrong thing. Part of it is working with people with different communication styles.

Here are a few strategies on providing useful updates I've thought about while writing this article:

  • Signalling intent more often so people don't have to ask for an update.
  • Keeping a progress log - I find it a useful reminder of all the different things I've been doing though I forget to update it.
  • Understanding the intent of the person asking the question.
  • Push back on providing an update straight away and offer to send an email with detailed response.

I'd be interested in hearing yours!

Notes: How Google Makes Managers Awesome

Michelle Donovan discusses Google's data driven approach to discover what makes a great manager.

Checkout the video here: https://youtu.be/QC_PGHkRvTw

How Google Makes Managers Awesome


The first step was to find out who were the best and worst managers using a performance review rating.

This combined team favourability and high performance.

They found that your manager at Google is the single biggest driver of your happiness.

What makes an awesome manager in priority order:

  1. Is a good coach
  2. Empowers team and does not micromanage
  3. Express’s interest/concern for team members’ success and personal wellbeing
  4. Is productive and results orientated
  5. Is a good communicator
  6. Helps with career development
  7. Has a clear vision/strategy for a team
  8. Has important technical skills which help them advise the team

Google ask team to feedback on managers every 6 months. Managers should share and show that the feedback has been heard.

Self awareness through report and making it easy to take action.

Google manager feedback survey

They have an individual contributor track for people who don't want to or aren't effective managers.

Bring your better managers into the training sessions as they can provide a view from experience.

Notes: Level Up: Developing Developers

In Level Up: Developing Developers Melinda Seckington from FutureLearn discusses what we can learn from gaming to help support our devlopers in learning and development.

Checkout the video here: https://youtu.be/18MI6n9hFDI

Experiential learning for developers


  1. Don’t overload new starters
    • Trello onboarding board
  2. Support and guide new starters
    • Provide a mentor
  3. Make it clear what people should focus on
    • Goal setting
    • Learning record
  4. Give people direct and timely feedback
  5. Provide space to learn and reflect from the past
  6. Provide opportunities to apply new skills
    • We need to be the ones to find and offer opportunities for people to spend their training budget
  7. Acknowledge peoples growth
  8. Expose basic competencies and how they are used
    • How are values linked to role?
  9. Allow people to choose their own path
    • Generalise and specialise - frontend/backend - acknowledge skills not covered by labels
  10. Visualise what progression looks like

Notes: Experiential learning for developers

In Experiential learning for developers Allison McMillian provides guidance on facilitating workshops.

Checkout the video here: https://youtu.be/FI-WvXYCmIM

Experiential learning for developers


  • Interactivity is about letting information sink in in a more effective way
  • People may think: “I don’t know enough to be a facilitator for this subject.” But you can all learn together.
  • Learning through reflection on doing


  • Goals - what do you want people to walk away with?
  • Trigger - the thing that they are experiencing and creates the discussion. Not complex but creative. - Discussion - tailor discussion questions to your goal.
  • Conclusion - close the workshop in a thoughtful way.This could be a statement or an action.
  • Supporting material - allow anyone in the future to pick up the workshop and run it themselves. - Materials needed - a list of all the things needed to run the workshop

Allison goes into more details on her blog Workshops for engineers:

  • Get comfortable with silence
  • Ask open ended questions
  • Make sure to call out people who haven’t spoken
  • Keep the discussion on topic but let it flow

Patterns Day

Today I was lucky enough to travel down to Brighton and attend #PatternsDay with a few developers and designers from @AutoTraderLife. It’s a great conference worth attending if you get the chance. Here are a few thoughts/themes from the day:

  • Be reassured no matter how professional and together the design system showcases you see from large companies are they are struggling too. Whether your one person or a team you will still be reacting to changes, fighting fires and trying to convince people over and over.

  • It’s okay to be reactive. Add things when you need them. Personally I need to be a little less “This should have been documented.” And more “It’s okay this hasn’t been documented, but now we need it, I’ll add it.”

  • Every line of content you add to the documentation is another thing for a designer or developer to take on board and think about.

  • Common components and patterns you might pick up from other design systems need to be tested in the context of your website/app/product. Removing a component may increase conversions in one app and have a negative impact another. This has been tested.

  • It’s worth keeping in mind the potential impact on efficiency of components before you add them to the design system.

  • It’s time to move on from using consistency as a crutch to justify a design system. It may not have much of an impact on users as we first thought.

  • You will have the same conversations over and over as you excite colleagues to use a design system and they naturally lose interest as other priorities kick in. Get good at those conversations.

  • The Government Digital Service provide honest reasoning and research into why a component is used or built that way. It reminded me of Architecture Decision Records which is a way of documenting decisions about a codebase and are stored within the codebase itself. Helps with questions like “Why did we pick React for this solution?” especially if person who’s made the decision has left the company.

  • I’d be interested in finding out which companies have gone down the route for separate versions for individual components. I think Financial Times started theirs like that. Means you could release a new version of the component without blocking updates to other components. But then adds complexity with multiple packages.

The conference itself is organised well, has the comfiest seats I’ve sat on at a venue, and free barista coffee. You won’t get lunch but there are plenty of great places to eat. You may find yourself queuing for the toilets though.

Brighton is a lovely city well worth a visit especially when it’s sunny. 😎