When we last met Dave, he was all about keeping things on the fast track. So fast, in fact, that he rushed several changes with the potential to break everything straight to production on his first day. For better or for worse, his tenacity remained a burden companion long beyond his first day.

Dave utilized a new hipster management philosophy called "overbearing." The main tenets of the philosophy are that 1) you have to be overbearing, 2) you have to be a jackass, and 3) you have to be an overbearing jackass. Dave became known for popping up at peoples' desks, asking one irritating question ceaselessly.

"Did you check in your code for that change yet?"

For Carlos, the answer was more often than not "no." Carlos's head is full of old-fashioned ideas, like making sure that code compiles before it's checked in, testing his code before checking it in, and generally not feeding the source control system with an endless stream of commits. Dave appeared with incredible, if not creepy regularity — every half hour, right on the nose. "Did you check in your code yet?"

"Not yet, Dave," Carlos would reply many times each day. "I'm still working on the feature." In this case, it was a scrollbar that was supposed to disappear when a context menu became visible. "It's not as simple as it sounds," Carlos explained, "the audio resumes when the bar is hidden, so now there are more factors that cause the audio to pause and start."

"How long will it take?"

"About an hour."

"OK, well just check it in after you have the scrollbar hiding. We'll work on the audio after that."

Carlos reluctantly agreed.

Commit! Commit!

The next day, Dave told Carlos that his change wasn't complete. "The audio isn't pausing and resuming correctly."

"Right, remember what I said yesterday? I just finished it."

"OK, I'll enter it in the bug system. Mark it complete and we'll do another test."

"Well, I didn't mark the last one complete. I'll just use that." Carlos couldn't believe the conversation he was having — the previous day he'd tried to argue that he wasn't done, which fell on deaf ears, and now he was getting a talking-to about the feature not being done. He tried to clear his head and moved on to his next task.

A half hour after their last exchange, Dave came back. "Did you check in your code for that change yet?"

"Not yet, Dave." Carlos waited for Dave's trademark demand that he check in his half-complete work.

This time, Dave's response was different, though. Rather than returning to the swamp only to reappear 30 minutes later, he had something helpful to share. "Ah, well, would it help if you knew that on the devices we'll be deploying to, input is handled a little differently than on the newer devices." Dave went on to explain the fruits of his research, and pointed out the differences in input handling across the different devices.

Carlos was incredulous. "Thanks, Dave!" It was something Carlos could have looked up and found almost instantly, but he didn't want to bite the gift horse's hand that fed him in the mouth and reject Dave's advice. "Oh, also, I wanted to let you know that I'm getting closer on the message processing, too. To fit in our time constraints, we had to make some compromises. For one, the messages can only pre-process, but post-processing isn't supported. It won't scale well, but this was the best way to get the features done on time."

"OK, Carlos, sounds good. I'll be back to check on you in an hour or so." Carlos knew that meant a half hour. Before a half hour had passed, though, Carlos was summoned into the VP's office.

Fall Guy

He took a seat, and looked around the room. The VP, the CTO, and Dave were sitting together opposite Carlos. "What are you working on?" the VP asked.

"I'm working on the messaging functionality," Carlos began. He explained the technique he was using, exactly as Dave had helpfully described.

"Yeah. What you just said, yeah, all wrong. Totally all wrong. Take a look at this," he said, spinning his monitor around. The VP was right — Carlos had done it wrong based on Dave's advice. He cursed himself for listening to Dave.

Carlos looked to Dave for help, but Dave was whistling and twiddling his thumbs, and clearly avoiding eye contact with Carlos.

"OK, I'll rework what I have," Carlos said. Turning to Dave, he asked "Dave, any advice? I mean, you know all about this stuff, right?"

"Uh, yeah, just rework what you have."

"It's the strangest thing. I could've sworn I heard somewhere or from someone that I was supposed to do it the other way."

"Yeah, well, be sure to research better next time." It was Dave's lucky day — Carlos would take the fall for his mistake. Subtlety doesn't work on Dave.

Of course, Dave wasn't just about constant checkins and letting others take the fall for his mistakes — his lies worked the other way too. Later that day, Dave talked to another developer about Carlos's code. Almost verbatim, he stressed the negatives of what Carlos had said earlier. "I was reviewing Carlos's code and found some soft spots. For one, the messages can only pre-process; no post-processing is possible with the code. It's also not going to scale well." In reality, Dave hadn't found any of these problems — he was just repeating what Carlos had said.

Later that day, Dave came by Carlos's desk one last time. Carlos rolled his eyes, wondering if he'd finally get an apology, or any acknowledgement of Dave's mistake. He wasn't holding his breath for it.

Dave paused for a second, making eye contact with Carlos.

"So did you check in your code for that change yet?"

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