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