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.

Referencing Concepts from Presentations

I've been delivering shorter presentations of late.  To keep things compact, I've been experimenting with just saying "I'm assuming you're familiar with these things.  If not, there are resources to help you with them."

For audiences that do know the things called out as assumptions, this has worked really well.  What hasn't worked so well is when the audience doesn't really have a good understanding of a body of knowledge that I reference rather than cover.

In retrospect, this is obvious but I certainly failed to predict it.

I'm grappling with a number of possible solutions.  I'll probably think of more later but here is what I can think of now:

• Keep materials on hand that address assumed knowledge and adapt a talk to the audience's needs.
• Do a better job of determining an audience's needs in advance and screen out ones that don't have the prerequisites.
• Do a better job of determining an audience's needs in advance and pre-adapt a talk before showing up at the venue, setting expectations appropriately in the process.

I don't know where I'm going with this but any suggestions would be welcome.

Test-Driven Architecture Article Published

The article my friend, Mike Brown, and I wrote has been published.  The topic is how to apply test-driven development to architecture.  You can find it here.

Another Article Submitted

I've submitted a third article about architecture to InformIT.  This will probably be my last one for a while.  I want to go back to focusing on the database stuff.  This most recent article has a moderately interesting story.

It started out as a position statement: Encapsulation is the most important thing in architecture.  Encapsulation is already the most important thing in any software development effort, so that ended up coming off a little pompous.

I then rewrote it as something that addressed the root motivation which underlies encapsulation: longevity.  That article ended up being interesting but it didn't talk enough about encapsulation, which was the original point of the original article.

I settled on the working title "Five Tips to Maximize Encapsulation in Your Architecture" and I have received word that it will be published on February 20^th, 2014.

I'll post a link when it is published.