Newsletter - July 2017


This month we look at why it's important to focus on habits rather than goals, Scott Wlaschin's F# for C# programmers talk from NDC Oslo and why we may need to rethink Tuckman's Theory of Group Development.

The Codurance Team

P.S Missed our first newsletter? Catch up here

P.P.S Have you written something that you'd to share with the Software Craftsmanship community? Perhaps you'd like us to include a topic that we have yet to cover? Reply to this email and we'll try and make it happen.

Our Opinion on ... DevOps and Software Craftsmanship

When I joined Codurance, I didn't expect that my career and mindset would end up changing so much. Whilst I'd already read about Software Craftsmanship and Agile before hand, above all, I'd always felt that I was just a coder. I would focus on creating software. All of the elements surrounding the code were therefore beyond my knowledge and interest.

This mindset changed when I joined a project that required my team to build the infrastructure for an application created by other teams. As a software developer, I discovered a whole new world which had not been visible to me before.

Since then, I've learned how to build infrastructure on AWS. I've had a chance to use many different tools such as Docker, Ansible, and Packer. But learning all of these new tools and technologies was not the biggest challenge. The biggest challenge was how to combine the low-level knowledge with actual business value, and how to organise our teams accordingly.

I soon realised that this should always be the main concern for a software engineer with a DevOps mindset. For me, it was where the principles of the DevOps movement and the declarations of the Software Craftsmanship Manifesto came together.

When trying to introduce DevOps into our organisations, we have to think about interactions between the business, software developers, and system administrators. We have to understand how we can incorporate our business experts into our daily jobs and how to focus on the business value that we are providing. DevOps teams must ensure that our software provides the proper feedback which allows us to improve and respond to changes.

If you want to hear more about DevOps, I invite you to join me in October:

Robert Firek is a Software Craftsman who strives to create software according to the rule "Simplicity is the final achievement". You can follow Robert on Twitter via @RobertFirek

Habits vs Goals: A Look at the Benefits of a Systematic Approach to Life

Farnham Streets' excellent comparison of Goals and Habits, and why we often set ourselves up to fail by focusing on the former rather than the later.

Pragmatic Functional Programming

Uncle Bob's entertaining article on the recent history of Functional Programming and some of the reasons why we should be thinking about coding in functional languages sooner rather than later.

TDD Did Not Live Up to Expectations

This thread started in May and we didn't have time to include in the last newsletter ... so here it is. A useful Twitter thread covering useful programming tools that we kept tabs on as it developed.

Software Craftsmanship London

Are you passionate about Clean Code & Extreme Programming? Do you take a pragmatic approach to Software Development?

Then immerse yourself in this 2-day conference, featuring the minds of some of the greatest thinkers and doers in Software Craftsmanship from around the world.

Learn More

Tuckman Was Wrong

You may be familiar with Tuckman's Theory of Group Development, and how teams move through the phases of Forming, Storming and Norming, before reaching their most productive phase of Performing. Doc Norton looks at the reasons why we need look beyond this theory, including how Storming may be a continual occurrence.

8 Proven Ways to use Docker

Flux7 are one of the original foundation partners of Docker. Their CEO & Co-Founder, Aater Suleman, provides insights into what he sees as the best use cases for Docker, based on his first-hand experience.

Converting Queries to Commands

Michael Feathers explores how methods that focus on a single responsibility, and the two broad styles that emerge, can be useful when refactoring.

Is It Pokemon or Big Data

Hours of fun. Probably.

The Rise of the Thought Leader

David Session's article on the rise of Thoughts Leaders in society, drawing from Daniel W. Drezner's book The Ideas Industry. Interesting thoughts on the conflict between personal profit and the needs of society.

Okay, WTF is Ethereum?

Chances are that if you're interested in Cryptocurrency you'll already know about Ethereum. If you haven't, this article from Daniel Oberhaus and Jordan Pearson provides an insightful introduction.

Simple or Complicated?

Back in 2010, Martin Odersky posted his response to a heated debate on whether Scala was too complicated for 'normal programmers'.

F# for C# Programmers

Scott Wlaschin's talk from NDC Oslo last week, providing a nice introduction to F#.

Summary of Go Generics Discussions (Living Document)

The generics discussion keeps turning up on the forum with the same points being argued over and over and over and over again. This document tries to summarize all the details, as well as the arguments for and against generics. Things will be added as new comments or suggestions arise.

Paul Chiusano: How to Write a Functional Program with IO, Mutation, and Other Effects

Paul Chiusano on writing Functional programs with effects such as IO. Hosted on, which is a treasure trove of Functional Programming content.

GitHub Enterprise 2.10

Webinar from GitHub on the features of Enterprise 2.10, including filtering and searching of repositories with Topics and the new GitHub GraphQL API.

Large-Scale Design in Haskell?

Stackoverflow thread first posted in 2011, asking whether large applications in Haskell has similar supporting literature to OO or imperative languages regarding best design practices.

SCLConf Q&A Blogs:

Paul Blundell talks about Software Craftsmanship at Novoda and XP in mobile development: Read here

Michael Sperber & Nicole Rauch on the future of Software Craftsmanship: Read here

If you're an aspiring Software Craftsman that shares the same values of professionalism, pragmatism, and transparency that we do, then we'd love to hear from you.