In this reprinted #altdevblogaday opinion piece, EEDAR's chief information officer Ted Spence explains why you and your team should take the time to analyze and solve small problems. Good programming stories don't quite grow on trees, but it's quite fun to take random bits of advice and make them apply to technology. One of my favorite witty aphorisms came from – if you can believe it – an inspirational saying on a tabletop. I came across this phrase at lunch across the street from Vivendi Universal's headquarters. The restaurant had decorated their furniture with little sayings, the kind that probably came from a fortune cookie. I found this one underneath my fish tacos:

That's quite a snappy turn of phrase. It's short, intelligible, pithy, and it quickly found its way into my collection of "Wise Programmer Stories."  This phrase is especially useful when I'm teaching a junior employee who would otherwise blindly use whatever tools and techniques I gave them.. I tell them the phrase, and ask them, "What is it that slows down your work? What can you do to improve upon your situation?"

Empowerment, proactivity, and $GENERIC_BUZZWORD_3

It's a cliche of management that you want your employees to think on their feet and solve problems without having to be told. But we, as managers, often make it impossible for employees to deliver the kind of improvements we wish they would produce! Modern development teams saddle our programmers with painful ticket tracking systems, arbitrary reporting requirements, continuous time management, and "priority-order" deliverables. We often tell our employees that "only critical tasks matter" and they should leave the little things for another day. By teaching my team to spot, and fix, problems without asking for permission, I am teaching them to use their intelligence to make the company better at every moment. Even more importantly, I'm telling them to improve on things that may not yet be problems, because often the person closest to the task sees a problem long before everyone else. When I tell my employees to fix their pebbles, I ask them to "sneak" improvements. I tell them to take a big task that's really annoying, pad its time estimate, and use the extra time to deliver some core improvement that matters to them. I certainly understand that sometimes this means I will lose an hour or two of an employee's time to scratching their own itch. But doing this has two key benefits:

Bad tools are often invisible

It's very easy for a manager to keep track of the "top level tasks." Nobody ever loses sight of the core deliverables, the top priority projects, the contractual obligations. But managers often miss the details. It's easy to develop a blind spot for little things that sap a team's time and attention. I've seen the following happen repeatedly:

In many cases, these (and innumerable other) tool problems are invisible. Because each problem is so small, and because the effort required to report little problems in a time-management system is annoying, employees don't bother reporting little nuisances. Instead, large tasks simply slow down because employees are busy doing and redoing these little tasks when they think they're working on the big ones. The manager who observes the team's progress data may not even notice the delay – after all, it's only a small percentage of a larger task. Isn't the large task the only critical thing? The customer doesn't care if your backup process is fast or slow; the customer only cares that they get their deliverable on time, right?

Our development "pace" is constantly measured

It's become a standard part of business practice – something they teach you every semester in business school – that you have to measure your progress. Many SCRUM and AGILE systems even explicitly ask you to cite your pace, or velocity, as a standard daily metric. Yet a simple measurement, "pace" often obscures critical information. If you have five "tasks" that are estimated to take 100 hours, and you complete four of them in a week, is your pace "4"? Is your pace 80 percent? Is your pace the ratio between the hours you estimated and the hours you spent? Does any of that information help the company? Setting aside these statistics, let's consider another way to look at our productivity. Every day, my team does some tasks that are mundane, boilerplate work – recording facts, submitting reports, updating statistics. But then there's the rich, unique stuff that is our company's value proposition: writing new code, building an improved system, delivering new features. What percentage of our time is taken up by the ordinary stuff? If you take an ordinary task – say, backing up the database and putting it on the disaster recovery server – and write a script to automate it, another script to test to ensure that it worked, you've just taken a task that added no value to the company and converted it into a task that adds value to your company.

Pebble spotting

Alright, let's put on our manager caps. We have two engineers and five critical projects that have to be delivered regularly over the next month. While you're dropping by to visit the team, you notice that Alice has her feet up on the table and is staring at the ceiling. "What's going on?" you ask. "I've built my code and now I have to test on the staging environment. Just waiting for Bob to set it up." "Why can't you do it?" "Bob is the only one with the credentials necessary to make the changes to the staging server. I pinged him a few minutes ago and he's just getting started now." Congratulations! You've just discovered a pebble. By itself, it's not a big deal. Many managers just shrug and walk away, and complain later that their programmers aren't as good as the programmers at Google. So what do you do next? Your team is already hard at work on the critical projects you've given them. You can tell them to work harder, or put in longer hours, or just focus more closely. But you might be better off tasking Alice and Bob with teaming up to develop a script to fix the staging problem. Without constant attention, these little time sinks proliferate. You may find that many of the delays in your top level date are actually an accumulation of little delays, because nobody bothered to fix these pebbles back when you had the time to do so. Here are some good places to look for pebbles that you can fix:

Good tools multiply your velocity

Does anyone think the original StarCraft would have been as good a game if it hadn't had a fantastic level editor? Blizzard achieved incredible, persistent success in their program in part because of their fantastic toolset: the StarCraft level editor was a breath of fresh air. It was used both internally and externally, and it took a game that was already at the peak of its genre and elevated it into something completely different; a platform that redefined competitive gaming. Yet many of us suffer in silence because we have to continuously redo our manual work every day. We know our tools aren't quite perfect, but there are always other pressures – deliverables, contracts, milestones. Sometimes we blind ourselves by constantly worrying about other things. If we do see the problems, we don't always allow ourselves the time necessary to fix them. But when you encourage your team to build incredible tools every day, you rapidly find that your speed on the big tasks increases. It's not just because your team eliminates a few minutes of hassle – it's because you're helping your team think about their work. When you give the team permission to fix the little nuisances, you teach them to value every part of their contribution. They aren't just working on a deliverable, they're working on improving your company as a whole.

Give it to the lazy guy

The rumor I've heard is that Bill Gates once said "I will always choose a lazy person to do a difficult job – because he will find an easy way to do it." (GoodReads) Whether this quote is accurate or not – I tend to distrust quotes that come with cheesy "meme" pages – it shows directly the consequence of the "pebbles" aphorism. If you take the things about your job that are difficult, frustrating, or hard, and make them easy – you'll enable yourself to deliver the big projects faster. Your company will move faster. And, most importantly, your employees will know that they should solve problems rather than just deal with them. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]