In the last few months every engineer I hired stumbled in exactly the same way: Project management. They learned quickly, but that first big project has become a right of passage.

Swizec's platform provides resources for developers, covering a diverse range of topics such as programming languages, web development frameworks, data visualization techniques, and software engineering best practices. Through tutorials, guides, and coding challenges, Swizec offers hands-on learning experiences and practical insights for developers at all skill levels. Readers can explore  technologies, industry trends, and software development methodologies to enhance their technical proficiency and advance their careers in the tech industry. Additionally, Swizec shares personal anecdotes, career advice, and productivity tips to inspire and motivate aspiring developers on their journey of continuous learning and professional growth.

swizec.com

Experienced engineers consistently struggle with project management when given autonomy. The core mistake is breaking projects into horizontal slices (models → API → UI → tests) instead of vertical slices that deliver end-to-end user value at each step. Horizontal slices produce unshippable intermediate states, delay feedback, and lead to massive pull requests stuck in review. Vertical slices let you ship to production at every step, gather real user feedback early, and course-correct before investing weeks in the wrong direction. The author also emphasizes defining a crisp 'definition of done' in terms of user outcomes before writing any code.

The one thing every experienced engineer gets wrong

I totally agree, and I think horizontal slicing is inherited from the org structure. It seeped into engineering and became a habit.
Now with AI one person can execute the vertical slice. I do this everyday with my coding agent, I have an orchestration running multiple sub agents from coding to UI to UX, so the execution itself got cheap.
But that created a new challenge: the accountability for the outcome also collapsed into that one person. Before, accountability was split among the multiple roles.

This isn’t a new idea and, believe it or not, it’s something I, as an experienced engineer, wholeheartedly agree with, and practice when I can. It’s called Lean.
I say “when I can,” because I’m on a team porting legacy code. If it’s the first day porting a feature, it’s simply not worth it to put it in production that day. That doesn’t mean I won’t, or can’t… it just means I can’t always see what the code is doing if it were in production. And I’m not talking about simple crud views here; I’m referring to complex business logic, or our most recent “report engine” which is ~250k lines of code and required a lot of “structure” before I could even begin routing my own local requests to it.
All that said, I commit code daily or as close as possible when working on this sort of stuff. But the dream is “something new” where even a sketch, shown to a user, would be an early day-one goal.

The tell is simple: if your first production-shippable increment is weeks out, you sliced horizontally. Vertical slices force you through every layer thin on day one, which front-loads the integration risk — and integration is almost always where the real surprises live, not in the models. Horizontal slicing feels productive because each layer looks done, but you’ve just deferred all the risk to the end where it’s most expensive to fix.

Not developers get that wrong. A lot of them know. Believe me.
Anti agile organization don’t know. It’s a sign of a non agile organization, no matter if they call themselves agile or not.

I’m a backend developer, but due to this AI, I’m coding UI, mobile apps, and doing deployments too. idk how many days we have to follow this unclear path.