We (software developers) write astounding amounts of worthless software. I find it hard to fathom just how much junk we are producing. As someone who spends a fair bit deal of time thinking and writing about how to be a 10x programmer and effectiveness, I believe we have lots of room for improvement here. In this post, I’m going to examine the problem of worthless software and what you can do about it.
Tag: Code Quality (Page 2 of 2)
There are hundreds, if not thousands, of articles about how to pay down your technical debt and most of them miss step one. They don’t tell you how to make the time to repay your technical debt. It’s unlikely that you’ll be able to convince management to let you stop working on features and bug fixes to repay your technical debt for long enough to truly make a difference. And since it’s always hard to quantify the impact of repaying technical debt, it rarely gets to the top of anyone’s backlog. Well, I’m going show you how to get around this problem.
Technical debt as a metaphor is not serving our profession well. It was meant to help us talk to business people and make better decisions about our software projects. But it has largely been a failure. Part of the problem is that business people aren’t afraid of future interest payments.
In business school, I learned about the power of leverage: what it is, how to get it, how to measure it, and how to manage it. Debt is a tool. My fellow business school grads are comfortable with leverage and debt. So when the programmers come to the business people complaining about technical debt, the business people are unconcerned. And why would they be? The metaphor is misleading; technical debt is only superficially similar to financial debt.
My team uses a code review checklist to prevent stupid mistakes from causing us problems and wasting time. In this post, I want to share the reasons we decided to implement a code review checklist, what’s on our checklist, how we created, use, and improve our checklist, and how it’s improved our effectiveness.
Every team has an optimal pull request size, it’s likely much smaller than you think, and making your pull requests your optimal size will improve the performance of your team. I’m going to convince you that these three statements are true by the end of this post.
Robert C. Martin (Uncle Bob) has been banging on the “software professionalism” drum for years and I’ve been nodding my head every with every beat. As a profession, I believe software developers need to up their game big time. However, I’ve become concerned about Uncle Bob’s approach. I reached my breaking point the other day when I read his blog post titled Tools are not the Answer.