The anal phase

Long ago I had a logic — real logic, not the computer thing — exam in my university and when my teacher was about to return the tests with our scores he started a diatribe about the anal phase.

He explained that at some point of their development, babies realize that when they defecate, the product is not a part of themselves. After this disidentification period, they also realize they are capable of creation. So, he said, most of the pleasure of doing it was, in essence, the same pleasure we get when we produce things, have new ideas or build something meaningful. But there was a catch: some people would not disidentify completely and this would be the genesis of someone who always takes criticism directed to the outcome of an activity personally.

The first and most important message was clear. Even though what we have done was a piece of shit it didn’t meant we were shit. We were only the creators of shit.

The second message was that we should grow up and start producing things that would make us prouder than shit.

Recipe for an idiosyncratic developer

So last month I had a long conversation with a very seasoned developer. He was in the industry for more than than 20 years and he was one of the exponents in a specific technology in the country I live.

He told me 3 things that really put my brain at work. It wasn’t because I didn’t knew many — if not most – developers believed in the same ideas, but the fact that someone so experienced would put forward these points of view made me wonder.

1. Pair programming and code reviews are intrusive

The first thing he told me is that developers don’t like pair programming for two reasons. First, it’s distracting.

He explained that when you code, your brain is wired in such a way to the activity that having someone else around would inevitably break your concentration.

This point I concede, ‘though I really don’t believe it’s always a negative effect. I agree in part with Uncle Bob, who made a case against getting “in the zone” in his marvelous book Clean Coder.

So what is “the zone”, or “flow”? According to wikipedia it’s “the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does”.

For Uncle Bob, when you’re in the zone you lose the vision of the big picture and this leads to worst quality. This is a hot subject, and every review of the book you’ll find in the internet will frame this point as “in dispute”.

So far, so good. The second thing he mentioned is that pair programming, and code reviews as well, are intrusive. That developers were uncomfortable with someone looking and providing instant feedback while they’re coding.

This is a perfect reaction if people are rude. But I don’t think this is the case very often. Practices like code review and pair programming may become a social problem, as most research in the area indicate, but, largely these are proven practices that only enhance team work, developers’ skills and overall quality.

This is a good hook to the second thing he told me.

2. Codings standards shouldn’t be mandatory

The second thing he told me was that, when he worked as a manager he didn’t enforce coding standards. He thought it was preferable to maintain individual styles, because these styles were hold dear for the developers and he wouldn’t sacrifice this special relationship for the sake of a unified aesthetics in the code.

This reminded me of a friend of mine who is, among other things, the maintainer of Perl’s Date/Time library and one of the developers of Perl 6. Once he told me that when he started introducing functional elements in his code style, the community asked him to step back, since functional development wasn’t a widespread technique, and required a steep learning curve. Although this friend of mine was very thrilled by functional programming and, in his mind, the code was way more elegant this way, he decided that building community, by allowing more people to contribute, was more important.

And this is a very specific scenario that sometimes happen inside an Open Source community. The rule of thumb in companies is that if you introduce new techniques, you can always convince your team to adopt this improvements. After all, teams are eager to learn, and new techniques will be received by good developers as a gift. But, if you can’t convince your team these techniques are helpful, should you still push your code to production?

But remember he wasn’t even talking about techniques, he was talking about mere standards. It’s a way more basic proposition.

So let me make an analogy. We all speak a slightly different version of our native languages. We all have some words that we like better, slangs that we’re used to and references that only who had the same experiences we had can understand. So we speak this slightly different language, and it would be weird to ask someone to comply with a “company standardized” language. But now let’s correct the analogy: imagine we work together in a company that writes dictionaries or encyclopedias. In this case it would make perfect sense to enforce a universal way to write things, so our readers are not bewildered by the fact every entry is written in a slightly different style. And “our readers” in this analogy points to our future co-workers in a software environment.

Anyway, the lesson here is about prioritizing a collective practice over a personal idiosyncrasy.

3. Developers should not do QA

This is another thing I’ve been listening over and over. The argument is that developers are so into the main technical challenges, the “bits-and-bytes” that they just hate details and corner cases. He asserted that it’s true for the work of most developers that just by pressing down some random keys you can trigger a bug.

Because of that, every developer should have on his side a QA engineer. A QA engineer, in his own words, is someone who understands code, but has started his career as a tester, and, therefore, wasn’t contaminated by this crazy bit-and-bytes fever that makes otherwise sane human beings blind to details.

So the developer would write the “important code” and explain to the QA guy what could go wrong, and he would assume from there.

I’m not going to go along explaining how economically unsound, and how actually damaging to quality this notion is. What I’m interested is on the idea that this is the equivalent of having someone just to clean my ass every time I go to the bathroom. Actually, it’s worst, because I’m not even required to ignore details in a specific place tailored for ignoring details.

The idiosyncratic developer unveiled

So now that we have a recipe to create and idiosyncratic developer, we also have a more precise image of it: He has this special relationship with his code, and whoever interferes in this relationship is an intruder. He only wants to relate with the code when it’s important for him, and when the code is not interesting anymore, he doesn’t care.

You may be thinking that this looks like a person in love with his code. I would say that, quite the opposite, this is about possession. This developer simply fears that someone else may discover that he’s actually keeping the code as a hostage and may try to free the code from this abusive relation.

He’s afraid of displaying his own shortcomings, his own vulnerability. This is why he takes such a reactive behavior. His unwillingness to have a public approach of writing code is just a masquerade for his unwillingness to learn.

Code as communication

The analogy I used before about writing an encyclopedia is also happy in another aspect. Writing code — specially modern, Ruby code — is way more a practice of describing the behavior of the app than writing a list of instructions to a machine. The best in our field are regularly reminding us that good code “reveals its intent”.

In this approach code is more like an explanation, in a as-close-to-english-as-possible language, of what the app is about. And the holy grail of development is to make it as clear and obvious as it can be, so other people who share the language can quickly grasp and follow along.

Instead of a bunch of developers talking with the code, each one in its own dialect, code should be seen as a direct communication between the developers themselves.