Subj : Re: Software Job Market Myths To : comp.programming,comp.software-eng From : H. S. Lahman Date : Wed Jun 29 2005 06:27 pm Responding to Terry... > The following myths are misconceptions that are hurting the U.S. and > European software industries. These misconceptions are reducing employment > in the software job market. They are hurting the lives of programmers. There > may be misinformation spread by companies that profit from outsourcing, by > established "big-business" software consultants, or recruiters. There is > just plain ignorance and false beliefs held over from the 1990s bubble. > Sadly, some software engineers continue to believe and propagate these > myths. > > Many of you will take exception to the list below because it threatens your > salary. If you are a software engineer and still make $70,000 per year, feel > lucky, but don't feel entitled. Some engineers have out-of-this-world > talent, and deserve even higher salaries. If this is you, good for you. This > list is not about the few super-talented engineers. > > > Misconceptions: > > > 1. Any good programmer requires $60,000 to $90,000 per year or more. > (Wrong. They may only require $40,000, or less, depending on the job. Entry > level programmers just out of college, many of whom are very capable, can be > hired for $30,000. It's not the 1990s anymore. There are many unemployed > engineers. The crazed demand for programmers is gone. Programmers require no > more pay than intelligent, educated, skilled workers in other professions.) It's not what the programmer requires. It is what market determines to be the value. Different markets result in different valuations. It is also well established that there can be as much as an order of magnitude difference in overall quality (in the general sense of productivity, maintainability, etc. in addition to reliability) between entry level developers and experienced stars. > 2. Any unemployed engineer must be unemployed for a reason and is not worth > hiring. > (Wrong. Many excellent engineers were let go simply because their employers > went out of business or drastically downsized. It's important to understand > that there was a true software market bubble and it burst. This, together > with dramatically increased outsourcing, has permanently changed the > software industry landscape. Many large software companies are simply not > hiring any US programmers as a policy.) While I generally agree, I think the last sentence is hyperbole. > 3. Hiring managers must demand years of hands-on experience doing exactly > what they need. > (Wrong. Any decent, college educated programmer can probably figure things > out quickly, possibly in a matter of minutes. Programmers are not like other > office help who can't function if you change their word processor. > Programmers understand software at a much deeper level. Most programmers > have been exposed to hundreds of different tools and environments throughout > their education and careers. Programmers are accustom to change. In fact, > many programmers with decades of experience have never worked on a similar > project twice. Programmers notice the similarities and themes in different > products. This allows them to adapt and learn to use new tools quickly.) I agree this is a naive view. Years ago before I retired we did a process improvement exercise for our recruiting. Part of the exercise involved weighting skills in order of importance so we could focus our interview time effectively. To our surprise all the tradition CS skills ranked at the bottom while things like communication skills, teamwork, self-starting, general problem solving, etc. ranked at the top. > 4. A programmer that lacks experience will require training. > (Wrong. Any good programmer can find the information they need and > essentially train themselves. Most hiring managers fail to appreciate how > all engineers have had to do this constantly in every job they have ever > had. Things change at light speed in the software development industry and > they always have. Learning to use a new API, a new tool, a new component, is > simply part of the job. Engineers don't even think of it as training. It's > part of engineering.) Here I have to strongly disagree. All one has to do is look at the huge volume of poor OO applications being produced today to see that reading a book is not always the answer. Producing quality software is an enormously complex undertaking and it is unrealistic to believe there is an easy path to competence. IOW, anyone can write C code that more or less works, but it is quite another thing to do it well. It has always amazed me that a large corporation will spend millions on evaluating copy machines and training everyone to use them. Yet the same companies balk at spending $100K for mentoring when their software people embark on a methodological sea change in the way they build products that directly affect the bottom line. > 5. Salaries listed in "Salary Calculators" at HotJobs or Information Week > reflect the industry and must be used for starting pay. > (Wrong. These numbers come from people who anonymously volunteer their > salaries. They put in larger than true numbers for three reasons. They hope > to raise the average for their profession thereby raising their own pay when > their review comes. They are asked to estimate their benefits, which they > are not good at doing. They wish they were making more and so fool > themselves or put what they wish they were making for the fun of it. Many > programmers do not read these publications or respond to the survey. That > means the surveys are not a representative sample of the industry. Finally, > there remains a gap between those who did not lose their jobs when the > bubble burst and new hires. Many who are still employed from the bubble are > now making much more than the true industry norms.) Actually, most HR departments don't use such surveys. They subscribe to pooled information services where the HR departments provide accurate information on their actual salaries in a blind manner. In that situation it is self-defeating to provide false information. > 6. Software consultants and full-time programmers are only for "big > businesses" and cannot benefit smaller "mom & pop" businesses. > (Wrong. Most small business owners are pathetically clues about what custom > software can do for them. Software can save so much time and money it's > crazy. It can totally replace employees. It can save months of work. It can > make almost every business more competitive.) I agree, but for different reasons. Software rarely replaces people. It mostly allows them to do their existing jobs better. IOW, software is an enabler of growth. > 7. Shrink wrapped software today can fill every need. > (Wrong. Most every business has specialized processes that are unique for > that business. Most every business has a competitive advantage that makes > them different. Even when it comes to shrink wrapped software like MS Excel > or Access, you likely need the skills of a programmer to get the most out > software of this kind.) While I agree that shrink-wrap software can't solve world hunger, it has still been remarkably effective. For example a recent article in ACM's Communications attributes one (of many) reasons for the failure of Japan's "software factories" to live up to the hubris of the '80s to reluctance to shift from mainframe processing to desktop tools like Excel. In addition, large scale reuse is becoming more and more common is software development as more an more core accounting, inventory, sales, etc. IT systems are becoming OTS commodities. In addition, technologies like MDA and MDD are focused on making it easier to shrink-wrap more complex systems. If anything the scale and scope of that trend is accelerating. > 8. Software consultants and full-time programmers are too expensive for > smaller "mom & pop" businesses. > (Wrong. Most businesses could realize a huge return on investment. A > programmer need not cost $100/hour.) This is related to (1). The market determines rates, not absolute dictums. The fact that the demand for developers has declined in the US will make them more available for small businesses as rates drop. OTOH, the demand for developers has more than outstripped availability in India, so it is unlikely they will be available there for small businesses as rates increase. Also, the traditional solution for small businesses has been the shrink-wrap market (7) -- precisely because economies of scale can be brought to bear when the small business can provide "sweat equity" for the details. > 9. People with real experience using a particular software product are > better suited than people with experience developing similar software. > (Wrong. This item is referring to programmers who may be looking for > non-programming technician jobs. This misconception reflects a huge lack of > understanding, respect, and appreciation for the capabilities of > programmers. Programmers understand software from the inside out. We can > predict what software will do. We know why it works as it does, and why it > fails. We can often fix things when they go wrong, instead of just calling > someone else. Depending on the situation, asking a software engineer if they > have full-time job experience using a particular software product, can be as > silly as asking an electrician if they have experience flipping a light > switch.) I agree but not for any of these reasons. The key need is for problem space knowledge, not tool knowledge. We deliberately standardize things like UIs so that the tools can be interchangeable. In addition, we have initiatives like MDA that strive to make tools completely interoperable at a semantic level. In addition, most of the "new" technologies just represent higher level abstractions of existing problem spaces. Such abstraction makes them easier to learn and use. So the tools and technologies we use are of secondary importance. Perhaps more important, automation is raising the bar for what is "inside". When I started in this business my first program was on a plug board; I was literally writing 1s and 0s into the hardware. Today most developers would barely recognize Assembly, much less be able to read machine code. Nor are they concerned with things like instruction set optimization because the 3GL compiler handles all that. In another decade developers will be solving problems via translation at the 4GL level so that most of the computing space will be transparent except to specialists. (RAD IDEs already achieve this to a large extent in the CRUD/USER processing niche.) ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl@pathfindermda.com Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH .