The 10x Developer

"You're going to learn quite a bit from Burt," Burt said. "He's one of the best."

Davide blinked. He wondered if his new boss spoke about himself in the third person as a matter of course. Cautiously, he said, "Well" I hope so?"

"Burt's been with us since the beginning," Burt continued. "Nobody but nobody knows our systems and our environment better than he does. He's one of those" whatchacallits"" Burt glanced around his desk, and found what he was looking for- a glossy trade-mag with a cover story about the most productive developers. "A Ten-X developer. We're really lucky to have him, and you're really lucky to work with him."

Burt was not speaking in the third person. Burt, the CTO of the company, was a huge fan of Burt, the lead developer at the company. When Davide was hired on, CTO-Burt spent a lot of time praising the genius of Dev-Burt. Once David started working, he didn't see CTO-Burt very much, but Dev-Burt also was eager to talk about what a genius he was.

"Not just anybody can manage a system with 100KLOC, mostly by themselves," Dev-Burt said. "But stick with me, and maybe you'll learn."

Dev-Burt's genius was questionable. Five minutes skimming the code-base made it clear that Dev-Burt had the coding conventions of a drunken lemur. The only thing that made the code even slightly readable was that most of it was in Python, and thus had to be indented logically. That was the only logical thing about it. Some variables were named in camelCase, others in snake_case. Half of them were just alwayslowercase. Function names were generally more consistent, only because there were fewer of them: Dev-Burt was the kind of developer that just loved to write 5,000 line functions. There were plenty of global variables, plenty of spaghettified code, and plenty "god" objects that mashed together thirty unrelated behaviors into one mess that behaved differently depending on which specific flags you set.

Dev-Burt was too busy being a 10x developer to give Davide any guidance about what he was supposed to do. The only coding conventions appeared to be "Dev-Burt does whatever Dev-Burt wants." From time to time, Davide would pick up tickets as they came through, tracking down and patching bugs, but mostly he tried to find opportunities to refactor the code and add some unit tests.

This radical behavior lead to a tense meeting with the Burts.

"Burt tells me you're causing problems," CTO-Burt said.

"He's making a mess out of my code," Dev-Burt complained. "He's making it more complicated!"

"I was just refactoring it so-"

"There he goes," Dev-Burt said, throwing a hand in the air, "using his made up buzzwords. Look, we've got product to ship, and your refractioning isn't getting us anywhere. I wouldn't mind so much, but it's eating into my own time, and making it harder for me to get work done!"

"That's bad," CTO-Burt chimed in. "Because Burt's a Ten-X developer. His time's ten more times as valuable as yours."

At least, after the meeting, Davide had clear rules to follow: Dev-Burt does whatever he wants, Davide does whatever Dev-Burt tells him to, and Davide was not to touch any code unless it was to deal with a ticket assigned to him by CTO-Burt.

This gave Davide a lot of downtime, during which he could watch the codebase grow. It was true, Dev-Burt was a 10x developer, in the sense that he could write ten times as much code as necessary and he'd often write the same code ten times, in different places in the application.

One day, while wondering if this made Dev-Burt the first 100x developer, Davide received a new ticket. One of the automated jobs had failed, dumping a stack trace to the log, and it kept failing every hour. It didn't seem to be having any other effects, but CTO-Burt wanted it fixed.

Davide assumed there was an un-handled error, and dug through the stack trace to find the offending code. He was half right. Once he cut away the bulk of the logic, the basic structure of the method was this:

def manage_expectations(*args,**kwargs): try: #about 1,200 lines of code except Exception, e: raise e

So, Dev-Burt had handled the exception" by re-throwing it. A few hours picking apart the function, and it was clear that the underlying problem was a FileNotFoundError when scanning a logfile for messages- there was no guarantee that the logfile would exist. It was easy enough to make the code fail gracefully when it encountered the exception, but that might be considered "refractioning", and so Davide needed to ask Dev-Burt for permission first.

"Hey, Burt," Davide asked, "can you pull up some code for me?" He pointed to the raise e and said, "Why are you doing that? Why is that there?"

Dev-Burt nodded, stroking his chin thoughtfully. "That's an exception handler," he said.

"Yes, I know that. Why is that raise there?"

"Hmm" I guess I'm not sure. What does the raise command do?"

Davide went back to his desk, fixed the exception handler, and then started sending out resumes. He'd learned everything he needed to from Dev-Burt, and was now ready to fail gracefully out of this job.

[Advertisement] Application Release Automation for DevOps - integrating with best of breed development tools. Free for teams with up to 5 users. Download and learn more today!