My friend Deep, who is a J2EE architect, sent me this article to "use it as a benchmark every time I am asked to rate my skills as a software engineer". I found it very cool and right away it helped me to see people on the project I am currently on in a very efficient and "simply simple" (KISS) perspective. I will definitely revisit these stages in the future to see what stage I am on, or between which stages I am at.
Here they are – The Meilir’s Seven Stages of Expertise in Software Engineering:
Below is a part of the article written by Meilir Page-Jones for Wayland Systems Inc.
I spoke with Meilir, and with his permission I am posting his wisdom here
Stage 1: Innocent
A Stage 1 may not have heard of Software-Engineering techniques. Or — more likely nowadays — he may be vaguely aware of their existence but may not see their possible relevance to his situation. Indeed, he may be only dimly aware that there are any software-development problems in his shop. You may find it incredible that Stage 1s could exist in the 1990s, but they do. And the reason stems from the way in which software complexity evolved.
Software became insidiously more and more complex in the 1970s and 1980s as users demanded more and more sophisticated systems be installed on the more and more powerful hardware that became available. Yet there was no sharp transition. The earth was not hit by a Complexity Asteroid in 1975 that suddenly made software three orders of magnitude more complex and cast our reptilian development techniques into extinction.
I call the way in which software complexity actually increased “Frog in the Pan.” This is because although a frog will jump out of a pan of hot water, a frog that is placed in a pan of cold water and slowly heated will fail to leap forth and will actually boil to death. The temperature gradient is so gradual that there will never be a point at which the frog declares: “Boy, it’s suddenly gotten hot in here! I think I should hop out.” (Before I get into deeper trouble from animal-rights folks, I hasten to add that this analogy is apocryphal. I’ve never tried the experiment and I don’t recommend that you do so either !)
Many Stage 1s are experiencing “Frog in the Pan” and are trying to tackle problems of the 1990s with approaches of the 1960s and 1970s, without realizing that the problems they’re facing are the very ones that modern Software-Engineering techniques were created to alleviate.
Stage 2: Exposed
Stage 2s have noticed that the water is getting decidedly warm, if not downright hot. So they are actively seeking Software-Engineering techniques that will get them out of the pan or at least reduce the heat. Stage 2s may survey magazines, confer with colleagues or attend one-day overviews of the techniques. Their interest level is high but their knowledge level is low, being limited to a few terms and definitions and not based on any practical Software-Engineering experience.
Stage 3: Apprentice
Stage 3s have attended one or two 5-day workshops on Software-Engineering techniques. In these workshops they tackled small but realistic case studies that resembled their own projects in miniature. The case studies provided valuable kinesthetic reinforcement of the formal lecture material and were thus indispensable. However, the case studies’ apparent realism conveyed to the Stage 3 a confidence that is often unwarranted.
If a Stage 3 absorbs everything from a seminar, then he is minimally equipped to tackle a true, full-sized project in the corporate jungle. Usually, however, a Stage 3 does not grasp everything or has difficulty scaling the techniques up from a case study to a real project. You could say that most Stage 3s know just enough to be dangerous!
Stage 4: Practitioner
The rite of passage to Stage 4 is the use of Software-Engineering techniques on at least one significant project. Achieving “Stage 4-hood” is for many people the most difficult transition of the six transitions between stages. The fledgling Stage 4 is asked to take untried (by him) techniques and apply them to a corporate project with the usual demonic cocktail of politics, deadlines and changing requirements. At the same time, he is attempting to recall what he learned in class and scale up the examples 10- or 100-fold. He continually needs consulting advice, without which he will encounter a series of minor setbacks or major failures. Since many people throw up their hands at this point and revert to their old mediocre but familiar ways, a large proportion of Stage 3s never make it to Stage 4. If an entire project is peopled with Stage 3s, then it’s highly likely that the project itself will fail and the Software-Engineering techniques will be publicly pilloried and then abandoned.
Stage 5: Journeyman
Stage 5s have made it. Their experience of Software-Engineering is “latched” in place and there is little risk of their reverting to the past. In the Stage 5 the Software-Engineering techniques yield for the first time the productivity the marketing folks promised; and on each successive project a Stage 5 further hones his skill and enhances his productivity. A Stage 5 is self-sufficient – more often the source of Software-Engineering advice than its recipient.
Stage 6: Master
The Stage 6 not only is an adept technician, but also possesses a profound methodological foundation. Beyond the “whats” and “hows”, the Stage 6 knows the “whys” of Software Engineering. This depth allows him sometimes to break a surface rule, while adhering to a more fundamental methodological principle. The Stage 6 is a good instructor because his theoretical and practical knowledge give him the wherewithal to tackle difficult student questions.
Stage 7: Researcher
The Stage 7 is concerned with delivering the latest developments in Software Engineering to a wider audience, via books, articles and conference appearances. The Stage 7 looks out for flaws in contemporary Software-Engineering techniques and for consequent ways to improve the techniques. He also scans the horizon for new problems towards whose solution Software Engineering can be extended and generalized. The Stage 7 is at a methodological pinnacle.
These Seven Stages of Expertise are valuable in their own right. You might think about a Software-Engineering technique that you know and consider which of the stages you are in with respect to that technique. You may also decide what (if anything) you should do to progress to the next stage.
However, there are organizational implications behind the Seven Stages. Below I discuss four of these: The Productivity Curve, Pilot Projects, The Critical Consulting Core and Ephemeral Technology.
Below is a "Stage-based Productivity Graph" that was compiled by Meilir based on his clients’ statistics:
Stage-based Productivity Graph
