An IDE Impostor

Despite having written code for twenty years before he'd even turned thirty, Jim couldn't help feeling like a bit of an impostor. He wasn't suffering from the Capgras delusion, though. He felt the way many of us feel when presented with a new job using new technology - in this case, the .NET framework and C# - that surely he couldn't be good enough at this to keep the job for very long. Surely his peers would find him wanting. While Jim struggled with his own self-worth, one thing he didn't struggle with was choice of IDE: Visual Studio. Intellisense, one-click refactoring, and a host of other features allowed him to fake it till he could make it. As far as Jim could tell, there was no reason to use anything else when developing a .NET solution.

Jim's first assignment was to work on a codebase created by Biff. Biff was a Something-Something-Level 3, so Jim was ready to learn a few new things when he fired up Visual Studio and opened Biff's solution. And learn he did. For example, he learned that VS marks syntax errors with a red, squiggly underline, much like Microsoft Word does with spelling and grammar mistakes. Biff's code lit up like a first-grader's essay about summer vacation, loaded as it was with misspelled identifiers, missing semicolons, and AWOL closing braces. Jim would have wondered if Biff had ever tried to compile the mess, but he was too busy wondering if the senior developer made a habit of typing with his eyes closed, since Visual Studio would have helpfully pointed out these sorts of mistakes as he made them.

Not wanting to scream "WTF?!" at a senior colleague he'd just met, Jim drafted the most diplomatic email he could, requesting that Biff provide input on the worst bits before Jim started making changes. After all, he explained, he didn't want to change something Biff intended to be there.

Biff made some changes, and when he emailed them back (Jim hadn't heard mention of source control since his job interview) Jim noticed two things right away: first, every class was declared in a single file, contravening the extremely common .NET convention. Second, and what prompted Jim to pick up the phone, the file's extension was .docx.

"Yeah, Biff? Jim here. I just got these updates you sent, but I think something's wrong with the attachment. Says it's a Word doc."

"Oh yeah," Biff chuckled. "I use Word to write all my code."

Jim tried to think of something, anything, to say in response. "You... what?"

"Word is where it's at! Way more control over formatting than that Visual Studio. I mean, what's with that fixed-width font? And in Word you can highlight things. This is Microsoft's best kept secret in software development, Jimbo. Swing by sometime and I'll show you what you're missing."

Jim hung up the phone and stared at his monitor, looking back and forth between his co-worker's IDE of choice and his own. It was clear that feeling underqualified was going to be the least of his problems.

Image from this prank application.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!

Featured Comments

Peter (unregistered) 2013-10-08

I worked with a experienced engineer, who felt that Word 2.0 was the best way to write CPLD code. He'd write the code in one color, the comments in another and the compiler directives in a third color.

Of course, the .doc file would not compile as written. First, the text was exported as a .rtf file. Next, he ran a complex script that used the text color as a cue to format the commands correctly. Finally, he ran the resultant source file into the CPLD compiler.

As our organization had long ago made the transition to XP (under which Word 2.0, not surprisingly, does not run), he kept a special machine loaded with Win95, on which he ran his editing system. As this machine wasn't networked, the source code had to be transferred to the system on which the CPLD compiler ran by USB key.

I wish I was kidding. I actually saw this and had to work on his code, when he left on a two week summer vacation. There was nothing wrong with his code, the guy was a good engineer. He just had this desire to make everything more intricate and complex than it needed to be. Job enrichment, I guess.

I ended up exporting his source .doc files as .txt and editing them in either vim or Visual Slickedit, something with an automatic syntax formatter for Verilog. I made some progress on the project. When he returned, he was annoyed. The boss seemed to be willing to let me continue to work on the project. The Word 2.0 afficianado left shortly afterwards, leaving us the legacy of a great tale...