Should Have Paid Me More

Note: You may wish to read Part I of this series to gain context.

When first assigned to the Plus project I was told to play the role of “bug manager”. “Jim (see Part I) wants to do the right thing,” the boss remarked. “so he’s informed his new company that he’ll be providing bugfixes and support on the Plus project during his first month. We can contact him about bugs at any time during work hours and he’ll try to have a fix coded and checked into SVN before the next day.”

Given Jim’s apparent charity, my role in the project was simply to aggregate bug reports from the 150 users, de-duplicate and prioritize them, and ship the result off to Jim. This seemed decently straightforward; after all, I didn’t know anything about the 500-class codebase or the difference between intended functionality and broken features, and there wasn’t any requirements document, project documentation, or decent in-code documentation available. As the voluminous bug reports crashed in like a tidal wave in monsoon season during an earthquake, I went to work. continue reading…

When I interviewed for a programmer/analyst job at one company I was impressed by the high-class technology and excited by the opportunities it represented (“You could be a god here” was mentioned several times). Shortly after starting work another member of the company’s four-person development team took off for greener pastures with a year of employment under his belt. This programmer, whom we’ll call “Jim”, had been the sole developer on a revolutionary project we’ll call “Plus”.

Plus was intended to be a company-changing desktop application giving remote field technicians the ability to record site visit information offline and later “sync” it with the company’s servers. The product was released straight from Jim’s development machine to production on 150 technician laptops just two weeks before Jim’s last day at the company. Being the only available developer, I was assigned to the project in his stead. continue reading…