Dan’s team had a large re-engineering project. They wanted to remove some Java dependencies and replace the UI layer with their new, in-house developed standard library. Like most large maintenance projects, it was big, had a few hidden traps, but was mostly time consuming tedium. For the tedious bits, they decided to bring on a new developer.

William was that developer. He radiated confidence like an LED bulb- cold, harsh, and efficient. He said all the right things in the interview. When Dan showed him their Git repository, William nodded sagely, “I know my way around Git quite well. I appreciate the distributed part of it. It gives me the freedom to work alone. I work best alone.”

Dan’s team wanted somebody who could work with minimal guidance, so William’s lone gunman motto seemed like a good idea. They brought him on, and Dan spent the first few days getting him set up, introducing him to the code base, and helping him with any questions he had. William didn’t have many, as he reminded Dan, “I don’t need you hovering over my shoulder. I work best alone.”

Dan took the leash off, and William got to work. For the next three weeks, the burndown chart resembled a gasoline-soaked house, and William was a lit match. Everyone was quite happy with the results they saw, and agreed with William: he worked best alone.

At least until all progress ground to a complete and total halt. “Hey, is there a problem?” Dan asked.

“Not really, I’m just fighting with Git. It’s so slow.”

“That doesn’t sound right. Do you want a hand?”

“No. I work better alone.”

Dan let William take a few more days to fight with whatever was slowing him down, but when nothing changed, he popped back. “Is there a problem?”

“Git is just frustrating. It’s so terrible at working with binary files!”

“Well, it’s not really meant to be good at that. If you want, I can take a look-”

“No, it’s fine. I work better alone.”

Dan was suspicious, but William’s work had been so good to start, he decided to let it slide for a few more days. Whatever specific problem William was having would clear itself up before long.

In a way, Dan was right. William’s problems did clear themselves up- he quit, without notice. He told Dan that the best part of his new job: “I won’t have to fight with Git anymore. They just use FTP for everything.”

That was fine for William, but it meant Dan had to go pick up William’s work. He started a git clone and waited for the download to finish. And waited. And had a cup of coffee. And waited. By the time it was done, 2GB of data had been copied over. That was shocking, since the original repository was only a few megabytes.

One mysterious file, derpecated.zip, drew Dan’s attention. Once he unzipped it, it was easy to see the problem. Each time William had changed or deleted a file, he added the original to the zip archive, renaming them from “foo.c” to “foo.1.c”, “foo.2.c”, etc. And each time, he’d restage and commit the derprecated.zip archive back into the repository. The resulting delta was nearly as large as the archive itself, and was tracked in the Git history.

Dan got to spend a lot of time fighting with the repository’s tree, trying to pick apart the zip file changes from the real changes in the code base so that he could shrink it back down to a reasonable size. It was complicated and fiddly work, and nobody could help him, which gave him lots of time to discover the joys of working alone.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!