Xaprb

I’ve been going through some old stuff that got thrown into a big cardboard box during my move in September. In particular there are a lot of papers from my desk — old notes I’d scratched down, legal pads full of notes taken during phone conversations, and so on.

Reading through these old conversations brings them back to me. There are notes from my first “non-interview” with Alan Rimm-Kaufman of The Rimm-Kaufman Group. (That non-interview led to me leave my previous job and join his company.) And lots and lots of notes on conversations I’ve had with others at the Rimm-Kaufman Group. And there’s a napkin with scribblings from when Peter and Vadim and I were riding in a car last April — the first time we’d gotten to talk alone together since I joined Percona, although I’d gotten to know them somewhat during an intense writing project that spanned a year.

One of the things that’s really neat about reading through notes from the past 3.5 years is seeing what changes over that time. For example, I’m seeing things I was working on that I’m not even involved in anymore. But even more striking is what doesn’t change at all.

To put it briefly, their focus on values is completely consistent over time — I see refinements, but the deepest core is constant. Their values come from who they fundamentally are, and they don’t change. Reading these notes from our conversations is just like reading notes I might have written a few days ago. This is a real source of inspiration and gratitude to me.

Here are some samples, slightly paraphrased because I’m expanding my shorthand back into real sentences:

• I believe that people are best at what they enjoy doing. Employees having fun and making money provide a unique value to customers.
• The best way to deliver value is to match your pay to the benefits of what you deliver, so there is only one motive and it’s aligned to the customer’s interests.
• Your career should be what you love.
• Open communications. There should never be a punishment for speaking what you feel.
• Non-experts have a lot to teach us.
• You should have a stake in the outcome.

I won’t say which quote came from whom. It doesn’t matter — any of them could have said these things. And a lot of people say such things, but the fruits of their labors bear witness to their true belief in these principles. This just supports me in my own convictions. I hope I provide good support in return.

From these conversations I have turned down many paths I might not have otherwise taken: reading Let My People Go Surfing and countless other books, for example. One of the things I love about this cycle of reinforcement is seeing the businesses follow this leadership, both internally and externally. And when I feel like I’m not aligned with my own values, I can have a conversation with one of the people whom I know share my values, and they help me find where the disconnect is and get back on track again.

Here’s an example: a a recent post on pricing from Peter, and one from Alan from a while ago. They both understand that the pricing model drives the behavior towards the customer, and they’ve both aligned with the customer’s benefit. It’s completely consistent because it’s truly who they are.

One of the other neat things about working with such people is their intense practicality. I am sometimes motivated so much towards what I feel is right, that I need their help to see a clear answer to the question “how much does this matter? What’s a good balance?” They help me to stay more centered.

These people have been and continue to be sources of inspiration and strength for me. Thanks!

I got some interesting comments on my previous article about unit testing Maatkit, including echoes of my own conversion to the unit-testing religion. One of the objections I’ve heard a lot about unit-testing is how it’s impossible to test code that talks to a database. “It’s too hard,” they say. “Oh, it’s easy to test a module that calculates a square root, but a database? Way too much work!”

Over in Maatkit-land, Daniel Nichter and I practice test-first programming, AKA test-driven development. That is, we write tests for each new feature or to catch regressions on each bug we fix. And — this is crucial — we write the tests before we write the code.* The tests should initially fail, which is a validation that the new code actually works and the tests actually verify this. If we don’t first write a failing testcase, then our code lacks a very important guarantee: “if you break this code, then the test case will tell you so.” (A test that doesn’t fail when the code fails isn’t worth writing.)