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.