In this fast food, same day shipping, not even one hour photo processing anymore world we live in, change is expected to be visible immediately. However, just because you have put process changes in to effect, or wrote a few new tests for your code, doesn’t mean you’re going to see immediate results. Be patient with getting the results. That goes for both you not losing faith in your own work and for your superiors to understand (manage up!)
I’ll admit, I’m a bit of a speed demon. My leaden right foot has certainly gotten me into trouble a few times. But there’s one time where I’ve learned that patience is definitely worth it: heavy traffic. Over all the years of my commuting I’ve done a little experimenting. One week I’ll (safely) drive aggressively, lane change to the lane that’s moving just a little faster, hard stop and start, well… you know the drill. You’ve probably either done it yourself, or have seen others do it day after day on your own commutes. Other weeks I’d just pick a lane and relax; just go with the flow and not be impatient. Believe it or not, over a 30 mile commute, the difference in times was only about 5 minutes, but the difference in stress levels and blood pressure was significant. Thanks to a little patience on the road, I was more relaxed and productive in the office, and much happier once I was back home.
But enough of the psychology of having some patience on your commute… How does it relate to being an engineer or a manager?
A little while back I was talking shop with some old colleagues of mine. We commiserated over how bad some of the coding practices were at that old job. One thing we never were given time to do properly was write tests, and that bothered all of us to one degree or another. Since that job, he’s started his own development company, and has vowed that everything they produced would be done with proper TDD (Test Driven Development) and he always shoots for at least 80-90% test coverage. He said that in the end it paid off, as the tests did catch an introduced bug before they launched the new release of one project. Here’s the kicker: it took almost 18 months for the tests to actually fail. On the one hand, that’s awesome that his team was able to go bug free for that long. However, it also highlights where patience matters. They worked hard to follow their processes, which admittedly slowed them down from time to time, but were eventually rewarded by seeing their test work catch an issue before it affected a customer. Comparing that to the job we had both shared before where the tests didn’t catch anything in a month, so management insisted that we stop wasting time writing tests. That project ran for over three years, and never launched; partially because of the number of bugs which kept being introduced but never caught until after the fact.
Similarly, I recently held a position where I was asked to introduce new processes with the engineering team to try and speed up their delivery as well as reduce bugs and better schedule feature delivery. Before I arrived the best delivery times were often “sometime in next quarter.” It’s just a little hard to sell something to a customer on a promise of sometime in the next three months… I put processes in place, opened up communication, tracked down answers and issues (like a Scrum Master on his third pot of coffee). The problem is, old habits die hard, and change didn’t happen overnight the way my boss wanted it to. I explained that it takes time and showed data to back up the small progress which was made. I corrected course based off of the data, and off input from the engineering team. None of that mattered though, because I wasn’t performing the miracle of overnight perfection that my boss had in his mind. I wish him success, but I also wish him a smidgen of patience and a willingness to let things properly run their course to be able to judge success. Some changes really are a long game, and need the patience and strength to stay fully committed to them.
As an engineer, you’re selling yourself short if you’re not urging patience on your management. There’s nothing wrong with pushing back with a better solution that may take longer to implement. The challenge is how to explain it. You have to be able to explain that it may take an extra day, but the solution will provide even more value to the customer, stability to the system, preparation for the next feature, etc… to justify the time. Explain the reason for why you’re asking for patience. With a solid reason which ultimately positively impacts business, you run a better chance of getting the time and patience than just a “because I need the time to do it right” type answer. With each success after the request for patience, you’ll find management more receptive to the next time you ask for it. If you’re lucky enough, you’ll find that management even starts asking or offering the time for a better solution. Of course, you’ll just have to be patient for that to happen…
It’s also critical to be self-aware when solving a problem. Don’t just rush through to be able to grab the next task. Have a little self-patience and ensure that the code is done right. Double check your work. Make sure you’ve covered the odd edge cases you thought of while working on it. That patience in your own work will result in less mistakes in the long run, and even deeper tests which will cover more detail. Of course, then you’ve got to be patient once more for those tests to catch something. But you already knew that, right?
In the meantime, I’m off to exercise that lead foot of mine. Patience is great, but sometimes you still want to go fast…
