How I work out tricky problems
Weekly roundup for the 14th of May 2026
First off, I want to start by saying that I'm changing the format of my weekly roundups. I was getting a bit fed up of having to think of three things I'd learned in a week, every single week, so I'm whittling it down to just one thing and I'm going to try and write about it in a bit more detail. This does leave me with the interesting problem that I often learn useful little bits and pieces that I'd love to share, so I'll try and think of ways to capture that content too. Maybe I'll just post those bits direct on my Bluesky rather than trying to figure out how to make them into longer posts.
For today though, I wanted to talk about how I approach figuring out a problem when it isn't very clearly defined or I simply don't know what I'm doing (which happens more than you think!). This week, I have been looking into adding Tanstack Query to our repo and given it isn't a technology I've used before and the area I am looking into adding it to was unknown to me and fairly complex, it was a perfect example for this week's roundup.
I'm not saying this is how everyone should solve problems, but it's how I do it, so I thought I'd share in case it resonates with anyone or gives you some ideas for your own process.
Start a document
Whenever I start working on something and there are a lot of unknowns or I'm not even clear what I'm supposed to do, I start a document. Although this document is largely for my own purposes, I often find that they end up being useful for others too and that they get shared around the team when they need to know about a feature I built or a problem I solved.
This document is almost a way of rubber ducking with myself, because I'll write out what I know so far, what questions I have, what things I need to look into further etc. Just by writing these out, it gets things out of my brain and onto the page, meaning I free up space to work on the next step. Basically, this whole process gets my brain going which means I can start pulling at threads and investigating areas I've identified as important.
I usually start with a Context section as if this is a document for other people - this explains the what and the why (and sometimes the when i.e. "why now"). For example, in the case of adding Tanstack Query to the repo, it could be "This document investigates what is required to add Tanstack Query to the repo because the team would like to be able to use some external components that use this technology under the hood. This will unblock requests from stakeholders to improve the way data is visualised for customers." This is just an example and not what I wrote in my actual document this week, but hopefully it gives you an idea of what I mean.
It might seem pointless to write this out, given this is a document for your own personal use, but I find that defining the context often gets me in the right headspace to start thinking about the problem. It also gets me out of the weeds and forces me to think about the problem holistically - we're not just adding a new technology, we're doing it for a specific purpose that serves our users.
Write down everything you know...
Once I've written down the context and made sure I understand what problem we're solving and why, I start writing down everything I know about the problem so far. So in the example of Tanstack Query, it would be things like:
Where this needs to be added
What new components will be pulled in
What the current setup is
Just thinking about the things I do know will highlight the things I don't, which is the more intimidating part.
This may seem like repeating the information in the ticket for the work and you're probably right, but I find that just writing this stuff out and expanding on it so that I deeply understand what I need to do will get the juices going and stop me from feeling overwhelmed.
...And everything you don't
As I write out everything I do know about the work, questions will naturally arise, so I make a note of them. Rather than going down rabbit holes and investigating things as they come up, I write down the question and carry on pulling on the thread I'm currently on. This stops me from context switching too much and ending up not doing anything.
Start playing with the code
As I'm writing this document, I will for sure be playing with the code. I often find that looking at what I'm supposed to be working on and doing some refactoring (there's usually something that can be tidied up!) will get me into the right headspace.
I might then start having a go at implementing what I'm supposed to be implementing, but only roughly, just to see what further unknowns and blockers there are.
Make a plan
Once I've got a firm idea of what I'm supposed to be doing, if the work is big enough, I might make a plan. This all goes into the original document I started. It means that I can come back to this at a later date if I get pulled onto something else and quickly remind myself of what I'd decided to do. It also an invaluable resource for colleagues - if you end up pairing on this work your colleague will thank you for the information.
In some cases, I'll create tickets to chunk up the work and make it easier to work on and share out to the rest of the team, but sometimes the work isn't big or complex enough. This is very much an "it depends" kind of situation.
Implement it!
Only then will I start putting PRs up for review. I know this seems long-winded, but it's a process that has worked well for me. I've been bitten far too many times in the past by just jumping into the code and trying to figure this stuff out on the go - it usually ends up in a mess and a panic as the deadline approaches.
Does AI come into this?
I will sometimes use AI as part of this process - certainly I'll ask an agent to explain the existing code to me if I haven't seen it before and it's complex enough for me not to understand it straight away. It also very much depends on what access you have to AI - if all your docs are in a platform with an AI tool, you might want to ask it to see if there are any existing documents in the same area you're already looking. I found Notion AI particularly good for this.
