I’m mainly at the conference to help hiring for Booking.com so come and ask for me at the Booking.com stand in the Expo hall.

And if you’re interested in any of the many positions we’re looking to fill also drop by, of course! Have a look at our available openings at the Booking.com jobs portal. We’re still trying to get hold of many, many experienced Perl developers, and we’re also willing to teach highly experienced developers in other languages Perl.

So what’s the problem?

First, try to look past that Bill skipped 30 years of research and experience in software engineering and stamps into it like a PHB-cliche, seemingly assuming his opinion is as valid as any research on the subject. That alone probably ticked off the defensive reaction in any software developer accidentally stumbling into the Harvard Business Review blog section.

The main misunderstanding is the assumption that there is only one type of talent. And both Taylor and a fair amount of the commenters makes this mistake and applies their experience with basic bell-curve measured skills onto a type of talent that is ruled by other laws.  Nassim Nicholas Taleb discusses this distinction in great detail in The Black Swan – the environments of “mediocristan” and “extremistan”. The first which you can understand using the bell curve and gaussian distribution, the latter where differences are of an order of magnitude and are qualitative or disruptive differences.

For example, in most manual labour or production line work, a practitioner can get good or even excellent, but mostly within a range that can be measured safely with standard deviations and the differences between average and excellent performance does not differ in it’s nature, but it’s output. Here throwing more people at the problem can solve it – maybe your top salesman makes ten sales a week while your average makes 4. Well, throw in 3 averages and you’re just as good. That’s not necessarily good economy or a good idea, but it can get you where you want.

In contrast, in the world of “extremistan”, a difference in skill can be of such a magnitude that it makes a qualitative difference. In the comment section of Taylor’s article, someone asks, “Would you want a Shakespeare or 100 Bill Taylor’s?”, and countless variations on the theme. And software engineering is that sort of talent. A “superstar developer” doesn’t necessarily a programming Shakespeare make, but he or she can make something a lesser qualified individual can never do, or do it so fast it makes the difference between staying in competition or not. Or just connect the dots and save the day.

Throw in the special problem of software engineering that putting one more person on a task tends to double the time it takes to solve it, and the effect is even larger.

But then, the Bill Taylor’s take their experiences with the “mediocristan” type of talent and applies it on the very different world of software engineering. It comes out, as is well pointed out in the comment section, as commoditization of something that can not be commoditized. Software development can’t be reduced to the number of lines written per day, in any meaningful way. Even business people who really, really want to think about it in that way, will still be wrong. It has been discussed and demonstrated countless times. The classic “The Mythical Man-Month” explains how you can’t just think of your software engineers as burger flippers.

When the original blog post received so much vitriol, it comes from every software engineer in the world’s experience with clueless managers who approach development in the Bill Taylor way. Today’s successful companies are ran in a different way, by Zuckerberg’s and Steve Jobs’ who are playing in a the-winner-takes-it-all world of the Internet. It doesn’t take that many, as long as you have the right people – Facebook has 2000 employees serving over 600 million users.

So what makes a super star developer?

I believe in the old truism that the difference between developers can be of the 100x magnitude – I actually think the Net Negative Production Programmer is a reality, so accordingly a top developer is infinitely better than the worst… However, unless you think the superstars have their skills handed down to them by divine intervention, something must have brought them to this. Here’s some points I believe are what makes up the super star:

• It’s knowing the codebase well. The superstar is often the guy who knows the codebase to the last semi-colon. It’s not about being the smartest guy in the room, but just knowing exactly where to hack in that little change, and that little change, and that little change, and that little change…. before lunch.

• It’s content knowledge. The superstar is the guy who also knows the content of what he is coding really well. If you’re making a chess bot, the developer who is also a chess grandmaster knows all the elements, the edge cases and the purpose of what he is trying to do. He will have a working prototype running while the developer without any chess background is still trying to understand all the implicit assumptions in the instructions he got from his Scrum Product Owner. I think this one is essential, and so often overlooked. Knowing the thing you work with, and working with what you find interesting is not only making development work into a whole other ballgame, it’s also does wonders for motivation.

• It’s situational. You can’t throw Linus Torvalds, Larry Wall or Bill Joy into your hack app shop and expect to have the next Angry Birds in a month. You need the right person and the right setting.

• It’s knowing programming well. The superstar developer doesn’t have to be a superstar in the inner working of his programming language – but he knows it well enough that it’s not in the way of him reaching his ultimate goal.

• It’s practice, practice, practice. Yeah exactly! No one is born into superstardom. This is written about a lot, and Malcolm Gladwell’s thesis of the 10.000 hours of practice rule really applies the software engineering too. One complicating factor with this point is, as I wrote about in accelerating your Perl learning, that most developers are on a lifelong learning mission anyways. They (we…) always look to learn something new, so what puts the superstar apart from the average? It’s not that easy to pick out, but in his article about the 10.000 hours of practice, Gladwell touches upon the differences of training and learning. It’s a large field of research and I hope to post more about it later.

• It’s a high level of intelligence. But not necessarily an extreme level of intelligence. However, a certain level of numeracy and ability of thinking in abstractions is necessary.  Maybe at some point we’ll find that super developers are able to hold more variables at the same time in their working memory, or something along those lines, and that turns out to explain the differences. But I have yet to see any research like that.

And it’s motivation… and the right management… but these things are also things external to the superstar, that you one move around to find. The brain finds it’s ideal setting..

So there, that’s what put the superstars apart from the average. I’d love to hear others’ take on it.

The sad thing is…

..that reality is that a well functioning team can usually match the lone superstar or even has it’s own advantages. It’s actually a good message: let’s not just celebrate these few people, they’re brought forward on the shoulders of people going through the daily grind of facilitating it and cleaning up the mess. Or we can achieve great things just by working together. It’s just presented so boneheadedly wrong.

Finally, Bill followed up with a clarification of some sorts, basically that IBM is made up of average people and see how long they have lasted, while Enron was full of superstars, and look how they crashed.  I wonder what IBM thinks of his base assumption there.

• The Risk of Being Undone
• The Risk of Maintenance
• The Risk of Failure
• Pronouns in Perl
• Functional versus Structural Code
• The Act of Naming
• On Answers to Smart Questions
• Embrace the Copious Documentation
• Embracing Idioms
• Cleaning Up Bad Code
• Declarations and Scope
• Scalar Context and Arrays
  

And a bonus: Essential Skills For Perl 5 Programmers.

Are there any other good resources out there expicitly aiming at taking novices to the next level – or is that just when general “documentation” takes over as learning instruments? What’s it like in other languages?

Also, while updating with Perl news, scruffy old perl.org has become dashing new perl.org!

Updated with new articles March 8, 2010.

It may seem like the recent efforts to market Perl, as well as the Perl Ironman blogging drive, is paying off big time in terms of online attention! The graph certainly sends a clear message that Perl is alive and kicking as never before.

Note: I tried to create comparative graphs for Ruby, Python and Java, but was left with enough noise from fake gems, snake attacks and earthquakes to fill several Hollywood movies. Any suggestions for good searches for comparison are welcome.

Note 2: Maybe this is just caused by some Google indexing algorithm gone bad, but a quick visual inspection of the first 100 hits indicated that the August and September hits are real Perl mentions. Is this a real empirical indication that the recent efforts are really paying off?

It also includes a few links to some really interesting blog posts: Does parallel processing require new languages?, What do you consider readable code?, The Top 25 Most Dangerous Programming Errors and this old article from Computerworld on how community and culture goes hand in Perl.

Enjoy.

Oh, and it also seems to be written extensively in rhyme.

And it makes me think, to what degree are organizations’ code bases shaped by their formal or informal organization structure? Are core modules and root objects often the domain of senior developers and objects lower in the hierarchy the domain of juniors? My experience is that it often tends to be, and it seems a reasonable overlap: after all, you want your more trusted developers fiddling where the damage can be greatest.

But how about other attributes of the code base? In the world of Perl, are CPAN authors often hired as external consultants? Are the most communicative programmers the ones that will write network services? Are the modules most used also written by the programmers that are most in contact with others?

And does organization structure also shape general code base structure? Will a more hierarchical organization tend more towards hierarchical object structures, while more chaotic or flat organizations tend towards more chaotic or flat code organization?

A lot of questions, but no answers… But one thing that comes to mind is, if organization and code structure follows each other, is this a good idea? I think few people designing a data model or object hierarchy starts with the organization structure as a blueprint, but speaking from my own limited experience, you can often at least see a reflection of either in both. Is this a good or bad thing? What can the consequences be?

Microsoft has done research on some popular conceptions about software engineering and come up with hard numbers on some factors affecting code quality.  Here are the main findings reported in the artice, with links to the research papers, in case the original is lost forever:

• More test coverage does not equal better code quality, as measured by number of post-release fixes.  Usage patterns and code complexity are the main reason test coverage is a poor predictor of quality.
• Test Driven Development increases quality, creating code that was up to 40% to 90% better in the Microsoft research. The cost is increased development time, 15% to 35% in the same studies. (Realizing quality improvement through test driven development: results and experiences of four industrial teams)
• Use of Assertions decrease program faults. However, this is also correlated with programmer experience, meaning more experienced programmers generally write more assertions and have less program faults. (Assessing the Relationship between Software Assertions and Faults: An Empirical Investigation). And here is more about Assertions.
• Organizational metrics, which are not related to the code, can predict software failure-proneness with a precision and recall of 85 percent. Not only that, but organizational structure was by far the best predictor of code quality, and was at least 8% percent better than the best predictor the researchers could get from code-based measurements. (The influence of organizational structure on software quality: an empirical case study)
• Organizational closeness is more important than geographical closeness, which has no effect on quality (Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista)

Here’s Microsoft’s article: Exploding Software-Engineering Myths (or if that doesn’t work, a Google Cache link).

One drawback with this research is that this is primarily based on case studies, which is a generally poor research method for drawing general conclusions. How valid are these observations for other organizations outside Microsoft? Is the organizational structure of your project or company actually more decisive than your programming methodology?

Also, how transferable is this to other programming frameworks. In dynamic typed languages like Perl, is test coverage more important? I often find that a sub-set of my tests do what a compiler could have done in a statically typed language, or even for Perl if I just had a more automatic testing tool. So maybe coverage would be more predictive of bugs if the compiler catches fewer mistakes? That would be a good candidate for further research.

However, this is excellent as a step towards more evidence-based software engineering.

Found through John Tells All.

THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions.
THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications.
THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.

Now why should you care?

Almost every mention I’ve seen of this online – or of any other personality type categorization system – is usually followed by a “which type are you?”. This misses the point utterly and completely. Psychological research like this first becomes really valueable when you stop thinking about yourself and start asking how this can help you understand other people. If you design API’s and base your design on what makes most sense to your own coding style, you will create something that two thirds of your audience will find difficult to use. Even if you don’t like or agree with their style.

Granted, that makes the assumption that programmers are always equally distributed among styles, which is a pretty wild assumption. The point is that other people are more likely to think differently than similarly to you.

That is also a good thing to keep in mind when formatting code for readability: if your coding style differs from standard Perl Tidy or your company’s coding standard, keep in mind that you are not formatting for yourself, but a colleague, maintainer or anonymous CPAN downloader. They are more likely to understand a common standard than your standard.  It sounds obvious, don’t it? I don’t think many (any) programmers think like this even so.

Now, Clarke, in an article to Dr. Dobbs Journal, has an example of a cognitive mapping of programmer types and API traits which is quite illustrative.  In Figure 1, thick blue lines shows the expectations of a particular programmer type, while the dark lines shows the score of a particular API. As you can see in this case, the match is bad. Now the good thing is that Clarke’s research gives you a framework to discuss how and why.

That’s important because programming style isn’t related to experience level or educational background. An programmer with an opportunistic style will not necessarily grow into a systematic programmer with more experience, neither will a systematic programmer become more pragmatic with age. Or perhaps they will – but you can’t assume that.

Finally, the dimensions which Clarke suggests APIs can be understood on at a cognitive level:

• Abstraction level. The minimum and maximum levels of abstraction exposed by the API, and the minimum and maximum levels usable by a targeted developer.

• Learning style. The learning requirements posed by the API, and the learning styles available to a targeted developer.

• Working framework. The size of the conceptual chunk (developer working set) needed to work effectively.

• Work-step unit. How much of a programming task must/can be completed in a single step.

• Progressive evaluation. To what extent partially completed code can be executed to obtain feedback on code behavior.

• Premature commitment. The amount of decisions that developers have to make when writing code for a given scenario and the consequences of those decisions.

• Penetrability. How the API facilitates exploration, analysis, and understanding of its components, and how targeted de- velopers go about retrieving what is needed.

• API elaboration. The extent to which the API must be adapted to meet the needs of targeted developers.

• API viscosity. The barriers to change inherent in the API, and how much effort a targeted developer needs to expend to make a change.

• Consistency. How much of the rest of an API can be inferred once part of it is learned.

• Role expressiveness. How apparent the relationship is between each component exposed by an API and the program as a whole.

• Domain correspondence. How clearly the API components map to the domain and any special tricks that the developer needs to be aware of to accomplish some functionality.

Steven Clarke seems to have discontinued his blog, but his scientific work is chronicled at Scentific Commons.

(Found, among other places, assertTrue() ).

Observation 1: Most programmers are on a life-long learning mission.

Actually, all programmers are. Programming is about solving problems. You must pick up something from that.

Observation 2: Learning happens at different speeds, both between individuals and within the same individual.

One day you get the point of mod_perl and burst forward, after  making CGI-scripts in the same way for three years. At the same time your colleague kept discovering new cool skills every week.

Accordingly, most programmers should be concerned not about their learning, but also their learning velocity. Your skill level is not only based on what you know, but how long it took you to learn it and how much more you can manage to squeeze in during your programmer life-span! If you’re ambitious, but your learning curve is slow or stuck, someone will put you on the sidelines. If your goal is to really understand something, you will be able to reach a deeper understanding if you can fit more learning into a short timespan.

So, this isn’t about using mind-maps, role-plays or fancy games at a training course. Rather, this is about tactics and strategies for life-long learning, or the kind of ten-year long learning it takes to create world-class expertise. I want to share something about what Psychology knows about making us learn more, faster, better and deeper – as well as some personal experiences – and hopefully get some feedback about people’s own experiences about increasing their learning rate.

So here are some points:

Avoid Arrested Development

You start a new job. You have an amazing learning curve while you pick up knowledge and skills from your new colleagues. Six months in you’ve found the comfort level at which you can do your job well. Six years later you are still at that level. Meet Arrested Development.  This is why some people are Formula 1 drivers, while most people drive their car good enough to get them to work and the beach.

Getting out of arrested development might not be easy. One key is to avoid automatic behaviours. In coding, this is to be aware of your habits and trying to break them up. Starting every day with opening a secure shell to the server and starting vim? How about learning to use Padre instead? Always firing up CGI::Application for every new web application? Learn Catalyst, HTML::Mason, even Ruby on Rails.

Or push your limits. Try taking on larger responsibilities. Take on a project that is larger, more complex or more difficult than anything you’ve built before.

The problem with getting out of arrested development is that it might take unlearning of the comfort level, and actually decrease your productivity and even understanding temporarily. It’s actually quite easy to explain in a programming setting: If you’re moving on from CGI::Application to Catalyst, your first web application is going to take longer than normal to develop. But your next one might be a big step forward for both you and human-kind.

(Although probably mostly for you)

Take Risks

It is found, again and again, that taking risk is a driving force in learning. In experiments in controlled learning environments, it is regularly found that being willing to try out more, click more buttons and do individual try-and-see experimenting is clearly correlated with higher outcomes in learning. And it’s just because the risk-takers will get more learning opportunities, they will simply see more of how things work.

So make sure you have a safe testing environment, a box for experiments and wild ideas. Try to break things that work, find edge cases or do things in a new way. Have a machine you can re-install without losing your precious collection of photos. Write some crazy ideas on your blog. Try and see what happens. But most important: Create a technical environment that is conductive to risk-taking, just as much as a social environment. If your development server is a sacred cow or people are dependent upon it, set up a crash-test server.

I think a reason Test Driven Development is working is also because it forces you to think about and try out your software. Writing tests is also a great way to get to know new packages or software suites, you can take risks you would never imagine doing while developing code. This method takes two scalars? I wonder what happens if I give it a 10.000 element list of japanese characters!

And let me repeat this: Take on a project that is larger, more complex or more difficult than anything you’ve built before.

Learn the right things

Some knowledge needs pre-requisite knowledge. It’s just a fact of life. If you try to learn how to make 3d graphics, it will take you a lot longer if you don’t know vector mathematics. (And you might want to look at something other than Perl for implementation..)

It’s pretty obvious stuff.

What is less obvious is what the optimal learning direction in computer programming actually is. In Perl, is there a learning run that is better than others? A sequence of reading perldocs that is more effective than another? I can certainly imagine some bad and good places to start, but everyone can do that. What is more unclear is what happens after that start. When you’re half-good and can do what you want, but want to expand, what is the most optimal directions to follow?

I actually don’t have a good answer to that yet. My only advice would be that if the terminology is getting too tricky, it is time to go back a step. And not only to..

Learn the terminology

When you meet a new term, don’t fill in it’s meaning from the context. One of my own most immediate improvements in learning came from always immediately looking up words I don’t understand. I believe there usually is a reason I don’t know the word, and often I’ve had some surprises where my “context fill-in” actually was way off.

Also, as suggested above, it you’re missing too much terminology, it might be a hint you are in over your head and need to gain the pre-requisite knowledge.

Learn something new outside Perl

Everyone will tell you this. Stuck on Perl? Get some new vibes from Ruby. Your C-coding is getting you down, try Scala (should get you back to C soon enough). And you can go further. Adam Kennedy says he gets inspiration from places like TED conferences, New Scientist or Economist. Some people will suggest just learning anything can get you out of a rut.

However, there is a condition. If it is going to help your programming, it must involve some sort of domain-transferable skills. Not everything new you learn will necessarily do that. I’ve been doing digital photography for nearly ten years and have gotten to a decent level. It has absolutely not improved my programming in any way. It is far too domain-specific. Getting a degree in psychology, however, has plunged me forward on a lot of levels, from new learning skills to seeing new ways of solving problems and learning about how the brain does biological information processing. Studying Zen sometimes provides me with a focus that is very conductive to understanding difficult subjects. The same with learning mathematics, particularly discrete mathematics.

So consider well what you learn. Pick the right thing, and you might gain a unique perspective on programming or just sharpen your thinking. Pick the wrong thing and you are wasting good learning time on taking vacation shots.

Of course, you might want a whole and fulfilling life filled with culture and art too, but that’s not what this text is about.

Accessing other peoples experience

Talk with people, and talk with them, not to them. Unless you are Ada Lovelace or Charles Babbage and invented this stuff, learning programming involves transferring knowledge from another human’s brain into your brain (I know some of you will lament this fact). One of the most effective ways of doing this, and the one way we are the most biologically disposed to, is talking combined with listening.  Reading is a hard-learnt skill that is piggy-backed on top of the visual system the last some-thousand years. Conversation, on the other hand, has a significant part of your head dedicated to it. Use that!

Study the code of excellent programmers and learn from it. Avoid the code of bad programmers, and if you have to look at it, don’t learn from it. Perl is fantastic for this. As well as being a great code repository, CPAN is also a fabulous learning resource. In addition, the core modules are often very good and thorough code that has been optimized and looked after a lot. If you bring your laptop on the train and lose the connection to the net, study a core module.

The problem of tacit knowledge. A problem of accelerating training towards an expert level is that the real expert knowledge is not the same as the knowledge written down in documentation and books. Rather, what actually sets a novice or an expert apart is unknown, or at least not explicitly known, to either. If you just squeeze 10 years worth of reading into someone in five years, they might just still be at the 5 year level in real skill, but with a lot of knowledge they don’t really know how to apply. This is related to the concept of declarative or procedural memory, or that what you read and what you do is remembered in completely different ways and places in your brain.

That, for example, is what things like the “variable roles” mentioned in a previous post try to encode. They find how experts understand and use variables, and try to teach that to beginners instead of giving them the basic intro and letting them get the experience the hard way. How do this apply in a life-long learning perspective? Study the how and what people do, not only what they say (or write).  Also: Study design patterns. Don’t necessarily base your own software designs on them, but know them, as they encode expert experience that previously was tacit.

Increase your physical learnability

Up until recently, we thought you grew new neurons (brain cells) up to certain age, then it stops and from then on it went down hill. It is not the case. At least in the hippocampus, which is the center of forming new memories, neurogenesis is found to take place all through life.

But there is a condition…

It takes physical exercise, namely aerobic training – that means running, biking, rowing or anything that makes you pant and sweat for an extended period of time.

I’m sorry… but it will increase your learnability…

Furthermore, your brain needs the right chemicals to actually form new neurons. One major compound that can’t be synthesized by your body from normal foodstuffs is omega-3 fatty acids. Omega-3 is found repeatedly to increase general cognitive ability (meaning higher processing power in your head) under many conditions. And you know you want more processing power as well as increased memory. Omega-3 fatty acids can usually be bought as pure capsules, or they can be found in salmon and walnuts if you want to eat that every day.

But be careful with the portioning. Too high Omega-3 dosages can lead to thinning of the blood, and while you might want to accelerate your Perl learning until your gum bleeds, you didn’t read that here.

And the last, but not least, point, is to be well rested. The code-all-night pattern might work when you are teenager or young adult and physically don’t need as much sleep. After that, it will effectively decrease your hard-won cognitive abilities.

And more?

Believe it or not, but I would actually like to expand on most of the points above and provide some more evidence and put some numbers to the claims above. But I have to post my Perl Ironman 10-day post and that effectively limits the time.

So, please share how you learn, or your advice to increase your learning rate. I know some rather able Perl-programmers drop by here occasionally. If you managed to become a guru, please share what you have done different. Is it just a lot of years of experience? Or do you have a unique approach?

Neither approach is particularly good -I can’t imagine code written for violent psychopaths  would really be that great to maintain. And on the other end, a lot of coders optimize for their own readability, and will argue the finer points of formatting from that point of view, not that of the actual readers – missing the point that readability is ultimately decided by the reader, not the writer.

I certainly catch myself doing this quite often.

In the Perl world, this is probably an even bigger issue than in other languages.  There-Is-More-Than-One-Way-To-Do-It is still one of Perls big strenghts, but certainly not all the ways are equally good – which is why Perl Best Practices is now a staple of any Perl-wielding office. The contrasting Python, with it’s “there should be one — and preferably only one — obvious way to do it”, seems to be able to get away with 19 simple statements to define the pythonic best practice.

Now, anyone can have an opinion, particularly since research on code readability it still quite lacking. We just don’t know for certain yet what makes people get code. However, cognitive psychologists have been interested for several decades in how people generally organize large data structures in their brains, and some of this has given some neat practical applications for coding, such as Furnas’ paper on ‘Fish-eye’ views (1986). (This is basically about IDEs with collapsing code branches, but now you know why that’s nice, how to do it right and who thought of it first.)

Research on general language comprehension, however, is a massive field. In the ACM Journal of Computer Documentation‘s August 2000 issue, George R. Klare provides some clear-minded and research-based adviced for communicators that might be enlightening and is a good starting point for thinking about readability of normal text – that might apply to programming.

He specifies four purposes of readability:

• Reading speed and efficiency.
• Reader judgment.
• Readership.
• Comprehension, Learning and Retention.

Of these, only the last is of any big interest for programmers; you don’t typically care about the speed the maintainer needs to read your code. You might care about the Reader  judgment if you code to impress your fellow programmers, but that is another chapter. Readership applies to how the size of the readership may be a function of  the simplicity of the text – a consideration on the skill level of your maintainers, perhaps, but few people code with the intention of their code to be read by a large audience.

However, the biggest issue with text and code is comprehension. Even more so in programming code, as it is essential that the maintainer is able to create a precise representation of the code in his own mind. Also he must be able to understand both what it actually does and what the intention is, since these don’t always add up.  For debugging purposes, it is actually completely essential that the reader can separate the soft human intentions from the hard computer operations, so any code must be understood on two levels simultaneously.

Now, how does readability affect comprehension? First, keep in mind that readability in natural language usually refers to choice of words and sentence length, and is typically measured by level of education necessary to read the text. This might not be appropriate for code readability – level of programming skill might not map to level of code understanding in the same way, and readability in code is often just a matter of indentation and syntactics.

But it probably maps somewhat close. This is where research is lacking again, so it is hard to tell.

Klare’s big advice, however, is that higher readability does not always convert into higher comprehension, but is modulated by situation and traits in the readers. And that is the important part. He describes four conditions when it does not work as you would think:

1. A reader can understand at higher levels than expected if his motivation is high. Also, skill level is a fuzzy concept.
2. If time is not limited, increase in readability might not make a difference on comprehension. The more time is limited, the larger the effect of readability
3. The greater the readers background knowledge on the topic, the less effect does readability have. On the other hand, even an expert on one field may prefer higher levels of readability in texts outside his field.
4. Type and level of motivation might affect comprehension.

or to quote his summary:

[..] more readable, written material is likely to produce greater comprehension, learning and retention than less readable only when one or more of the following factors are present: the less readable is much harder than the more readable, and clearly beyond the reader’s usual level; reading time is limited; the reader does not have a large amount of background or experience with the topic being covered; and, the reader has a relatively strong set to learn.

Now does this particulary increase understanding of readability of programming code?

Perhaps not.

However, if we think of readability not as just the reading of code as natural language, but rather of understanding of the semantic concepts, there is an interesting observation to be made.  If we consider using more basic programming to make the program easier to understand, while avoiding more advanced concepts, Klare’s summary of readability shows something that also adds up with other research, namely that this approach to readability doesn’t always increase comprehension.

In a very recent piece of research using Scala, Gilles Dubouchet found that using more compact and advanced functional programming methods rather than basic, typical loop-constructs increased comprehension.  Although one single piece of research such as Dubouchet’s is too limited to base decisions on, it becomes more interesting when it actually adds up with prior research on language comprehension.

Together it indicates that using more advanced methodology can increase comprehension for both original programmers and maintainers, unless they are pressed on time or motivation.

Unlike many other languages, Perl allows you to increase the complexity of your programming across methodology quite freely. You can start with the simple baby-Perl, go through procedural programming, add objects or start playing with functional approaches. You can use Aspect Oriented Programming or add on your own crazy, homespun programming methodology, if you so please.  For comprehension and readability purposes, the above research indicates that if you consider your audience and their situation well, going for a higher and more advanced level might not be a disadvantage.

But do keep in mind that the research is still a bit patchy, and this is mostly an argument without empirical data. But I’ll make sure I report what I find, as this is just the first in many articles about readability…