Programming with Wisdom

_DSC4737What is wisdom. Wisdom is knowledge with the weight of experience that has been evaluated. The key part of the sentence is ‘evaluated.’ When I was a kid, my father told me, “Ian, no matter how many years you live, I’ll always have 21 more years of experiences.”

Of course, me being who I am, I challenged him on the spot. I said, “so if you take ten 65 year-olds, you can guarantee that they are all equally wise?”

He reluctantly said, “No.”

So I said, “So just because someone has more years of experience, it doesn’t mean they got the same amount out of them.”

That is where the ‘evaluated’ part comes in. Someone who has done lots of things, but never reflected on them didn’t receive any wisdom from those experiences.  They likely created relationships, memories and so on, but they probably did not create much wisdom. Wisdom is created by thoughtfully reflecting on experiences, evaluating them and determining the merits or deficiencies. That’s right, wisdom is largely created. Acquiring wisdom isn’t passive and it also requires critical thinking. Someone who spent their life repeating the same patterns over and over again didn’t passively acquire much of wisdom.

Now take this definition into the professional world of programming. If you look at three resumes, one has a year of experience, another has five and yet another has ten, our industry says that the person with ten years experience is the senior programmer. Bullshit. He’s senior because his rear was in a chair for five more years than the second guy and nine more years than the guy with a year? That’s what they tell us.

I see it frequently where a full-time employee with little to no wisdom is promoted to senior simply because of the amount of  ’ass-in-chair’ time. I see young guys come in with way more insight and even wisdom than others with many more years on their resumes. This is a symptom of our unevolved way of structuring corporations. But you need hierarchy right? To some extent, but what you really need are people who understand what the hell is going on and what their role is in doing it. I’ve seen junior level-people with a lot of potential who are given a senior level title. Immediately they start trying to quiet their actual seniors and be the voice. This is a perfect example of over-indulgence within corporations. Now you’ve stunted the growth of someone who had potential merely because you want to indulge their fantasy of being the man. Good job.

You aren’t senior until you have wisdom. Wisdom isn’t knowing what the best MVVM library is. Wisdom isn’t using Visual Studio 14 in beta. Wisdom isn’t ten years of experience. Wisdom isn’t having worked at Microsoft, Google, NASA, etc. etc. You know when you have wisdom, but you don’t know when you don’t have it. It sucks like that.

Another problem with wisdom is that there has to be a demand for it in order for it to have any value. Lots of places there is simply no demand for it at all. People want to work with buzzwords. People want resume padding. Managers tend to pander and over-indulge. What we get is a giant cluster-fuck, too often.

So how do you develop wisdom while programming?

  • Think critically about what you are doing, what those around you are doing and what the results are. You have to be honest. If you lie to yourself you aren’t gaining wisdom, you are increasing denial or making some type of personal schism.
  • Take the best parts of your experience and keep applying it. Throw the other parts away. Journal about things that work and don’t work and try to determine whether it’s a personal lack of understanding or whether it’s just a bad practice.
  • Talk to people who seem like they have wisdom and ask them questions.
  • Quit trying to be right all the time (guilty!) Try to start assuming that you don’t understand anything at all and carefully measure along the way. Think like a scientist not a politician (unless you are on management track, but then this isn’t for you because this is for programmers).
  • Live life! Life lessons in general apply to your career. Get off the computer and go do something interesting that requires thinking differently.

Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect. Think. Do. Reflect.



Haibun: Vieques

StarsTips of sliver moon point away from mangroves digging into the mud of
Mosquito Bay. Sensual decay clings to roots where fish lie. An oar
plunges into billions of diamonds, alive and full of light 100 times
bigger than each microscopic gem. Blue glimmer dances with the stroke
and leaps behind the trail of frightened fish betrayed by

Her bare finger
traces a heart
in magic water


80% Code Coverage

Today I was talking with my colleagues about code coverage. A team of remote developers had questions about what we were targeting. 80% is commonly a number that is mentioned, for good reason.

However, almost every project I’ve been on, the code coverage percentage doesn’t point to the really important thing: complexity.

Complexity is where most defects occur. Defects typically don’t occur in code that is adding 2 + 2. It occurs elsewhere.

So my current equation for calculating a target code coverge is:
unit test target code coverage % = % of app’s complex logic * 1
where  complex logic == method cyclomatic complexty > 10
This is minimum. This is what I would feel comfortable shipping. Covering simple methods is great, but to cover them and neglect complexity for the sake of getting the numbers up is the wrong approach.
Test complexity first.



Honey, I Didn’t Hear You

I’ve played in bands a lot of my life. My girlfriend swears I only hear 5% of what she says. I conceded I had a problem. One day I thought I had a great idea that would prevent any further damage. I wanted to invent a pair of earphones that would measure the decibels being output from the headphones and then limit the signal just before the decibel level where hearing loss occurs. I wanted maximum volume with little to no damage to hearing. I went to the U.S. Patent Office and did a cursory search. Nothing really came up so I did a quick Google search.

I saved a lot of time on my ground-breaking idea when I found these DBLogic Volume Leveling Earbuds (and Headphones).

I put in an order right before leaving for vacation. They just arrived. They are working well. I cranked my headphone amplifier up from 2 to 10 and the level stayed relatively flat. You can hear it adjusting the level which can be a little distracting. This happened rarely though through two listenings of, The Darkness, “Hot Cakes.”

If you are like me and can’t resist doing things that could be somewhat self-destructive, these are good protection from yourself. If you are a developer who listens to music all day long while coding, your hearing might be saved with these.

*Note: I initially tried to order these from the company website, but the link was broken. You can find them on World Wide Stereo for $31 at the time of this post.


guitar playing

Coding Journal #3: Being Catalyzed

It’s the last day of a long contract. For me the measurement of the quality of a contract is how much I grew. I grew a lot over the last 17 months, but I’m not certain how much of it I can attribute to the actual work I performed there.

However, I have to give credit to a small number of the people I met there who were a catalyst for my desire to learn more. I’ve heard this a lot lately. Be a catalyst. Like foreplay, it’s easy to do, but few do it well or often.

Most of my growth is simple personal growth driven by my own desire to get better. I think this would have happened regardless of where I was working. I worked on technologies outside of work. I read books outside of work. I attended conferences outside of work. Most of the growth I acheived happened outside of the contract work-place, but without interactions with these catalyzing people, I never would have been stimulated to acheive as much.

Being a catalyst can be something as simple as casually mentioning new technologies or theories to your fellow programmers. It can be taking initiative on a proof-of-concept. Many of these things propel others in a new direction or change their views in a way that is productive.

On this particular project there were few people who were inspiring or catalysts, but those that were had great impact. These people weren’t catalysts always in the context of work. Many times they were catalysts while getting coffee or having lunch. These are the people you want to be surrounded by because they stimulate the parts of your brain that are dying to be brought forth.

In the midst of a culture that tirelessly worked to push everyone down to the lowest-common denominator (and it was low), there were these few people who in their own unique ways breathed some life into an otherwise meaningless project and environment that resembled an episode of “The Walking Dead.”

I’m going to name a few of them: Sean Walker, Glen Bryan, Bryan Gertonson and Jason More. Not only were these guys smart and talented, but they had personality. It takes personality to be a catalyst. I meet smart guys all the time with the personality of a coffee mug and they are not catalysts. They make you wish someone would fill them up with some methamphetamines or bad crack just to make them interesting.

So now I’ve mentioned some of the significant people who were catalysts on my project in the same paragraph as catalysts that are addictive drugs. It’s the yin-yang of chemical addiction. You can be addicted to drugs to stimulate your brain and ruin it or you can be addicted to wonderful minds that make the chemicals in your brain that are associated with creativity, passion and laughter, overflow on a regular basis.

These people are my drugs and I can’t wait to be catalyzed again soon.

*shout-out to H. Alan Stevens for being a catalyst at “That Conference.”

Ian Felton is a thinker, brewer, tea drinker, programmer, entrepreneur, writer, musician, human, American