I’m sure you spend a lot of time thinking about how to write better software just like I do. And if you’ve dipped your toes into the waters of unit testing best practices, you will have undoubtedly asked this question at some point: how simple is too simple to test?
Tag: Software Engineering (Page 2 of 3)
So, if you’re reading this it means you’re involved in a software project that’s a steaming mess and you want to explore your options. Don’t be embarrassed. This is a safe place; we’ve all googled “rewrite vs refactor” at some point.
The problem is that our profession is long on opinions and short on evidence for what to do with troubled projects. And the opinions we have are all over the map. So, it’s hard to know what you should believe.
In this post, I’m going simplify things for you and help you navigate the rewrite vs refactor debate.
Learning a new language takes a long time. Unless you need it for your job (or a personal project that’s important to you), it’s a bad investment. In this post, I’m going to show you why “learn at least one new language every year” is bad advice and what you should do instead.
As software developers, we are doing a terrible job of protecting the data we collect from our users because software security is hopelessly broken. This is a huge topic so I’ll restrict my comments to coding, encryption/hashing, web server configurations, regulation, and what we can do about the security of the software we create and maintain.
In this post, I’m going to share some of the books I read this year. In the nonfiction realm, some of them are very much on point for software developers. Others are just good books that let you know what’s going on in the world.
In fiction, I’m drawn to technology-driven Sci-Fi. I found some great reads this year. I also listed some books at the bottom of this post that weren’t that good. I think it’s just as important to tell you about the good books as the not so good books.
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.
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.