My position as an in-house developer did not come with a lot of managerial input on my projects. That is to say, the boss was in the office but wasn’t there to conduct a standup or routinely ask about timelines. He had his own stuff to work on and it would’ve been obnoxious if he was also expected to chase down whatever I was working on for updates.
In effect, I was my own project manager, for better or for worse, and it was up to me to make sure that I could give reasonable estimates and ship software. It was also up to me to talk to the people who would ultimately use my software to figure out just what it was they required.
This company wasn’t enormous. We definitely needed information systems to keep things running smoothly but the idea of the “user” wasn’t abstract to me. It was someone I could go hang out with if I went down a flight of stairs and knocked on the right door. They were pretty receptive to me showing up and asking questions because it signaled to them that I was interested in solving their problems and giving them useful tooling.
That knife cuts both ways. It turns out the developer wasn’t an abstract concept to the user, either.
Within a month of my first day, I had cobbled together a new feature for our sales department. I gave them what I thought they asked for and, with input from the sales department manager, I selected a group that would test this stuff and give me some feedback. Since this was the first effort, you can probably imagine how it went. I believe the only time my phone wasn’t ringing was when it was already in use. My inbox was full of emails about bugs and suggestions. I had entirely missed the mark, and it was a humbling experience. There was plenty of time to get it right, of course, but I discovered something.
I hate it when my phone rings.
At that job, the phone ringing was a sign that I had somehow failed in my efforts to produce good software. Maybe it wasn’t intuitive because I didn’t grasp their workflow well enough. Maybe it was failing in some corner case situation that I didn’t anticipate. Maybe it had a bunch of bugs once it was deployed that I could’ve worked harder to ferret out. Whatever the cause, there was a device on my desk that would interrupt my day and someone on the other end would bring me an issue that I’d have to fix.
This proved to be a powerful motivator, much stronger than any manager would have been able to bring to bear on me. I wanted eight peaceful hours in the office and that meant getting my phone to quiet down.
I ran down my options: muting it or ignoring it would just mean that I’d get pinged on the intercom or they’d show up at my desk to ask some questions. It probably wouldn’t be good for long-term employment prospects, either.
Instead, I opted to use the phone as a metric. If it rang a bunch after a release, it’d be time for a retrospective to uncover what I missed and do it better next time. If it was quiet after a release, that meant that I did a bunch of stuff right and I should probably take notes.
I ultimately ended up with a suite of best practices that were nearly identical to what the industry at large was (and continues to be) excited about. Things like automated testing, user acceptance testing, understanding the requirements and the business use case, etc… I fell backward into all of them merely because I wanted my phone to be quieter.
This meant that I spent a great deal of time thinking about exception handling and how to get back to a valid program state as gracefully as possible so that I didn’t receive either a bug report or a complaint about how it wasn’t doing what they expected. It also meant that I grew ever more capable at anticipating inputs and expected outputs and was able to minimize exceptional behavior before it even got to that point.
I learned to ask detective-style probing questions to really get to the bottom of the features that they were requesting so I could anticipate corner cases. The amount of times I would catch them in language that doesn’t translate well to code was astronomical, and I’d have to ask really nitpicky, annoying things like “When you say ‘always’ does it mean ‘this cannot possibly be another way in this universe’ or does it mean ‘usually’?”
Logging turned out to be one of the most well-used tools in my box. Certain situations would result in a phone call often enough that I would have those situations alert me and I could fire off a quick message to correct something before it became an issue. Combing through the logs would also provide useful pattern recognition so I could fix something before it necessitated a meeting to ask why something was working counter to their expectations. In some ways, the users were communicating with me constantly and they didn’t even know it.
This experience was priceless later in my career. My meticulous approach to making sure stuff worked the way that we wanted it to allowed me to catch corner cases and unspoken assumptions in user stories at more organized jobs. I didn’t need to be sold on any of the benefits of robust unit test frameworks and in-depth informative logging. I had lived through it and invented it entirely in parallel.
Just so my phone wouldn’t ring.
Joe Writes Software 