Solve Every Problem Twice
One habit that I think every software developer, if not practically every professional in any field, can benefit from is that of solving every problem twice. Watch my video on this topic, too! I remember first reading about a similar concept in Joel Spolsky’s blog, Joel on Software, where he wrote back in 2007: Fix everything two ways Almost every tech support problem has two solutions. The superficial and immediate solution is just to solve the customer’s problem.
5 Reasons for Code Review
In my programming practice, peer code review has become such second nature to me that it’s sometimes a challenge to articulate why I think it is important. I was recently asked this question, which forced me to think about it, and so now I want to put it into writing, lest I forget my answers. It’s just to reduce bugs, right? Before I jump into the list proper, let me address what I believe is a common misconception about code review.
How to use GitLab-CI with a GitHub-hosted repository
Watch my video on this topic, too! In response to my previous article, Solo DevOps, a reader asked me to recommend a Continuous Integration (CI) tool to use with GitHub-hosted repositories. My choice is GitLab-CI, which integrates nicely with GitHub, even if you don’t want to switch to GitLab entirely. In this post, I walk through configuring GitLab-CI for a GitHub-hosted repository. I have chosen one of my real repositories, github.
I’ve been thinking a lot lately about how DevOps scales. DevOps, and related practices, get a lot of attention when it comes to scaling up at large organizations like Google and Netflix. But what about the other extreme of very small teams? This is a list of DevOps practices I use on the tiny scale: Solo projects. While most of these practices offer an immediate benefit, even for a single-person team, in most cases, the benefit grows as the team grows.
You’re building a complex piece of software. Then it comes time to deploy, so you spend a couple weeks stuffing it into a Docker container or a .deb or .rpm package, and debugging the build and deployment process. Then you add some sort of monitoring or logging, set up email or SMS alerts to tell you when it crashes, and probably a dozen other things to make it “production ready.”
Automated Testing False Dichotomy #2: All vs None
This is the second installment in my series The False Dichotomies of Automated Testing. If you’ve ever met a recent test convert, you’ve probably heard them talk about the mythical creature that is “100% test coverage.” As with most benevolent mythical creatures, this one is highly sought after, and possibly even worshiped. It is claimed to have magical powers, although the precise nature of these powers is often hotly debated even among the most ardent of believers.
The False Dichotomies of Automated Testing
This is the first in a series of posts about automated testing for software developers. I’ve been fascinated by this thing called “programming” since I first learned I could enter BASIC programs into my family’s Commodore 64 when I was 8 years old. I became a full-time software developer in 2006. And I “got religion” about automated tests shortly after that. But still not everyone is as “enlightened” as I am when it comes to writing automated tests.
Unsure? Browse the archive.
Where are the domain experts?
A couple of weeks ago I made a comment to my team at work which I think a couple took harshly, but I believe it is true, and an indication of a deeper problem. I said “All of the really smart people at this company move to the ‘infrastructure’ teams within a few years, which means we have only new, untrained people writing the real software.” Today, on a flight back home from vacation in Oslo, I was reading Domain-Driven Design by Eric Evans, and once again I found myself taken aback by how precisely this book has described my work place–and not in a good way!
One thing I miss about unit tests: Unit tests as Documentation
I wrote this post in October of 2015 as I was adjusting to life without unit tests at a new job. I recently stumbled upon it in my Drafts, and edited it down to a single point for publication. In October of last year I took a new job at a company with a large group of programmers, and an old (15+ years) code base. The new company doesn’t generally do unit tests, for various historical reasons, none of which make much sense upon close examination.
How to learn REST: A resource guide
I have a new software project in mind. I want to do it right. So I’ll use a RESTful web API. Which, of course, like any good software developer, I already understood pretty well, but I wanted to just brush up on my REST game, and make sure I got all the best practices down. Thus began my search on Amazon for a good book about REST. I found one. I read it.