People are Happy when they are Effective
When you first start practicing anything new, there is an initial novelty, a joy of discovery, and then, just as certainly there is a period where practice is work. It doesn’t matter what the subject matter, piano, riding a bike, Latin. Many people give up at this phase, mistakenly thinking that they aren’t any good at it, or that it just doesn’t fit their brain. In actuality this is a step everyone goes through, it just matters whether you keep going or not. It is work to master, or to begin to master anything worth doing.
If you keep pressing on, you will gain competency, and with perfect practice and sufficient time, mastery. There is much to be said for the rule of thumb that master in anything takes about 10,000 hrs.
What is just as interesting is that anything at which you are very good, you are likely to enjoy. Even if you hated those piano lessons your mom made you take, if you kept on taking them and gained competence, you are likely to enjoy playing. Competence doesn’t guarantee that you will enjoy the activity, but it does greatly increase the likely hood that you will. If we take effectiveness to mean that you are good at something, and that something matters, then you are almost certain to enjoy it, and doing it will increase your happiness.
Software development is notoriously hard to measure. We approximate it with lines of code, number of defects etc. But we know these measurements lie. The best engineers will produce much more functionality per line of code. Code you can avoid writing altogether doesn’t have bugs. The difficulty of implementing a feature varies widely, and hence the number of defects produced. Some features are never used by anyone, while another can save a business. Quantitative analysis of who is actually being more productive usually costs too much to do, and even if you could determine by the numbers who is being the most effective, the analysis would likely leave no clear guide how to help the low performers improve.
There is a simpler, better way: Optimize for programmer happiness.
It really really matters, and can revolutionize your team. It is the best guide to identify top performers, and to know what to do to increase productivity. If you don’t believe me have a look at how software companies die (it’s a good read, even if you do believe me)
As a side note, the happiest programmers I’ve ever seen are those in the emacs & Ruby communities. I think they are both very effective, and tend not to take themselves too seriously. Something for the Clojure folks to think about.
Permission, Fear and Innovation
- n. A feeling of agitation and anxiety caused by the presence or imminence of danger.
- n. A feeling of disquiet or apprehension: a fear of looking foolish.
- n. Extreme reverence or awe, as toward a supreme power.
As a discipline we fear Object Oriented Programming (OOP), in the third sense of the word, and we fear breaking from the OOP tradition in the prior senses. And it is damaging our ability to innovate and to build better systems, and to grow beyond the best of what is currently known.
OOP has so long been “the right thing” that speaking critically, particularly with the degree of criticism that it likely deserves, will quickly get you written of as inexperienced, or a crank. There are no silver bullets that will cure all software development ills, and you will still be writing classes and using objects, but it would be better to limit classes & objects use to where they fit, and use other styles (especially functional and logical programming) where they fit.
It does matter. Software is changing the world, but making it is expensive, and maintaining it is even more expensive. OOP solutions are larger, harder to understand, harder to change, and harder to maintain.
I think one of Clojure’s most valuable contributions to the field is the permission implied by it’s success. It works. People are using it to build impressive things, with few people, on tight schedules and budgets.
Embrace the “odd” ideas of functional programming: immutability, minimize state, use built in data types where they serve well rather then creating your own (via classes) for each restatement of an old problem you encounter. Choose simplicity, choose fewer data types, and more functions which operate on them.
It is important to practice. In Japan the automakers have found that they cannot build better automotive fabrication robots, because no one knows how to make better cars then the robots do. The masters which have their 10,000 hrs of practice in, and which the robots are designed to imitate, have retired, or died. If you aren’t practicing the best that you are aware of, you aren’t ready to move onto the next step, and you certainly aren’t ready to push the state of the art.
Use new techniques, then let others know about your experience, so they can have the permission to know that non-OOP paradigms work and can they can try it them too.
I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the fear has gone there will be nothing.
Only I will remain
– Frank Herbert in Dune
– Jordan Schatz