But FWIW, my first programming job was as a mathematical programmer on a team working on video conferencing. I had no idea what it was when I was hired. At least I didn’t think it was being attempted on computers and had no idea how my background was going to contribute.
Fact is, when a job is advertised in a computer field, they advertise the skills/language/knowledge needed, or assume a certain level of knowledge. They brief you on what the company is going to do with those skills.
This should be obvious and old hat to anyone in technology fields.
“We need a person to do so-and-so because our company is working on this-and-that”.
Well, everyone on earth might understand what this-and-that is but if they don’t know what so-and-so is, then they’re not right for the job.
Keeping up with the lingo has been difficult for me too.
When I was interviewing for positions I kept on getting questions like “what’s the difference between early binding and late binding”, etc.
I found it really difficult to trot out the MSDN definition for that stuff. So I learned to reply to the question, well, I wrote such and such an app, and I chose late binding over early binding because of such and such a reason. That was generally good enough for the interviewer.
It is hard to keep up with the lingo. I’m a vb.net programmer, and my SO is a C# software engineer, and a lot more experienced than I am. He often talks circles around me, but still he didn’t know what I meant when I said I had to GAC my assembly to make Biztalk recognize my dll.
Speaking of which, I’m looking for a robust, world class, mission-critical end-to-end e-business solution that will enable synergy among end users. Can anyone here help?
I’ve never seen GAC used as a verb before – we normaly talk about putting things in the GAC. So I can see how someone could be confused, especially when using the term verbally (where it would sound like “I had to gag my dll…” :)). However, i’d be very concerned if an experienced C# programmer didn’t know what the GAC is or what it means to put a dll in it.
I have sort of the same sentiment. The part that bugged me was this thing I’ve seen with programmers not wanting to document projects or comment their damn code. It’s almost a badge of honor with some of them that they either won’t or resist strongly any attempt to make them do both. (Usually with the retort, “I don’t need to comment, just read the code.” As soon as I find someone that reads “code” as well as a natural language I’ll agree with you.) Actually not all programmers/software engineers are like that. However it seems to me the “just code” crew are the ones that just want to bang out the code with very little design work at the beginning. (It’s been my experience when you just try to shoot out code the code is horrible.) It seemed more often that good code came from guys who document by basically designing everything up front. Once they were done with their design they basically the documents already, it was just a matter of following the blue print when writing the code. Come to think of it if I hear anybody say “Boy I’m glad this project had no documentation or comments.” I’ll excuse such blatant attempts at being just plain lazy.
Oh well, just my rant that is coming from the guy who quit as a software engineer to do a pre-med program. (Hopefully I’ll get into med school in a couple of years. At least the job paid well enough so I can do that.)
The problem I find with most of IT management is that IT Managers and Directors are usually IT people who were promoted into these positions. I know the big thing in IT is to slam non-technical background managers but those people but many of those people have been trained in how to interact with people. IT managers who came from the trenches usually only know how to treat people how they were treated. Everyone I’ve worked for or with has the slave driver mentality. First they ask how long something will take and unless you say 20 minutes, they will grill you about why it takes so long. The worst boss to have is one who is paranoid about keeping their job, as many IT managers seem to be. They will be ruthless with employees in order to ensure their job security.
When I took my first management course for my MBA it was a real eye-opener. They actually talk about people, what makes them tick, rewards, personal feelings, team work and many other things essential to success. You might be the best programmer on the planet but without at least a basic understanding of how to handle people, you will fail as a manager.
