Wednesday, 19 December 2007

Code Reading and Improvement as a Craftsman

An answer to a question from Michael Finney on LinkedIn:

How can one learn to comprehend software code that other people wrote faster than they do now? Join an open source project and practice, practice, practice? I am inspired by people who practice their martial arts every day. Ron Jeffries gave me the idea most recently. Shouldn't we all practice our craft?



I'm intrigued with a number of things about your question:

  • why are you asking it? Motivation and Intent.

  • for whom are you asking it? Yourself, a friend, your team, a student, ...

  • What environment are you intending to do this in?

    Work or hobby. Teaching or self-dev. GUI or UI, real-time, low-level, database, web, batch processing, ...

  • Are you attempting to improve your Programming-in-the-Large skills, code development, code maintenance or design skills?

  • Is this going to be done in Personal time or Paid Time?

  • How will you measure 'improvement' or success?

  • Why Ron Jefferies? Who is he? Your connection to him.

  • Why Open Source?

  • Is this an abstract question or addressing a Real Felt Need currently present?

  • In what way 'faster'? Clock time, time on task, fixed-first-time, ...

    What about other primary aspects: Quality, Security, Performance, Usability. Quality & Design preceed everything else.

  • The question is itself confusing to me... Which is part of the answer to it.

  • Are you asking for "tips, tools and techniques" that others have used in their professional development?



Most importantly:
What's your Passion? Why do you do what you do?

If you were an aspiring musician and this were a question on "how do I get to the next level", people would be asking you a) where you are NOW and b) where you want to GO.

The same contextual questions apply to you.

Are your career aspirations to "get into management" or to become The World's Best Coder [in some area]. And what are you prepared to give up or go through to achieve that. Linus and Tridge (of Samba fame) both had many years where their wives were worried about their future security.

Jerry Weinberg made an excellent point:
The more poorly designed and implemented code is, the harder it is to understand.

I once stood my ground and declared some code 'unmaintainable'. Whilst I was 'right' and the only long-term solution to the code was complete redesign and rewrite. That became a 'Career Limiting Move'. I'd have achieved much more by Just Doing It [read Clifford Stoll "Cuckoo's Egg"].

For an answer out of my world to make sense to you, you need to understand where I'm coming from, what I've done that makes me relevant to you (just now). My CV is on the web plus some of the stuff I've written.

I've included a link to a piece by an Economist and Academic - Gregory Mankiw. His 'Rules of Thumb' are deliberate, conscious strategies that he deliberately pursued. Obviously refined & redefined over time. He rates "Mentors" very highly. Perhaps this is your way forward...

If you "practice, practice, practice" it will be of little value *unless* you reflect, review and analyse. Demmings "Plan-Do-Check-Act" cycle [Prepare-Execute-Review-Improve in current lingo] is definitive on this. I've included a link to Watts S Humphrey's PSP [Personal Software Process] The most important thing is to find out what you are unconscious about [mistakes you are unaware of] and prevent them.

Jerry Weinberg [in his writing] also stresses the importance of keeping a Journal - the most important part of which is Reviewing it..

The final link is "How to be a Star at Work". Kelley, a respected Organisational Psychologist was asked by the Bell Labs team that wrote exchange software, how to identify & choose "Star Performers". They knew that some of their staff were *at least* 10 times more 'productive'. The management wanted to be able to hire more of them. Kelley and his team took 2 years [and millions I bet] to find there were no psychological differences. It's all about what you do with what you've got... His 9 strategies [in the book index via the link] - the foundation of which is "Initiative". I think there is a Zero'th Law: Improvement is a Conscious, Intentional activity. The same questions/approaches encompass Learning, Quality and High-Performance [reflection and questioning].

Finally, what was the confusion I found in your Question?
Who are the "they" in "they do now?"

It can't be the "one" who's the subject (as in How do *I* read code faster?) Because that doesn't parse.

Clarity of Thought, especially the Quality of your Questions, comes before all else... That takes Practice *and* Feedback.

Ken Thompson, perhaps the best systems and tools programmer ever, made the observation:
My most productive day was deleting 1,000 lines of code.
[Unix V6 was 20,000 lines. That was a massive cut.]

So perhaps the answer to your question lies in another direction.

Links:


Mankiw - Rules of Thumb

Watts S. Humphrey - Personal Software Process

Robert E. Kelley - How to be a Star at Work

No comments: