The Case of the Unconventional Coder

Some engineers and programmers insist on marching to their own peculiar drums. Sometimes that can be a good thing, but for managers it can be a complete nightmare.

Some engineers and programmers insist on marching to their own peculiar drums. Sometimes that can be a good thing, but for managers it can be a complete nightmare.

One of my team members was a very quirky character, which also translated into his style of coding.

On one project, we were writing a somewhat large embedded code in ARM, with more than 60 modules. Instead of adhering to our common style, he insisted on doing it his way.

At a certain point, I gave him the task to design several complex data entry screens, with a particular "look and feel" to communicate over our dumb terminal interface.

After leaving him at it for a month, I went over his code to peer review it. I was absolutely astonished. All his screens -- very complex, context-sensitive screens -- were contained in a single printf() statement.

He wrote the longest printf call I had ever seen in my entire life. The line was 1,450 characters long!

It was constructed with ternary operators like {"%s%s%s%s.....%s%s", a > 2 ? b < c ? "this" : "that" : f == 0 ? ......}. Just imagine a line with more than 8 layers of logic, over 60 extremely complex ternary operators, spanning over 1,400 characters in a single printf() evaluation.

It worked, but I presumed that it would be impossible to maintain. I trashed his work and asked him to redesign it from scratch.

It was very tense, and we argued intensely, but he ended up doing it right in the end. He was a brilliant engineer, actually.

— Jonny Doin is CEO of GridVortex Systems. He has over 25 years experience working with embedded systems R&D and hardware and firmware design. He has worked on medical, broadcast video, industrial, and energy applications and founded GridVortex in 2012 to design and deploy IoT intelligent networks for large-area urban projects and embedded micro-clouds.

In early eighties , we used manual code by using coding sheets to modify our programs in binary code using piono key switches on the front panel of the computer. This was because the recompilation was done only once in a while .Any changes of the programs had to be done as patches as the recompilation of the code was not possible every now and then . So we used to keep a record of the patches until the enxt compilation. One of or smart programmers kep all the record of the patches in his brain, never recording it on the paper. This led to many a situations where we used to spend hours in debugging a code until this smart programmer pulling out a patch from his memory and fixing the problem.

Reading the article and the some of the comments, my reaction was, I'm sure glad I don't work in that environment. Took me some time to figure out how to get this across.

Sure, code should be clear in preference to JUST efficient. That's not my problem. My problem is, engineers who feel they are "subordinate" to management, or management that feels it has "ownership" of the work. Both concepts are foreign to me and to where I work.

Where I work, the management of the actual engineering work is done by engineers, typically lead engineers. And "ownership" is definitely with the engineers that did the work. Everyone knows who they are. I wouldn't have it any other way. Surprising that others haven't reacted similarly.

@Jimmy99Neutron:
I agree that expectations should be clear. Actually, the programmer mentioned is a very good Engineer. The case described took place during his integration into the project, and into our Aspect Oriented methodology.
It took a little time and effort to convince him that I wanted his brilliant mind on the logic and design, not really on cryptic descriptions. He ended up contributing with many good designs, and also learning a lot with his peers also.
Instead of adhering to rigid rules, the person must adopt the style due to the perception of gain.
Peer review and code clarity are much more than management concerns. When people realize that they can easily tackle projects with 300k lines of code by practicing a clear style, they embrace it. In a well integrated team, we can write code at ten hands and the code seems to have been written by the same person. That's what peer review does for you: you get all the best contributions to rapidly disseminate through all the programmers.
- Jonny

Firstly, as this person was a subordinate, expectations for his work should be clear, a process is to be followed as it benefits the team, the project and its management and the product ( reduced maintenance, robustness, correctness, etc.).

Knowing this persons history, the guidelines or standards should have been emphasized. Tolerating deviations incurs risk, re-work, time/schedule implications, quality and money. As the Leader of the project you "own" the results. In no way does this condone the Coders preferences and choices.

Re "clarity is the prime virtue." Amen - writing turgid code that's "efficient" costs more than it saves. From a cost-benefit standpoint the optimal program is no faster than adequately fast (C and assembly programmers reading this are probably reaching for the smelling salts). If future additions makes it unacceptably slow, then and only then do you make an analysis of hot spots and work on those that produce the greatest bang for the buck until the program is again adequate.

Re the manager who wanted three clever lines replaced with one that would be familiar to other readers: they promoted the right guy to manager.

However, the managers referenced, who insist on rewrites to improve clarity, are thin on the ground, at least in my experience (1959 - present). The ones I've encountered would not take kindly to the programmers taking the time to (in their view) "beautify" code. And it wouldn't win them any friends among THEIR managers.

There's a place for code like that; the "Obfuscated C" competition, where programmers can get the perversity out of their systems before producing real work.

People acquire all sorts of ideas about what constitutes good code, from all sorts of haphazard sources, but managers should make it clear upfront what constitutes merit. (It took me a while to figure it out, and I ask forgiveness of my victims.)

A program is not just a set of instructions to the compiler, it's an open letter to the next unfortunate who has to maintain it. As long as it does the job in a reasonable time, clarity is the prime virtue. It should be obvious what it's doing, and why. This can take a surprising amount of work, distilling the essence of the problem's structure and using the most powerful tools available.

One of the unfortunate consequences of CS education is that people feel compelled to recreate compilers and usurp the functions provided by the operating system, presumably to justify the pain of studying them. KISS, dammit!

% For a moment I thought perhaps this programmer was a postscript programmer. We use lots of % as these are comments.

% Normally I code my lashups in postscript. This last week I have been coding in C. Must remember to put the ifs and elses at the top of the bracketed {} blocks not the bottoms. << and >> are used to denote dictionary structures.

% Perhaps this is why I prefer AVR ASM for embedded. It feels really strange to use C on an 8 bit micro with only 2K of SRAM. printf and fprintf are not the best solution in such a limited environment.