I sat in seat 20B on United Airlines Flight UA 949, enjoying the roominess of the Boeing 777 in service on this route between London (LHR) and San Francisco (SFO). At this time I decided it was time to hack together a Go CLI Project.
Mission: Create a Command Line Interface (CLI) that takes some flags, basic user input, and prints out something.
Recently I started researching what people think DevOps means. What it was originally intended to mean and how ridiculous it is to actually see it in a job title. On the flip of that, since one of my titles was actually “Site Reliability Engineer” I started looking into what is perceived to be the roles of that job. This article is my findings, in full unconstrained wording, about the absurdity of one as a title and the specifics of the other.
In the first part of this series I kicked off writing about how we created a manifesto at Home Depot. This is something I’d strongly urge anybody that is helping to lead an enterprise toward open source efforts. The second part focused on tactical tools used with open source software development. I’ll be adding more to the tools conversation a bit later in this series. Then in part three I delved into some of the positive cultural characteristics of a team working on open source projects.
In this part of the series I want to share a few thoughts on some of the anti-patterns that came up in the process. These are specific hurdles that continue to afflict the efforts, and range from a general disturbance or an outright conflict with efforts.