See it, Say it, Sort it: LJC 22 July 2026
This evening I attended the London Java Community event at CapitalOne.
Jack Bough, a staff engineer at CapitalOne, spoke about ‘Fleeticide’ caused by resource starvation resulting in a failure of a container to respond to health check requests. The resource under contention was not CPU or Memory, but a thread pool.
The example system was using synchronous programming, and so the service thread was blocked while waiting for responses. With a small thread pool, the system was quickly overloaded and couldn’t respond to the health check.
The container system then killed the container, pushing the load onto other containers. Repeat until total annihilation of your deployment.
Jack highlighted how to monitor thread pools as a resource, in addition to the typical CPU and memory, to make the container system scale up the deployment instead.
He also moved the health check onto its own thread pool, so that it couldn’t be starved in the same way. I’m less convinced about this; what if your system is deadlocked, or otherwise not responding to client requests? You will need to ensure your main system threads are regularly updating a resource that the health check can read to know that the system threads are still making progress.
My approach would be to address the reason the threads are being used up: synchronous requests.
Turning the service requests into asynchronous requests allows a single thread to serve multiple client requests - including a health check - at once. A thread is only used when it’s actually doing work.
The next talk was by Melinda Seckington, titled ‘See it, Say it, Sort it: How to be more proactive’.
Melinda presented an easy to remember (for Londoners1, at least) framework for how to “be more productive” — a common piece of feedback.
See it: be aware of what’s happening and recognise when there are problems or areas for improvement. Identify the wider context for the situation.
Say it: raise it with someone. Your team, your manager, the company. Get a discussion going.
Sort it: take ownership. Make sure the work gets done.
I asked what teams or managers can do to help promote this culture of productivity. Melinda suggested that directly asking those who have been quieter in a meeting is often fruitful in getting people into the second step of ‘Say it’.
Following up with ‘What do you think we should do about it?’ can get us moving into the ‘Sort it’ step. This is a technique I’ll try to be conscious of using in my own meetings.
Another interesting question was ‘Can someone be too proactive?’
It’s a trait I might see in an eager junior developer. They have lots of suggestions, but it typically results in eye rolls.
Melinda again gave a great answer: what do we actually mean when someone is too proactive?
Melinda pointed out that this is an indicator that the person isn’t moving into the final step. They don’t propose a solution, and don’t move forward with it. Encourage the engineer to take one of their suggestions through a discussion with the team, evaluate its impact vs cost, and – if there is buy-in – implement.