Ancient Stoic Wisdom for Writing Better Software

My time at a software company has shown me how much focus there is on the new: new smartphone and laptop models, new revs, new development boards, new languages, and so on. But what about the old? I’m talking really old, like “two millennia before the Unix-Epoch” old.

The Stoic philosophers Zeno of Citium, Epictetus, and Seneca spoke at length about logic, control, and truth–all terms we discuss as programmers, but with very different meanings and applications. Still, Stoic works have lasted for thousands of years. What lessons do the ancient Greeks have for an industry with an obsession for the newest, latest thing?
Read more on Ancient Stoic Wisdom for Writing Better Software…

Three Attitudes that Lead to Maintainable Code

When writing code, there are many specific principles that aim to make your code more maintainable: DRY, the single responsibility principle, the Law of Demeter, the open/closed principle, etc. These are great principles to follow, but it can be difficult to keep all of them in your head at once. I’ve found it’s often easier to keep a few broader ideas in mind. Read more on Three Attitudes that Lead to Maintainable Code…

Diagrams as Software Documentation – When a Picture Says it Best

Software documentation is all too frequently overlooked or becomes irrelevant, lost in the inevitable wave of change. Accurate documentation requires not only thought and execution, but maintenance, as reality changes.

One form of documentation that is too frequently overlooked is a diagram. Read more on Diagrams as Software Documentation – When a Picture Says it Best…

Debugging Techniques: #1 Break the System into Small Pieces

My PC wouldn’t boot, didn’t even make a sound. I traced the problem down to a particular mounting screw, but there was nothing to indicate that this screw was problematic. It was a perfectly fine screw, correctly installed in the right place. How did I figure this out? Debugging!
Read more on Debugging Techniques: #1 Break the System into Small Pieces…

Security Hygiene for Software Professionals

As software makers, we face a unique threat model. The computers or accounts we use to develop and deliver software are of more value to an attacker than what ordinary computer users have—cloud service keys can be stolen and used for profit, and the software we ship can be loaded with malware without our knowledge. And that’s before we consider that the code we write has a tremendous value of its own and should be protected.

Padlock by Moyan Brenn. Used with permission under CC BY 2.0.

Taking responsibility for our security hygiene is, thankfully, not very difficult. Today, most tools we need are either already present in our operating systems or can be added without much effort. In this post, I’ll take you down a list of things you should consider.
Read more on Security Hygiene for Software Professionals…

Three Tips to Make Your Next Dependency Upgrade Easier

Over time, even well-managed web apps can see their dependencies fall behind. The JavaScript community moves fast, and if you don’t stay on top of it, you can wind up with a package.json from the stone ages (two months ago). A few weeks ago, my team upgraded an aging Ember 1.13 app to Ember 2.10. Here are three tips to help make your dependency upgrade process go smoother than ours. Read more on Three Tips to Make Your Next Dependency Upgrade Easier…

Retrospective: “Building a Virtual Appliance – Repeatably”

A few years back, I wrote a post describing how we used Chef and other tools to build a virtual machine “appliance.”

The short version is that we tried to make a copy of everything we were installing so that if we needed to make a point release later, we’d be able to reproduce the build. We made sure that we mirrored all external dependencies, downloaded all the RPMs, and kept the DVD ISOs around.

It’s been a few years now, and I had cause to go back to it. Spoiler: It didn’t really work. Read more on Retrospective: “Building a Virtual Appliance – Repeatably”…

Your Logs Should Be Considered Features, Too

Sometimes, printing things out is the simplest debugging technique we can use. And then, when we forget to take the print statements out, we call the output our logs.

That’s a mistake. Logging shouldn’t be an afterthought. It’s a core piece of diagnostic tooling. Logs are so cheap to integrate that they are almost always an extremely high return-on-investment feature. Your logs should be treated as first-class features warranting all of the attention to detail that you give to your more user-visible features.
Read more on Your Logs Should Be Considered Features, Too…

Functions and the Single Responsibility Principle

You’re most likely familiar with the Single Responsibility Principle (SRP)-it’s the S in the SOLID acronym and a cornerstone of many folks’ object-oriented software design guidelines.

If you’re like me though, you’ve pretty much always heard SRP discussed in relation to modules or classes. I had started thinking in an SRP way when writing Clojure functions, but I hadn’t made the mental connection until I read Bob Martin’s recommendation in his Clean Code book.
Read more on Functions and the Single Responsibility Principle…