Clean Agile: Back to BasicsRobert C. MartinPrentice Hall, 2019 Bob Martin begins this book by describing it as his personal recollections, rather than a work of research. He starts by pointing out that agile software development started as a way of describing what had worked for some small development teams working on reasonably small projects.… Read More »
In a previous post, I spoke a bit about why to you might want to learn vim. Despite the fact that I prefer vim as my programming editor, I would never argue that everyone should use it. For some of people, vim meshes with the way they think. In my case, it wasn’t an immediate… Read More »
The writing of standalone tools is an underappreciated part of software development.
I realize that the title of this post is likely to generate a lot of noise, but it’s a subject I have been thinking about for much of the last two decades. Over ten years ago, I wrote a post questioning the everything is an object approach several languages seemed to be taking. That post… Read More »
I recently ran across the article Why use Vim: Forget easy-to-use design. Choose something hard instead — Quartz. This article suggests that you should learn to use the vim editor because it’s hard. Although I do think most developers would benefit from using an editor like vim, I feel like the because it’s hard advice… Read More »
Long ago, I posted a short note On Proficiency where I noted four things I believed were needed to become proficient at an activity: aptitude, interest, knowledge, and skills. My experience learning software development took a different route than many developers today. I started development in very small teams (1-2 developers). I had actually been… Read More »
I’ve spent a fair portion of my career teaching and mentoring other programmers. Some of this training involves covering basic programming and design concepts that they may not have learned previously. When covering a fundamental concept, I often defer to books written by people much smarter than I am rather than explain the concept myself.… Read More »
In previous posts, I’ve talked about the importance of naming to make it easier for whoever maintains the code. One thing I’ve left out is the importance of not misusing standard names. Naming Fail In a previous position, I was manipulating a collection of data, when I hit a bug. After running some new code,… Read More »
No matter how careful your testing, no matter how complete your review, there is a non-zero probability that releasing your new code will expose a problem. The last phase of risk management is handling a risk that actually manifests. At the end of the last post, I mentioned the importance of post-release testing and an… Read More »
You’ve carefully assessed the risks in your new system. You’ve considered the implementation and eliminated bad implementation decisions and removed unnecessary features that involved extra risk. Considering the result, you note that there is still risk. So, what do you do? You try to mitigate the remaining risk. Risk mitigation does not remove the risk… Read More »