People often claim that with Rust code “when it compiles, it works”. Like most programming aphorisms, it is a slight exaggeration. This is not actually a claim that it is impossible to write bugs in Rust. It is not a claim that any program written in Rust is bug free. It is meant as a… Read More »
I see a lot of development advice that assumes the developer is working on a green field application. Many of the tools that “make a developer’s life easier” are also designed mostly for use in creating new applications. Most of my experience as a professional developer (or whichever title you prefer) has been improving and… Read More »
If you work as a developer, you probably spend a large amount of time in your editor. You are adding features, improving tests, looking for bugs, reviewing changes, and otherwise looking at the code. When I started programming, screens were a lot smaller and almost no one had space on their desk for more than… Read More »
Long ago when I began programming, most programs were standalone executables. Back in those days, almost all programs were run from a command line or executed by clicking on an icon on a GUI. This was before the web existed and most people didn’t even have dial-up access. Things are very different today, with many… 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 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 »
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 »
You might wonder if code review is necessary if your team practices pair programming. (Assuming that your team does either code review or pairing.) Pair programming was originally one of the practices pushed by Extreme Programming (XP). The reasoning was pretty straight-forward, if we assume code review produces better outcomes, more frequent code review should… Read More »
It’s time for another post in my intermittent series of Best Practices Gone Bad (BPGB). This time we’ll cover the dark side of the Single Responsibility Principle (SRP). According to Robert Martin: A class should have one, and only one, reason to change. The basic concept is easy. Every object or method should be responsible… Read More »