Every year I try to take a short inventory of the books I read through that year. I find that doing so helps me solidify the concrete things I learned from each. You can see last year’s list too if you would like.

Let’s jump right in.

Crime and Punishment cover image
Crime and Punishment cover image

Crime and Punishment by Fyodor Dostoyevsky

One of the classics, Crime and Punishment takes us through the minds of several Russians in St. Petersburg following a brutal murder. We explore the psychological and relational consequences of murder, the motivations for it, and how society plays into all of it. …


Image for post
Image for post
Photo by Vincent Tom on Unsplash

I remember my first code review as a software engineer. I was pretty nervous about opening the link in the email saying my code review was complete. I was afraid to look at the feedback.

I’d never had my code formally reviewed before. In my undergraduate days, we just kinda made sure each other’s code was “good” — whatever that meant.

When I entered into my first full-time role, I learned that code reviews were a common part of ensuring code quality. Often done via pull requests, developers were encouraged to provide feedback on how to improve code and validate its correctness before merging code to the mainline. The core intention was to keep a high-quality codebase. …


Image for post
Image for post
Photo by Portuguese Gravity on Unsplash

Let’s face it: giving feedback is hard.

You want to help that teammate improve their coding skills. You want to tell your manager you feel like they don’t listen when you share an idea. You want to help the newcomer struggling with a concept on the team by sharing your experience.

But how do you do that without sounding like a know-it-all? Or sound like you are just complaining?

While I’m not an expert at all-things-feedback, I’ve grown a lot in the past several years concerning how I give feedback — from technical aspects to soft skills and professionalism.

I want to share some of the tools I have learned to help you give better feedback. Whether you are a senior engineer who just got promoted, a junior struggling just starting, or someone who finds it hard to articulate what you think is helpful, these are for you. …


Image for post
Image for post
Photo by Elaine Casap on Unsplash

If you are a beginner in the world of Git and hosted Git platforms (such as GitHub or GitLab), then you’ve probably never heard the term “pull request” or “merge request” before. You also might not understand what they are or the value they bring to your team.

Sidenote: I’ll be using the term “pull request in this article, but it’s effectively the same as a “merge request” in GitLab.

Pull requests help teams build and share software. They do have a bit of a learning curve though, but I believe its worth it. …


Image for post
Image for post
Photo by HS Spender on Unsplash

Ever had a moment in your software career where you needed to make a simple change, but found it hard to implement? The code was so fragile you couldn’t make your change without breakout myriads of tests? I’m guessing you have.

Or maybe it was a time when you couldn’t understand what caused a production problem while looking at the source. You couldn’t understand which code was executed or where to start. Logs and metrics couldn’t help either.

These are common symptoms of what I tend to refer to as “messy code.” It isn’t easy to work with, it isn’t easy to read, and it certainly isn’t easy to add new features too. …


Image for post
Image for post

For the better part of last year, my team was having trouble with what seemed like a trivial problem.

We needed to publish release notes for our releases to stakeholders.

I’m sure many of you have similar requirements. You have users (internal or external) and you would like to publish something that makes it easier for your users to understand the new release. Are there any new features? Any fixed issues? What about performance improvements? These are all things to consider to publish into your release notes.

For our team, we had mainly technical internal stakeholders, which solved (at least partially) some of the problems other teams might face. …


“Hero” programming only lasts so long.

Image for post
Image for post
Photo by Limor Zellermayer on Unsplash

It’s 9:45 pm on New Year’s Eve. I was supposed to be downtown a few hours ago with a group of friends to and stay up to be part of the Raliegh NYE celebration (which, btw, features an acorn drop).

Instead, I was on my computer. Hunched over, manually verifying the last of our billing statements were ready to go out. The past day had been an exhausted one. Every process had gone wrong, no one was around due to the holiday, but we had to get statements out.

We thankfully did, and everything was fine. …


Why only focusing on the end game will disappoint you.

Master blacksmith on an anvil
Master blacksmith on an anvil
Photo by Nicolas Hoizey on Unsplash

I’ve had a pretty short career as an engineer. I’ve spent ten years writing code in a professional context across a few different companies, and only 6 of those as a full-time engineer.

In that short time, I’ve had those moments where I realized I wasn’t where I wanted to be as an engineer. I was taking a while to code seemingly simple solutions, and I felt like no matter how hard I tried, I wasn’t getting that much better.

We all want to become masters. We want to become expert craftsman (or craftswoman) in the art of coding. We want to have those moments where we see a problem, know how to fix it, and then execute as if it were an intuition rather than conscious thought. …


And does 100% coverage mean anything

Image for post
Image for post
Photo by Federico Lancellotti on Unsplash

Code coverage is another one of those topics that tend to divide developers. Some developers and managers insist that 100% coverage is the standard. Others, especially thought-leaders, insists on a number somewhere between 80% and 90%.

So what is code coverage? And what, if anything, does it bring to your team?

Code Coverage is Just Another Measurement

Code coverage is just like every other quality control metric you might use to monitor the quality of your codebase. Its also probably the simplest.

While I won’t review every aspect of code coverage (line vs. branch vs. condition, etc.), coverage reports are telling you the percentage of code executed during your tests. Coverage gets collected by invoking your tests with a special agent or compilation flag that tracks the blocks of code executed while tests are running. …


Image for post
Image for post
Photo by Jukan Tateisi on Unsplash

I first heard the term kaizen in the popular book The Phoenix Project. In the book, we learn about how a recently promoted IT manager is trying to solve all of the problems in his organization. The problems seem intractable, but never the less he persists.

One of the biggest realizations of this character is that without making continuous improvement, things deteriorate. The law of entropy always wins. Additionally, the character in the book realizes that one person can’t merely mandate change, and it happens overnight. …

About

Dan Goslen

Jesus follower | husband | IJM advocate | software engineer. I share tips and tools for building great software as a team.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store