3 ms·

Seems naive. I came up with an engineering scale that I think is pretty solid, at least over the 0.5 to 2.2 range. http://michaelochurch.wordpress.com/2012/01/2

Seems naive. I came up with an engineering scale that I think is pretty solid, at least over the 0.5 to 2.2 range. http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ http://michaelochurch.wordpress.com/2012/01/26/the-trajector... . I'm only about 1.7 so beyond about 2.2 I had to start using "bigger and badder" type definitions because I could only delineate those levels based on visible accomplishments, not experience or observation. Also, it's more of an "liberal arts" engineering (adding value to organizations) than one focused on domain-specific programming capabilities, which are still important but much harder to measure. You can become a 2.0 engineer in artificial intelligence, or in front-end web development, or in embedded device development and the processes of getting there are rather similar. Being a "good programmer" in each discipline is different. What OP's system describes is the progress from a novice (0.5) to a competent adder (1.0) to a general-purpose multiplier (2.0). Most serious programmers are between 1.0 and 2.0, so the growth process is about becoming a multiplier. At 1.1, you start automating annoying tasks by writing scripts. At 1.4, you're starting to become aware of the need for language-level support for code reuse and complexity management, so functional programming becomes attractive. The 1.5-1.7 range is when Lisp's language-oriented features (macros) start to shine. Most 2.0 programmers are cautious about when they use such things, though. Yes, DSLs can be very powerful; they can also be unmaintainable, miserable cruft-piles. Being a great (2.0+) programmer is about adding the most value though team- or company-wide multiplier effects, not being clever. Often, you add the most value by designing systems so simple and elegant that they almost insult the user's intelligence (in a good way). Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects). And pretty much every 1.5+ programmer knows what functional programming is and what its rules are (and when to break them). That said, it's not a strict rule that to reach or surpass 1.4-1.5 you have to spend X amount of time using functional languages.

j_baker 15y ago
You know, one thing I like about your system is that you aren't at the top of it. I have to question peoples' motives when I see an article like this where they're clearly at the top of the hierarchy.
- michaelochurch 15y ago
  I developed the scale because I found myself frustrated by "95th-percentile" syndrome. I noticed that, from when I started programming to now, I always considered myself around 95th percentile. And so did most other programmers I knew, whether they were "objectively" 80th or 99.5th. Which meant that these percentile-based self-assessments were worthless. Similarly, if I were at the top of the scale, that would show a lack of imagination on my part, and also make the scale worthless in a "I won at a game where I just wrote the rules" sort of way. Personally, the territory that's most interesting to me is 1.7 to 2.2, because that's what I intend to be covering over the next 5-10 years. People tend to estimate themselves as average within what they consider their peer group when comparisons are difficult or impossible to make (and the fact is that it's really hard to compare two programmers). So I think the 95 comes from the fact that it's "common knowledge" that 90% of "programmers" are incompetent. Of course, these percentiles depend on a population and competence distribution that are by no means immutable, which makes them meaningless as technologies evolve and more people come into software, so I needed a scale for professional development of an engineer based on general knowledge and approaches. The actual 95th percentile is probably around 1.5 on that scale, but that's just a wild guess. I'll still use "5-percenter" (loosely; no clue what the actual percentage is) to describe an elite set of programmers, but that has more to do with attitude, bearing, and trajectory than present-time skill. For example, the guy who picks up SICP because he's topped out and bored at his Java job is probably only 1.2-1.3, which is not yet 95th-percentile, but he's a "5-percenter" because he has the attitude and has found the resources that will make 1.5 likely and 2.0 possible-- which wouldn't be the case if he stuck with his same-every-day enterprise Java job.
mjb 15y ago
I was mostly agreeing with you until you starting on the technology bigotry. > Because while the Java+IDE environment makes it extremely difficult for an individual engineer to have a 1.5+ impact –there are two cases in recorded history of programmers breaking 2.0 in Java; one is Martin Odersky, who wrote Scala, and the other is Rich Hickey, who wrote Clojure What about people like Doug Lea and Josh Bloch? What about people like Trustin Lee? Why do these people not qualify as 'multipliers' in your framework because of their choice of technology? The idea that using a single technology or approach - in your case a functional language and not even a functional style - would be the difference between an adder and a multiplier is simply absurd. And then you go on to say: > This is because the Java+IDE environment, and operating systems like Windows, are designed to bring up the rear (0.7 to 0.9) while holding back the best programmers, artificially imposing that “ceiling” around 1.2-1.5 You have now introduced a definition which implies that the designers behind projects like the Windows kernel, MSSQL, and Kinect are a lower level of programmers because of the technology they use or the company they chose to work for. What about many of the really useful sites and services that are served from Windows (or Java running on Windows, gasp!) or the innovative and world-changing pieces of software which are primarily developed for Windows? Excluding all the people behind those from being upper levels seems like a stretch. > these technologies are intentionally designed for a performance-middling effect– to make it possible for huge teams of “commodity” developers to produce something while holding the excellent back from producing great things. This is the core of my problem with your argument. I can think of many more things I would call great that used technologies like C++, Java and Windows than used technologies like Lisp, Scala and Clojure. > Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects). You are simply wrong about this. There are many marks of a good engineer. An interest in different programming paradigms is one of them, for sure. To call functional programming a 'shibboleth of good engineers' seems to exclude too many people I would call good engineers to be a good or even useful measure. I would go as far as to say that, for above average programmers, interest in and use of functional programming is orthogonal to their contribution and skill. I have been lucky enough in my career to work with many great engineers, leaders in their fields, who have chosen to use the technologies you deride and are therefore forever stuck at the lower levels of your hierarchy because of those choices. (On the other hand, I may have just fed the troll).

j_baker 15y ago

You know, one thing I like about your system is that you aren't at the top of it. I have to question peoples' motives when I see an article like this where they're clearly at the top of the hierarchy.

michaelochurch 15y ago
I developed the scale because I found myself frustrated by "95th-percentile" syndrome. I noticed that, from when I started programming to now, I always considered myself around 95th percentile. And so did most other programmers I knew, whether they were "objectively" 80th or 99.5th. Which meant that these percentile-based self-assessments were worthless. Similarly, if I were at the top of the scale, that would show a lack of imagination on my part, and also make the scale worthless in a "I won at a game where I just wrote the rules" sort of way. Personally, the territory that's most interesting to me is 1.7 to 2.2, because that's what I intend to be covering over the next 5-10 years. People tend to estimate themselves as average within what they consider their peer group when comparisons are difficult or impossible to make (and the fact is that it's really hard to compare two programmers). So I think the 95 comes from the fact that it's "common knowledge" that 90% of "programmers" are incompetent. Of course, these percentiles depend on a population and competence distribution that are by no means immutable, which makes them meaningless as technologies evolve and more people come into software, so I needed a scale for professional development of an engineer based on general knowledge and approaches. The actual 95th percentile is probably around 1.5 on that scale, but that's just a wild guess. I'll still use "5-percenter" (loosely; no clue what the actual percentage is) to describe an elite set of programmers, but that has more to do with attitude, bearing, and trajectory than present-time skill. For example, the guy who picks up SICP because he's topped out and bored at his Java job is probably only 1.2-1.3, which is not yet 95th-percentile, but he's a "5-percenter" because he has the attitude and has found the resources that will make 1.5 likely and 2.0 possible-- which wouldn't be the case if he stuck with his same-every-day enterprise Java job.

mjb 15y ago

I was mostly agreeing with you until you starting on the technology bigotry. > Because while the Java+IDE environment makes it extremely difficult for an individual engineer to have a 1.5+ impact –there are two cases in recorded history of programmers breaking 2.0 in Java; one is Martin Odersky, who wrote Scala, and the other is Rich Hickey, who wrote Clojure What about people like Doug Lea and Josh Bloch? What about people like Trustin Lee? Why do these people not qualify as 'multipliers' in your framework because of their choice of technology? The idea that using a single technology or approach - in your case a functional language and not even a functional style - would be the difference between an adder and a multiplier is simply absurd. And then you go on to say: > This is because the Java+IDE environment, and operating systems like Windows, are designed to bring up the rear (0.7 to 0.9) while holding back the best programmers, artificially imposing that “ceiling” around 1.2-1.5 You have now introduced a definition which implies that the designers behind projects like the Windows kernel, MSSQL, and Kinect are a lower level of programmers because of the technology they use or the company they chose to work for. What about many of the really useful sites and services that are served from Windows (or Java running on Windows, gasp!) or the innovative and world-changing pieces of software which are primarily developed for Windows? Excluding all the people behind those from being upper levels seems like a stretch. > these technologies are intentionally designed for a performance-middling effect– to make it possible for huge teams of “commodity” developers to produce something while holding the excellent back from producing great things. This is the core of my problem with your argument. I can think of many more things I would call great that used technologies like C++, Java and Windows than used technologies like Lisp, Scala and Clojure. > Functional programming is a shibboleth of good (1.5+) engineers because it's usually what they first learn as they break through the 1.2 ceiling observed in Javaland (since Java and enterprise programming actively work to prevent people from having multiplier effects). You are simply wrong about this. There are many marks of a good engineer. An interest in different programming paradigms is one of them, for sure. To call functional programming a 'shibboleth of good engineers' seems to exclude too many people I would call good engineers to be a good or even useful measure. I would go as far as to say that, for above average programmers, interest in and use of functional programming is orthogonal to their contribution and skill. I have been lucky enough in my career to work with many great engineers, leaders in their fields, who have chosen to use the technologies you deride and are therefore forever stuck at the lower levels of your hierarchy because of those choices. (On the other hand, I may have just fed the troll).