My 2017 Developer Resolutions

We’ve just started a new year, so I think it is a good time for us software developers to give some thought to where to focus our learning efforts in the coming months. In the spirit of making overly ambitious resolutions, here are the software development topics I intend to explore in 2017.


I have worked on some projects that consisted of multiple services, but none of those projects scaled beyond a handful of instances. Massive concurrency fascinates and terrifies me–a good indicator that it is worth digging into more deeply.

In a related vein, I want to learn how to develop software that is resilient to external failure, like disk failure or network interruptions. Microservices and distributed computing aren’t going anywhere, so this will be a productive topic in which to become proficient. I still favor starting with a well-composed monolith over presuming the need for microservices, but I suspect that, even for monolithic projects, the techniques that support increased parallelism and resiliency will be useful. In particular, I intend to learn more about actors.

Evidence-Based Technology Selection

All developers have their preferred tech stack and tooling, and that’s fine–as long as they don’t start a holy war over it. However, I’m increasingly unsatisfied with the way most technology decisions are driven by anecdotes, aesthetics, or politics. I’d like to look into what research–if any–has been done on programming language effectiveness. The closer I can get to hard data, the more I can base my choices on evidence, instead of personal preference.

This is as much about identifying my own biases as anything else. For example, I prefer typed functional languages to dynamic imperative languages. I can support this preference by stating my belief that a good type system provides helpful constraints and guideposts on a system and that immutability helps eliminate unintended side effects.

But are developers actually more effective in a typed functional language, such as F# or Haskell, over a dynamically typed imperative language, such as Python or Ruby? And precisely what do we mean when we say “effective”? I think there’s a lot of work to do here, and maybe I can find a way to be a part of providing some more concrete, evidence-based conclusions.

Better Abstractions

There is an old aphorism in programming that any problem can be solved by another layer of abstraction. I think there is a lot of truth in this saying, at least when it is the right abstraction.

Over the last several years, focusing on TDD and functional patterns has improved the baseline/low-level abstractions in my code, but I know there is room to grow. The current patterns I use (Single Responsibility Principle, inversion of control, immutability, etc.) have become a sort of “autopilot” for me. I use these patterns almost without thinking about them consciously.

Yet for any reasonably large project, I think another layer of abstraction becomes necessary. Without this layer of abstraction, a large project becomes hard to reason about, even if all the little pieces are well designed. I think advancing to the next level of abstraction will help address this problem, and it will necessarily be more domain-specific.

To that end, I’d like to learn more about domain-driven design–or even denotational design. I’d also like to introduce specific practices or reminders that help me keep the “big picture” of the domain in view as I add to the code base. This is especially true when I am under time pressure, the most likely cause of banging out poorly-designed code.

Containerized Development

Docker and other container technologies have been around for a while now, particularly for deployment purposes. However, I’d like to use Docker to isolate different development environments for different projects.

As a consultant, I frequently work on multiple projects at the same time. For example, say I’ve recently completed one project and am a few weeks into a new project, when suddenly a high-priority request comes in for the original project. Isolation helps ensure that the development environment for the original environment won’t be adversely affected by any new software or tools I’ve installed for the new project. Currently, I isolate each project by using separate virtual machines, but I’d like a lighter-weight solution. I think Docker could make isolation faster and less taxing on my computer.

There’s Always Something New To Learn

While it can be overwhelming at times, in general, I like that the tools and techniques used to make software are constantly evolving. What do you want to learn in 2017?