"Make it faster."

I'm obsessed with performance tuning. It's an itch that can never fully be scratched. A sickness that can never be cured. Here's the story of how I caught the bug.

Back in the summer of 2001 I had my first internship at a well funded startup in Hilton Head named Databuilt, Inc. It wasn't well funded enough because it eventually went under, but that's another story for another day. What matters for this day is that it was my first internship.

There were several interns at Databuilt that summer, but I was the only one there for programming. That went to my head because I thought that meant I was the one that got to do real work. You know, write code, contribute to the launch of an innovative startup, get handed stock options for my awesomeness and then be a millionaire by the time I was 22?

Yes, fine, looking back I was delusional but it was one of the best learning experiences of my life. I was able to work with a great team of people who taught me some valuable lessons about life as a programmer and what it takes to make it in this field.

Then there was Dave Paris. Dave was the alpha geek of the entire company. The lead developer, the architect, the big man (although I still swear he looks like Seth Green). His title was actually Alpha Geek.

He gave me my first programming project for the company. Build a job queue in C++ that could handle priority levels. So I built it and got it ready to show after about a week. He looked at it said just said, "Make it faster." Then went back to what he was doing.

So I dug into the code and tried to find places where the code could potentially run more efficiently, tweaked it, and then showed it to him again about a week later. He looked at it and said, "Make it faster."

So I tried memory management optimizations and got some improvements to show him again. "Make it faster," again was his only response. Now I was starting to obsess. I've done nothing but try to make this thing faster for the last month, clearly I was missing something that he was waiting for me to realize.

So I did some research and then bought a book on more advanced C++ where I learned about threading. I spent a couple of weeks tinkering and making the queue multithreaded with some more improvement to efficiency. Not much mind you, because my laptop at the time was a single processor machine but you could see the parallel execution in the demo which I was pretty proud of at the time.

"Make it faster."

...

...seriously?

FINE! Yes sir! Let's see what else we can do. I was now resigned to spending this entire summer obsessing about making this thing faster. I poured over the code. Refactored it, found places where I could give it a tune up and managed to give it a big performance gain. Big enough that one of the other programmers joked that I must have taken out the sleep() function.

"Make it faster."

I don't remember making any more progress on it after that because the summer was almost over...but Mr. Miyagi left his impression.

I was obsessed.

As it turns out, it's a great thing to be obsessed with in the web world. I spent the early part of my professional career doing PHP development and after a while you need to make changes to the server configuration to really make PHP fly. That led me to getting into Apache tuning, then Nginx reverse proxies and caching. That then led to running my own servers and teaching myself how to run them efficiently and securely.

Which then led to building a performance tuned system as the backbone of all of our projects at Brightball that was able to take advantage of specific configuration options on the server like using APC shared memory. All of that then led into performance tuning databases. It started out with MySQL then it eventually led into Hadoop and MongoDB (it's web scale you know) followed by a turn into analytic databases like Infobright. When I started managing developers that obsession dovetailed into workflow efficiency.

Recently I even got the opportunity to save a company on the brink of disaster because of a botched rebuild by a team that didn't begin to consider performance (or much of anything else) on a very high traffic application. That's also another story for another day.

But all of that. All of it, created because of an obsession started by three...little...words.

About Me

My name is Barry Jones and Brightball is my consulting company. We help business leaders understand the long term effects of their technical decisions as well as navigating the process of interviewing software developers.

I also blog about technical topics quite a bit. If you enjoy my writing and want to support the habit please use my referrals to help me pay for my servers with Digital Ocean, my DNS with DNS Made Easy and my email with Sendwithus.