The code is just the output. Planning is the full job.

"A house full of windows, totally symmetrical, light coming through evenly. That doesn't happen by accident. Someone planned every detail before a single brick was laid. The beauty of the output is just evidence of the discipline that came before it. Code works the same way."

Great engineering doesn't only consist of delivering code. As AI completely revolutionises the industry, taking us to places we've never been, there's one thing that won't change: planning. Planning before, during and after software gets delivered. Great engineering is both great code and well-written tasks, structured channel threads, status updates, and transparency. It's the backbone of good engineering. Planning isn't just about efficiency either, but because shipping something we don't understand is a form of carelessness. The outcome is important, but the commitment to doing the work properly is equally as important.

First comes understanding.

The most expensive bugs aren't the ones that appear in production out of nowhere. They're the ones where we build the wrong thing. Before even thinking about implementing, I've made it a habit of fully understanding what needs to be done. Mapping out requirements, which then turn into acceptance criteria.

"No structure has ever been built without scaffolding."

This first phase is where most future mistakes can be cheaply solved. It's where I gather all the evidence to know which direction my code will take. This doesn't have to mean long meetings. A quick alignment conversation before starting a task can save multiple hours of rework. While planning sometimes feels like a delay, or adding extra hours to a task, it's actually the opposite. It's the fastest path to shipping the right thing, in the right direction.

The best tool to build trust is transparency.

Planning doesn't stop when implementation starts. As soon as we're executing a plan to implement something like a new feature, we keep gathering information that needs to be assessed as it comes. What if the API doesn't work as we thought? Or the scope is larger than it looked? Or there are bugs to fix before taking on a new task. All of this context is data, information that shouldn't live only in my head.

Sharing updates and progress with the whole team gives the people around us the information they might need to do their jobs well. Saying something like "I've feature-completed what I'm working on, now fixing a couple of edge cases" does more than it seems. It removes uncertainty, surfaces potential unseen blockers. But most importantly, it builds a kind of trust that's extremely valuable.

Transparency gets built in the open.

Discussing a problem in a direct message makes it impossible for the rest of the team to know what's going on. Decisions made in DMs don't leave a record. Other engineers and team members get cut out entirely. What if someone had that problem before? What if someone needs this context a few days from now?

Moving all technical discussions into open forums like team-wide channels is one of the most valuable habits a team can build. It creates a living record of decision-making, a git tree of conversations. It encourages unexpected perspectives. Junior developers learn how senior developers think through problems. Open communication accelerates learning, reduces duplicated effort, and sets the foundation for a team to function as a unit rather than a group of individuals.

Working on software might seem intangible, but it isn't.

There's nothing more demoralising than a day that disappears without a trace, and this is very common in software teams. Every day should have tasks with a start, implementation time, and an end. Even if they're small. Tracking work, in whatever form it takes, turns effort into evidence. It doesn't have to be complex or take long to organise. It transforms "yesterday I was working on the same feature all day" into a clean record of what moved forward. Vague statements become tangible evidence of what has evolved and delivered value.

At the end of the day, after leaving a record of what I've achieved, I can feel the weight of what got done. Software development involves a lot of invisible effort, tracking every step gives shape to that effort. It also makes planning the next day or week easier, because you know exactly where you left off.

The hardest part of building software isn't the code itself. It's misunderstood requirements, unclear directions, miscommunications, and those almost always result in technical problems down the line. The code is only the output.