After college, I spent a year working with my dad at Labco Welding, where he finished his career as a precision sheet metal mechanic. Before that he had worked at Pratt & Whitney and New Britain Machine — so by the time I showed up, he had decades of experience in precision work.
Here’s what stuck with me:
- His tools were always within reach.
- His plans were taped to the bench, not tucked in an office.
- If something didn’t match the drawing, he updated the schematic on the spot so nobody repeated the same mistake.
At the time, I thought that was just “shop discipline.” Years later, as a software developer, I realized it’s a principle we constantly ignore.
We leave our “plans” (tickets, tasks, decisions) in Jira, Trello, or some detached system. The code lives here, the context lives there — and we lose flow jumping between them.
That’s why I’ve been working on something I call Context Driven Development (CDD).
- Keep the tasks with the code.
- Update the “schematic” (task, doc, or note) right where the work happens.
- Make it so the next person — whether it’s a teammate or AI like Copilot — has the real context, not just the theory.
I’ve been building Imdone to help with exactly this. It lets you sync Jira issues into your project folder as markdown files, so developers can update them right in their IDE, side-by-side with the code. Comments and attachments stay in sync too.
For me, it’s like taping the plan to the bench the way my dad did — context is never out of reach.
💬 I’m curious: how do you and your team keep context close at hand? Do you update docs/tasks in the repo, or does everything live in Jira?
Top comments (4)
I went a step further by creating a git forge based entirely on this concept. gitroot.dev integrate issues but also grafts (pull/merge-request), boards... All is just aside your code ;)
Please note that it is still in alpha!
Very cool!
Great article. The analogy with your dad's workshop really drives the point home.
The cost of context switching is definitely real. Keeping the "why" (the ticket) right next to the "how" (the code) is a very practical solution to this. It basically acts as a permanent, high-context comment for any future developer.
Thanks! Glad to hear my story resonated with you.