Hal fixing a light bulb (from Malcolm in the Middle S03E06 - Health Scare)

This short scene from Malcolm in the Middle is the best explanation I've found of ADHD as an adult: [this video] He tries to turn on the light, the bulb is dead, unscrews it, then as he's getting the bulb the shelf in the cabinet it's in is loose. He gets a screwdriver to fix the cabinet, but the rails on the drawer the screwdriver's in are squeaky. He gets some WD-40 to fix that, but the can of WD-40 is empty. He then gets in the car, which refuses to start. Then his wife gets home, and he's underneath the car covered in motor oil. "Hal, did you replace that light bulb in the kitchen?" "WHAT DOES IT LOOK LIKE I'M DOING?!".

Find out their frame of reference, look for comparable concepts in the real world. For technical debt, this scene from Malcolm in the Middle (S03E06) [this video] might be a good comparison. If you refuse to explain relevant concepts to your PM, as a neighbouring commentor suggests, that increases the knowledge gap between you (or your team) and the PM. I think it's in the best interest of both the team and the PM that they have a shared understanding of what happens within a project. On the other hand, if the PM is not interested in any of those details, that is a sign that they might not be a good fit in that part of the organisation.

> I've often thought about that when there's a work crisis: If I'm the second on the scene, what can I do to support those fighting the fire right now, before jumping in. A lot of it depends on the size and skill-set of your team and the escalation routes available to you, but in general (and off the top of my head): - Get the first people on scene to give a summary of the problem as they know it. Make sure everyone actually agrees on what the problem is and what symptoms have been observed. Understand what areas people are currently investigating and make sure they aren't trampling over each other or actually making the situation worse [1] - Make sure the situation hasn't evolved whilst the first on scene have been investigating the initial symptoms. It's easy to get lost in the weeds digging into a handful of monitoring alerts only to look up and realise there's now 300 and the original problem is only a small part of what's going on. - If there isn't one already and you're not better doing something else, become incident commander. When done right it's an extremely important and useful role. - Take over external communication and protect the team from distractions - Start assessing escalation options - Take copious notes and keep a timeline - Act as a shared memory and keep people honest - Have a less panicked, wider (non minutia) view of the problem - Start collating and pulling up documentation/schematics so the people at the coalface can quickly query it rather than get

We started with plain Docker Compose files (one container for our project, others for DB, Spark, Airflow, etc.). For more experienced, full-time developers this setup was good enough (though it required a few extra steps after `docker compose up`). But it still showed significant friction for (a) very junior developers (b) non technical business people who wanted to code. Generally the same folks that would need help installing PostGIS on their machines, etc. People just wanted to merge some cool ideas into our codebases and now they needed to learn wtf Docker and Docker Compose are[1]. That was a huge time waster. Devcontainers are neatly integrated into VS Code's UI, so they solved the "last mile" problem of allowing non-tech folks to use containers. [1] [this video]