The Best and the Worst : Working with Genius Programmers

A long time ago, in an office far away from where I now sit, I once worked with a chap I still refer to as the best programmer I've ever met.

This was a guy who could take the whole code base, in Delphi, home and over a single weekend re-write it in Java.

This was a guy who I saw, from scratch, write a C controller for an embedded PIC to capture an image from a supposedly incompatible TTL driven camera and then an analyzer for the captured images which would detect and show motion, making for our common employer their best ever selling product a cheap security motion detection system, which didn't rely on relatively expensive high resolution cameras.

It was awe inspiring as a newly graduated programmer, whom had a huge background in DOS programming, but whom had never worked in Enterprise level development before.

I sat next to what I still regard as near genius.

This very same chap was also the worst programmer I've ever worked with.

Because he was so highly functioning he never needed to document his code, fine I hear you cry, good code should be self documenting; and you're absolutely right; the problem?  This guy also got bored so so quickly, so he used to tell himself stories in his code.

Yes, Robert Jordon eat your heart out, this guy wrote epic fantasy on a grand scale, across hundreds of thousands of lines of code, in Delphi, C, C++, Java and even in HTML which I saw him churn out, it was all a gobbledygook puddle of story telling rambling mess.

But the code worked, the managers didn't care that it was gibberish; at least not at first; because they could churn out product to the anticipating masses of customers.

Such a prolific talent, he had so many fingers in so many pies, he was invaluable, key man, the man, the one person every project started with.

The result?  Every single code base he touched was tainted with this un-maintainable morass of code.  Which an ever increasing march of cheap graduate programmers, like my then self, had to then decipher, maintain and coral.

Often the time it took to bring a project into some semblance of order would be three or four times more than it took that one original chap to write, this did not go unnoticed and managers rightly pointed their fingers to ask the question "How could you not keep up?"

I however was the first such junior person with a voice, I've always had a voice, and I pointed right back "How could you let us get into this mess?"

I dated to question, sweep, and change the code, I dared to spend time even just aligning the code correctly.  No JetBrains formatting (or resharping) tools, very few tools existed to cover the whole pantheon of mess we were now wrestling to stay a head of.

Daring to question, change, read and challenge the talented one resulted in his changing his ways, he returned to some of the projects I had lead re-working, he saw the structure and the discipline within he saw that you could quickly pick up and get to work without needing to load all the software into ones wetware in a laborious re-read.

This skill, this willingness, to press the boundaries is somewhere I've oft and continue to take projects, and I do ask those I throw code at to feedback to me where they think anything needs reviewing.

I deplore any project or maintainer whom takes the grounding that they must keep things secret and keep things safe.

Drop, the epic fantasy, you're not Gollem, share, review and open the boundaries.