Mindful Iterations
I’m not a marketer by strict definition. While in the past I have spent time working in SEO as a Project Manager, I am, by definition, a geek.
I started off in the IT industry back in 1997, when I answered my first AT&T WorldNet (remember dial-up?) tech support call. “Thank you for calling AT&T WorldNet technical support. My name is Samantha. May I have your name and the telephone number you registered with please?”
Since then, I’ve held so many roles in IT, that I’m a bit of a jack of all trades; a technical generalist, if you will. My current role is that of software engineer. However, in my day to day work, I’m lucky enough to come in contact with many high profile brands. That’s not a responsibility I take lightly.
Maybe I’m a freak, but when I did technical support, I felt a strong sense of responsibility to my callers. They were entrusting me with caring, over the phone, for their several-thousand dollar machines. While there were times I didn’t quite feel like fixing broken Internets, helping customers backup several years of data, or walking through my 40th software install in a day, that’s what I did. Not just because it was my job, but because these people trusted me. They trusted me to guide them down the proper path. They trusted me to do what was best for them.
Fourteen years later, I still feel that sense of responsibility when it comes to clients. They are entrusting me with their brand. That’s a much larger scale than an Internet connection, a software suite, or a few thousand dollar computer. Their brand is bigger than a logo, slogan, or jingle. Their brand is their livelihood. It’s their reputation. It is responsible for feeding hundreds, sometimes thousands of families. Maybe that’s why I’m a bit of a perfectionist. I don’t like rushing through things. I like taking my time and making sure things are done right.
In a way, I’m a steward of my client’s brand. If I make a glaring mistake on Client X’s project, hundreds, thousands, or even millions of people aren’t going to know that Samantha made a boo-boo. But, it may very likely reflect on Client X’s brand. It opens the door for Client X’s prospective customer to ask themselves, “Jeez – if Client X can’t manage this, how are they going to handle my insert random customer need here?” I’m not okay with that.
So, to the brands I’m fortunate enough to work with, I say thank you.
You have entrusted me with your brand. That’s a pretty big deal. I understand that your brand is bigger than a logo, jingle, or slogan. Your brand is your livelihood. It’s your reputation. It’s responsible for feeding hundreds, maybe even thousands of families. If I make a mistake, it doesn’t reflect on me – it reflects on you. That’s a pretty big deal. Thank you.
For those who know me and are familiar with the programming side of my life, they know I’m a relatively opinionated person. When it comes to writing software, I believe in doing things the “right” way. As a general rule I don’t believe in copying and pasting code, nor do I believe in a rush-it-out-the-door coding practice or mentality.
I believe you can either pay for something in the front end by putting in the time and thought for a quality product, or pay for it in the back end by fixing bugs and potentially alienating customers. My philosophy is that I’d rather spend the time and thought to do it “right” up front than pay for my mistakes later on down the road.
After all, if I’m paying for it in the back end, not only am I going to spend extra time on something that I could be using for new work, I’m also running the risk of forgetting what I originally did. Even worse, I’m running the risk of giving my customer a bad experience with faulty software. If something isn’t written right and gives my customer or their customers difficulty, they’re going to automatically have a bad taste in their mouth as their first impression, no matter how forgiving they may be.
When I am faced with a situation where I need to copy and paste code, I feel the need to fully understand what the code is doing. By copying and pasting code I run the risk of copying and pasting bugs (or shall we say interesting features?) into other areas or products. I can’t explain how much that bothers me. Anytime I’ve Ctrl-C’ed Ctrl-V’ed code, a little part of my soul has died.
If I absolutely have to copy and paste code, I’m going to type it out by hand, and then use a diff tool such as vimdiff to compare the two versions. At least if I retype code, I’m getting a better understanding of what the code does than if I’m blindly moving snippet A to text editor window B. I don’t like doing things blindly.
Unfortunately, my propensity for “doing things right” isn’t always the quickest route from point A to point B. Sometimes I find myself in that dreaded state of analysis paralysis. I enjoy the process of drawing my program designs on a whiteboard or a piece of graph paper. However, I also enjoy finding the holes or problems in my thinking; finding the reasons why something won’t work, which then gives me the opportunity to find a better way to do “it” – whatever “it” is.
What can I say – I’m in love with the edge case. I find people rarely think of the edge case, when maybe we should think about the edge case a little more often. It’s the edge case who is going to find a way to hack the system and expose a huge security flaw. It’s the edge case who is going to find that your software does what they’ve needed all along and then tell all their friends and coworkers about how your software saved them time and money when nothing else did. I’m a champion of the edge case. Why? Because the edge case almost always provokes a more thoughtful design. It’s true – you can’t make everyone happy all of the time, but if you can make a couple more people happy, the rewards can be great.
But what do you do when you have a hard deadline and you need to ship your software in a timely manner? When do you risk throwing the baby out with the bathwater because dammit, something has to ship? For at least the last ten years I’ve had a joke or quote about myself:
“I’m not obsessive; I’m just thorough.”
I don’t remember when or why I came up with it, but it’s stuck with me throughout the years because it’s true. Quality and detail are two things I’m passionate about.
The longer I’ve been programming, the more I’m learning that there isn’t necessarily one right way, leaving all others to be wrong ways. The more I do this, the more I see that there are different shades of right and wrong for different circumstances.
If I have 15 days to launch a product and there’s no way to reset client expectations, I’m going to do the best I can with what I’ve got, but I’ll also do my best to learn something for the future. Whether that’s an efficiency to be found in coding, or that I need to readjust the way I handle client expectations, I’m going to learn something. And hopefully next time, I can veer closer to “right”. To paraphrase my partner, sometimes good enough is good enough; the trick is in finding the balance.
I’ve looked at this post for at least fifteen minutes now, trying to figure out how to make it better and contemplating edge cases. Remember, I’m not obsessive; I’m just thorough. I think I’ll take a risk and hit publish. Hopefully my post doesn’t have any bugs.
Follow Me!
