Technical debt is the work we don't do when we build and maintain software. In a world filled with tradeoffs, technical debt is a tool to descope projects to stay on budget and schedule. Technical debt can get projects to the finish line but like any other form of debt - can be crippling in the long term. How do you recognize technical debt? How can you ensure that it doesn't ultimately undermine its intent?

There are great projects. You can go to the moon. You can build a house. You can write a novel. Completing a project does not mean that there is a product.

The code review is a long-established "first line of defense" so that engineering teams don't unleash hell upon the world. Years ago, the code review literally was a developer printing out their code, handing it to a senior engineer, and having it marked up with red pen like it was a college essay. The code review has come a long way - it has been established part of development workflows everywhere largely because of the pull request feature at GitHub. Code reviews were part of the job description for senior developers and development managers everywhere - a pedagogical function that promoted stewardship over a code base. But that was then. It's time to pour one out for the code review.

I spent two years between WebMD and Vitals taking on a monster for the business - optimizing for organic traffic. Once I sorted through a lot of the misunderstandings in the organization, the paranoia, and the downright hopelessness - I presented the business with one option to fix their issues with organic acquisition: make Vitals a better experience for users.

The Chief Technology Officer. The maker of things. The knower of stuff. The solver of problems. The guy who probably has to fix their parents computer each Thanksgiving. But how often should they be coding?

My wife and I were loyal, sheepish players of Alexa's Jeopardy game. Every weeknight like the moths to flame that we are, we would flock to our Amazon device (well, an Alexa-enabled Sonos actually) and commanded Alexa "Play Jeopardy!"

The Scrum Master - a mainstay in Agile culture, particularly Scrum. Heralded by consulting firms, conferred certificates by training academies - here's why you don't need a Scrum Master and why if you have one, they are hurting your agile efforts.

Waterfall. Scrum. Spiral. RAD. XP. Software methodologies are plentiful, all in an effort to make it so that timelines and budgets are predictable. They are an attempt to create repetition and commonality within software development. But they are a lie.

In a place far away and long ago, teams used to be asked "when will this be done?" which at some point go confused with "how much time will this take to finish?" Business stakeholders and software engineers - forever separated by semantics and the inability to communicate were united by consultants who came up with an abstraction: story points. Ever since, we have been in hell.