Why there are so few rock stars in development (aka, why so many advanced devs suck!)


Before I get into this rant, I want you to know that the information here is constructive criticism (just in case someone recognizes themselves in my rant). My point here is not to gossip, naming names of the people who have caused me extra work. Seriously. The people I am talking about here are pretty advanced developers and do some really rocking work. But, they all suffer from a bit of suckiness.

One more thing. I am sure I have some suckiness in myself, as well. So, I am potentially throwing stones in a glass house. But, I gladly welcome finding out where I suck, because I think admitting your suckiness is the first step (of twelve?).

What I am talking about here are some things I think are so basic I cannot believe there are people at this career level that are still doing them.

Rock stars

I live in Nashville, TN, a metropolitan area of 1 million plus people. Nashville is a .NET town. Of the people floating around, there are probably a few dozen rock stars who code .NET in this city. And, the consulting groups kHarnow who these people are. Today, fewer and fewer of the rock stars are floating, leaving a consulting glut of sorts. A main reason for this trend is companies are treating talent better and giving good compensation. Don’t get me wrong, there are still a few hellholes in Nashville. And, if you are an unknown guitar god, and you work in one of these hellholes, you are underselling yourself. And, yes, this post is aimed at at least one hidden rock star I know.

Nashville is not unlike other towns. I know people all over America are clamoring for .NET talent. Despite the fact my own resume is not even showing, I am still having people find me and send me offers. For the record, I am not interested right now, as I have a very good position at this time.

Stupid Programmer Tricks

Okay, I am now ready for my rant. 🙂

Security Faux Pas

I recently got a look at a Flex Framework app that really rocked. The GUI looks like a lot of things from this particular group, but that is not a bad thing. I would personally have loved to use Silverlight, but it is a bias thing, as I have not played with Flex yet (may be on my plate soon?). I got a chance to rip through the app last night and found that I can log in as an administrator this way:

http://www.thisapp.com/login.asp?userid=2

Yes, that is a traditional ASP extension. I am not overly worried about that, however, as I can rework the container rather easily. My biggest issue is userid=X. If I were hacking a site and decided sniffing was in order, don’t you think I would look for querystring arguments that circumvent authentication? I suggested that we use the Membership bits from ASP.NET. We cannot use them out of the box, of course, as the user has soem additional adornments I do not feel like sticking in a single string in ASPNET_Profile, but a custom Membership provider will do me well.

In case you are a bit of a newbie, or someone questioning why this might be bad, let’s go through this quickly. There are two ways to request pages on the Internet: GET and POST. A GET sends all of its parameters on the querystring (that means something anyone can see in the browser’s address bar – worse, something anyone else getting on that computer can pull from history). A POST is not necessarily safer, without SSL, but it does hide from the "internal hacker" who looks over the user’s shoulder.

It’s the Metadata … Stupid!

This one is a personal pet peeve. I go into a website and I find a drop down hard coded in the code behind. WHY? I can understand an enum, in many instances, but drop downs, in general, should come from some form of persisted store.

Let me tell a story to illustrate this. We have an application "suite" (too tightly coupled, another pet peeve) that includes a backend "listener", with a "parser", and a website. There are other pieces, but these are the important pieces. We create a new hardware "unit" (we do GPS tracking) and add a new feature. The new feature does not work. Why? The "parser" cannot properly translate. Why? Because the information coming in comes in two different fields and has to be translated to a single event.

Since none of that probably made sense, let me break this down and then give you a proper solution to the problem. The unit sends in two pieces of information. First there is a flag that corresponds to a particular register, and then there is user information to tell you how the reigster is set. For example, I get the following (not real values, but an example):

Register     User Info           Means
10               0                       Vehicle Ignition turned off
10               1                       Vehicle Ignition turned on

In the application, these translate to 10 and 11, let’s say. So, now we have a new event (100 and 101 in translation, but register 12, user bit 0 or 1 in the unit). Since the "parser" does not understand 12/0 and 12/1, it simply turns it into a 0, which corresponds to "unknown".

The solution is simple. Create a metadata table that has the register and its value with an event type. But this was not thought of. In fact, it seems NOBODY in the industry does this. Now, certainly there are differences from manufacturer to manufacturer, which is why this has not been thought through. Each one does it slightly different. But, there is a way to represent each manufacturer in its own table and translate to a single 10 and 11 in the database that serves the website.

This one is a bit more complex, but I have found that nearly all of the values are not in the database. They are coded in the code behind. I will give a bit of leeway to the developer, as there was a serious time crunch on the application. But this person is rather advanced and should be determining "enums" (lookup tables in the database schema world) before coding his application.

Why do we have this problem?

To put it simply, there are very few people who consider development a career. It is a great paying job for far too many. Compound this with the fact that so few consider their code something they are placing their name on. And this is compounded by the fact that it is hard to really screw up your career when everyone is drooling for advanced devs, esp. at the "right price". This means one can work a 40 hour week, in many instances, and not spend one moment learning after hours, and still make close to six figures.

It is not helpful that we end up with two types of interviewers. The first asks questions he has pulled off the web, that everyone has studied. Once they realize the dev is advanced, they do not ask any basics. At the other end of the spectrum we have egotistical bastards who want to prove they are God’s gift to programming. These are the jerkwads who really piss me off. You will often here them say things like "Oh, Scott Guthrie could never get a job here as our standards are now too high". In general, these types try to make interviewees cry.

BTW, the comment is a real person, but he was not demeaning Scott Guthrie in real life. But then, you would not be in tune with the person he was demeaning, so Scott makes a great example to give you an idea how incredibly stupid the comment was.

The first interviewer is trying to do the right thing. The problem is he let the interviewee control the interviewer. To be honest, I am often the interviewee that controls because I am tired of answering "that would be the code behind page Dave" types of questions. If you are also tired, just hit one out the park when you get the soft ball. Things like "the difference between displaying data in a table in ASP and ASP.NET is looping versus binding. Although, when you decompile the .NET classes in Reflector, you find it is actually looping". Bing! No more basic questions. But, the interviewer should ask the basics. Not those types of basics necessarily, but make sure you cover the issues you have seen advanced devs really screw up.

Interviewer type 2 has one of two agendas:

  1. Wants to prove he is smarter than you
  2. Wants you to validate his development skills

Person one is easy to spot. When you start knocking everything out the park, and he realizes you should be his boss, he throws in something like "name all of the methods on the Iscrewyou interface in the System.SomethingReallyImpossibleToRemember namespace". This is normally in a phone interview, and he is looking it up. One possibility, if you are a quiet typer, is to name all of them and then state "but only an idiot would actually use that interface". The other, which I have used is "well I can see that this interview is over". Numbnuts then said "no it isn’t, because I still have a list of questions to ask you". My answer, "yes, it is, because I am hanging up on you now". You can’t win this interview, unless you bow down to the demigod in front of you. If he really is smarter, you might take the job to learn. But, if you smell BS, you don’t want this job.

Person two is also easy. After he asks you how you would solve X problem, he will then ask something like "well what if the person did Y instead". This is a strong clue that the interviewee did Y. If you think Y is really stupid, you also don’t want to work there. So, the proper answer is "why would someone do something that stupid" and get yourself excused from the interview as quickly as possible.

BTW, there is nothing wrong with answering an interview question "I don’t know, but I know where I can find the information". In fact, provided you meet our needs, I will give you extra points if you don’t know but can show me where you would find the information. Nobody knows everything!

And, this leads me to my point. one of the reasons so many developers suck is they are afraid to answer "I don’t know". Add this to the fact that most developers are trying to show they can mark higher up the tree (dog reference) and you have a cluster waiting to happen.

There are a few books I think every .NET developer should read … numerous times:

  1. Design Patterns – dry as hell, but you have to understand patterns to work efficient in an OOP paradigm
  2. The McConnell triplets
    1. The Software Project Survival Guide – every manager should read this too
    2. Rapid Development – Understanding how to define before you build
    3. Code Complete – these are the basic rules
  3. Refactoring: Improving the Design of Existing Code

I have more, but if you understand patterns, the rules, why projects fail and how to refactor code (the last is a major pet peeve of mine), you have tackled most of the basics. If you want a different patterns book, that is fine. I also think Refactoring to Patterns is a very useful book, to make sure you are not a man/woman with a hammer, just searching for nails. To get these books will cost a few hundred, but they are worth EVERY penny. As an aside, the $20 you spend on buying your boss the Software Project Survival Guide will be worth the hair you save.

Wrapping this up

I know a lot of rock stars in my town. I know even more rock stars from my association with the Microsoft MVP program. Yes, not all MVPs are rock stars, but there are many that are. And, to a person, I have noticed that all of them are excited about software. They are living their career and not merely doing a job. They will spend time after work learning technology.

As time goes on, the rock star will take less time learning most new tech (there is some, however, that is just plain hard – most of this type of tech dies out unless it is compelling), but they do not give it up. The reason they spend less time is they realize that they can always learn MVC, but they will never have a daughter’s first birthday …. ever! You miss it, it is gone.

If you are a rock star, you know this already. And, you probably do not even think of yourself as a rock star, although you do know you know a lot (and you know where to find the stuff you have not memorized). If you are not a rock star, this is not rocket science. It is never too late to go back and learn the basics. Consider Tiger Woods. Years at the top and he takes a year to relearn the basics. That year, his game sucks … but he came back the next year and pretty much swept the competition. He had to unlearn bad habits, even if he was still winning with those habits.

One more thing. The day you look at 6 month old code and say "I could not do better than that today" is either the day you should retire or you should become a teacher. As Denis Waitley says, "if you’re green, you’re growing. The moment you stop growing, you turn brown and shrivel up and die". Translated, if you do not see room to grow (improve), you need to find a new career, as you either have outgrown technology (not likely) or you are too egotistical/incompetent/insecure to understand/admit how much you still have to learn.

I am finally tired now, so a demain!

Peace and Grace,
Greg

Advertisements

9 Responses to Why there are so few rock stars in development (aka, why so many advanced devs suck!)

  1. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  2. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  3. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  4. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  5. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  6. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  7. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  8. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

  9. Alan says:

    Nice rant, Greg. I agree across the board.++Alan

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: