A good ninja is resourceful, avoids excessive waste and never stops learning so he (or she) can be at the top of their game. Likewise, I find that it’s incredibly important apply these principles in the environment of a build engineer. The build is complex, and at the center of every project. It’s like a hub with all kinds of inputs and outputs. A really smart guy once said:
“The build is a piece of software and should be treated as such. The build is among the most heavily used and complex pieces of software in the development group and should be treated as such.”
~Danny Glasser (1991)
So it’s kind of important that this “thing” is strong, stable, consistent, reliable and any other positive attributes you’d want in a boyfriend or girlfriend. Similarly, the team that develops and maintains the build should have these qualities in spades. So the first three principles I mentioned (resourcefulness, avoiding waste, and constant learning) are really key to a build team and the quality of the build system they produce.
I read a good article the other day that really inspired this post in the first place. I’ll let you read it but wanted to highlight a few points that I think really affect build teams today:
(Too Much) Work in Progress
“Completed work in the hands of our customers is valuable. Until then, it isn’t” – LINK
This is one of the biggest struggles for a build team. like a software team, you have new features, bugs, and customer requests all coming in at the same time. The difference is that usually, a software team only has these things coming from one or two directions. The build team has them coming from every input and output stream of the build (developers, validators, program managers, release teams, debug, analytics, etc…).
Be resourceful. Stop complaining about what you don’t have and figure out what you can do with what you do have! A stick is just a stick to the untrained eye, but broken in half and tied together with twine and you’ve got yourself some nunchucks! I’m not implying that you should duct tape and “Jimmy rig” everything because that would be counter productive. But by spending more time in a positive, constructive space and thinking outside the box, you might be able to complete tasks faster, or remove them altogether.
And why is it that every developer who writes a script to zip or unzip a package, thinks they’re the first ones in the history of humans to write that script? Reuse can dramatically trim down that “to do” list. Also, look for solutions in “out of the box” places!
“Sure, I can do that tomorrow.”
While the article focuses on the quality of work in this area, I’d like to take a moment to talk about the procrastination of work. I can’t count the number of times I’ve heard a build engineer say they can do something “tomorrow” when requested to do something that takes less than 5 minutes. Do it NOW! or at least TODAY!
While the next topic (Task Switching) may somewhat contradict this, your schedule is only as good as the next build break or other critical issue. You wouldn’t drive at rush-hour speeds if you weren’t stuck in traffic right? Handling a simple five minute request immediately, or at least within the same day will delight your customer and save you the hassle of remembering to do it “later” and making that assumption that you’ll even have time to do it whenever “later” was supposed to be. Seriously! You have enough post-its on your monitor already, put the pad down and just do it!
Secondly, learn! But more importantly, learn often and in your “off” time. Spending time learning something new during a task can often push that task out more than you think. While it is sometimes unavoidable to have a learning curve or “ramp up” phase as apart of an assigned task, this is not necessarily the best time to learn (unless the task itself is about learning, then you’re good!). your brain is in “task” mode and not necessarily primed for learning. you’re looking specifically for the answer to your problem rather than absorbing information in a more holistic manner. This can lead to a poor or even incorrect solution because you did not have the full context of what you were trying to learn.
The “off” time mentioned above does not necessarily mean you have homework to do that you’re not getting paid for, but it is your career after all and some light reading on the weekends probably wouldn’t hurt. More generally what I mean is, don’t wait until your in the middle of a task to start learning. most “healthy” teams don’t schedule their work at 100% capacity, there is usually a decent buffer to account for technical debt, meetings, and wait for… learning!! Use your time wisely!
This requires A LOT of diligence and mastery for the build ninja. Sometimes you need your nunchucks in one hand and your throwing stars in the other. I get it! I really do! And it looks freaking awesome when you’re in your ninja suit (Less so in your graphic tee and converse, but still, awesome!!). It can be tempting to show off all your sweet ninja moves, but remember all those Chuck Norris films? As soon as the ninja starts showing off, they get punched in the face!
Ninja’s do their best work when focused on a single task at a time. And generally try to complete this task before moving on. Don’t get this confused with “tunnel vision”. It’s super important, especially for a ninja to be aware of their surroundings and to be able to adapt to them as they change.
In other words, don’t waste a bunch time in “overhead” activities like setup and breakdown of tasks! I know this seems like common sense to most, but if we all took stock of our day to day routine, you might find out your wasting a lot more time than you think!
Moral of the story
Be flexible, but don’t break your back. Be fast, but don’t let quality suffer. And only juggle when you have to, and never with sharp objects! It’s a balancing act, but that’s okay! You’re a ninja and you have those funny shoes that split your toes apart so you can climb trees and balance narrow ledges and stuff!