A PathOfTheProgrammer

The stages of prgrammer development

Uploaded by

Charles Tolman

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

9 views

A PathOfTheProgrammer

The stages of prgrammer development

Uploaded by

Charles Tolman

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 4

1: The Path of the Programmer

It is easy to criticise other people’s software.

My experience is that looking back at our own careers teaches us a

salutary lesson about just how long it can take to develop coding skills.
For example I started coding for a living back in 1980 and spent most
of my career implementing large high data rate video editing systems
and realised that it was not until 1995 that I was happy with the
quality of the work I was producing. This curbed any sense of
frustration I felt about the quality of the software produced in a
commercial context. It also caused me to try and understand why it is
so hard to find people who could make the switch from actual coding
and implementation to taking a more structural view. Current
knowledge states that it takes 10 years to become an expert in a
domain1, but my experience working on large (> 10MLOC) codebases
is that reaching such a level in software development takes even
longer.

I shall draw inspiration from such people as the architect Christopher

Alexander as well as the Austrian philosopher and esotericist Rudolf
Steiner, whose epistemology drew from Goethe’s natural scientific
work.

[REF: ACCU2013 Talk “Software and Phenomenology”]

[REF: ACCU2014 Workshop “Imagination in Software Development”]

I will characterise the Path of the Programmer by borrowing an idea from Zen about the three phases on the
path to enlightenment: Novice, Journeyman and Master.[REF?]

The Novice

During the Novice phase one is still

learning about the tools at one’s
disposal. Novice thinking is Rule
Based as they will be learning the
process steps required to do the job.
The complexity of novice thought will
be less than the complexity of the
problem in hand when working in a
‘live’ commercial context. Hence the
software developed will be ‘brittle’
and/or it is unlikely to be doing all that is required. The novice will be aware of their own limits because they
know they have only a small amount of knowledge. However it is unlikely that they will be aware of their own
personal learning process since they will have their hands full of learning the domain of software development.

For the novice this phase is thus characterised by an undisciplined self-awareness of their learning process and
habits.

1 Dreyfus Model of Skill Acquisition

The Journeyman

I consider the Journeyman phase to

be the most dangerous time of a
developer’s career.

Here the person has a better

knowledge of tools, having learnt
about quite a few of the programming
libraries available to you, but the trap
here is that the Journeyman is so very
enamoured of those tools. This
conforms to the upward spike in the
confidence curve that Dr. Marian
Petre talked about this morning.

Here the problem is that you can get into Abstract thinking and this can lead you to having an overly complex
view of the solution. Your thinking here is more complex than the problem warrants. It is quite possible that up
to 80% of the code will never be used. Therefore you are unaware of your own thinking limits and this can lead
to an experience of total panic, especially if you are working on larger systems. [About a quarter of the listeners
raised their hand when I asked if anyone had ever experienced this] This conforms to the downward spike that
occurs after the upward spike on the confidence curve.

One anecdote I have is the story of one rather over-confident colleague who was given responsibility for a
project. The evening before the client was due to turn up for a demo he was still coding away. When I came into
work the next morning there was a note on his desk saying ‘I RESIGN’. He had been working through the night
and didn’t manage to get to any solution. Of course the contract was lost.

This highlighted the total lack of awareness about one’s own limits. In this phase I also remember having an
arrogant positivity – its just software, anything is possible – as I had an undisciplined lack of self-awareness.
Some people can stay in this phase for a long time, indeed their whole career. It can be characterized by an
insistence on designing and coding to the limit of the complexity of their thinking, which means by definition
they will have massive problems debugging it, because you need more complex thinking to debug a system than
was used in creating it.

So we have gone here from one undisciplined state of partial self-awareness to another undisciplined state of no
self-awareness. Of course this could be seen to be a bit of a caricature but you know if you hit that panic feeling –
you are in this phase.
The Master

Here we have a good knowledge of tools, but the issue that is different is that you will be using a Context Based
thinking. You are looking at the problem you have got in front of you and fitting the tools to that problem. There
is a strong link here with a practice when flying aircraft. You need to read from the ground to map, not the other
way around. You must do it correctly because there have been a number of accidents where the pilots have read
from the map to ground thus misidentifying their location.

It is the same with this. Focus to the problem, bring the tools as you need them. It is interesting what Dr. Marian
Petre said about how experts can look as though they are novices – which is exactly what I feel like – sometimes I
look at my code and think “That doesn’t really look that complicated”. You bring the ‘big guns’ out when you need
them, hopefully abstracted down under a good interface. You know you need to keep the complexity down
because there will be a lot of maintenance in the future where you or others will have to reason about the code.

So here the software complexity is of the order of the problem complexity, perhaps a bit more because you will
need a bit of slack within the solution. At a personal level the big thing here is that you are aware of your own
limits because in the previous phase you have been panicked.

One of the big things I have learnt through my career is the ability to handle this. For example there will be a bug.
The client may panic. This is to be expected. The salesman may panic. Still possibly to be expected. As a
developer if your manager panics too, you have a problem, because the buck will stop with you. Can you
discipline your own thinking and your own practice so that you can calmly deal with the issue, regardless of how
others are handling the situation? This is the struggle you can get in a commercial coding environment.

Implicit in this description is that you have developed a disciplined personal practice.
Summary

Novice

• Rule-based thinking
• Undisciplined
• Some self-awareness.

Journeyman

• Abstract thinking
• Undisciplined
• No (or very little) self-awareness.

Master

• Contextual thinking
• Disciplined
• Deep self-awareness.