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!

Monday, December 7, 2009

How to Prepare for SCJP 6 (Sun Certified Java Programmer) exam?

VISIT NEW HOME OF THIS PAGE: http://scjp.jbottle.com
In November, 2009 I passed SCJP-6 with the score 96% (58 correct answers of 60). That is quite high result, so being inspired with the achievement I have thought about unveiling my "secret of success":

1. Get a good book for your studies. Definetely, it must be "SCJP
Sun Certified Programmer for Java 6 Exam 310-065" by Katherine Sierra and Bert Bates (K&B). Other books for preparation are:
2. Make a plan for your studies unless you are a very disciplined programmer. Otherwise it's not easy to follow the "mind-plan". For reaching high score, expect to consume 20-40 full-days for studies (depending on your experience with Java) or 1-3 months for part-time studies (depending on your skills too).
I recognized that using a spreadsheet is a good way for planning. My spreadsheet contained the following fields:
The column chapter represents a chapter or sub-chapter of the book or any other activity. Deadline is for pre-defined deadline, which motivates to be quick enough and avoid "lazy days". Date really completed stands for real date when chapter/task is finished. Level of skills marks the level of skills acquired. Red is for "poor", yellow is for "average", green is for "perfect/almost perfect". Things to re-read is a place for marking notes what topics/pages must be read again. And two other columns were just for my notes and ideas for my blog.

3. Join the JavaRanch community or bookmark this page at least. It has a good forum for certification questions. There is also a place where certified guys and girls share their ideas how to pass exam with the best score.

5. Look around for mock tests. Two of them are included in the CD attached to the book. One bonus exam can be found following instructions in the book. SUN gives a demo-exam too. However, JavaRanch lists much more.

6. Relax and start learning. Keep up your shape each day. Take a pencil and underline all unclear places or places that raise questions. Also underline all essential things that you don't know already very well. Write down your notes, ideas, doubts, insights etc. directly on the book. Do not underline very well known or nonessential things (i.e. jokes, sarcasm or names of chapters). You will see this method helpful when reading the book for the next time. Also: always have a simple text editor (For Windows I recommend Notepad++; avoid using IDEs with autocomplete and autobuild options like Eclipse or Netbeans), JDK 6 and write many small classes that support your thoughts or test the material. Two benefits come from that: first, you will master the material much better, especially if you are "kinesthetic-learner", second, you will start noticing compile-time errors. Exam contains many questions where the student needs to "compute" correct result of the program OR mark the answer "compilation fails". So do not be lazy and wiggle your fingers all the time.

7. Somewhere in the middle of your studies, buy the exam's voucher (more information at Sun's website, also try to contact your local Prometric site. They also can help you to get the voucher). It is usually valid for one year after purchase and it will motivate you to reach the goal.

OK, now let's go into the details. You have the book (or books), internet connection, computer with Notepad++ and JDK 6, a box full of coffee or tea and much of enthusiasm. Keep reading my experience.

After initial review of Table of Contents of the book, I decided to read the chapters in the following order (I saw it easier according my background):
1 Declarations and Access Control
2 Object Orientation
4 Operators
3 Assignments
10 Development
8 Inner Classes
9 Threads
5 Flow Control, Exceptions, and Assertions
6 Strings, I/O, Formatting, and Parsing
7 Generics and Collections

You can use any other order that looks reasonably, i.e. do not put basic topics like Assignments or Operators to the end.
Some chapters contain several "topics" (i.e. chapter 5 consists of "Flow control", "Exceptions" and "Assertions") so splitting the chapter into several smalled pieces and moving them all into the plan is a good idea.
How to build up the schedule? I used to study few hours each day and more hours at weekends (part-time studies), so you have to adjust the times according your study intensity. I suggest to use several book reading rounds approach. Allocate about a month for the first round. Use one or few days for short chapter and dedicate roughly speaking a week for each long chapter (5, 6, 7).
The round means completing the book once. Two rounds mean that student read the book twice etc. A round consists of performing the following job for each of the chapters:
  • read a chapter
  • marknotes, essential places, hard things, things to remember
  • code a lot
  • read "Chapter summary"
  • read "Two minutes drill"
  • do exercises at the end of the chapter immediatelly. Do them carefully because that will help you getting used to pay attention to details (and you must be sharp-eyed as the exam will definitely try to catch you). Think about the problem, syntax, API, solutions, alternative solutions etc. instead of marking the answer mechanically. Try to explain the problem and why the chosen answer would solve it
  • check the answers, read explanations of incorrect (and correct) answers
  • evaluate your skills and progress. Type the results into the spreadsheet
After the first round I recommend to retake the exercises all at once. That will take several hours or more but it will help to avoid "short-memory" effect when you can remember facts for some short time immediatelly after accepting the material but leads to a "lost-memory" later. Find and complete simple mock tests (Google/Javaranch will help you to find mocks).
Then prepare for the second round. Everything remains the same. The only difference -- skip 100% obvious things while reading the book. And after finishing the round, read all the "chapter summaries" and "two-minutes drills" at once. Then take the exercises. Also you can take one of the exams in the CD attached to the book. You can complete Sun's online test exam. Expect to collect ~90% or more, but pay attention to details.
Third round: remains the same as the first and the second, but skip all the clear content, and concentrate on hard things. After the round, do the second and the third mock tests on CD.
The most important thing: don't overestimate your skills. Java is a tricky language with lots of pitfalls. Expect to get many of them during the real exam.
A note regarding the ExamLab exams: I did "open book" exams because the label "CORRECT/INCORRECT" appears straight after answering the question. In case of failure it's possible to get back and read the question again with noticing what has been wrong. These exams have few mistakes, but you will find them described somewhere in Javaranch.

There is one more thing: open the Java API documentation and read about java.lang.System class. Try to notice essential methods. You can get a question regarding them despite those described in K&B book.

That is all about preparation. Now, how to take the real exam?
First, read the initial chapter of K&B. It contains some invaluable information regarding the exam. Pay attention to these:
  • Drag'n'Drop questions lose their answer if you want to recheck them later. Mark their numbers on the board/paper (depends what you get for the exam, I got several plastic cards and a felt-tip, but that's very bad as it has big tip) 
  • Take some water if you are allowed to bring it in -- you will get thirsty during the exam 
  • There are easy and hard questions, so "answer easy questions, mark hard questions" strategy is reasonable. 
  • Get a good sleep before as you will need fresh head. Necessarily
My advice: do not be lazy and before leaving the exam room CAREFULLY CHECK your exam answers. Do that again and again as much as you have time left. Do not skip "obvious" and "perfectly clear" questions. You are fighting for the perfect result, right? I made ~7 mistakes initially, and after several reviews fixed them one by one. However, two still left despite my clear understanding of the material. Learn from that.
And, of course, feel free to put your experience/questions/feedback right here, into comments.