My Breakthrough: Anticipating Problems

Breakthroughs From a Digital Agency (a Series) We have a small, close-knit team here at Brolik. We’ve experienced solid growth year over year since our inception in 2004, but 2013 felt different from the rest. The company celebrates 10 years in business on January 14th, 2014. But, it’s not just this milestone we’re celebrating… this year the company reached a level of maturity that we can be proud of. As a small agency, cash flow challenges, production bottlenecks, inefficient processes and peaks and valleys in new business are common. This year our talent, experience and execution aligned better than ever before. To put a cap on the year, and to put this somewhat vague concept of “maturity” into more tangible terms, each of our team members will present their personal breakthroughs over the last year. In the process, we hope you’ll get to know the people who make up Brolik a little better.

As a developer, I always see things saying, “Don’t take short cuts early on in a project because you’re going to regret them later”. Yet, somehow, I still took shortcuts, and they always came back to bite me later. Have you ever had that feeling, where you remember something you did as a young kid and then just cringe and wonder what the hell you were thinking? Well, you can get that feeling when developing too, and it’s a massive headache. After going back to several projects this year to fix issues for clients, I finally decided to take the message of not taking shortcuts to heart. Not only that, though, I added a bit to it: anticipate problems. I’m sure many developers have heard of the idea that the user is stupid; but that’s not true. The browser is stupid, the user is impatient and they aren’t always going to do what you want them to. So what did I start to do in the second half of 2013 to save myself future headaches? I began to plan and anticipate things that I should have done all along. For example, what if the user can upload an image through your CMS? Well, what happens if they don’t upload one? How should the layout change? What does that do to the design? What happens if the image is corrupted? Or lost? What if they upload a really small image, or a really large image? These are the type of questions I began asking while working on a project to save myself not only headaches with unintended user interaction, but also, with messy code. When you start to include more intuitive checks in your code, it forces you to think more about what you’re writing, and for me at least, it has cut down on the amount of messy code in our projects. Practicing anticipating problems won’t help just me, but it will help my colleague, our clients, and their users in the future.