At first I wasn’t having much luck. It was always me asking kid #1 whether he wanted to program, and the answer was pretty much always “no”. I started wondering whether he was really mine at all since no spawn-o-mine would answer in that way.
Back in April, I wrote about a practice we were experimenting with at LeanDog. I called it Collaboration 8. The intent is to figure out who are the right people to have involved in a discussion. Rather than the boss making the decision, Collaboration 8 provides a way for the team to self-select...
Building a productive team begins with understanding the talents and skills of each member. The goal is to have a well balanced team. This balance is achieved through diverse programming skills, varying personalities, and personal strengths.
Today we started day 1 of our first ever ITOps sprint. This all came about because we needed a way of working out our productivity on “project tasks”, as well as learning how to triage our interruptions a bit better.
The idea is to get the simplest implementation of a pipeline in place, prioritizing a fully working skeleton that stretches across the full path to production over a fully featured, final-design functionality for each stage of the pipeline.
Imagine you want to introduce automated configuration management to your organization. You’ve read all the books and even visited a great conference where you heard a lot of success stories. “It’s really time to get our servers under control” you think. But how do you get started?
One important issue that comes up when undertaking a configuration management effort is how to design “the schema” for configuration management data. There are a couple of general and complementary approaches you need to know about if you’re working on this.
A while back I read Making Software – it made me disappointed at the state of academic research into the practice of developing software. I just read Leprechauns of Software Engineering which made me angry about the state of academic research.