(This is a continuation from part 1 of “Depression and the Software Developer”.)
If one of the most powerful weapons against depression is hope, one of its most powerful fuels is hopelessness.
I attacked my next job with gusto and enthusiasm. The company had previously outsourced a project to an offshore contractor, and now that the fit had hit the shan, they were looking to bring it back in-house. The product was a stand-alone box with embedded software, and they hired me to take over the hardware diagnostics, which are used to ensure that the units sent to customers actually work.
Somewhere, I read that it takes six months for a new employee to become situated in a new job. But I did it in four. And then I crashed. Hard.
Prior to this time, I had been working in small companies. In a small company, when something needs to be done, you do it and get it done. At the time, I didn’t realize that in a larger company, there are people hired into key roles, whose job functions include preventing you from accomplishing anything too useful.
For example, when manufacturing powered up a new unit for the first time, they needed to install the software that ran it. This software came from the software department. Of course, as a diagnostic engineer, I worked in the hardware department, not the software department. That meant that after the manufacturing tech installed the device’s software, he needed to go through a whole separate process to install the hardware diagnostics. Now, when you’re building up thousands of these boxes, adding an extra step on each one is expensive. So the manufacturing engineer asked me if I could package things up so that he could install both the main software and the diagnostics in a single step.
Like an idiot, I told him that it should be no problem, and I set about making it happen. I talked to the release-engineering department and found out what would be required to get my files into the main software distribution. No problems there. Then I tracked down the software engineer who could modify his installer to install my files. In toto, we needed to tweak three lines of source code. We all seemed to agree it could be done quickly and with minimal risk. Everything seemed to be coming together nicely.
Then the software-department manager got together with my manager, and they quashed the plan. As I understand it, they were afraid the change might break something in the software release, and they didn’t want the CTO to blame them when the software was delayed.
As a result, that three-line tweak took six months to deploy.
In retrospect, I understand. After all, the software manager didn’t care how much time or effort or money that three-line change would have saved, and he didn’t care about the manufacturing engineer, and he didn’t care about me. He only cared about not being blamed for introducing more bugs into an already-late and out-of-control project.
My manager at least was big enough to deliver the bad news to the manufacturing guy personally. He stood behind the decision he had made and didn’t expect me to explain it, and I respected him for that. But that didn’t change the way I felt about being shot down.
(Continued: click here for part 3 of “Depression and the Software Developer”.)
You need to stop taking things so seriously! You worked hard at the fix, the manager rejected the fix. So what?! Did the universe collapse? Did you not get paid? Bodidharma spent nine years starting at a wall and became a supremely enlightened being (i.e. a totally non-suffering guy!). Why not learn how to not give a damn if your software is deployed or not – then you’ll be a man my son (apologies to Rudyard Kipling…) The end-external-result is no worse than the end-external-result staring at that wall. *You* allowed yourself to become depressed about there being no external result. Work on zero-external-results, and daft managers, meaning *nothing* to you. Sail through it all with equnimity, like a Zen master. Maybe you say all this in part 3, if so I apologise for teaching you to suck eggs, now on to part 3…