|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
The former geniuses might decide to micromanage the project and rip out large swaths of code because they had a new vision. Or maybe they'll prattle on about how they did the same thing in half the code back when they programmed in 8080 assembler or C or Java. In any case, they can get more obsessed with technical details than with the big picture, though they were hired to keep their eyes on the latter.
Programming productivity obstacle No. 8: Macho programmers, aka "brogrammers"
While it is always enjoyable for programmers to blame the suits and glad-handers over on the sales team for every problem
and any disruption, the programmers must also admit that some of the problems can lie with themselves. Programmers are hired
for their computer skills, not their people skills.
Programmers are bad at communicating, and they're not known for thinking of feelings or ego. They can latch onto some technical argument like a pitbull will lock onto a steer's leg bone. It doesn't matter if the client wants something different; the programmers get hung up on the technical arguments, and they'll still be hashing it out at the company picnic in two years.
While programmers can often filter out each other's idiosyncrasies, teams can fail when programmers knock heads. It's common for two people with different political views on, say, dynamic languages or NoSQL to end up on the same team. The decision on what is right for the project becomes a referendum on everything these programmers have held dear. Then nothing ever gets accomplished. Everything is tied up in the next battle of the 100-year war.
Programming productivity obstacle No. 9: Selfish or cowboy coders
Did you just get a null pointer from his code? That's your job to catch that. And you better think twice about passing in
a zero because the self-absorbed coder doesn't check for divide-by-zero errors. That's your job.
The narcissist coder's work is supercool and superfast but only because it leaves much of the bulletproofing and testing to you. That's your job to handle the mundane chores so that it doesn't crash.
Many teams end up finding this out too late. The blocks of code work fine during the early tests, but after someone starts pushing real data through them, everyone realized that no one was checking for problems. Oops.
Programming productivity obstacle No. 10: Poor documentation
Writing documentation takes time. But we're paid to write code. We're often measured by the lines of code we generate. You want results. We're just doing
what you want. Don't worry, we'll remember it all and write it down eventually.
Sometimes there's plenty of documentation, but it's for a version of the code that is months or years old. Did I say that this method stores the data in the Foo table? My bad. That was two generations ago, and we haven't had time to work through the code and fix those old notes. But we'll get to it -- honest.
Programming productivity obstacle No. 11: Slavish devotion to documentation
While we've all experienced projects with no documentation, it's common for projects to fail with too much verbiage and too
little coding. I've had several people show me a shelf filled with binders and say, "They were paid by the pound for their
documentation." Reading it all would take a year.