|
|
The following text is taken from pages 19-21 of Computer Job Survival Guide. What the Statistics Show about Credentials The Real Salary Survey data shows that although the majority of those who found their first computer job in 1999 had one of these computer-related four-year college degrees, a significant number did not. Other credentials that entry-level computer professionals with one or less years of experience reported to the Real Salary Survey in 1999 were BS degrees in Math, Chemistry, and Business, and BA degrees in Philosophy, Anthropology, and even English. The Real Salary Survey also received salary reports from a handful of professionals working entry-level salaried computer jobs who reported having no degree at all. Several of these had completed Junior College certificate programs, a few had earned vendor certifications, and a surprising number reported having no recognized credential at all, although, of course, they did have strong self-taught computer skills. The graphs on Page 16 show how starting salaries correlated with credentials for a sample of 73 people with one or less years of experience who submitted salary reports to the Real Rate Survey between Apri1 1, 1999 and April 3, 2000. As should come as no surprise, the entry-level jobs of people with weak credentials paid lower salaries than those of people with shiny new computer science degrees. But they still paid excellent salaries for people just starting their careers: most paid salaries in the $30,000s. But whatever their starting salaries, these people with weak credentials got their foot in their door. And, as we shall see when we look at how computer careers evolve, by the time they reach the five year point some of the people who have started out at lower salaries in less impressive jobs may outstrip those with far better credentials because they will have made better career decisions at each step of their career. The reason for this is that in computer work, unlike in most other career paths, your actual value in the marketplace is determined far more by what you can do right now than by what you might have done in the past. Once you are experienced, the employers who are desperate for competent programming and system support help don’t care what college you attended or what your grades were. They care only that you can do their job, right now, and that you know the intimate details of the technologies to which they have committed their businesses’ future.
The following section comes from pages 32-34 of Computer Job Survival Guide. Avoid Beginners’ Mistakes There are a couple of behaviors that scream out "newbie!" It is natural that you will display some of them, after all you are a newbie! But with some foresight you can prevent yourself from making the more flagrant errors that new people are prone to. In almost every case these errors come from a new person’s lack of appreciation of the complexity of the environment that they have entered. Often, too, they occur because the new person, fresh from school, is used to working as a lone individual and not as part of a team and they are not used to thinking about what effect their actions will have on the many other people who are working on the same system as they are. It is this unawareness that leads new people to edit system files shared by many other programmers and forget to mention it or leads them to move their own untested modules into the department’s test system, again without mentioning it. In many "test" environments there are programs that are shared by all programmers currently doing testing—programs that may be considered "test" programs because they are not the actual production programs run to do the company’s business but which twenty or thirty programmers use to enable them to build a framework in which to do further testing. If you mess with one of these debugged "test" programs you can easily ruin many other programmers’ entire day of testing. Move your own .dll file onto the test server, and Windows starts crashing on everyone’s machines. Change a batch module shared by several applications and reports from final "parallel" test runs, which are supposed to have perfect output, can show up with junk all over them. Worse, the programmers who unwittingly use your modification of a testing module often waste a lot of time debugging your code, thinking that the errors they see are coming from their own changes not yours. Take the time to have your test environment explained to you in detail and when you are in any doubt about whether you can modify something—ASK! Attempting to appear smart by not asking "dumb questions" usually just results in you doing something far dumber—screwing things up for your coworkers. Another typical mistake that new programmers make is to write tricky code that cannot be understood by ordinary mortals. Seeing an opportunity to use something they picked up in school, they use a little-known technique (the more devious the better) that a teacher or, more likely, a lab assistant showed them. This devious solution solves an immediate problem, and the person rushes it into production without writing an explanation of what they did because they know that they did a great job and assume that no one will ever have to fix their code. Two years later something changes in the system and their tricky code ceases to work. Perhaps they used some undocumented feature that no longer works under the latest release of the operating system. Perhaps they "faked out the system" by doing something tricky to a system control block somewhere that the vendor just changed. Whatever the reason, such displays of brilliance always result in time wasting and frustrating work for other people. No matter how smart you are, the code you write will always need work someday. Write it so the dumbest person in the world can understand what you did. Believe me, the worst possible experience is having to give an immediate lifesaving fix to tricky code that you simply can’t follow, and then realizing that you wrote it yourself a few years back! There is another common mistake made by brash young programmers. They comment loudly on the deficiencies of the old software they have been given to maintain. "Look at this!" they crow. "The documentation stinks! Talk about spaghetti logic! I could have written this whole routine in six lines! Who wrote this garbage?" The answer, all too often, is "the current boss." This is especially prone to happen when the new programmer doesn’t recognize the boss’s maiden name. Even if the author is not in a position to slow down your career there is never any excuse for insulting the people with whom you work. But beyond that there are often very good reasons behind the writing of what looks like "bad" code. The code in question may have been written in response to hardware or software limitations that have been remedied in intervening years. The code may have been developed before standards that are now commonly taught to all fledgling programmers were even thought of. After all, those standards only could develop after a large enough body of work had been developed and maintained that the need for the standards became apparent. Finally, the code you are looking at might have been gorgeous when it was first developed but since then has been subjected to a host of enhancements and fixes applied by harried maintenance programmers who preferred to remain anonymous. The developer whose name is in the documentation at the head of the program is often the only person whose name can be found, even though only slight vestiges of their actual work remain. The wise programmer will therefore keep their exclamations of disgust to themselves and share them only with members of their immediate family. You can be sure that a certain percentage of the code you are writing right now will embarrass you in years to come. Sometimes our brash programmer doesn’t stop at just commenting about old code either. They take it upon themselves to improve it—without consulting their boss first. They lavish time on rewriting routines that already work in order to make them more efficient. Since their own salaried time is usually worth a whole lot more to the company than the nanoseconds they save, this kind of behavior marks our new programmer in the eyes of management as someone who is not yet aware of the rules of the business game. Even worse, when improving the program’s efficiency our new programmer all too often fails to grasp some obscure function the sloppy code was performing so that the software, at some future time, fails. |
View the complete Table of Contents, including charts and fact sheets for Computer Job Survival Guide
Table of Contents
Order Your Copy of Computer Job Survival Guide!
