I created this blog almost one year ago. It has been quite a ride. I have shared a lot and I have learned a lot also. I’ve published 50 articles, divided in 30 opinion articles, 13 interviews and the rest are references to videos.

During this year I’ve had +20k unique visitors. My top 5 most visited articles are:

1. From Rails to Clojure, then to Java, then back to Rails
2. Code patterns that are a recipe for trouble
3. My framework for one-on-ones
4. That project where no one wants to work at
5. Create an onboarding template

Erik is the author of DaedTech, a blog about software stories that I follow. He has published several books, being Developer Hegemony: The Future of Labor the latest.

On this interview we discuss topics that go from strategic decisions regarding code bases, guidelines for building software, how to deliver features with quality and how to make developers more valuable.

Last week I finished reading The Alliance: Managing Talent in the Networked Age. I really liked the book and it helped me better understand my own views and ideas on growing teams and developers. The book is small-ish and talks about several processes that are used at Linkedin. They also have online materials and tools at The Alliance Framework website.

When I was suggested to read this book I remember that I crused through the reviews and I noticed that several bad reviews had a common theme: they said that the ideas were good and interesting, but that they wouldn’t be possible to implement in a corporate company. That hinted that this book would bring out of the box ideas and naturally I was very interested.

So what were my key take aways from the book? The concepts of tours of duty and the alliance relationship.

Markus Schirp (twitter, linkedin, homepage) is the author of Mutant, a mutation testing tool for Ruby.

In this interview we’ll cover the topic of mutation testing and the added value of incorporating it in our day to day workflow.

We’ll also cover other quality techniques that can be used to improve end to end quality of software deliverables.

Things go wrong. This is something that we can try to control, anticipate an plan for. But ultimately we will fail and we won’t be prepared for it. If we consider the amount of interactions we have, the amount of changes by so many people, and the limited amount of resources we have, it should be clear that if we don’t hit some bumps, we’re just going too slow.

One thing that we can do though, is to better handle problems after they happen with a good postmortem culture.