Tuesday, October 16, 2012

STEP - Levels of Learning

After years spent in software engineering, I have identified four common levels of learning a subject (technology, methodology etc), which I called STEP. It is worth to notice that this concept is not limited to the software engineering and can be often successfully identified in any area of life and work:
1) "Student" level (S). One learns as much as needed to complete the particular task or several highly similar tasks
2) "Teacher" level (T). One learns as many high- and low-level details as it is reasonable to know for practical purposes when using the subject, explaining or answering common and many complex questions about the subject
3) "Engineer" level (E). One creates abstract conceptual model of the needed artefact in their mind, then explores the field for existing solutions or creates their own realisation of the idea if the solution has not existed before or if the existing solutions do not fit the requirements or are very hard to integrate
4) "Professor/Passionate/Paranoid/PHanatic" level (P). This means real fanatics of the domain. They not only know the subtle differences between all or almost all existing artefacts of the domain problem, but clearly know pros and cons of (almost) each of them and usually provide their own a theoretical and/or a practical solution to the problem.

My considerations below are purely from the software engineering perspective. Sooner or later I will explain how this model fits things that are more "down-to-earth".

It is also worth to mention that one or another "level" can be considered as "achieved" or "being achieved", also the names of those levels can be used to describe the person who has achieved or is aiming to achieve particular level of knowledge, or to describe that person's level of commitment to learning the subject.


One at "S" level is good at creating simple prototypes of separate software components, doing shallow research in technologies or "just doing it" when the boss, business, customer or the upcoming exam is applying high pressure, and result is needed "right here and now" (or even "yesterday").

Sources for learning:
  • basic tutorials found online
  • outdated official documentation (!)
  • other "Student"'s help
  • for many inexperienced people, "it should be like this" or "I know that better myself" approach to the problem
  • "brute-force" solution following series of guessing and "try-fail" attempts
  • steep learning curve
  • immediately applied knowledge
  • result achieved typically in a short time for small tasks
  • the level is strongly backed by Paret's principle (80% of result is produced using 20% of effort/knowledge)
  • low to average quality of the code
  • lack of consistency across the solution
  • further maintenance of the code is possible only if the task is small enough to avoid pitfalls that might have been introduced due to the lack of knowledge
  • completing average complexity task can take relatively large amount of time
  • each "Student" in a group can have very different set of skills, level of skills or/and approach to the basic things, therefore a team consisting only of "Students" has its limits to implement more complex task(s)

Bad practices often become a norm as the early prototypes of the product often have been made without firm resolution that they are just "throw-away" prototypes. A typical case is that the prototype becomes "the core" for one or more products, and set of the "copy-paste/workaround/ignore-problem/don't-break" principles makes refactoring very difficult if not impossible due to the time/money/lack of people concerns.


"T" level fits when the new technology is used more than once and by more than several people. People who know above the basics can collaborate significantly better compared to the group of "Students". They all know many common patterns of the technology, official and non-official conventions, best practices and pitfalls. When working in a team, it is the same as speaking the same language. This also allows to wire up all the separate details provided by the technology into "the big picture".

Sources for learning:
  • official current and prior documentation
  • books, articles, blogs written by other acknowledged people ("Teachers", "Engineers", "Professors")
  • direct help from other "Teachers", "Engineers" and "Professors"
  • API documentation
  • one's experience
  • average to high quality code which is easy to maintain
  • expert of the product with skills and experience of what is good and what is bad, pitfalls and best practices
  • can teach other people within and outside the team
  • can perform quality checks
  • result achieved in a relatively short time for average projects
  • very quick start of the project, as the "T" typically knows where to start from scratch
  • after receiving task optionally complemented by high-level specification, the team of  "Teachers" can work very effectively under minimal or zero supervision and further guidance
  • it is often possible to collect a team of "Teacher" type contractors for a specific task
  • inability to provide comprehensive up-to-date comparison between the mastered technology and existing alternative technologies
  • firm sticking to the particular technology and quick jump-in blocks considering possibly better/cheaper alternatives before starting the project
  • code and architecture tightly depends on the specific technology which might be unpopular, becoming outdated or already outdated

Very small project or one-time task can be overengineered by using "best practices" where they are not needed or alternative technology can provide much more practical solution to the problem. Also lack of analysis of alternatives due to the firm stick to particular technology(-ies) can negatively impact further improvement of the product where flexibility of choosing alternative technologies might be preferred. One more thing, "Teachers" can apply pressure to others to use their favourite stack of technologies just because "they know it very well and it has been already proved". Despite my agreement that it is often practical behaviour, that might ignite long and unconstructive discussions between "Teachers" of different technologies and also between "Teacher" and other people who tend to do some pre-research before the actual coding (Hint: very popular "wars" or so called "flames" are Windows vs Linux, NoSQL vs RDBMS, Tomcat vs WebSphere, Java vs .NET). While this is important for professional development, sometimes it might create long lasting tension between team members representing different "religions".


"E" level is typically reached or being reached after mastering several alternative technologies, gaining practical experience of using them and becoming free of preconceptions (if one had them before). These people understand that the world is changing fast these days and before making important decisions they love to do some pre-research. They also keep the level of their knowledge up to date thus making their input very valuable for long-lasting projects, where quality, flexibility, extensibility and maintainability of the new system are essential. In my opinion, it is very reasonable to allow one or a few engineers to spent time for a good pre-research before starting the real development, which later can be taken over and leaded by "Teachers". Engineers can comprehensively evaluate the problem and decide either some existing technology is adaptable or a custom alternative is needed.
The one who is at this level is probably the most practical person among all the four STEP types for many different kinds of projects.
Unsurprisingly that "Engineer" often performs architect's role. By the way, it is not uncommon that their hours are quite expensive.

Sources for learning:
  • all used by the "Teacher"
  • analysing source code of the existing technologies, often Open Source
  • fixing bugs in Open Source technologies, doing small improvements
  • active involvement in diverse communities of highly skilled, open-minded professionals
  • optimal key technology decisions at the start of the project/task
  • practical yet flexible architectural decisions oriented to expected future needs
  • high quality, easy to maintain code
  • expert of several alternative products with knowledge of what is good and what is bad, pitfalls and best practices
  • early adopters of new technologies
  • can cope with large and complex projects
  • delays in early stages of project while the problem is being analysed and alternatives evaluated
  • high cost
  • impractical for simple (but not necessary small) projects, where pre-research is not needed and over-engineering should be avoided

In order to maintain level of their skills, engineers can rarely devote their full day time to a monotonous project that can be performed by people who simply love working with a particularly technology. "Engineers" often act just as the initiators for a project at first stages or on core parts of the system itself or its modules. Many "Engineers" eventually transfer the project-specific knowledge to their successors and leave for new challenges.
Another risk is associated with "Engineer"'s love for new stuff. Some really good "Engineers" tend to see small projects as their "sandboxes" suitable for checking how some new technology will survive the live test. While this is often acceptable and is probably the best way to improve one's skills, in my opinion the possible impact for business should be carefully evaluated in advance by both technical and non-technical people. Quite often prototypes and small projects unexpectedly evolve into long-lasting legacy systems that are supported by other people for years. Therefore adding little known library or still unpopular framework can later turn into significant costs if the technology does not become well supported. Although such mistakes are  mostly possible to avoid by using "conservative" technology over "innovative" one when in doubt, they can still happen due to the lack of critical attitude. Wrong choice of technologies can lead to high impact in business. So this should be not overlooked and undervalued.


"P" level people are true exceptional experts of their knowledge domain, pioneering in creating theories and technologies around it. They are always ahead of changes and create tomorrow's "toys". They are creative, hard-working and extremely passionate about what they do. More than often they maintain their own alternative versions of existing technologies/products because they believe in the key differences reflecting their opinion about the problem domain. Typically they can realise themselves best when doing research in their field, creating concepts, architectures, critical limited size components, more rarely full E2E solutions, performing challenging optimisations for existing technologies and similar tasks demanding extraordinary brains and solid experience.

Sources for learning:
  • all used by the "Engineer" with strong orientation to the most recent achievements within the domain
  • conscious and persistent search for weaknesses and drawbacks in existing technologies
  • findings and achievements in alternative areas that can be applied to their area of interest in one or another way
  • inventor of new things
  • exceptional quality of work result
  • exceptional up-to date knowledge of the domain
  • can work on problems that others give up
  • create technologies that later become widely used
  • the best consultant of the domain and technology (with exceptions though, as extremely deep skills are not always needed to explain things; much more important is ability to explain them in such a way that less skilled people could understand)
  • impractical for non-challenging projects, as the research and more general results are more preferred than the specific result needed by business

This type of people are not suitable for general projects. Scientific, highly research-oriented work or building general, widely-applicable components solving existing general problems is what they can do best. Also it is not uncommon that such inventors and "Professors" are solo-players.

So these are my thoughts about levels of learning and commitment to learning. I believe that all people start at the bottom level ("S") and eventually become "T", and then sometimes "E" . The line between "T" and "E" is thin though because of possible parallel learning of different technologies at the same time (imagine a WEB developer who creates pages that must be rendered equally smoothly on a number of browsers existing today including those used in modern mobile devices). Most people stop improving themselves at one of these levels ("T" or "E"), as further self-improvement needs extra passion, devotion and lot of time, not mentioning a clever head. But that not always guarantees better payoff and/or work/life balance.

Do you have different opinion/experience or noticed mistakes/mistypes? Share them in the comments!

1 comment:

  1. Readers might find this interesting too:
    The article presents four stages of acquiring and mastering some skill -- from "unconscious incompetence" to "unconscious competence"