Every process, every person, every thing - a work in progress

Full article

At least the week ended on a high note. We had a family friend over that we hadn't seen in awhile, who's a great guy - and makes a damned fine mead as it turns out. I thought mead was some kind of beer from the middle ages, but it's actually honey wine and most definitely takes the edge off. Probably needed it during the black plague. If we were gonna keep something, glad it was the mead.

As I sit here contemplating mead and the simplicity of a time without electricity, plumbing, or curbside pickup, I wonder if the days leading up to a production release ever go smoothly? I'm starting to think they don't. Like everything else, I suppose there's always room for improvement, and perfection is always just out of reach. I felt like I planned things better than last time, which was better than the time before that. Everything's a work in progress right?

Nearing the end of one project and beginning the next seems like a good time to reflect on what hasn't gone well and, just as importantly, what has gone well.

Do merge all the code

There's a lot of different ways to handle a code merge at the end of a project, but I think most teams keep their work on separate branches and then push everything to one main, production-ready branch. Of course there's different opinions on how often to merge things. I mean, it's programming.. there's always a difference of opinion. We happen to do it at the end of a project, but some teams are always ready to ship, even if they have to disable or hide things.

This recent project touched more repos than usual, and although I thought I was tracking them all, I only started doing it midway through the project and missed an early one, something we'd touched once months and months ago. I've been a longtime user of Trello, so I created a new "projects" board with lists for various projects. I tossed some "pre-release", "release", and "post-release" cards on there, with checklists for things I need to do - pull requests, merges, documentation, follow-up emails, cleanup, etc. Some vary by project, but most are the same. The next project is underway, and I've already begun adding repos we've pushed to, and documentation I want to create.

Don't kick problems down the road

We had a new database script that needed to be run as part of the installation process, and at some point someone realized it wasn't being installed on our test servers, so they just applied it manually. Basically, they got things working and kicked the real problem down the road, but we lost sight of it.

A week before release, we realized it was a problem we had never solved. Luckily, one of the other team leads knew what had to be done and walked me through the necessary changes, which I didn't know about and haven't seen documented anywhere. Next time, no shortcuts. It's too easy to forget to go back, although had I known about it I could've added it to the ol' Trello board.

Oh, and that "luckily someone knew" thing leads to the next point.

Do discourage tribal knowledge

Tribal knowledge sucks, insomuch as a thing exists only as tribal knowledge. I've been on a huge kick over the last couple of years to clearly document everything I discover or learn or create. I do it at work, I do it on this blog, I do it personally, and I've gotten pretty decent at it with practice.

In the past, I used to feel really really lucky, when someone stepped in to save the day. Like, oh wow thank goodness you were here! I don't know what we would've done if you didn't have that bit of knowledge! But therein lies the problem. Why does someone, or some few, have a bit of arcane knowledge that saves the day? Don't have a good system for note taking? Setup something, anything, that's accessible to the whole team, and start tossing stuff in there. Organize it as patterns emerge. Link pages together if you can.

If all we (developers) were ever doing was cookie-cutter stuff that every other developer would reasonably be expected to understand, then maybe documentation wouldn't be as necessary. But everything we touch is a custom piece of work, built on top of a hundred other custom pieces of work, using a custom set of technologies applied in a custom way. We owe it to future developers (and our future selves) to leave user guides wherever they make sense. There's no reason that someone leaving the team should bring everything to a grinding halt.

Don't do it manually if you can automate it

Before our previous manager left, the first manager I've ever had who was strong technically and managerially btw, he setup an Azure DevOps environment and began automating things. Over the last year, a few of us have taken up the mantle, building on what he put in place. It was a huge help when we designed a website that needed to be built in a certain way and deployed (frequently) to several servers, and it continues to be great for running automated tests whenever someone checks in code and a whole host of other things.

Documentation makes certain things manually repeatable, but environments like Azure DevOps take it to the next level. Where Trello allows me to create reminders and schedule repeat reminders, automation does it for me. It's great. I recently setup a job that creates PRs for individual team branches and assigns them to team leads, whenever someone checks something into master. It needs some tweaking, but for us it's important to pull any changes from master into our team branches asap, so we're working against the latest production code.

Do appreciate a good team

Everything's a work in progress, and there are opportunities to improve all the time, but a lot of things have been really good too. I'm lucky to be working with a couple developers who are confident and eager to learn and good at communicating. It's made the project go as well as it could, given some setbacks and other extenuating circumstances. It's saved me from a lot of heartburn, like in the past when we had tight deadlines and I didn't always have that kind of support. It's also made me aware of how I didn't value these things, didn't understand why I should value them, when I was starting out years ago, and I wonder how much smoother projects I was on would've gone if I had.

Every process, every person.. a work in progress.


Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.

Comments / Reactions

One of the most enjoyable things about blogging is engaging with and learning from others. Leave a comment below with your questions, comments, or ideas. Let's start a conversation!