Tag Archives: Driving Technical Change

We Suck at Apologies

apology_kid_opt

Several incidents in the past few weeks, both public and private, have led me to the conclusion that we all suck at apologies when we have offended people. I’d like to try and start a conversation to see if we can fix that.  I feel like I am qualified to give advice here, as I spent my 20’s as an angry and often offensive guy, who had to apologize quite a bit.  Because of this, I’ve learned a little of what works and what doesn’t.

Let’s start with a premise.  You said something that offended someone somewhere. They are angry, and they have called you out on it in some fashion.  (It’s vague, but every example I could come up with might have been offensive.)

“Why should I apologize, what I said (or did) was right?”

This here is the major problem we have with apologizing. We think that apologizing means that we are saying “I was wrong, and you were right.” It doesn’t.  When you offend someone, you have damaged your relationship with them. Whether you are an individual offending another individual or a company who offended a potential market, your actions have damaged the relationship.  The true purpose of an apology is to try and fix the damage in the relationship between you and the offended party. That should be your goal.

“I didn’t mean to offend you.”

Actions have consequences, intentions do not matter.  Actually, it would be better to say, intentions can mitigate consequences, but they cannot erase them.  Suppose I hit a young man with my car. That my intention was to drive home has no impact on the consequence that the young man’s leg is broken. Now the fact that I was soberly driving home, and did my best to swerve out of the way can maybe mitigate what the law says about my culpability, but it cannot fix the man’s leg.

So, good on ya, that you didn’t want to offend anyone. Unless you’re a deliberate provocateur I don’t assume anyone believes you did.  If you were deliberately offending people, I assume you don’t have any interest in apologizing.  So if you are apologizing, shut up about your intentions. You just sound like you are trying to excuse yourself.

“I don’t see what you are getting so upset about.”

This is a shitty, defensive way of saying “I don’t understand how I offended you.” That’s fine.  It is perfectly acceptable to not understand how you have been offensive. If you were able to wrap your mind perfectly around the thoughts and considerations of the offended party, you probably wouldn’t have taken the action that offended them. It’s perfectly fine to ask for clarification and an explanation. Just try not to phrase that request like an asshole.

  • “I’m having trouble wrapping my mind around this, can you explain where you’re coming from?” Good.
  • “Can you tell me why a person like you is offended by this?” – Bad.

“I can’t have said something homophobic, I have quite a few gay friends.”

Repeat after me: There is no such thing as a “ghetto pass.” That you have gay/female/minority friends does not mean you can’t say homophobic/sexist/racist things.  It means that you probably shouldn’t say them, and perhaps you should check to see if you still have those friends.

“You’re overly sensitive.”

This encapsulates a lot of things but at the core of it you are denying the reasonableness of the person taking offense.  The thought here being there are thoughts that while controversial, reasonable people can talk about without taking offense.  There are two problems with this.

The first problem with the reasonableness trope is that it assumes offense is an intellectual response.  It’s not, it’s an emotional response. Therefore reasonableness of the offense is irrelevant as offense in this case is not a product of the reason.  You can tell someone to stop being sad because their life is overall great, but if a personal tragedy has occurred, you can’t stop them from being sad. Likewise whether or not it is reasonable to be offended is irrelevant in the face of actual offense.

The second problem with reasonableness is that it doesn’t matter. Because reasonableness is part of the right/wrong discussion. “It is not reasonable to be offended over this, therefore you are wrong and I am right.”  –which is irrelevant, because apologies aren’t about right and wrong, they’re are about repairing the damage to the relationship.

“140 characters/email/IM is not enough to have a proper conversation about this.”

You’re right. Happy?  Now stop wasting time and move to a higher bandwidth form of communication.

“That’s not what I meant.”

Okay, this is a tough one, and it’s different from “I didn’t mean to be offensive.”  It happens when what they think you said and what you think you said are two different things.  It could be because of someone mishearing you. It’s also perfectly possible that someone is reading into what you have said or done, and giving it a context that makes it offensive to them. It’s also possible that you were not communicating well.

Again it’s time to remember what’s important, fixing the damage.  So apologize first, get acceptance that you want to fix the damage, then start to talk about the misunderstanding.  Ask what language you could have use to make your intended meaning come through.

So how should you apologize?

  1. Start with “I am sorry I offended you.” No qualifiers.  No “If I offended anyone.” You’re sorry that the relationship is damaged and that you caused the damage.  Start from there.
  2. Seek an understanding of what you did that caused offense, and acknowledge it.
  3. No excuses. Unless you were kidnapped, drugged and slammed down in front of a keyboard or phone, you are responsible for whatever you did to offend someone.  Even if it is a “not what I meant” incident. You’re responsible at least in part for the misunderstanding.
  4. Don’t apologize angry. When we are criticized, it’s easy to get angry and emotional ourselves, and therefore get in the way of a real apology.  If the criticism you receive makes you angry or defensive, then wait and calm down.  Very little relationship damage can be fixed with anger.

There you have it, apology advice from someone who’s had to do a lot of it. It’s not about winning an argument, it’s about saving a relationship.

Say Yes, And!

A friend and mentor of mine, Avish Parashar has a new book out named Say Yes, And! Avish has a ton of great advice to give you, and I highly recommend the book. Go forth and pick it up from Amazon.

Still here? Okay, let me tell you why I think this is a great book.

Improv Comedy

Avish’s philosophy has it’s roots in improv comedy. Improv comedy imparts a great deal of skills that can be useful in the work world:

  • Creative Thinking
  • Effective Collaboration
  • Public Speaking

One of the core concepts of improv comedy is the offer.  An offer is an attempt to create or develop a scene it is vital to creative thinking and collaboration.  For example a group of improv players get the location of a bathroom from the audience. Player 1 steps out, mimes slapping a wet mop down on the floor, and announces in a terrible Scottish accent that “Accckkk the lavatory has been invaded by the filth again!”

That’s an offer, he’s created a reality: he is a Scottish janitor in a filthy bathroom and it’s his job to clean it up.

Now Player 2 has the ability to do three things:

  • Block
  • Accept
  • Build

Blocking is bad.

Player 2 steps out and says, “What do you mean filth, this bathroom is a monument to cleanliness”.

See what he did there? He completely invalidated what Player 1 said. It completely derails the scene, the two of them have to start building from scratch. It doesn’t bode well for the scene.

Accepting is better

Player 2 steps out and says, “Well if you cleaned them more often, they would’t get this bad.”

This is better, he accepted the reality that player 1 offered and didn’t just bring the scene to a halt. The two of them can go on from there. But Player 2 didn’t make it any better. Nothing was added.

Building is best

Player 2 steps out and says, “Yes, and I need to get home fast today. I noticed that there is an emergency fire hose in the hallway. I bet it would blast the grime away.”

That is the beginning of a scene where something happens. Something dumb and disastrous, but that’s comedy.

Yes, And! is the name of an exercise that teaches you to build instead of blocking or merely accepting. Basically someone says something and you have to start your response with “Yes and.” It forces you to accept and add, which is building.

Back to work

How many times have you been brainstorming trying to solve issues or come up with something new and confronted by people blocking you:

  • Offer: Let’s build a full featured version of PhotoShop for tablets!
  • Block: But even the most powerful tablets are still not powerful enough to run desktop PhotoShop.
  • Accept: Okay, what would that look like?
  • Build: Yes, and we could use the camera to pull photos directly into the app, something that doesn’t make sense on desktops.

One response stymies progress, one doesn’t help it, and the last advances it.  Our goal should be to get to a place where the building response is our first instinct.  It doesn’t make the statement put forth in the block any less true, but most of the facts that get put forth to block ideas are obstacles to overcome, not reasons to prematurely abandon ideas. (PhotoShop Touch is doing very well thank you. )

Say Yes, And! by Avish Parashar is a book that will give you the tools and training to get yourself to think of building instead of just accepting or even blocking in the business world. Avish is a great teacher, and you can get a lot out of it.  Go get it!

Chameleon

Just because some skeptics are irrational about something, doesn’t mean that they don’t know they are being irrational. They know that if they gave the real reason for their resistance that people would find their objections unacceptable. In short if someone’s reason for not accepting that your company should support the iPhone and invest in iOS apps is that they think “Apple users are obnoxious hipsters,” they’re going to get dismissed out of hand. They know it, so they resist by bringing up “the Evil Walled Garden” argument. If you are able to mount a solid case against the “Walled Garden” argument, they switch to opposing Apple because “Android hardware would be cheaper”

Now to be clear, I’m not saying any objection to Apple is irrational. I’m saying if you specifically are going to resist Apple in an honest business focused decision for the specific reason “Apple users are obnoxious hipsters,” you are being irrational. I’m also not saying “the Evil Walled Garden” or “Android hardware is cheaper” are right or wrong arguments. I’m saying they can be rational arguments (with evidence and justificaiton) but that arguing those things without believing or weakly believing in them to cover up for an irrational objection is the problem here. 

Scenario
I worked with a guy who stated “I don’t believe in indices [in a relational database].”

I know. We can argue many things: what columns to index, clustered or unclustered, whether we should even be using relational databases… But we can all agree that if you are using relational databases at some point you need to use indices.

But that was this guy’s beef. He resisted any sort of argument that he needed an index on any of his tables. He showed us articles that said “YOU DON’T HAVE TO USE INDEXES… on tables with many more writes than reads“. When performance was effected by a lack of an index, he said the performance was acceptable. When performance was still an issue he went into a long diatribe about how hardware upgrades on the server side would make his performance issues go away in an acceptable timeframe.

Then we introduced ORM (object relational mapping) into the environment. He objected…. loudly. Why? “The performance tradeoffs are too great.”

Clearly his issue with ORM wasn’t really performance. He had no problem waiting for performance to be enhanced by hardware upgrades, which is itself kinda silly.  And his acceptance of poor performing SQL was not because he hated indices. It was because his real resistance was based on something else.

What was that real reason? I don’t know but I have my theories. (I became much friendlier with him later, and it never came up.) I think in general the truth had more to do with trying to limit the number of new technologies and techniques so that he could keep a handle on the environment as he was also doing a fair amount of managerial, administrative, and business work as well. When you’re stretched so thin, you have to figure out a way to contain complexity. But that’s just my theory.

Ultimately his real reason doesn’t matter. Because like all of the Irrational types, you should ignore them.

It’s tough though, because these guys masquerade as rational types before you realize what’s going on. So how do you spot them?

A few signs:

  • Drastically changing objections, did these guys start out as Burned, and then change to Time Crunched when confronted with evidence?
  • Dramatic reversals of objections raised in previous discussions, did they go from indifference to performance to performance being the only thing?
  • Being a Chameleon in the past, if they have done this to you before, and you haven’t figured out a root cause then it is likely that they are repeating.

In general these guys and gals suck. They waste a lot of time because you are fooled into arguing with them rationally since they act rational. But if you suspect you’re face to face with a chameleon: cut your losses – move on to try and convert someone else. Either they are Irrational, and you saved yourself some grief, or they aren’t, but they’ll be easier to bring around with more converts on your side.

You Are Not Your Technology

Do you see you have a “friend” that sees themselves as an X developer?

  • I’m a JavaScript Developer…
  • I’m a Flash Developer…
  • I’m a PHP Developer…
  • I’m a ColdFusion Developer
  • I’m an iOS Developer…
  • I’m an Android Developer…

This statement usually indicates that this person will be very resistant to any sort of technical change you are driving that in any way competes with those technologies. Why? Because they have worked their technology into their identity.

When one makes a technology part of their identity instead of a tool they use, they see any competition, replacement, or massive alteration of it as an existential threat. Keep in mind, they see this as a threat to themselves, not just the technology. People get crazy irrational about existential threats. It’s not their fault. Fight or flight is built into us; carefully understand and weigh your options is not.

In the long run this is a bad thing.

  • Viewing change as a threat makes you fight it.
  • Viewing change as an obstacle makes you rise to overcome it.
  • Viewing change as a challenge makes you expand to face it with pride.
  • Viewing change as an opportunity makes you seek to capitalize on it.

The goal should be to move your reaction to further down this list.

Oh yeah, I know you don’t really have a “friend” with this problem.

What’s the Fix?

What do you do to fix working your technology into your identity?

Immediately start talking about yourself by what you do, not what you use:

  • I’m an Interactive Developer (thanks Lee Brimelow)…
  • I’m a Web Developer…
  • I’m a Mobile Developer…

Even if you don’t believe it, even if it is uncomfortable, even if you have to ditch business cards and domains, do it. Identity is about perception, both yours and others. You won’t believe it till it’s rote for you. Others won’t believe it until you do.

Start learning about the competing technology. Figure out why people chose it over your technology. Figure out what parts of its philosophy you can absorb to make you better in whatever technology you use.

Why bother?

There are a lot of excuses you can use to prevent yourself from fixing this:

  • This technology has a lot of life left in it.
  • This technology is dominant, and will be forever.
  • I’m too old to change.
  • I don’t have time to change.

Bullshit

We are on the cusp of yet another major shift in computing, the post PC era. The post PC era has more significance than I can wrap my mind around, but one thing is glaringly obvious: The device, the browser, the platform is being swapped out much faster than in the past.

User adoption is a major brake to technology advancement. The 3 to 5 year cycle in swapping out technology is dropping. What will happen to the rate of technology change when people are swapping out their major information device every 2 years? Well it has the potential to be at least twice as fast, if not faster. Technologies are going to rise and fall faster. Those who see technologies are tools to be swapped will fare better than those who think they are their technology.

Finally, your technology is not special or safe. 1 year ago BlackBerry was still the dominant smartphone manufacturer. 2 years ago WebOS still had a shot. 3 years ago there was no iPad. Will JavaScript be dominant 5 years from now? Maybe Dart will gain traction? Maybe browser makers will make the jQuery DOM API native to the browser? Maybe Apps will win? Maybe NodeJS usage will eclipse PHP? The point is nobody really knows what the future will look like exactly. But those who will have the best shot at facing the future and succeeding will be those who view it more as an opportunity and less as an existential threat.

The Fetishism of Douchebaggery

In the wake of Steve Job’s passing there have been a number of takes on his character and impact. One of the common themes that have permeated a lot of reactions in the blogosphere and twitter is Job’s tendency to be a douche. Most people have been negative on this, but a recent article, The Jerk on TechCrunch by MG Siegler has gone the other way, stating:

the tech world could probably use more jerks.

I couldn’t disagree with this statement more, although I agree of much of what Siegler is saying in article. How is that? That sentence is the sound bite distillation of a bigger point: we need more and better criticism in the tech world. That is totally true and not contested; however, I contend you don’t have to be a douche about it.

Why not? Siegler argues that Job’s and in his case Arrington’s abrasiveness had a positive impact. Mostly because in both of these cases, they deal with someone in power being douchy to someone with less power. People have to listen to their superiors, even if they don’t like it.

Most of us in the business of driving technical change are advocating to equals or superiors. When people aren’t compelled to listen to your douchiness, they don’t. Poor delivery in these cases will almost completely ensure that no one will listen to you, no matter how right you are.

Additionally, it presumes that somehow Steve Jobs could be Steve Jobs, give respectful criticism, and people would have not listened. Granted, perhaps being Steven Jobs had to include that abrasiveness and so is unavoidable. But I think once he made it, once he was the great and almighty Steve Jobs, he didn’t need to use it as a tool anymore. Yet reports state he still did. I’d believe that his abrasiveness was a slight obstacle to his success that in his case was outmatched by the rest of his considerable positives. Steve Jobs had a huge impact on the world, far and beyond what most people accomplish. In this sense he was a “Great Man” in the classic definition of it. However that does not mean that everything about him was great, or an advantage. Grownups can admire people and yet still acknowledge flaws in them.

But in any case, I’m not informed enough to know if douchiness worked for or against Steve Jobs with any authority. However I’m firmly convinced that it won’t work for the rest of us.

 

Angry Old Technologist

The Angry Old Technologist (AOT) has been around forever. They built the system that you are trying to change. They’ve forgotten more than you’ll ever know about programming, hot shot. In short, you’re trying to change things, they’re yelling at you to get off their lawn.

Now, that’s not to say anyone with more then a few years of experience is a senior citizen. Nor that all criticism from people that share characteristics with this group.

Unlike last week’s character, the Angry Young Technologist (AYT), I don’t have experience being the AOT. At least I think I don’t. I’m fairly sure I’ve never been the one saying we absolutely shouldn’t change something. I may have argued against a particular change, or implementation, but not generalized change. Therefore, my thoughts here are more conjecture and inference than actual experience. Anyone who sees themselves in this description is welcome to set the record straight on anything I get wrong.

Scenario:
I was once at a conference where there was a Q&A with representatives from Microsoft, Yahoo, Google, and, of course Adobe. Someone got up and started talking about the current pace of change, and how every year all of us were coming out with more tools and technology. And he got angrier and angrier as he spoke, until he blurted out:

Why do you guys keep forcing me to learn new stuff?

And therein lies the key problem of the Angry Old Technologist: progress forces change; change forces them to learn; and they don’t want to.

Now, back when I was an AYT I never understood this. How can you hate to learn more things? As I get older, while I don’t resent learning new things, I can understand why you might.

I’m lucky, part of my job is to keep learning new things. Not all jobs build into them the need to learn new things. Most don’t. When you’re younger and have less responsibility, it’s not a huge deal, you can just spend your free time learning new things. As you get older, other concerns come in, like family, kids, housing, health care, retirement funds, school districts, PTAs ARRRRGGGGGGGHHHHHHHH.

All that stuff, some of which people refer to as your real life, destroys your free time. When you’re young, and passionate about technology, that free time is where you spend long hours focusing and mastering new things. When you get older and attached, you don’t have that time. Learning goes from something you love to do and you can easily do because you have copious free time, to something you have to make time to do.

And that’s if you’re passionate about what you do. If not, you start as a young person having to spend time to play catchup. By the time your free time is gone, the idea of learning new things terrifies you because you don’t know when you’re going to do it, and you never know the worth as all technology has an expiration date.

Where does the anger come from? What do you get when you combine no time, with years of responsibility, the pressure to constantly learn new things, some of which may be “dead” before you even implement them, and fear of what happens when you fail? You get rage, pure and simple.

There is bad news here for the guy from the conference, and for all of the other AOTs: There is no stopping the change. We technology companies might impact, alter, or nudge the waves of changes. But ultimately we don’t control them; they are caused by too many disparate sources to be controlled, even if we wanted to.

So what do you do when you’re face to face with an AOT?

  • Well they’re irrational, so you should ignore them. Didn’t you read my book?
  • Learn from their knowledge of the current environment.
  • Engage them and try to bring them onboard without patronizing them.

So what do you do when you’re face to face with an AOT… in the mirror?

  • Accept that the future cannot be stopped.
  • Accept that it’s okay you can’t grasp every new piece of technology.
  • Be part of the change, which will eventually replace what exists now, instead of opposing it.
  • But mostly stop being so angry.

So what do you do when you’re face to face with an AOT and they’re your employee?

 

  • Build-in continuing education and skunkworks into employee goals.

 

This is a tough group, and they are some of the most resistant to change. They’re also tough because a lot of them end up in management. So avoid, if you can, defer if you can’t, and give them opportunities to save face along the way.

Angry Young Technologist

The Angry Young Technologist (AYT) is fresh out of college, or in some cases high school, new to the workplace, and has strong beliefs. They get their information from whatever sites are the bleeding edge, and are a great source of information about up and coming technology.

You might think that since AYTs are interested in the latest and greatest, that they are perfect choices to help you drive change, but they are hampered in their ability to help by a couple of things. If they are on your side, they are tenacious allies in the quest for change. But their choice of sides wasn’t governed by any convincing arguments that you made, merely that you chose something they liked. They might agree with you, but they can’t objectively review your solution and tell you if it doesn’t fit the environment. If they oppose you, they are obstacles that will not listen to any argument.

Now, not every younger person working in technology is this type. I’ll make it clear I’m not saying that at all. Venn diagrams and all that, not every YT is a AYT.

Scenario:
You enter a typical staff meeting and the AYT has a problem with the latest upgrade to the site.

“Why are we still using stored procedures for this application? We could switch to an ORM solution, and not be tied down to the SQL server. ” or something like that.

And, on the surface, it’s true. Stored procedures in this environment have to go through the DBAs. This adds an extra day to updates. It’s also low on the priority list of the DBAs and so can take more then a day. On top of that, a lot of the developers have good SQL chops, and are a bit better at SQL than the DBAs.

The AYT tends to find lots of issues like this:

  • It’s absurd that we aren’t using [insert currently rising language here].
  • Why the hell are we still using [Technology older then 2 years].
  • The fact that we have to do [whatever policy mandates] is a joke.
  • If only we did [whatever] we wouldn’t have all of these problems.

Then on top of it, they have terrible delivery. Words like “stupid”, “idiotic”, and worse are their goto adjectives. At this point in their careers they don’t have a firm grasp of diplomacy, tact, or the basic understanding that someone can disagree with them and not be stupid.

In the case of the above mentioned SQL policy he’s got a point. It’s terribly inefficient. The DBAs have other things to do, don’t get updates out on any sort of schedule, and don’t add a lot of value to the process.

The AYT is a few years out of college, so he wasn’t here while this app was being built, deployed and used in production for the first year. He didn’t track down crazy bugs in the reporting system. He didn’t enter 50 bug fixes that one week in September.

What the AYT wants to do amounts to a complete burn and redo of the existing code, simply to make the code technique (not quality or features) match current practices. It’s a bad idea, and people smarter than I have made this case.

This one example points to the root cause of the AYT’s lack of reason, a failure to understand the history of a given environment. Also he tends to not understand that decisions are made for more than just pure technology reasons. AYTs often don’t get the context of business, personnel, or other non-technology concerns.

  • If an organization has deep expertise in proprietary technology x, switching to free technology y has high retraining costs.
  • If an organization has expensively committed to technology x and technology y is only moderately better, the utility of switching is low.
  • Policies that effect technology are more often than not driven by non-technical reasons. While CYA policies are annoying they combat the high negative utility of drawing management ire.

These are all true, but would be dismissed by the AYT as irrelevant. Most of us that have been around for a little bit know that each of these has a tremendous impact on organizations.

Combine that failure to grok things with terrible delivery and you get one outcome: almost total lack of adoption for the things that the AYT champions. He’s making the wrong arguments, and he’s doing it like jackass.

I’m being tough on the AYT because I used to be him. I thought managers were idiots, upper management didn’t get it, and if only we did X, things would be so much better.

How’d I get over it? Getting beat by people with better people skills and less technology chops wears thin after awhile. Being successful the few times I stumbled into diplomacy helped. Not starting from a position that people who didn’t immediately agree with me had brain damage was a healthier place to be.

In short, experience is the best teacher. I wish I could have learned some of that easier and earlier.

Not all is lost. There are some positives to be gotten out of this character, whether you are one, or are confronting one.

  • Their passion, while perhaps a little rough, can be a great agent of change
  • The need for a given rule, procedure, or technology expires before the practice of it. They may be blustering, but they can also be the canary in the coal mine.
  • If they realize their delivery and vision of the problem are wrong, they can become a rational actor.
  • Coming along without the baggage of the past allows them to catch things in need of genuine change.

Do you know any AYTs? If so, try and take them under your wing and explain context when you can. When you see them crash and burn, let them know why.

Are you an AYT? After you’re done flaming me because “I don’t get it”, do some self examination. Are you ignoring non-technical factors? Are you being abrasive? Are you arguing against change because it doesn’t use the latest and greatest?

And don’t worry, my next post in this series will be on Angry Old Technologists who can be just as bad.

Make Your Line Longer

Ray Camden wrote a blog post earlier today about my demeanor towards ColdFusion advocacy. I am very appreciative of his kind words, and thought it would be a good time to share a little bit of the philosophy behind my attitude.

A phrase that has stuck with me through the years is “Make your line longer.”

It’s my paraphrase of a story from Zen in the Martial Arts by Joe Hyams.

Basically the story goes :

I will remember one of my initial sessions at his dojo in Los Angeles where I was practising Kumite (sparring) with a more skilful opponent. To make up for my lack of knowledge and experience, I tried deceptive, tricky moves that were readily countered. I was outclassed, and Parker watched me get roundly trounced. When the match was over I was dejected. Parker invited me into his small office; a small sparsely furnished room with only a scarred desk and battered chairs. “Why are you so upset? ” he asked. “Because I couldn’t score.” Parker got up from behind the desk and with a piece of chalk drew a line on the floor about five feet long. “How can you make this line shorter?” he asked. “I studied the line and gave him several answers, including cutting the line in many pieces. He shook his head and drew a second line, longer than the first. “Now how does the first line look? “Shorter,” I said. Parker nodded. “It is always better to improve and strengthen your own line or knowledge than to try and cut your opponent’s line.”

From KenpoKarate.ie (emphasis added)

The idea here is that people waste time trying to undercut their opponent instead of improving themselves. Undercutting an opponent benefits you once. Making yourself better is an investment that benefits you for the rest of your life.

What does this have to do with ColdFusion? The reason I don’t reciprocate to haters or bash competition, is because these are attempts to cut at their lines. I’d rather lengthen my own line. Show how ColdFusion is better. Make it do cooler stuff. Honestly accept and answer criticism and make ColdFusion and its ecosystem better.

And for those that don’t believe it can work, I will tell you it can. I’ve gotten into several conversations on twitter with people. One of my favorites I remember the best was with a Ruby on Rails guy who was bashing the tag based nature of CFML. Instead of fighting the tag/script war I talked about CFScript, and pointed him to my Google Translate API CFC on github. He admitted me might have been wrong, and was impressed by the fact that ColdFusion had unit testing. I didn’t convert him, but the next time he encounters ColdFusion he’ll take it a little more seriously.

The fact is that some people are haters, and will never accept somebody else’s argument. They’re d-bags. And with so many of us coming to age in a post-Internet world, they’re just getting worse. Don’t waste your time.

But there are many more venters in the world. They come to something they don’t understand and get frustrated, and when they do they vent. When they vent about ColdFusion, see it as an opportunity to help un-frustrate the frustrated, not a chance to avenge the hate. Do it by making your line longer, and not trying to cut the other guy down.

That’s what I’ve tried to do.

Three Choices

I was reading a review of Driving Technical Change by Roger The Geek (his label, not mine.)

He has both positive and negative things to say about the book. Read the review, I think his criticism’s fair. However he said one thing that sticks out to me.

Do you want to fight for technical change on your team or do you move from team to team or company to company looking for that great fit?

Basically, in early talks I gave on this I phrased it a little different:

You have three choices:

  1. accept the status quo
  2. leave
  3. change your organization

 

This was inspired by Martin Fowler‘s quote:

You can Change Your Organization or Change Your Organization.

The problem I see in Roger’s question, is that it sort of assumes that work has only one compelling feature: the work. I see this from time to time, and I’m not entirely sure that Roger is saying this, but I feel in the minds of many people it assumes that passionate people don’t stay at a job where people are resistant to change. It implies that the people that do want better things have to leave to grow.

I know it’s not trendy to say this, but there are times where being an adult means that you can’t just hop from job to job following your passion. Having a family, a mortgage, and other ties require that from time to time you have to suck it up for a paycheck, heath benefits, and stability. You aren’t always free to leave.

This is not to take shots at people who set up their lives to enable this. They value their freedom, and they earn it by sacrificing other things. I respect and admire that, but theirs is not the only path to passionate fulfillment in your life.

This is also not to say you shouldn’t try to leave a bad situation. Just that you have to weigh your options and take passes on riskier ventures waiting for the right opportunity.

But while you wait where your coworkers aren’t interested in change, what do you do? If you cannot leave, your choice is between accepting the status quo, or changing the organization.

I’d argue that if you accept that status quo it is the first, if not the only, step to giving up on the passion at your job. That’s cool. No judgment. It might be right for you. It was decidedly not right for me.

Let’s assume that it’s not right for you – you have the passion to want other things, and as stated before you can’t change jobs… then you’re going to have to change your organization.

At first that seems like you’re making a poor decision. Fighting a fight that you cannot “win.” But what is “winning”? I’d argue that making your organization better isn’t a journey to a destination – it’s the journey itself. So even if you don’t get everything you want, you can still effect some change, rejecting the status quo, and making yourself a little happier in the meantime.

Success at change has to measured by your deltas, not your destination or current location. People tend to lose sight of the fact that between where you are, and where you ultimately want to be, there are many, many better places.

Keep that in mind as you drive change.

A Different Take on Expertise

Saw a great post, Today’s Noise, Tomorrow’s Dinosaur on General Musing.

One of the points I make in Driving Technical Change is that expertise constantly decays. Every piece of technology out there today is evolving and changing. If you stop paying attention to areas of your knowledge, then you will lose expert status.

The author disagrees with me. He states:

I think this is a sweeping generalization which I believe is wrong, and I know is wrong for me. I regularly go on sabbatical for 3-6 months where I don’t or hardy use a computer, with hardly I mean I checked my mail once after 3 months. In this time due to the fact that I’m traveling I don’t read computer books or magazines. Coming back after this time I notice one important thing, nothing has changed except the version numbers. New features have been added to old software, new design patterns have been thought up and new frameworks have been created, whole sections of the linux kernel have been rewritten. And with in a week I am at my expertise level, and a week later I have covered most of the important things I’ve missed.

Impressive that he is able to do so. I, of course, think he is an outlier. However, I agree that 3-6 months off won’t kill your expertise, assuming the rest of the time you are working on it.

What I do agree with him about is the idea that there is a lot of noise out there, and following it doesn’t add to expertise. He’s right that following every single release note, or bleeding edge build of your tools won’t help your expertise.

But I still believe you need to keep up to date on expertise maintenance information. I also believe tuning it out for long periods will cause your expertise to atrophy.

The hard part is to judge what is noise and what is signal.

For me, it, like many things, is like pornography, “I know it when I see it.” If I had to categorize what fits that bill for me, it usually comes down to source. Certain sources–bloggers, publications, companies–seem to always put things out that expand my thinking, illuminate choices, and convey tough concepts in easy to understand metaphor.

So, sorry no easy answer, but I can at least tell you it’s not in the release notes.