When all you have is a hammer, everything is a nail. For the folks at TCTSRN, all they had was a 20 ounce ball peen called T-SQL to solve their IT problems. That’s fine if all you need to do is generate file extracts or shuttle data from one source to another behind the scenes of an enterprise application that had a front-end. But after a few years, the TCSRN users started to demand more, like custom intranet applications. If you have been doing nothing more than data-diddling for a long time, you are woefully ill-equipped to deliver anything more than crap to the end-user.

I was trying to get that point across to my team – they didn’t know shit, and they were going have to get with the program. I was more than willing to show them the way, mentor them, coach them, whatever. But they where going to have learn something more than SQL.

They didn’t like that idea.

For one, SQL is a procedural language. It’s great for linear thinkers. The code at the top runs before the code at the bottom. Nice, top down paradigm.

Secondly, you could keep monkeying with a query until you got the results you wanted. Hit EXECUTE, and you get instant gratification.

So, with the nice procedural nature of SQL, and the immediate results that show up in your editor when you hit F5, it becomes a very comforting programming environment. Sort of like a application development security blanket. Always there. Stable. Controllable. Complex enough to keep you awake. But even if you are trying to solve complex data issues, all you need to know is the basic syntax, and you could hack your way to a solution. The language hasn’t changed in over a decade.

But developing applications requires more. Event-driven programming, object-oriented programming, multi-tier development, remoting, etc. – some of that is hard shit that requires some creativity, tenacity, and curiosity. My team had none of those traits.

This became painfully evident when Mr. Whiteboard asked me to work on a web project with the TAC (Thick-Accented-Cambodian).

“I don’t want you to do the coding, but help him out,” the shovel-faced bozo had asked me.

That would be rather tough, I had thought to myself, since the TAC had never coded anything but SQL. But I took it as an opportunity to demonstrate how things can and should be done in the shop. This would be the app that I could leverage as a learning exercise for the team.

On the surface, it was a simple page that queried the massive back-end system, combing through millions of records to return just few, depending on the specific criteria the user entered. With the brute force approach of building a dynamic query and passing it to a stored procedure, it would take minutes to return a result – a worthless solution. But with some sophisticated front-end work using AJAX, a solid middle-tier object that does the bulk of the processing, and a basic stored proc that returns small recordsets, the app would rock.

Not that the TAC was going to be able such an app – he was a SQL-writing idiot who knew one way of doing things – brute force. His stored procs sometimes where 5000 lines long. He thought temp tables were a gift from the heavens – and fancied himself to be a genius for knowing how to use them.

Get a clue, you data-diddlers – temp tables are no big fucking deal. If not used properly, they are just a way to get yourself in more trouble. And most of you are really lacking in the creative side, so I see a lot of brute force in those nasty stored procs you SQL hackers are so proud of. So many of you write like you get paid by the line of code. The rest of us are not impressed – after all, there is something called elegant coding. But I digress.

To top it off, the TAC has a nasty habit of nesting sub-queries. His code looked a lot like this:


Select
YADA_YADA
From TableYada Where YADA_ID IN (Select
YADA_ID
From Where YadaYadaID IN (Select YadaYadaID
From Table YadaYadaYadaId)))…

... And so on, and so on and so on…

You get the idea. It was like the TAK would curl himself up in a little ball of logic and fuck himself.

So I decided to lead by example. I came in on a Saturday (that was getting to be a habit), and wrote a nice prototype ASP.NET application that solved the problem. Leveraging some 3rd-party AJAX components (not some Atlas vaporware), I had a UI working in hours that queried that database and offered drill-down functionality without post-backs and excessive delays. It used one stored procedure that was twelve lines long.

I commented the C# code, excessively. I wanted the TAC to get the idea -- not everything can be solved by SQL.

It didn’t take long for me to figure out that the TAC was not impressed. I met with him the next Monday in my office.

“Did that code make sense?” I asked him.

“Uh, wud, the web page thing?”

“Yeah, notice how the middle-tier database code reduced the round-trips?”

“Uh, ummh, maybe,” he stammered. “But maybe, uhmm, it not so good. Maybe you can make it stored procedure, so not so much C sharp code.”

Really, I thought? Little shit-for-brains SQL boy thinks we need more spaghetti code…

Fuck, I was going to loose it….

“And how would we debug that?” I asked. “There are four levels of detail, each with its own query.”

“Uh, maybe you use PRINT statements,” he said. I realized that this marble-mouth cretin had never used a debugger. It was a lost cause. All he had was a hammer, and the world was one big nail to him.


Posted in:   Tags:

I've been away from the blogging routine for awhile, and have had some time to reflect on a few things. You see, I have been doing some heads-down coding for the last six months and haven't had to deal with any management or political issues, and I've come to a conclusion.

Most programmers are shitty employees.

No, not bad coders. Bad employees. Of course, I generalize.

But is there a group of people more anti-social, belligerent, unjustifiably arrogant, and plain unproductive than programmers?

And God-forbid one should dare suggest that. If so, prepare for indignant rants, suggesting that management is always the problem. After all, how dare someone expect an employee to communicate professionally, follow some standards, and for the most part, not be a fucking self-indulgent, quasi-autistic jerk all the time?

As someone from both sides of the great programmer/manager divide, am starting to realize that maybe the poor reputation of I.T. managers is not very accurate. Some suck. Some suck more. Some are very, very good.

As for programmers, most are horrible people to work with, and especially, to manage.

For example, my current contract has me working in a cube on a floor that is primarily filled with salespeople, and I’ve noticed a few things.


  • They dress nicely.
  • They smile when they pass you in the hall – even if they don’t know you.
  • They banter, flirt, and generally engage in polite social mannerisms during the workday.
  • They hold the door open for you.
  • They say ‘excuse me.’
  • They are polite to coworkers and bosses.
  • They wash their hands after using the toilet.

Most programmers do none of these things.

OK, I’m sure the trolls are ready to flame me and say “If you weren’t such an asshole, people would be nice to you!”

But even the programmers I don’t know, the ones that work on different floors, that have no reason to think that I am an asshole, share these common traits:

  • They are rude.
  • They dress poorly.
  • They are downright mean. Like “fuck you, I can code” mean.

Just an observation, and I am probably over-generalizing. But I try to counter the stereotype by being somewhat polite, holding doors open for people, and whipping the anti-social sneer off of my face when I am not staring at the screen.

So for an IT manager, there is a huge hurdle that has absolutely nothing to do with technical competence that impedes their ability the get things done and successfully manage projects -- their staff are assholes.

And I’ve noticed a cottage industry developing in the blogosphere that revolves around IT manager bashing, and I am partly guilty of that. But let’s not give the jerk-off programmers that dominate the trade a pass. They are the ones causing management to move jobs to India. I mean, if you want a surly, smelly developer with poor communication skills, you can get one from WiPro or Infosys for a lot less money.

Now for an update – I haven’t felt the urge to get up early and blog lately, and I can’t with good conscience blog at work. But I’ll try to post a little bit more often.


Posted in:   Tags:

- Vineet Nayar, CEO, HCL Technologies

Recent Posts

Slumdog Comment Generator

Clueless?
Not Sure How To Respond?
Use the Slumdog Comment Generator!

Calendar

«  October 2017  »
MoTuWeThFrSaSu
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
View posts in large calendar

Month List

Disclaimer
The thoughts expressed on this blog may or may not be the author's own and are protected by the 1st Amendment. Any attempt to reveal his identity by contacting a slumdog hack at Google, or a corrupt Desi sys-admin at his ISP will be dealt with promptly and severely. Civil and criminal penalties may apply if one is found to have used private information in an attempt to get the author fired at the Hindu-only I.T. ghetto he currently works at. In addition, any Desi who attempts to burn the author's house down because they are enraged over his writing will be prosecuted to the fullest extent of the law. This isn't India.

© Copyright 2017 Life of an I.T. Grunt


View My Stats