Open eyes Working brain

I spoke at Better Software 2010, together with Fullo, about speeding up web applications. The talk draws heavily from Steve’s work, but it’s a little bit different from current literature because it tries to organize best practices not as flat list but under macro-areas emerged as “slow parts”. Also, i concluded with my obsession that complexity inherently introduced by performance optimizations should not be dealt with by programmers directly, but by means of automation and abstraction.

Here it is.

update: now i am linking to the extended version which i gave at phpday 2010

Until, from the midst of this darkness, a sudden light broke in upon me, a light so brilliant and wonderous, and yet so simple. Deep practice, eradicate errors and deep practice again. I alone succeeded in discovering the secret of bestowing skill. Nay, even more, I myself became capable of bestowing mastery upon apprentice matter.

It could work.

At the end of august 2009, while i was reading about the importance for a programmer to touch type, i found out many programmers could type at 80 wpm and above. I tried myself and consistently scored 60 wpm or below. I have been spending many hours a day at the keyboard since at least 1996. How could it be i am not as fast? I already knew about the importance of practice, but i did practice for years, didn’t I? Well, uhm, no.

Think of the career of a professional football (soccer) player. How does he get there, does he play all the time for years? Actually, he spends most of the week training: stretching, pushups, sprints, weights, long runs, ball work, etc… Only a small percentage of time is indeed to play short games and the main game on sunday. That’s because play alone can only push your performance to the upper end of the range set by current skill. It’s not going to push you to the next level, to the next order of magnitude, and it doesn’t keep you from developing bad habits. And that’s where i got, very fast at typing in my very flawed 7-fingers posture. Not able to improve any further, not even in more than 10 years.

I really wanted to get better, so the questions were How? and How long will it take? I didn’t know the answer to the latter but the former was by then clear in my mind. Find a keyboard dojo, do keyboard katas and take the needed time. After trying a lot of viable solutions i found my dojo at www.typingweb.com. To add some salt to the challenge i switched keyboard layout from italian to U.S., which is quite better for programming, and i started practicing daily with their courses, routinely taking tests to record my progress. Two pomodoros a day for the first two months, then one, then again two when i was reaching the end. Always striving to get 97% or above accuracy at the higher possible speed for every single lesson.

Now, five months and about 120 pomodoros of deep practice later, i am writing this to shout to the world that IT COULD WORK. Next i’ll be moving to vim katas, while still having some fun at www.typeracer.com, because you never really stop to practice right?!

Yours sincerely,
ten fingers typist
american layout
80 wpm average
up to 100 wpm under a good moon
Federico.

The browser is emerging as the best platform for applications, so a large community is growing to address its final weakness: speed. Google, Yahoo and various independent programmers are all pushing a bunch of clever techniques to boost performance and please end users. That’s nice, yet as Mark Twain once said, half of the results of good intentions are evil and i see potential danger in many of the suggestions made. Here a representative short list of them:

• Avoid for-in and forEach in favor of optimized while loops
• Before making modifications to a DOM node remove it and then re-insert it
• To insert multiple DOM nodes, first insert them into a Document Fragment and then add it to the DOM
• Join all scripts into a single file
• Load javascript files on demand

Let’s make it clear for once, execution speed is not a human problem, that’s what computers are for, they execute our commands fast. The human problem is programming speed and writing down clear, readable, maintainable commands aka programs. forEach loops make sense to me, they say “i want to do something on each item”, optimized while loops make sense to computers. If i want to add DOM nodes or modify one, i don’t care of removing it or document fragments, browsers care. To me it’s just noise. Almost all of the problems addressed by those techniques stem from lack of smartness in the browser, and that’s where fixes belong to, on the machine side. The fact that there are inept browser makers is no excuse. Fixes still belong to the machine, they’re repeatable and can be made automatic. We have a long history of programs automatically converting human friendly code to machine friendly code. They’re called compilers and the output either machine code or optimized javascript doesn’t matter.

So, learn about javascript performance since knowledge is always the way, but don’t turn yourself into a machine, you’d be an awful one. Use the tools and wait for browsers to catch up.

• Aptimize
• Closure Compiler
• YUI 3 use

I’ve recently blogged about talent and how it’s grown through disciplined, committed, error focused practice at the edge of your ability, known as deep practice. I guess now it makes sense to approach it from the perspective of programming: What’s programmer’s deep practice? Unsurprisingly, inspiration can be found in the great japanese culture, people who highly value discipline and self improvement. Specifically i’m talking of martial arts. If you were to learn, say, karate you would go to a dojo and perform katas. If you happen to be a programmer, you can go to a coding dojo and practice code katas.

Code katas, a term first coined by Pragmatic Programmer Dave Thomas, are small programming exercises geared to hone a specific programming skill. Traditionally, they tend to be algorithmic like parsing or visiting graphs but could as well aim to improve understanding of particular programming paradigms, like functional or object oriented, or a specific language. Also, as remarkably pointed out by Matteo, katas can be crafted to master a certain technology like web or database. While, as you may guess, Coding Dojos are sites, groups or communities which propose and maintain collections of katas hopefully with solutions and reviews.

So, how do you practice? I suggest you solve a kata, review your work, compare it to other solutions, share your code with others and discuss it. Then solve it again trying to take a different path, balance pros and cons, then solve it again and again, until you feel you internalized the essence of the problem. Finally, you can move to another kata. If it feels like a lot of work, then you got it right. No question mastership requires time and effort but, then again, masters are those destined for greatness.

Resources

• Katacasts
• 21 Code Katas by Dave Thomas
• Lots of Code Quizzes with Ruby Solutions
• Matteo Vaccari’s Technological Katas
• Coding Dojo Code Katas
• Corey Haines Video Solution in Ruby of String Template
• Uncle Bob Code Katas (search “kata”, ie bowling kata)
• Micah Martin on Code Katas and Video Solution in Ruby of Langton’s Ant
• Micah Martin’s BattleShip Tournament
• Google Code Jam
• Jeff Atwood on Code Katas
• Steve Yegge on Code Katas
  
• Peter Norvig on Deep Practice

During my holidays, on a beautiful spot by the river, i had the opportunity to finish The Talent Code. This nice book brings empirical evidence and scientific foundations to something i have felt for quite some time:
Talent isn’t born, it’s grown.

Actually this has been something known to humanity for at least a century and it’s best explained by this quote from Thomas Edison:

Genius is 1% inspiration and 99% perspiration

The point is that becoming great at something is largely a matter of the amount and quality of practice one does. While God given talent can only boost this process, but it’s by no means the most influential factor.

About the amount of practice, there’s the old “Ten Years Rule” and a more refined study by Anders Ericsson who sets in 10000 hours of committed practice the time taken to achieve expert level. From the Pomodoro Technique, we know one can do about 5 hours/day of efficient work (10 pomodoros). That means 5 years and a half, 5 hours every day of hard work could be a good guess to the question “How long does it take?”.

About the quality of practice, the book calls the good one “deep practice”

working on technique, seeking constant critical feedback and focusing ruthlessly on shoring up weaknesses

So deep practice has a pretty simple recipe:

• practice just beyond your current ability
• focus on errors
• fix them
• repeat

Basically, it’s tenacious, steady continuous improvement, so it’s not surprising Kaizen is mentioned in the book.

In the end, we are left with two news: one bad, one awesome. The bad one is if you fail to reach master level in a discipline you care of, there’s no one to blame but yourself. Sadly, you got to take responsibility even for that. But the awesome news is you can really become what you want be. Just keep working.

Let’s close with this sweet advice from great italian poet Giovanni Papini

Chiunque, purché sappia chiaramente cosa vuol divenire e non perda un solo secondo della sua vita, può issarsi al livello di coloro che dettano le leggi alle cose e che creano vite più degne. (Da “Diventar Genio” – 1912)

and my rough translation

Anyone, as long as he clearly knows what he wants to become and doesn’t waste a single second of his life, can raise himself to the level of those who lay down the law of things and create more worthy lives (From “Becoming Genius” – 1912)

It’s becoming clear to me that a programmer is probably closer to a craftsman than a scientist. The craftsman greatest strength is mastership of his tools. So just as the carpenter masters the plane to shape wood, the programmer must master a text editor to shape programs. I’ve spent enough time wandering aimlessly around a lot of editors and IDE’s. It’s time for me to settle down, make a competent choice and take the years needed to become proficient in it. I wanted something possibly simpler, light and which would leave me in control. That means an editor over an IDE, but which one? I did some deep research and after an endless stream of positive reviews backed by Gabriele “warm” suggestion, i bought “Learning the Vi and Vim Editors 7th edition”. Vim is 1991 software based on a 1970s one, and it’s great. Btw my second best was emacs, another 1970s software. This must say something about advances in text editing software industry. Anyway, now that i’ve finished the book and daily using Vim, i realize its very existance is relevant to the “simplicity in software” debate.

Is Vim amazing software? Yes. Is Vim simple? No. This could imply that simplicity is a highly overrated software value, but i think it’s not. It just implies that, as any other thing under the sun, simplicity is a relative value. Relative to what? I guess to user’s knowledge of the domain. Let me explain.

Simple software is one that provides a few objects and a few rules to compose those objects coherently into newer more complex abstractions. This makes an optimal hotbed to learn. Few objects are easy to understand and remember. Few corner case free rules give confidence while exploring the unknown. It’s important that the learner is not exposed to further possibly useful complexity which is not ready for yet. Only some to ignite inspiration, but greater power cannot come a priori, but as a consequence of greater understanding of the domain. This way user and software evolve together.

“Good” Complex software, which still tries to minimize basic objects and rules and completely avoid corner cases, may ship equipped with many levels of abstraction relevant to the domain. That’s for the sake of efficiency, so that the skilled user will be able to manage complex scenarios by quickly referring those abstractions. Give something too simple to the master and he will end up bored and unproductive. Give something too complex to the apprentice and he will run away confused.

Vim is extremely good and complex software which comes with a plethora of short keyboard commands to make any conceivable manoeuvre on text at top speed. Optimized for being efficient with keyboard, which already happens to be the most efficient input device, usually much better than mouse. That’s heaven for touch typists as i am. The nice thing about efficiency is that it can be easily quantified by time. Same goal, the faster the better.

Let’s close with a fulgid example of vim capabilities with a common editing pattern: swapping two words.
An usual hybrid keyboard/mouse approach on windows:

• Select the first word (click/drag the mouse or double click)
• Cut (ctrl+x or right click and use menu)
• Move the cursor after the next word (move the mouse and click)
• Paste (ctrl+v or right click and use menu)

I guess it takes 3-4 seconds to complete correctly

Vim keyboard based approach:

• type dwwP

An average good typist can do 50 wpm which means it takes about 1 second to type 4 characters. That’s efficient.