The things I'd tell you on day one.
If we were starting a project together, these are the beliefs that would shape every decision I make. They come from real systems, real failures, and real wins.
Don't Tell Me You Can't Do It Unless You Can Tell Me Why
If you can explain why something can't be done, you usually understand it well enough to find a path through. The inability to articulate the blocker is often the actual blocker. It leads to understanding and collaboration.
The right abstraction at the wrong time is still the wrong abstraction.
xremature generalization is its own form of technical debt. Building for flexibility before you know the shape of the problem creates layers nobody understands and nobody asked for.
You can delegate a task. You can't delegate the outcome.
Engineers can own a ticket. Leads can own a sprint. But the outcome of what ships — the quality, the reliability, the user experience — that stays with the manager. Delegation is a tool, not a transfer of accountability.
Scaling buys time, but it is not fix
Scaling feels decisive, but it can simply buy time while the actual issue keeps operating underneath.
Over-fetching can make the database look guilty when it is not.
The DB was doing exactly what it was told. The problem was the query pattern, not the infrastructure.
Not all technical debt should be paid at once.
Some debt creates blast radius. Some just creates drag. Fixing drag debt first feels productive — and it is, until you realize the blast radius debt has now accrued interest into a migration. Debt sequencing matters as much as debt reduction.
Addressing underperformance is an act of respect.
Avoiding a hard conversation doesn't protect anyone. It signals to the rest of the team that standards are negotiable, and it robs the individual of the clarity they need to actually improve or make a decision.
Clean code that ships never is still just a draft.
Perfect architecture that never gets deployed solves nothing. Iteration beats perfection.