Neophytes Keep Away! This book is dangerous, seriously.
Although the author of this book has over forty years of experience at all levels of corporate programming (from programmer to developer to consultant to company owner), I can not recommend this book to anyone. While the author provides excellent advice on many topics, the items on which he is blatantly wrong are VERY dangerous for anyone follow, especially those new to the field.
Seemingly all of the author's experience is with mainframe-based applications and coding techniques. It is sad and very scary to see the author promoting years worth of bad mainframe coding-style habits and bad techniques to his audience. His advice starts with copying and pasting as much code as you can to solve a problem, one the top causes of software bugs. Next, Mr. Harkins' advice is, "Reviewing your source code as you wrote it, without compiling it, is almost always a very big waste of time, because only the program compile is the final judge of whether your code is correct enough to create an object program." All of the top programmers I know strive to write code that works without depending on the compiler to find mistakes for them.
His advice to not bring in headphones because "that will not only make you less efficient" is quite simply dumb. The developers I know who listen to music while coding, including myself, do so in order to concentrate on their work. This often involves canceling out the noise from inconsiderate co-workers and mangers who insist on using their speakerphones all day.
The author's advice for those looking to found their own consulting firm is not any better. He quotes a friend who says, "If a customer is really unreasonable and difficult, I tell him, `Why don't you people go away?' Then they get scared that they won't have any support." The author then says, "That's what you can do when you own your own firm." Wow, and I thought you had to pay executive mentors for advice like that.
These are only a few random exmaples yet for all the scattered yet exceptionally poor advice in the book, the author does have some good, though non-surprising, points as well. In summary, his best point that spans the entire book is that to be highly successful as a corporate programmer you need an in-depth understanding of your company's business functions. Understanding the code should come secondary. Here's a quote that I actually agree with:
Many corporate programmers never get beyond looking at the source code as their basis of understanding business functions and how programs work. These programmers are, I believe, doomed never to understand vast amounts of important business functions or program code, because it is difficult to learn that way. They can't see the business function because when they are looking at the details in the code, they are looking at details that are rarely, if ever, executed. These programmers typically spend their programming careers bored and unhappy because they are focused on support of a tiny part of the corporate business function.
Buy it on Amazon
