This post was edited by Taavi Kivisik A reader recently sent me this question: I'm getting quite serious with programming. I finished reading Clean Code and am doing a course about design patterns, nerding out on Node.js, etc. I have to say it's quite amazing to realize the level of sophistication and effort involved to make quality software. It makes me really appreciative working with engineers who are capable of working on that level.

Edited by Taavi Kivisik Happy New Year to everyone! I was excited to kickstart the new year with a new position at Lana, a Spanish FinTech startup. As part of my first week on the job, I met a candidate for another position there, and we started talking about controversial opinions in IT. Unfortunately, we found nothing to disagree about. Although I was inspired to catalog a number of my own personal opinions about software development, which may be more controversial.

Conventional wisdom tells us that an automated test pipeline is the necessary first piece to Continuous Deployment. I challenge that thinking.

There is a lot of variety when it comes to Continuous Integration and Continuous Deployment (CI/CD) configurations. But I am constantly amazed by how many projects fail to even implement the absolute minimum CI configuration. In this article, I outline what I believe to be the absolute, bare minimum automated continuous integration tests that should exist on practically every project. These are table stakes. You ought to be embarrassed if your project doesn’t do these things.

How often do you find some code like this in your production code base? form.submit(function(event) { console.log("Submit hit"); var formData = { It’s obvious case of stray debugging code that never got cleaned up during code review. Or have you ever seen something like this, perhaps in your CI config? script: # - npm install # - npm test - ./script/test.sh This one is especially dangerous. It appears that someone commented out the core functionality of the automated test stage of CI!

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.

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.

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.”

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.