Replacement Trainwreck
There's an old saying about experience in IT: Some people have 10 years of experience, and some have 1 year 10 times. Every day, someone learns the hard way how true this statement really is.
Raquel returned from holiday, only to get a call from above saying her contract would not be renewed, giving her 2 weeks' notice to find a new placement. The boss explained it was a budget thing, since contractors are often more expensive than salaried employees, especially ones working remotely in the Asia-Pacific region. C'est la vie.
Raquel's big project was a perl module to talk to a high-end but aging storage system. The hardware had no API, and the CLI was arcane, with wildly inconsistent formats in the command output. Raquel abstracted that all away to give a programmatic interface for the other developers. The downside of this approach was that every time they put out a firmware update, she had to modify the perl script to match the changes. The module had grown to 1600 lines of code through 400+ commits in the 3 years she'd been working there. The other developers would include this as a git submodule so they could pull in changes in an automated way and re-release their tooling.
Raquel was asked to hand off the module to John, who assured her he knew git really well and enough perl to figure things out. It seemed reasonable ... at first. She got John set up with another, smaller tool she'd written: a plugin for a popular monitoring system to read the storage drives. It used the library she'd written as a backend, so she figured it'd give him some understanding of the functionality. Since some of their customers used Windows, she taught him how to compile to an executable. Once John was compiled and running, Raquel sent him to their lab environment to test the plugin.
A few hours later, she got her first bit of bad news: the plugin was failing, and John didn't know why. He attached the error message:
SSH connection to 192.168.1.10 (22/TCP) failed after 1 attempt(s).
Now, the library used SSH to connect to the drive, so Raquel's first suggestion was to make sure John could SSH into the storage system from the host he was working on. Things went quiet after that, so she figured he'd sorted it out-likely a loose cable or a disabled Ethernet driver-and went on with her day.
The next day, however, she came in to a more urgent message: John was still having problems. She asked for more details, and this was all she got:
SSH connection to 192.168.1.10 (22/TCP) failed after 1 attempt(s).
Maybe he forgot what he was doing? Raquel reminded John about checking the connection, and he replied that he could SSH just fine from the machine.
Weird.... She fired up a WebEx call so she could see what was going on in the lab. Sure enough, John could SSH from that machine to the storage device ... but he was running the plugin on his laptop. He was genuinely puzzled why that mattered.
Over the next half hour, Raquel dug up a network architecture diagram to show how only the lab machines could talk to the lab storage devices. Finally, still confused, John agreed to just do his development on the machines in the lab and they hung up.
That afternoon, Raquel's favorite type of ticket came in: a nice easy feature add for the monitoring program. It'd require a new method in the library and a handler for the Nagios plugin; it was perfect for John to get his feet wet. She assigned it to him and attached a link to a method in the library that was about 97% similar to what was needed, for him to study (read: copy and paste).
Several days slipped past in silence. Since there'd been no commits, Raquel dropped John a note to say that her contract was almost up. If he wanted a code review, he should push his changes and let her know.
John replied that the code was "almost complete" and would be checked in "shortly."
Fair enough, Raquel figured, and let it go.
Her second-to-last day, John sent a note saying he'd checked in his changes. He also included a link-to a different git repo.
Maybe it's a fork? No such luck. It was a brand new repo with exactly 1 commit. Not only had John made a new repo, that repo contained both the library code and the Nagios plugin code, with no submodules in sight.
Raquel could hardly believe it. How am I supposed to review without a diff?
She set up another WebEx for early the next morning-her last day-and explained to John how the lack of history was a critical problem. He agreed with her and assured her she'd get the diff she wanted.
Now what, dear reader, do you think Raquel actually received? If you guessed an email with bullet points outlining "At line 75 in foo.pl, I changed A to B. At line 89 I changed C to D ...", you're today's lucky winner.
Glancing at the clock, Raquel decided she had time for one last good deed before departing forever. She ran diff on the 2 repos, then typed up a polite, precise email outlining her comments. John's code wasn't all that bad really; he needed to code more defensively, since the storage system would sometimes throw errors, and he probably shouldn't loop over output that would always be exactly 0 or 1 lines of code, but it functioned well enough. Oh yeah, and the big chunk in the middle of the original method that he'd elected not to copy over? That handled the fact that the storage system was a cluster, so you may not be on the host you want when you first SSH into the machine. But otherwise, it was decent code.
Raquel's final email arrived soon after that, from John's manager. Apparently, John had complained that she was unprofessional.
She wrote back to wish them both the best of luck, collected her things, and laughed her way home.
[Advertisement] Release!is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped!