Browse all posts in this category
The production database went down on Friday at 6pm. The post-mortem was held on Monday. In the write-up: five process improvement points, three technical remediation actions, and a discreet mention that 'the incident was caused by human error during migration.' That sentence is the opposite of a blameless post-mortem.
If your team spends more time debating monorepo vs polyrepo than writing code, that is a sign the debate is framed wrong. Both approaches work. The real question is: which structure fits your organization and your delivery cycle?
Your codebase has 47 active feature flags. Five are documented. Three are tied to features shipped nine months ago and no one thought to remove them. Two conflict with each other: enabling both at the same time produces undefined behavior. You have just discovered why feature flags are not free.
The team spent three weeks modeling the bounded contexts, aggregates, and domain events of their content management application. The application does CRUD on five tables. That is the sign that DDD is being used as an end in itself, not as a tool.
"We need a technical debt sprint." This phrase is spoken in hundreds of teams every quarter. What happens next: two weeks of refactoring without clear direction, whose value is impossible to communicate to management, and which doesn't fundamentally change the most painful problems.
How many days does a new developer spend trying to get the project running locally before they can actually contribute? In most teams, the answer is somewhere between two and ten days. The onboarding documentation exists - it's just wrong.
How many times have you seen a release turn into a catch-all of half-finished features, last-minute fixes, and tickets migrated from three previous sprints? The release has lost its meaning because it is only used as a delivery container, not as a management tool.
There is no other profession where foundational knowledge expires as fast as in software development. This reality generates a particular state of mind: a mix of chronic FOMO and genuine helplessness. Here is how to get out of it.
Working with AI promises a miracle: develop faster. And it’s true. Code lines write themselves more quickly, features take shape in hours instead of days. But this promise hides an invisible price, often ignored or minimized: the progressive loss of mastery.
We celebrate the speed gain. Five features written in a week instead of three—that’s measurable. Quantifiable. But how do you measure the loss of mastery? How do you account for what you no longer truly understand?
