We Don't Need Campaign Finance Reform, We Need Campaign Audience Reform

People bitch about campaign money all the time.  An argument that is regularly made can be paraphrased as follows:

The campaign with the most money can buy the most votes so we need to modify how people get funded to ensure their interests align with the people's.

This is a specious argument.  The problem is not that we must control who has the money to buy the opinion of the voting public so that the right opinion is bought.  The problem is that we let people vote who are so easily influenced that an insubstantial, 30-second advertisement can change the course of their actions.

Think about it.  Is it really reasonable that someone who, essentially, votes in accordance with the last advertisement they happened to hear should be given the power to choose who lives and who dies?  Of course it isn't.

...and don't kid yourself.  That's nothing short of what voting is: the power to kill someone who disagrees with your choices strongly enough to not comply.  Sure, it's filtered through dozens of layers of indirection - judges, juries, laws, cops, et cetera - but that doesn't make voting any less what it is: the power to compel under threat of death.

Most people - even really, really stupid people - would agree that one guy shouldn't be allowed to take whatever he wants and kill whomever tries to stop him.  Nearly one-hundred percent of that group would agree that the power should no more be granted to two or twenty such people.

In fact, the public response to organized crime - groups of people who compel under (ultimately) the threat of death - seems to indicate that many of us have an implicit grasp on the non-linear nature of this kind of problem.  That is, everyone seems to know that two thugs are a little more that twice as bad as one thug.  Most of us know that a large organization that takes what it wants and kills those who try to stop it is a really dangerous, bad, and - dare I level a value judgment? - evil thing.

So why is a group of four-hundred million people doing the same thing somehow magically better?  Why do we care about the opinion of someone who just wants to vote themselves money?  Their vote certainly shouldn't count.  Why do we care about the opinion of someone who is persuaded by arguments like "Yuh-huh!" and "Nuh-uh!"?  Isn't that person's opinion noise at best and, at worst, and amplifier for the person who can buy the most ad-space in their field of view?

My dad likes to complain about how we live in a marketing-driven economy.  We all see some huge number of advertisements every day.  Corporations are using those ads to drive people's behavior.

How the hell is that the corporations' fault?  You see the ads.  You choose how (or, I guess in some people's cases, whether or not) to interpret them.  If you elect to be a subject of the media's sway, that doesn't make the corporation at fault.  It's your fault.

If I was playing chess with you, you'd not fault me for exploiting an enormous opening you left me, would you?  It's no more wrong for a company to exploit the weak minds of its potential buyers.  It's no more wrong for a politician to buy an ad spot that says there's no proof his opponent isn't a lizard man who worships the devil and eats puppies.  It's no more wrong for a major lobby group to fund that ad.

If there is any fault to be assigned - and, given the current state of affairs, I believe there is - it must be on the people who are influenced by such things.  If someone is too simple to vote properly, it is their own fault, not the fault of the people who take advantage of that fact.

A simple thought experiment can demonstrate this.  Imagine this scenario:

Ninety-nine percent of the voting public bases their decisions on their own thoughts.  That is, they take their own experiences, values, and judgments and synthesize a model of the world then base decisions on that model.  One politician's promises and track record jives with the model developed by fifty-five percent of those thinking voters - more than half of all voters.  His opponent has ten times as much funding but they both have enough funding to reach basically all of the potential voters.  Who's going to win in that scenario?

Naturally, it would be the person whom the thinking people believe will accomplish what they want accomplished.

Now flip it around.  One percent of the population thinks and the remainder votes in accordance with the number of advertising dollars to which they've been exposed.  In such a case, funding would be almost the only thing that matters.  If you imagine the same funding bias, it's pretty obvious who is most likely to win that election.

Both cases have a huge funding bias but only one has a corrupted election, the one where corrupt and weak people are allowed to vote.

We don't need better campaign financing rules.  We don't need better rules around advertisements.  We just need to start taking responsibility for our actions - including the act of voting - and peeling off the mantle of power the sticky fingers of anyone who can't or won't do that.

Another Generally Positive Review for Test-Driven Database Development

I would be a fool to think that my first book would receive only positive feedback.  This review, I think, is excellent.  I like it for three reasons:

1. My own self-interest
2. The reviewer clearly understood what he was reviewing
3. It contains actionable criticisms that will benefit a 2nd edition, if there is one

Vanity of the Database Authors

Mr. Carlson's review is, I think, generally positive.  This means that it will cause more people to buy my book, which is nice.  It also means that it fans the flames of my own vanity, which is really nice.  Most importantly, though, it means that more people are likely to actually read my book which, in turn, means more people are likely to take a sane approach to database development.

Deep Understanding

The author of the review in question clearly took the time to read, understand, and evaluate the concepts in my book.  I think a lot of people who buy books do this but, for some reason, only about half of people who write reviews appear to do it.

Mr. Carlson didn't necessarily understand all of my motivations or what I know about outside the scope of Test-Driven Database Development: Unlocking Agility but... hey... who's fault is that?  Right?

Actionable Criticisms

Not everything Mr. Carlson has to say is positive but those bits which are negative are highly actionable.  He says I give the appearance of not understanding normalization.  I do understand how to do it and why people do it in addition to why it actually should be done.  However, looking back, I can see how someone might get the impression I don't if they were basing their opinion solely on my book.  In the 2nd edition, I will remedy that by adding material that addresses those kinds of concepts.

Likewise, he makes the point that I don't address object-relational-mapping at all.  He rightly guessed that it is because ORM runs contrary the message I send - databases as instances of classes with tightly-controlled and rigorously-tested sets of exposed behaviors.  Nevertheless, his argument is that ORM is a very popular concept in designing interactions with databases is true.  If I ever get to do a second edition, which I happily think I might, and ORM is still popular, which I sadly believe it may be, then I will address it at that time.

I may address those concepts sooner, too, in the form of blog entries or articles.

Being a Jerk Is Only the Beginning!

It occurred to me while I was writing yesterday's entry.  That there is a cute little play on words to be had.  I wrote this post then and couldn't resist posting it today when the word "jerk" is flying around like hail in a windstorm.

I'm a Big Jerk

In physics, jerk is the 3rd derivative of position over time.  That is, velocity is the derivative of position, acceleration the derivative of velocity, and jerk is the derivative of acceleration.

In business, if you allow yourself an analogy between value-delivered and position, then some interesting parallels become apparent.  Your product would be analogous to velocity, as it is what continuously delivers more value.  Developers would then be agents of acceleration - constantly working to improve the product and increase velocity of value-delivered.

It would follow that technical leaders who take an interest in developing the skills of those around them would be agents of jerk - working to improve the rate of acceleration.

So yes, I am a jerk.  For the last eight or so years, it's been my primary objective to be a big jerk.

At long last, I can wear the label with pride.  Who am I kidding.  I've always worn it with pride.

To Jerkdom and Beyond!

Sometimes, though, I'd like to think I'm more than a mere jerk.  The fourth derivative of position over time is called "jounce."

Lately, I've not been as interested in being a jerk.  I've wanted to grow beyond that role and jounce seems like just the ticket.  What exactly would parallel that in the software development world?

I think a good analogy is leader-making.

As I get older and wiser, I take more of an interest (and show more aptitude) in developing new technical leaders.  Not that I'm anywhere near the level of Al Shalloway or Scott Bain, both of whom I consider to be my mentors, but I am starting to gain some traction nonetheless.

So, every once in a little while, in addition to being a big jerk, I'm a little jounce but, over time, I'd like to get more jouncy and less jerky.

Orthogonal Kinds of Growth

Anyway, it occurred to me that this is the real ladder of skill to climb.  Sure, having a better product is good but having a sustainable way of making it better is better.  Sure, having a sustainable way of improving a product is good but having an accelerating way of improving it is better.  You get the idea.

Being an expert developer is good and important but it is not the end of the journey.  There are other kinds of learning that are very important.

Going from being an okay developer to being a good developer is mostly a matter of practice and study.  Going from being any kind of developer to any kind of leader is a qualitative change.

At least, for me, it was.  It required (requires?) a fundamental shift in how I think about and interact with people and in what kind of problems I consider.  Going from being a leader to helping develop leaders probably requires just as big a leap but I'm so new to it that I can't really say.

Here is a handy picture I composed illustrating the distinction between kinds of skill and level of skill within an organization.

Planning Ahead

So, if you're a young developer and setting goals for yourself, you might want to consider that there is more than one dimension to your growth.  You can (and will need to) make yourself a competent programmer but you can do the most good by going from being a good programmer, to a leader, to a leader-maker.

If you work hard, maybe one day you can become a big jerk like me.  I'll do my best to be a bigger jerk by the time you get there and, if I'm lucky, I'll be more than just a big jerk too.

Technical Leadership Is Leadership

Being a technical leader can involve a number of challenges.  Between outside forces, long- and short-term pressures, legacy systems, and complex problems an architect, lead developer, or development manager has a lot on his plate.

Many of the most skilled programmers are comfortable with those kinds of challenges.  For a lot of technical people that's the only kind of problem with which you are comfortable.  Whether, like me, you are arrogant and demanding or, like many others, you are shy and reserved, there is a decent chance that you don't count people skills among your strongest.

Yet the technical challenges only represent half of the problems facing a technical leader.  To be truly effective, you have to be a leader of people in addition to a setter of technical direction.  That is, unless you want to do everything yourself.

I'm not saying that every kind of management problem necessarily rests on the shoulders of a technical leader.  I do believe, however, that empowering the people you work with to make better technical decisions on their own will have an enormous impact on your effectiveness as a technical leader.

For instance, I recently wrote an article for InformIT that touches on the subject, entitled Five Ways to Optimize Encapsulation in Your Software Architecture.  In most scenarios, every single step requires someone to not just be a leader in the area of design and architecture but also a leader of men.

For me, this is the biggest kind of challenge available in the software world.  It's hard and rewarding.  Sure, there are things that are harder - like trying to maintain really terrible legacy code - but those things aren't as rewarding because so little is accomplished in exchange for so much energy.  There are areas where I have more success - like maintaining code that was written the modern way - but that's not as rewarding because so little energy was exchanged for the benefit obtained.

Building up people's skills, guiding them, helping them grow, and influencing their decision making meets all my challenge criteria.  At least, it does now that I've become interested in that level of challenge.  It requires patience, understanding, and a close approximation of empathy - things that don't come easily to me.  On the other hand, in exchange for the enormous effort involved, you get enormous value.

The worst likely case is that you fail and nothing happens.  In the software industry, that's actually a pretty good bad scenario.  Once you develop your mentoring and leadership skills, the most likely case is that you will permanently modify how effective someone is as a programmer, building up a portfolio of recurring dividends over time.  Sometimes, you will help someone else become a true technical leader, improving the rate at which dividends are increased.

The rate of return on this kind of effort is very, very high.  For most of us, there's nothing more rewarding than hard work with a high rate of return.  So, the next time you're considering your position as a technical leader, try to think about how much time you spend leading people not just products.