|
|
|
| Non-WTF Job: C++ Developer at Good Grievance (Ronkonkoma, NY) |
| « Some one is trying to Hack the Site | The Upgrade Treadmill » |
All eyes were on Darrell as he swaggered past the rows of cubicles. Darrell was different than the other developers -- sharply dressed in an expensive suit with designer sunglasses dangling from his breast pocket. He left shortly after arriving with a huge smile on his face.
The interview had gone well. The company -- a midsize logistics software provider out of New England -- had been falling behind schedule and delivering their custom reporting tools with more and more bugs. Darrell had successfully sold himself as the company's savior who could improve code quality and deliver faster than the others.
Darrell was a C# guru who would work for no less than almost double what the other contractors were paid. Even better for Darrell, he'd get to work from home, remoting in to an on-site workstation -- a perk which none of the other contractors received.
When Darrell returned home, he got right to work. He spent a few hours familiarizing himself with the app he'd be maintaining -- a custom-built system that tracked inventory, scheduling and members for several libraries in the area. After paging through a few files, he knew he had to make changes to several core modules.
He returned to the office the same day to berate the other developers for their unacceptably lousy code. "I'll fix this awful code, but then I need you all to follow my standards," he told them.
Darrell took it up with management, who immediately enacted a code freeze -- for everyone except Darrell. That'd give him the opportunity to fix all of the modules that no one had even realized were broken.
So for three days, Darrell coded furiously while the rest of the staff watched YouTube videos and honed their solitaire skills. On a Friday afternoon, he showed up to the office in his characteristic suit and sunglasses, announcing to the staff that he'd finished.
"You guys use your weekend to examine all the changes I made. This is the way experts code! I want all future code to look like mine."
Job, a longtime developer at the company, had been wondering the whole time what was so bad about the old code. He was eager to see Darrell's updates. Breaking out his trusty diff tool, Job found that the only changes were tests for equality.
The old code looked like this:
if (customer == null)
{
throw CustomerNotFoundExcepetion();
}
And the new code was:
if (customer.Equals(null))
{
throw CustomerNotFoundExcepetion();
}
The irony being that System.Object's .Equals() is an instance method, and would throw a NullReferenceException if "customer" was, in fact, null. Darrell's changes did nothing but break existing functionality and cause the wrong exception to be thrown.
Darrell made other so-called improvements to the code. His next change was to re-tab every file in the solution with a code-formatting utility. The merge tool struggled with all of the whitespace changes, so it was up to the rest of the team to merge the changes: change by change, line by line, file by file.
In an eight-day programming blitz, Darrell checked dozens of files out of the main branch in their source control, and was apparently so busy improving the code that he never got a chance to check them back in. Other developers on the team were getting miffed, because they needed to edit the modules and had no way to access them. Worse still, Darrell had vanished -- he wasn't answering his phone or responding to e-mail. The team was skeptical that he was doing anything.
Complaints eventually bubbled up to management, who summoned Job to join in a conference call with Darrell. And finally, Darrell answered the phone.
"Darrell, we've been noticing some delays in your check-ins," Job's supervisor began.
"Delays? What delays?! Everything's done!" exclaimed Darrell. "I've even done next month's work for no extra charge. It's just a lousy connection on your end -- you really need to update your connection. Right now I can't connect or even ping it!"
"Why didn't you let us know about this sooner? I'll restart it now."
"No, don't touch it!" It was too late, though. Job and his supervisor were sitting near Darrell's on-site computer, so Job had reached over to turn the monitor on.
To their surprise, it was in the middle of downloading a torrent. And the cursor was moving.
While Job watched Darrell's session, Darrell kept complaining: "I can't believe you have such old network equipment. I've been trying to connect for hours! Why haven't you bought newer network equipment?"
Darrell opened up an IE window and went to eTrade. He sold a few shares of one of his stocks.
"We haven't been able to get the budget approved," said Job's supervisor. "But maybe you'd be willing to help with the $7,000 in stock you just sold on eTrade."
"..."
Darrell's contract was cancelled that day, and management began requiring more rigorous technical assessments as part of the interview process.
|
And the sad conclusion is: If you want a good pay, try to look nice.
|
Re: Skills.Equals(null)
2008-05-22 11:03
•
by
Neil
(unregistered)
|
|
Knew a guy just like this. Acted like an all-knowing authority on anything and everything, but secretly knew nothing.
When doing a code review with a colleague (who coded in Pascal/Delphi), Mr X proclaimed that the code was terrible and that it wasnt going to be a good review. When asked by my colleague to elaborate, he was told "I dont know why its bad - I dont understand Delphi, I'm a Java programmer". |
Re: Skills.Equals(null)
2008-05-22 11:22
•
by
Mike Dimmick
(unregistered)
|
|
Some developers just aren't comfortable with merging (and if you use SourceUnSafe, it's no surprise, since that tool does automatic-merge-on-checkin and there's no other way to do an automatic merge).
We use SourceGear's Vault. Whether you need to check out or not, whether files retrieved by 'Get' are writeable, whether checking out is exclusive or not, and whether auto-committing of add/move/delete operations is enabled, are all separately configurable. There are also two big buttons on the 'Concurrent Development Style' page of the Options tab that read: - Check Out/Edit/Check In (VSS Style) - Edit/Merge/Commit (CVS Style) VSS Style is the default, as Vault tries to be an easy upgrade from VSS. I'm happy with merging so I hit the CVS Style button. It only causes problems when another developer using VSS Style has made an exclusive checkout, so I have to ask them to check in before I do (and I have to merge my changes with theirs). If I could check in when they had the file checked out they'd then have to merge my changes which is what they're trying to avoid. Our company generally has only one or two developers working on the same codebase - typically only one developer on a project, as we're a contract software house - so it's very rare that there are conflicts. In that case Edit/Merge/Commit speeds things up massively. Unfortunately older versions of Visual Studio don't really understand Edit/Merge/Commit. VS2005 and 2008 are extensible and Vault 4.x now replaces the built-in source control features with its own, if you have the "Visual Studio Enhanced Client" selected. For older versions I tend to avoid 'integrated source control'. |
| « Some one is trying to Hack the Site | The Upgrade Treadmill » |