by Anonymous

Recipe for career suicide

analysis
May 30, 20063 mins

When your boss thinks function calls and DLLs are mysterious mumbo jumbo, you have problems

My first job in the states was working for a company that sold database applications to hospitals. The president, “Mr. Charles,” had written the main applications himself using a programmable DBMS. Originally its programming language had been similar to BASIC, but after a couple of releases, it morphed to something much closer to C.

I’d been programming in the C style since I started using that DBMS, while Mr. Charles’ code was written in the older BASIC style. But hey, no problem! Mr. Charles loved my screens and menus, and he hired me to add that kind of pizzazz to his apps.

I started making modifications to his original code, creating libraries, making calls to functions — nothing crazy. Everything was going fine until he asked me to create a new application for a small hospital. It had to run under the then-new Windows environment, and it had to send out faxes.

When I installed it at the hospital, the users loved it, even though a small bug appeared the first time users tried to send a fax overseas. Apparently the library function I’d used couldn’t handle all those extra digits. I began working on it, but when Mr. Charles got word of the problem, he decided to check on the project.

Surprise! He couldn’t follow my code, despite my compulsive use of comments. I had created some DLLs and was using the latest programming methods to work around Windows’ memory constraints. Unfortunately, all this was new to him.

He printed my code and took it home. When he came in the next morning, he demanded that I show him all the changes I had made to his original applications. He wanted to know why I was not repeating the code every time I needed to do something, like he did. I explained that this was what function libraries were for. I even showed him programming manuals, but I knew he didn’t get it.

Two weeks later Mr. Charles ordered me to delete all my function calls from his apps. In the meantime, unbeknownst to me, he started creating his own version of the fax software. When he was done, he ordered me to go back to the hospital, remove my application (now working perfectly), and install his. I was supposed to tell the customer we were giving them a free upgrade to an improved version. This was a hard sell, considering that the new interface sucked, and that Mr. Charles’ version wouldn’t run under Windows.

When I told the hospital’s IT manager that he’d need a dedicated DOS computer to run the app, he flipped. Ultimately he insisted on my reinstalling the original version before I left. Then he called up Mr. Charles to demand a meeting. Before we went in, Mr. Charles went off on me, accusing me of badmouthing his version to the customer. He was a knowledgeable programmer, and he had built the company on his skills. If he couldn’t understand a programmer’s code, then the programmer was creating undue difficulties in order to maintain job security, yada yada yada.

The meeting was a disaster. The IT guy declared that unless the older version was retained, we would never see payment for either app. Mr. Charles was livid and stomped out without saying another word. About a week later, I was let go.

Being better than your boss is not always good for your career.