Expertise takes time

Once I borrowed a book about Fortran (yeah… I’m that old) and during the weekend I read it and did a few experiments. I was able to do quite a lot with it already.  I have to be honest, it was not my first nor second programming language and it was not that different from the Imperative languages I already worked with.

This seamless moving between programming language or technology trick us into thinking new things are not that hard to learn. We believe we can master a new technology after a “weekend workshop”.

Business as usual

For someone on the business long enough, most things are pretty much the same most of the time: you have a list with values and with some of them do something (Example: MapReduce pattern) or a HTML form with a bunch of fields and we have to validated them (as Angular does really well), … For all the exception highlighters out there (guys who always highlight the exceptions about what you say), I emphasize it’s most of the time.  Big percentage of our time is solving the same problems, but with a twist.

When we start using a new programming language, we will most likely solve a similar problem to one we already solved before. The only new challenge is the language. There should be no surprise to how well we do. We are mesmerized and taken to believe we already master it. And it gets worst as experience grows.

The devil is on the details

I always thought companies were being conservative and narrow-minded by wanting to hire people with many of years of experience on a specific tool or technology. In some cases it is correct, but not always.

After 20 years on Java, as in my case, new languages are received with some resistance and new paradigms are skew towards OO. It requires tremendous effort to fight this bias. If companies only hire experts, they end up stuck with a bunch of weird shaped cookie cutters when all they need is a round shaped one.

Most of the time we are doing normal things, but not all the time. The little details that make the difference are not more of the same, but the exception. It is then that expertise makes the difference.

Expert in failing

Expertise, on my point of view, is more about knowing what not to do rather than what to do. An expert as enough experience from plenty of errors and by not falling into to them again, increases chances of success. If a company is serious about Software, these experts will make the difference.

I remember when I started doing TDD, I made the mistake of thinking it was not that hard and I had nailed it. On a greenfield project, I pushed the envelope too far. I was so proud of my 100% code coverage. I thought I was an expert until adding new feature became painful; adding a new parameters to a method a nightmare; refactoring design near impossible.

It took me some time to realize the hole I was getting into. All that time to learn one lesson. I need to do more costly mistakes before I dare call myself an expert. Everything requires lots of mistakes until we master it. In larger scale, this error dictionary can prevent a company’s data from being completely deleted, huge loses of downtime during peak hours, or simply causing bankrupt in 45 minutes. People learn the hard way what not to do.

The hard path to expertise

Expertise is a trial error mechanism. You try this, you try that and you mess up considerably on the process. I understand that companies hiring an expert cuts the cost overhead introduced by mistakes required to grow their own experts.

Money is not the only impediment to growing expertise. People have a tendency to be afraid to fail and condemn other when they fail. When we fail, we look bad and others might get a bad image of us. Every one wants to be a winner not a failure. Invariably everyone fails, we can only do something about getting quicker up on our feet again.

“Fail fast” is a cliche on a company I worked for. Every Friday there was a contest to see who committed the biggest flop of the week. People felt better about themselves: they were not the only ones to screw up. Tolerance to failure is the yeast for expertise, because only by failing we can become better.