Um... Some of the very best programmers I've worked with had degrees in something unrelated to computer science (often an engineering degree), and one had no degree at all (he was brought into the fledgling programming group at United Airlines in 1966 after passing a basic aptitude test).
Sometimes intelligence and experience trumps a degree.:-) Of course, I'm saying this as someone with a BSCS.:-)
My current employer has a number of open positions that can not be filled due to the lack of qualified candidates (some entry level some expert).
Where are they located? What sorts of positions? How specific are their requirements? How open is your employer to light or moderate training? Will they pay relocation expenses? Are these long-term or short-term positions? What level of compensation are they providing relative to other companies? Does the company have a reputation? How are they advertising these open positions?
My anecdotal observation is that the majority of you who can not find equivalant work/pay were worthless to start with.
Big words from someone who has probably never gone a significant length of time without a regular paycheck.
Let's see how well you do when the major employer in your area lays you off along with hundreds of other experienced IT people, no other similar businesses exist in your town or metro area, and you don't have the funds to finance a cross-country move without some sort of assistence.
I've known several people who found themselves in that position, myself included.
If nobody is hiring folks with your specific set of skills or your industry experience in the areas you can move to, then it really doesn't matter *how* good you are. You *will* be unemployed for a while unless you're lucky enough to find an exceptional company who is willing to take you in and train you.
Face it -- the world isn't fair. Sometimes people get screwed by circumstances. It doesn't matter how good they are, how much they knew, who they knew, or how competent they were. Sometimes pure luck is the main differentiator, not effort, experience, or skill.
This has been confirmed by a recent thread on Slashdot which discussed candidates that can not stand up to a real technical interview.
*Real* technical interviews tend to stress fundamental skills and the basic ability to recognize and solve various real-world problems, not test one's ability to engage in rote memorization.
I've been writing code professionally for 18+ years, and I certainly know some stuff off the top of my head (yes, it burns in eventually [grin]), but I would expect to be tested on my ability to learn and apply what I know rather than my ability to spew answers from the interviewer's favorite manual.
Chemistry with the team that one is being hired into is also very important, sometimes more so than the hard technical stuff. It isn't always fun or productive to work with a genious-level teammate who knows all the right answers but is also a pompous ass. That's why I rather like team interviews (both as an interviewee and as an interviewer).
If you work hard, are dependable, and competent within your IT discipline you will not be affected.
Tell that to the thousands of high-quality IT people that were axed from the airline industry after 9/11. Some of the best technical people I've known over the past 18 years were cut in that timeframe, and some of them had a very hard time finding work, mainly they were located in a smaller market and had skills which were seen as only applying to one specific industry.
Of course, you wouldn't know. You've probably never gone through it yourself, so you're just sitting in your armchair and speculating. I've been laid off twice, both times from companies that were hit hard due to outside economic circumstances and had to trim staff to survive, and both times where folks were cut based on their team, their seniority, or their position within the organization, not based on their work ethic or raw abilities.
No, I think you're about as far off the mark as you can be. Some folks dodge the layoff axe, some don't, but it's usually an impersonal process that doesn't care about what you know, what you've done, or what you've contributed, since the folks making
Is there really a skilled labour shortage? Everyone who works in HR at an IT company or a company with an IT department seems to think so.
That's because companies continue to search for people who have VERY specific tech and LOB experience rather than people with general tech skills and IT expertise. The former is very hard to find in many sectors, while the unemployment lines are absolutely crawling with the latter.
Face it, a skilled programmer can learn a text editor and the basics of almost any development envirionment in a few days, weeks, or months at most. Given someone to use as a mentor periodically, and that time can be greatly reduced. The hard part is application vertical knowledge, something you're not likely to find outside your company anyway (unless you work on some fairly generic software in-house).
I think most folks would be happy to make a living wage.
The "ridiculous amounts" tend to be reserved for those folks nn IT who are living on the coasts (and who sometimes need those elevated wages to pay for little things like housing, which tends to be far more expensive in NYC or the Silicon valley than it is in most other major cities in the US).
If you work hard, are dependable, and competent within your IT discipline you will not be affected.
While moving across the country is certainly an option (and one which I chose to take), it is not a choice without disadvantages, especially if one has a family and owns a house.
Besides, I would consider having to move as "being affected"...
Our mainframe system stores dates as a binary accumulated value (number of days) since a base date stored in a system parameter table. It doesn't have a limit.:-)
Georgia has a rule that any employee whose compensation consists wholly or partially of gratuities is exempt from Georgia's minimum wage law, so some of the folks I know who are waiters or who tend bar are only making around $3.50 an hour for base wages. It's the tips that make the job livable.
The parent seems to be describing the types of ideas you sometimes see from end users and/or mangement, while you seem to be describing ideas from someone who has a better idea of the software development process.
Sometimes those sets of ideas intersect. More often, unfortunately, they do not.
Well no one really teaches software design do they.
One of the courses I took as part of my BSCS almost 20 years ago (gads) involved 4-person teams doing precisely that -- the coordinated design, documentation, and presentation of a complex software system (well, as complex as you can get in 10-12 weeks).
That course did an effective job of teaching us a LOT of things, including how to compromise when multiple good ideas were placed on the table and a project stage deadline was coming up.
Granted it was only one class, but even one well-presented class can provide good insights into the process (IMO).
Uh... What tasks do you think Linus has performed over the years w.r.t. the kernel? Or are you referring to the entire distribution universe (which is still effectively decentralized)?
The designing of software is much like describing the plot of a book.. by the time you've given the typist enough details to write what you want, you may as well have written it yourself. Since programmers are just the typists, they usually have no idea what the architect has in mind. When the architect / designer leaves a lot of the design to the programmers, the end result will fall short of what the designer had in mind. This is why a lot of awesome software projects are generally one or two man efforts, not designed by a team. If you're writing a novel, you don't bring in a dozen co-authors; at most, you collaborate with on or perhaps two people.
FWIW, most of the mainframe shops I've worked in don't have separate roles such as "designers" and "programmers" -- instead, they have fairly experienced programmer/analysts who perform both roles as a matter of course, or they have programmer/analysts plus at least one experienced business analyst to collaboratively and iteratively create and refine the specs as development rolls along. The latter is far more common.
Project Managerment may or may not exist at any level, and I'm not convinced it's necessary in many cases when the P/A's are experienced (unless a project requires complex resource coordination, a PM can often prove to be more of a liability than an asset).
The Unisys Airline Center I worked in came closest to what you're describing, but that group was releasing fairly static airline applications with a lengthy (6- to 18-month) release cycle and which already had formal PDS (Design Spec) and PFS (Functional Spec) documention created and *formally agreed to* by the main paying customers before work even began on the new version. From that point, the new version's specific feature set was locked for the most part. That was only design at the screen level, though -- implementation details were usually left to the programming staff.
In the three shops I've worked in (an airline, a window-manufacturing company, and a IT/communications company) where production systems were being developed for in-house use and then supported in-house, expertise was aligned vertically along subsystem lines, not horizontally along coder/designer lines, and most of the work was designed, coded, initially tested, and eventually supported by the subject-area experts on the programming team.
With experienced people, that seems to make the most sense, and it provides most of the advantages of a small 1-2 person team even when a large project is being developed (since the net effect is a large number of small functional teams, each working in their areas of expertise in parallel).
That and software is more like art than engineering, but no one wants to admit that.
I suspect a lot of programmers are fully aware of that (though I would agree with another respondant that "craft" might be somewhat more accurate), but that a large number of managers (mainly those who don't have a software development background themselves) don't fully understand the truth behind the statement.
Software development is still a subjective process in many respects, and I'm not completely convinced that it's a bad thing. Sometimes the effective expression of a radical idea requires a solo programmer who just happens to have a brilliant insight or even just a vision of something.
Writing software isn't like building a bridge -- there are often a fair number of incompatible but equally elegant solutions to a give problem, and sometimes the elegance is readability and supportability rather than cute tricks in the code (which might legitmately save clocks or bytes but make also make life miserable for some unsuspecting support guy five years down the road).
Heck, I even run internal tools that I write for internal company developer use past other programmers as a sanity check (after using them myself extensively) to make sure that things are actually working before I make the tools available to the general developer public.
Multiple testers are better than one, since different users often have different approaches, and I think testers are optimally obtained from a pool of actual end users (or in our case, quite often, from a pool of business analysts who either used to be end users or who are still end users). In any case, the folks testing should probably not be familiar with the code internals. It's too easy to unconsciously behave in certain ways (and avoid certain types of behaviors) if you know precisely what is expected by the program logic.
...it was difficult to learn the ins and outs of our users (flight dispatchers and pilots) because their jobs were themselves quite technical, required specialized vocabulary, etc. But that's what our business analysts were for (to act as an interface between the end users and the software developers). Most of them were former dispatchers or pilots themselves, so they understood the user issues, and some had programming experience as well so they had some handle on technical issues.
Our design process was also collaboritive and iterative -- it involved users, BAs, and programmers, and it started with the basics and only got fancy after the basic requirements were met.
The end result was a fairly useful system which was designed with both the end users and the programmers in mind.
Slashdot Mirror
Um... Some of the very best programmers I've worked with had degrees in something unrelated to computer science (often an engineering degree), and one had no degree at all (he was brought into the fledgling programming group at United Airlines in 1966 after passing a basic aptitude test).
:-) Of course, I'm saying this as someone with a BSCS. :-)
Sometimes intelligence and experience trumps a degree.
Where are they located? What sorts of positions? How specific are their requirements? How open is your employer to light or moderate training? Will they pay relocation expenses? Are these long-term or short-term positions? What level of compensation are they providing relative to other companies? Does the company have a reputation? How are they advertising these open positions?
Big words from someone who has probably never gone a significant length of time without a regular paycheck.
Let's see how well you do when the major employer in your area lays you off along with hundreds of other experienced IT people, no other similar businesses exist in your town or metro area, and you don't have the funds to finance a cross-country move without some sort of assistence.
I've known several people who found themselves in that position, myself included.
If nobody is hiring folks with your specific set of skills or your industry experience in the areas you can move to, then it really doesn't matter *how* good you are. You *will* be unemployed for a while unless you're lucky enough to find an exceptional company who is willing to take you in and train you.
Face it -- the world isn't fair. Sometimes people get screwed by circumstances. It doesn't matter how good they are, how much they knew, who they knew, or how competent they were. Sometimes pure luck is the main differentiator, not effort, experience, or skill.
*Real* technical interviews tend to stress fundamental skills and the basic ability to recognize and solve various real-world problems, not test one's ability to engage in rote memorization.
I've been writing code professionally for 18+ years, and I certainly know some stuff off the top of my head (yes, it burns in eventually [grin]), but I would expect to be tested on my ability to learn and apply what I know rather than my ability to spew answers from the interviewer's favorite manual.
Chemistry with the team that one is being hired into is also very important, sometimes more so than the hard technical stuff. It isn't always fun or productive to work with a genious-level teammate who knows all the right answers but is also a pompous ass. That's why I rather like team interviews (both as an interviewee and as an interviewer).
Tell that to the thousands of high-quality IT people that were axed from the airline industry after 9/11. Some of the best technical people I've known over the past 18 years were cut in that timeframe, and some of them had a very hard time finding work, mainly they were located in a smaller market and had skills which were seen as only applying to one specific industry.
Of course, you wouldn't know. You've probably never gone through it yourself, so you're just sitting in your armchair and speculating. I've been laid off twice, both times from companies that were hit hard due to outside economic circumstances and had to trim staff to survive, and both times where folks were cut based on their team, their seniority, or their position within the organization, not based on their work ethic or raw abilities.
No, I think you're about as far off the mark as you can be. Some folks dodge the layoff axe, some don't, but it's usually an impersonal process that doesn't care about what you know, what you've done, or what you've contributed, since the folks making
That's because companies continue to search for people who have VERY specific tech and LOB experience rather than people with general tech skills and IT expertise. The former is very hard to find in many sectors, while the unemployment lines are absolutely crawling with the latter.
Face it, a skilled programmer can learn a text editor and the basics of almost any development envirionment in a few days, weeks, or months at most. Given someone to use as a mentor periodically, and that time can be greatly reduced. The hard part is application vertical knowledge, something you're not likely to find outside your company anyway (unless you work on some fairly generic software in-house).
It's a little harder to save much of anything when you have to recover financially from a lengthy layoff every 5-10 years. :-(
I think most folks would be happy to make a living wage.
The "ridiculous amounts" tend to be reserved for those folks nn IT who are living on the coasts (and who sometimes need those elevated wages to pay for little things like housing, which tends to be far more expensive in NYC or the Silicon valley than it is in most other major cities in the US).
While moving across the country is certainly an option (and one which I chose to take), it is not a choice without disadvantages, especially if one has a family and owns a house.
Besides, I would consider having to move as "being affected"...
Our mainframe system stores dates as a binary accumulated value (number of days) since a base date stored in a system parameter table. It doesn't have a limit. :-)
Georgia has a rule that any employee whose compensation consists wholly or partially of gratuities is exempt from Georgia's minimum wage law, so some of the folks I know who are waiters or who tend bar are only making around $3.50 an hour for base wages. It's the tips that make the job livable.
We also have two K-Marts within 10 miles of our house which seem very much alive.
...I thought the SoA (Sacrifice of Angels) mod for Homeworld was an excellent game.
The parent seems to be describing the types of ideas you sometimes see from end users and/or mangement, while you seem to be describing ideas from someone who has a better idea of the software development process.
Sometimes those sets of ideas intersect. More often, unfortunately, they do not.
One of the courses I took as part of my BSCS almost 20 years ago (gads) involved 4-person teams doing precisely that -- the coordinated design, documentation, and presentation of a complex software system (well, as complex as you can get in 10-12 weeks).
That course did an effective job of teaching us a LOT of things, including how to compromise when multiple good ideas were placed on the table and a project stage deadline was coming up.
Granted it was only one class, but even one well-presented class can provide good insights into the process (IMO).
Uh... What tasks do you think Linus has performed over the years w.r.t. the kernel? Or are you referring to the entire distribution universe (which is still effectively decentralized)?
FWIW, most of the mainframe shops I've worked in don't have separate roles such as "designers" and "programmers" -- instead, they have fairly experienced programmer/analysts who perform both roles as a matter of course, or they have programmer/analysts plus at least one experienced business analyst to collaboratively and iteratively create and refine the specs as development rolls along. The latter is far more common.
Project Managerment may or may not exist at any level, and I'm not convinced it's necessary in many cases when the P/A's are experienced (unless a project requires complex resource coordination, a PM can often prove to be more of a liability than an asset).
The Unisys Airline Center I worked in came closest to what you're describing, but that group was releasing fairly static airline applications with a lengthy (6- to 18-month) release cycle and which already had formal PDS (Design Spec) and PFS (Functional Spec) documention created and *formally agreed to* by the main paying customers before work even began on the new version. From that point, the new version's specific feature set was locked for the most part. That was only design at the screen level, though -- implementation details were usually left to the programming staff.
In the three shops I've worked in (an airline, a window-manufacturing company, and a IT/communications company) where production systems were being developed for in-house use and then supported in-house, expertise was aligned vertically along subsystem lines, not horizontally along coder/designer lines, and most of the work was designed, coded, initially tested, and eventually supported by the subject-area experts on the programming team.
With experienced people, that seems to make the most sense, and it provides most of the advantages of a small 1-2 person team even when a large project is being developed (since the net effect is a large number of small functional teams, each working in their areas of expertise in parallel).
Specs?
*Blink*
You didn't get my voice mail?
I suspect a lot of programmers are fully aware of that (though I would agree with another respondant that "craft" might be somewhat more accurate), but that a large number of managers (mainly those who don't have a software development background themselves) don't fully understand the truth behind the statement.
Software development is still a subjective process in many respects, and I'm not completely convinced that it's a bad thing. Sometimes the effective expression of a radical idea requires a solo programmer who just happens to have a brilliant insight or even just a vision of something.
Writing software isn't like building a bridge -- there are often a fair number of incompatible but equally elegant solutions to a give problem, and sometimes the elegance is readability and supportability rather than cute tricks in the code (which might legitmately save clocks or bytes but make also make life miserable for some unsuspecting support guy five years down the road).
Well, yeah... :-)
Ah... There's a preview button. I should use it next time. :-)
Wasn't the First Crusade largely a response to a Muslim invasion of the Byzantine Empire?
Much of it is free. Much of it is not free. All generalizations are false. :-)
It's easier to profit when you can legally print (or coin) your own currency. :-)
Heck, I even run internal tools that I write for internal company developer use past other programmers as a sanity check (after using them myself extensively) to make sure that things are actually working before I make the tools available to the general developer public.
Multiple testers are better than one, since different users often have different approaches, and I think testers are optimally obtained from a pool of actual end users (or in our case, quite often, from a pool of business analysts who either used to be end users or who are still end users). In any case, the folks testing should probably not be familiar with the code internals. It's too easy to unconsciously behave in certain ways (and avoid certain types of behaviors) if you know precisely what is expected by the program logic.
...it was difficult to learn the ins and outs of our users (flight dispatchers and pilots) because their jobs were themselves quite technical, required specialized vocabulary, etc. But that's what our business analysts were for (to act as an interface between the end users and the software developers). Most of them were former dispatchers or pilots themselves, so they understood the user issues, and some had programming experience as well so they had some handle on technical issues.
Our design process was also collaboritive and iterative -- it involved users, BAs, and programmers, and it started with the basics and only got fancy after the basic requirements were met.
The end result was a fairly useful system which was designed with both the end users and the programmers in mind.
There are so many text editing paradigms that it's hard for me to imaging only using one. That way lies stagnation, methinks. :-)
When comparing vanilla vi to NEdit, I find things like syntax highlighting, concurrent file editing, and ctags support to be large advantages. YMMV...