Tag Archives: lazy

When You’re Holding a Hammer (Everything Looks Like a Nail)

The wisdom of good programming is pretty similar to the wisdom of good life. There are definitely people in life that are too theoretically minded to be any practical good, but practical seldom turns out to be a vice as long as it is accompanied with skill. So the saying, “when you’re holding a hammer, everything looks like a nail” may be warning us to not be overzealous in swinging whatever power we’re given, but I would contend that in the world of programming a brain full of fantastic tools can certainly ensure there aren’t any loose planks in our projects. Yes, I am encouraging the zealots.

You see zeal is almost never the problem, it is zeal without knowledge that wrecks things. Or worse, the unintelligent whose sole skill appears to be the act of getting in the way. They are quick to bloviate, and raise “red flags” when they meet a zealot, but slow to accomplish any but the simplest of tasks. There are far too many folks out there that scream that the sky is falling as soon as they see a bit of ambition and enthusiasm. I love enthusiasm, it’s one of the things that are impossible to teach. I can teach a guy to code, but I can’t teach him to not be lazy. When character vs. competence, character is top of the list. I’m often amazed at how much energy the unskilled can put into debating a topic, while being completely incapable of contributing. It’s as if they feel that they are the brains, and the capable are just the “brawn”. However, the more capable the capable are, the more these leeches come out of the woodwork squealing in alarm. For good reason, someone who can actually “do”, will make them look like fools, and squeal all the more, like hungry piglets.

So, whatever your involvement in IT remember to spot the warning signs. Look for the guy who does little himself while criticizing the ones who do much. Listen for the empty claims and if you’re really lucky you might even catch a “When I was president I did it this way and it worked.” whopper. A good follow up to such a grand claim would be:  “Can you provide references?” Or better yet: “Time to get your references together, lying like a child is not a trait we value here.”

Sony failed, Apple failed, why?

The world of software development is not too unique. Just like building a house, the skills of the developers involved will affect the end result in ways that may take quite some time to determine. Did that door jam go crooked? How about those windows, open it 5 times and does it break? We have worked with big teams and small teams, complex processes and streamlined, and the quality of the end result has almost nothing to do with the process and everything to do with the developers.

I personally remember years ago being on a team where one guy got real territorial about his part of the application. While I’ll readily admit the whole project was a mess, I took a lot of pride in my little piece, and perhaps I was real territorial also. The day finally came when I needed to ask him for a minor modification to his “piece”. I needed read access to one of his private variables. He said: “NO”. The cost for my part would be paid with every implementation of a specific object type, the cost for his, well none really, but he claimed to management that providing a getter method for that variable would invalidate too many tests and could introduce serious bugs. If you understand what I was asking for you’d know he was just flat out lying, but management simply didn’t know.

Therein lies the enabler, management.  While we have met a few good ones, they are more often like a bandwagon fan, except they often have much too much say. Or worse, they are simply complacent. We are constantly surprised at how many organizations continue to pay staff to sit on their hands. I have personally been told more than once that a person has no greater ambition than to keep getting a paycheck until their retirement in the next few years. No wonder they fall for these dirty consultant tricks.

So what happened when Apple launched it’s iPhone early order system? Or more recently to Sony’s gaming network? Underneath the media talking points there is certainly lazy “clock milkers”, and perhaps a sharp young developer labeled “chicken little” who either moved on to find people more serious about their work, or has been hammered into submission. That is why we chose the name VeraciTek, we do not plan to ever be “hammered out” and become complacent  and lazy. We’ve gone to bat for our clients and in some cases the problems were their own staff. That was certainly the problem in these cases. Bad staff = bad results. End of story.

Some indicators of bad staff:

  1. More preoccupied with smoke break than bullet proofing their latest methods.
  2. Long lunches on crunch days.
  3. Lying.
  4. Lying.
  5. Lying.
  6. Never stays late.
  7. Never comes to the office with ideas from the night or morning before.
  8. Lying.
  9. Doesn’t get excited about the project, this is based a bit on personality too.
  10. Lying.
  11. Lazy.
  12. Lying.

Veracity means “dedication to fact or truth”, hence lying being a pretty big violation in our book. It’s intolerable, and often the first offense can cost our guy his job. Even if we really like him. I’ll never forget having a conversation with an employee smoking a cigarette on the terrace about a small package I wanted built. It wasn’t the cigarette that cost him the job, it was the bologna excuse he gave for not doing it. VeraciTek will not be defined by the output of B$ers, cause we all know what they output.