Categories
code development programming

A checklist is the first step to automation

wp-1450118458148.jpg
↑ ↑ ↓ ↓ ← → ← → B A

My first big responsibility at my current job was to package a release and deploy it to the customer. Back in those days (2007), that involved creating a set of installers (server, desktop and tablet client – Windows XP tablet), burning them to a CD then driving to the client site on the day all the mobile workers returned to base for their monthly meeting, and installing into all the machines.

I remember my dad telling me how he taught others. Let them sit at the machine. Let them take notes. And be patient.

There weren’t many notes to work from at the time, and I wanted to be confident I could do it myself next time, so I wrote the steps down as a series of checklists, one for QA and build, one for media prep and one each for installing onto each target device.

And I noticed something. As soon as it was written down, I started to see where things were duplicated or could be automated. Within a couple of releases, I’d got the checklist down from 5 sides of A4 to 2. I probably could have done more, but 1 sheet felt right, and that project was coming to a close.

I thought every project had a way to visualise their release process, it sounded obvious. It wasn’t always the case, as I discovered when I started working on legacy projects with ad-hoc procedures and distributed troubleshooting guides, a SQL script here, a helpdesk ticket there, or an appendix in the technical architecture. It seemed crazy to me. You’re dealing with a legacy system, with a complex deployment process, or build process, scattered throughout various machines, and various people’s heads. It’s error prone and you want to improve it.

The first step to improvement is understanding, and the first step to understanding is to visualise it. If you don’t know what you’re doing, make it visible.

Categories
development leadership

Bootstrapping new developers

Dawn behind the trees
Start of a new day

When things are tough, do them often, to get more practice, as Sky Betting discuss in their recent blog post. It’s certainly something that I’ve noticed as we’ve moved to more regular releases, more regular planning and reducing feedback cycles.

One big thing I’m still learning how to do, where that doesn’t apply, is adding new developers to a team. I’ve been thinking about this after hearing The Improv Effect talk about onboarding to a company on .Net Rocks 1253 : Onboarding is Culture with Jessie Shternshus

My usual approach doesn’t apply, because good teams are stable, so onboarding is rare, which makes it harder to know how to bring new people on to the team. I always try to write a short introduction, on a wiki, to introduce the project and list the useful urls, and the getting started steps, and I ask new developers to update it with any differences they find, to keep it up to date.

Most of the team knowledge doesn’t come from there. It comes from the rest of the team. So the team needs to be built so that the onboardee collaborates with other members of the team from day one. Getting involved in code reviews, asking questions. I’m sometimes tempted to give as little information as possible to encourage asking questions, but that’s not how psychology works, and I’ve had more than a few gotcha moments where someone who’s been on the team for a while says “I didn’t know that was there” or “oh, so that’s why we do it that way”, and I have to revisit the onboarding story again, and wait for the next chance to validate it.

So, assuming your company has a good story for onboarding employees, how to you take a fresh start, or a start from another project, and build them into your team?