This is not quite my typical rant on the job market and such, but today was a real eye opener of something I've never ever considered, nor could I imagine. I've always known that certain people don't understand certain things, and I know that some are more clueless than others. Some people are flat out liars, and some flat out incompotent. That's just how things are as is with any line of work.
However, I exchanged some emails with someone, and in the course of things, I had an intriguing realization. What if you were approached with a position in a given field, and you could never find anything. What if it only seemed to be relavent but you learned there might have been a load of positions that were the wrong discepline within your field?
How could that be you might ask? It's what I like to call whittled down communication. As we all know, if someone says one thing and they pass it on, after so many generations, it turns into something completely different to the extent that it's incorrect or flat out garbage for whatever reason. Montel Williams demonstrated that on his show with something simple just to prove by the time a preset message was passed through the entire audience, when it came back to him, it was very distorted.
With each person in which some piece of information goes through, some portion gets whittled down. Now, if you couple with that someone who isn't versed in the field as well as the people who they're seeking, they can't detect it. So with each generation or passing along the information, they take a few words out, reword it, and then by the time it gets to someone like me, it has a whole new meaning. Managers and sales people like to reword things to such an extent that it's too ambiguous, and as such certain descriptions can be misconstred to the wrong position.
Here is an example. Say you're in the IT department. You need to hire someone. You know you need a programmer. You realize you need someone who knows something about C#, ASP, ASPX, Visual Basic, and something else. You throw in some other requirements such as databases. Say you need someone who does Oracle do some degree, MS SQL, and maybe something else. Maybe you have some other wish list items.
Now, the manager takes this, and between them and some staffing firm, all that gets consolidated into they need someone who works with Windows, is versed in multiple languages and multiple database platforms.
Now, say you're a job seeker. You might know some C/C++, Java, and COBOL. In addition, you know how to administrate Windows and Linux platforms as maybe you're a network admin. In addition, you know something about networking with Sun stuff, DB2, AS/400, and Oracle.
Now you get some staffing place that sees your resume and says you might be a good fit because per the job description, you know various database platforms, and you know something about not just Windows, but Linux as well. So as a result, you get submitted.
The person who submits your resume fails to understand that maybe you're more of a network person than you are a developer persay. They also have failed to reach the relevent platforms because maybe they are just pasting what they've been emailed. You never learn that for one, the position is not your discepline or your platform! The staffing firm is too clueless to realize it, and nobody gets anywhere.
I ran into that scenario today, and it seemingly rubbed the staffing firm the wrong way for just saying..."Hey, this is stupid because....".
I got a breif email back as to the number of applications this particular job entailed maintaining, which was mind boggling. There is no way a small team of people could "maintain" several hundred applications. They made specific references to certain coding languages, so whoever has the buzz words gets tagged.
Here is an example. One of the requirements is that you know "Windows". In the context of the job description, "Windows" could be a reference to a particular platform. It could also mean they want someone who programs "Windows" desktop applications, or in general they want someone with experience that knows something about programming and "Windows". These all have specific meanings, but within a certain context, there is room for ambiguities.
When you put in a job description that your job is to "support" an application, and a certain amount of your time is devoted to that, and another portion to writing new stuff, someone like me says, this is a programming position. I am (or was) a developer, and the term support coupled with the phrase "applies patches and fixes" can have a very specific meaning.
If I tell a network administrator or someone of like capacity within the discepline of networking, "fixes" and "patches" have a specific meaning to that individual. That means, there is an update for some operating system, or something along those lines. It's your job to install those "updates". Does that mean you have to understand how to code? Not at all.
Now, if you use that same phrase to someone with my background, this has an entirely different meaning. In the same context, especially with certain other developer specific verbige, that says my job entails fixing what someone else screwed up or fix some bug. Then you implement the bug, and it's just what it says-a patch. In that case, if you don't know code, you can't do the job-period.
So, there is a HUGE difference to two very different types of people over the same word. However, the same key word might appear on someones resume, so that's more "matches" based on a "job description".
This job goes on to say that the person needs to have "effective communication" and an understanding of "servers". The effective communication is a laugh given the ambiguities, and the use of the term server is someone of a misnomoner for lack of a better word. Again, two people from two different disceplines will view this differently.
If you ask a network person what a server is, they might show you a box that has a database on it, or some server based operating system. That machine accepts requests. For instance, they might show you some mechanism of a server like MySpace uses for web pages. That is in fact a server. That person is showing you a hardware device with certain specific software on it, and it does a certain job. That's accurate.
If you talk to someone who writes software, they might say a server technically is either hardware or software that simply serves requests. If I am a developer, I might write some software or software based component that does just that. I can put as many of these things on a given machine as I wish. How well that works out is another story, but it can be done.
Let's assume I write software, or you're learning, tinkering, etc. You have a database of some sort and you have a web server on your PC at home, or your laptop, etc. From an architectural standpoint, you can have a database server and a web server on the same machine just so you can write code. If you simply have a web page, and a data base that interact and nothing more, you have a 2-tiered architecture. That's an accurate and technical description of something.
Now, if I want to implement something written that way to be open to the world, I might put my database on a dedicated machine, and my web server on another. I have 2 physical servers or machines, but I still have a 2-tiered architecture. I still have 2 "servers" talking to each other. In specific, I have scaled a database server and a web server across two machines in the later instance.
Now from that, if I state I have written a 2-tiered application, does that mean I have used 2 physical machines? Not necessarily, but there are those people will say pending on their background that unless you have, it's not 2-tiered. However, from an architectural standpoint, I have a data access layer and a web/presentation layer. Therefore, it is 2-tiered and has nothing to do with how I scale an application or not. NOTE: From an architectural standpoint, I would never write a 2-tiered application and would preach against this evil. That's another series of blogs though.
Now, if that sounds confusing, don't feel stupid. Here is where it gets worse. Some people don't realize pending your perspective and the context in which you're using that verbige, it can mean different things to different people. Having said that, either interpretation can be correct.
Here is where it gets worse. Often, you have someone who is/was a networking individual. It's a seperate discepline within computers that is vastly different than someone who writes software. Network people can tell you how to get things to interface with each other, communicate and such. Software people might say, let me show you how to write an application that will run on a network and support several thousand users.
The network person for whatever reason seems to get the title of project manager faster than the person who writes software. So what happens is, you now have someone who is a network person supervising someone who is a developer. They are two different animals, and one knows very little of what the other does in any appreciable depth aside from a few basic commonalities. If that person does the hiring, they often take the stance that if you're interpretation isn't that of their job specific understanding of an ambiguous term, you don't know what you're talking about and get passed over. The problem is they don't understand the context the other person is referring to or even that the term has a degree of ambiguity to it. If they are more versed, it's another story. Don't bank on the latter.
Sometimes, these 2 animals can overlap. Both a developer and a network admin might know how to build a computer tower with parts. The network admin might know how to write a "Hello World" application in a given language just like a developer could. It's very basic, but the difference is, one might be able to tell you more about one or do a significantly better job when you throw in the depth factor. The ability to do one doesn't make you the other.
Now, this particular job description specifically stated don't submit a high level developer. Well...they might as well put my name in there and said don't submit me because I am a high level developer. I've done high level work before. However, if the person reading my resume doesn't read it enough, or they don't understand what high level development is, they won't know.
So now, when you have someone like me that preaches things that only someone versed in high level design will preach, and you start with "patches and fixes", that has a certain context to it. When you say you need to know this, that, and the third language, and so much of your time is support, that means to a developer, you're going to spend so much time fixing someone elses stuff.
Then there was this on call part, and hard deadlines, I started to wonder what madhouse was this. I knew what madhouse it was because I saw other job descriptions like it. So I knew, and I read all that this place wanted. It was unrealistic as the job entailed 3 or more different positions rolled into one.
For one, you had to document various things. A technical writer can do that. However, they go for 50K-60K annually as of 5 years or so back pending on what part of the country you're in.
They wanted someone who was versed in more than one database platform and "maintain" a database. Now, when you talk to someone like me about maintaining a database, that has a specific meaning to it as it pertains to my discepline. There should be nothing to maintain from the design and development standpoint. If there is, something is wrong or something is being lost in translation. So immediately, this makes no sense. Why? Additionally, an Oralce or SQL DBA can get 80K-85K a year. There are DBA's and DB developers. They're two different animals, and both have their place.
Now, we're up to 2 positions in one. Why? Start adding up the dollars. It gets better.
They wanted someone who knew certain programming languages. A developer who specializes in those languages would know these things, and pending on their experience, and since it's not a high level position, $60K-$90K a year is not an outrageous figure-unless we're talking about the Mumbai market. It is possible to have a single man to do all of the above, but you don't have the time to focus on these things to the depth a given individual focusing on merely the one specialized person might have. As such, you get nothing done. If you do, it might not be quite as nice as it would be otherwise.
Now, in addition to that, they wanted someone who understood networks. If you hire a network person, pending on the exact position, that salary can vary widely. However, you're either a network person or a developer. If you know both, you're stronger at the one than the other. If you're strong in both, that's rare. In that case, yes...that person can laugh at 100K and say you're low balling me. The demand is there, and the people who can do both are very rare.
This place appeared to want all 4 of those people in on position, and support several hundred applications. I thought to myself, this has to be an insane asylum to work in even worse than I expected.
Then after hearing that tidibit, the gears started to turn. I finally realized what the issue was at hand and why nothing made sense, and part of why they didn't want a high level developer.
It turns out, that it appears if you view things from a different context, they want someone who is what is known as a systems analyst who knows something about code writing. Systems analysts are people who look at everything from a network position, and they scrutenize all aspects of it to get it to function better. However, much of networking is support once the network is in place. Users have issues-period. Sometimes the analysts have issues with the users, but that's another story too.
Now, network people love scripts. You get these guys out there who think the world lives in script. That's all there is to it. You type a script, and all this magical
just happens. When they need something done, let's write some script. That means code writing that they've picked up along the way, or tinker with code someone else wrote in some script.
In a case like that, what people like that know in code is pale in comparison to what coders do. Then you get some high level person like me who looks at these things, and we stare at it, and we cringe, and we ask who the
wrote this steaming pile of
. Why? The network guy might know something about code, but their training is not in development. However, they are forced to do development work. When that happens, they can create issues without realizing it. Why? They don't know any better.
So when the problems arise, they hire more system analysts, and you guessed it...more scripts or tinkering with what some engineer wrote. Then the problems replicate and evolve, and you have a dire mess.
So then, someone who is a high level person like me comes in, and we have to report to some network person who thinks they know how to write code. They have a title, and that's it. They have no training in my discepline. However, because they have a title, they start dictating how someone like me is going to engineer, and what they say is problematic on various levels.
So when you get a high level person in, they say you need to break apart all this crap and/or rewrite it. That costs money, and lots of it. If they hired a developer in the first place and let them do the job right the first time, the fixes would be cheaper. So instead, they have someone to make things worse, and keep the department budget flowing.
If someone like me redoes all that has been done, figure what it cost to write the application. Now, take the cost of "support" and tack that on. Now, when I rewrite this thing to remedy these headhaches once and for all, all those resources that have been spent have gone down the drain.
Then there is the business side of me that says why this doesn't work. You spend 50K to 100K on some application. Then you spend another 180K for someone to screw it up and make it worse. Then you get fed up with that person realizing its your own dang fault for getting the network person to do something he wasn't trained to do in the first place, and you spend another 60K to 120K for me to begin to undo all that has been undone. When I say you need another 100K to fix this thing and stop the bleeding, that's too much.
You spent 300K at least just on the upkeep. However, if you did it right the first time, and even if it cost you more then, and you had no issues with it, and you spent maybe 20K for upkeep over the same time, you made out. Guess what? You just found several hundred grand in your budget to do something else with! You can do all sorts of things with that money besides play fix it man.
Yet, people say the costiler way is cheaper and it "works". How the hell does spending the better part of half a million dollars for something that doesn't work due to giving it to lesser trained people work, and doing it right the first time for about as much or maybe a little more, but keeping the same cost well under half of the other way not work?
When you work for a company, you're supposed to add value to it. When you do things like the former of keeping the headaches alive to drain the budget, you're not building anything or adding any value. You're putting on a chirade to keep up with appearances in the name of job secruity.
So in short, it has occured to me that positions show to me that were presented as development positions were negligently represented simply due to the lack of understanding of how things work due to the staffing firms and the hiring managers. As such, I might have had more irrelevent positions come my way that were not within my discepline as the client never knew what to really ask for.
So looking back, I've had positions that were presented to me that appered to be developer positions, but the reality is that's not at all what the client wanted. They wanted some network person who knew something about code, but not to the depth I did.
So if that's the case, I've been mislead a number of times. Why? You have people who whittle down so much that they leave you with a job description that could be deemed as something that it was never meant to be. Yet, they all preach effective communicaton.
This is like saying, you need a doctor. You see your family doctor. Well, you're family doctor is a physician. So is a vascular surgeon. If you need a surgeon to take your spleen out, would you ask your family doctor who has not been trained for these things to cut you open in his office and do the procedure?
What if you went to a physician who was chief of vascular surgery and you said you didn't want some high ranking surgeon to treat you as you merely wanted your spleen removed due to trauma? What if your family doctor removed your spleen, but you had complications that the surgeon would have took one look at and asked who butchered you?
If you can envision that, you can now finally appreciate part of the problem with getting a job in what was my field. The people who run the show can't differentiate between the family practitioner and the head of vascular surgery, but they're going to dictate how the surgeon should do surgery despite them not being surgeons themselves.
What's worse is when you say, I think you meant to say you need this individual and not this type of individual like I am, but it still poses problems and here is the math to prove it from experience, people begin to take it personally.
I had no idea that for all these years, some of these positions were from people who couldn't differentiate between someone who wrote code and someone who did network stuff and knew just a little bit of code although it was far from their forte.
That's what I finally realized today, and when you try to clear that up with facts, people get really bent out of shape.