Experience of a beginner

One of the thing i really like about being a consultant, is that i get a chance experience first time reaction of people i’m consulting to the new practices. Sometimes these reaction are suspicion, fear and doubt. But in some (happy) cases when I’m able to bypass these, I see beginners takes these practices and leverage them in ways I only expect to see much farther down the line.

so what am i talking about?

Every programmer is given from time to time a task to change/fix sections of the code he is unfamiliar with. Over time I’ve noticed that there seem to be two basic approaches in this situation:

Lets read and understand

one approach taken by many when facing new code is to treat it as a text book to be understood. First the programmer will collect every piece of information he can get his hands on, specifically those related to design. If possible he will even ask for tutoring sessions with someone more knowledgeable. When that’s done, this programmer will continue to investigate the source by reading it, until he reaches the level of understanding he feels comfortable with. ONLY then he will actually start changing the code in order to perform his given task.

Lets Feel the code

This is a different kind of programmer. (Once I believed i was unique in doing this, but over time I saw that many are doing just the same) Anyway, this programmer when approaching new code to learn, will start out by diving in with an editor, and immediately “refactor” the code to his pleasing. In fact refactor is a little over statement, in most cases its just pure formatting and does not involved any real changes to the code. I think that what the programmer is doing is trying to “feel” the code through the keyboard. Recently i spot the same behavior in my kids when given a new toy. they start out by physically feeling the toy and only after they feel comfortable actually start the “playing’ phase. When dealing with software, the closest one can get to this is by applying an editor on the source text. Over time I understood this is a very powerful technique, but I came to realized the context of this process i.e. pure learning. Today I tend to throw away the result of doing this and start over when I’m done.

Using tests to Grok new code

When doing TDD for some time you develop a new technique for handling new code. And this is what i saw one of the people doing here (although his experience with actual TDD was minimal at best). I think its the ‘feel it’ approach taken one step further. Instead of reading the code or blindly hacking it. he used tests to drive out your learning process. That person was given a task to do on a part of the code he was unfamiliar with so the first thing he did was to just write some tests to for that code (the organization is new to TDD so most of the code is not yet covered) in order to understand what was going on.

doing that helped him uncover several strange behaviors which really made him realize that something is not right there (later on one of them even turned out to be a hidden bug), and as an added bonus the tests written were included in the team suite of unit tests.

For me seeing that was a really nice surprise. I recall it took me quite a while to adopt that and use that approach and i was starting to do it on a regular base only after several months of actual TDD experience.

so what’s the moral of the story?

1. always look for new beginners to see how they adopt new habits. There is much to be learnt there.

2. when dealing with new code, try approaching it with tests.

Posted in: Engineering Practices,TDD