Customer Reviews

How to Become a Highly Paid Corporate Programmer

5 star:		(4)
4 star:		(0)
3 star:		(2)
2 star:		(1)
1 star:		(3)

 

 

I'm almost angry at how bad this book is. Most of the advice is dated from mainframe days, and the rest is just wrong and following it will get you fired. Chapters tend to be short (3-4 pages) and consist mostly of stories from his friends, which aren't always developed past the telling of the story.

There are a few good takeaways. Mainly, if you're going to be a corporate programmer, it's important that you know the company's business processes, instead of just focusing on building technical skills. Make your boss look good. For everything else, using common sense is a better guide than following the advice in this book.

An awful lot of the best programmers I've ever met are true geniuses. Unfortunately the genius aspect only goes so far as to programming. Many of then have "discovered" that late in high school or early in college they know more than their professors and quite school to get a programming job that pays a lot more than flipping burgers.

What they don't understand is that programming something is just the tip of the iceberg. They now have to compete in the regular business world. The salesman calling on a prospect wants to take a teckie along with him to help explain the details. The long haired high school drop out wearing Army fatigues and a few earrings who doesn't know how to put a sentence together isn't going to be a help.

Here is an analysis of the business world written for programmers. The book has four sections:

1. Starting a Successful programming Career
2. Thriving in a Competitive Environment
3. Mastering the Corporate Culture
4. Beyond Programming.

In this last section, there are a few chapters on starting your own business. By no means is this a complete how to on starting the next Microsoft, but it is at least a few hard cold facts.

This book just may help you break out of the mold in which you find yourself.

I'm the CEO of Scherrer Resources, Inc. developers of the popular Web Ally CRM software (www.WebAlly.com) and I wish all our staff had read this book years ago. Why? Because I continue to tell our staff that I am not the person who hires them; they work for the customer... listen to the customer and you will have a lucrative programming career. Paul Harkins, the author, understands this and puts it into perspective in this concise, easy to read manual on becomming a highly paid corporate programmer. I've seen my share of bad code, yet improving the code doesn't always make the customer happy. It's the logical convergence of good coding and meeting the need that makes for success; and Paul's book makes it clear and provides case studies that drive home the message. Our developers will read this and our next versions of Sales Ally, Advisor's Ally, Broker's Ally and Web Ally will come to market with better functionality, improved user interface and Paul's special mix of tips and tricks on how to meet customer needs. The "Harkins Trace" is wending its way to market and ten years from now we'll all look back and wonder how corporate consulting programmers would have been able to dig through such mountains of spagetti code without the Harkins Audit Software product. Move over Peter Norton, here comes Paul Harkins! Paul has built a set of programmers utilities in the same fashion that Peter Norton got his reputation for PC utilities. The only difference is that Norton built for end users and Paul is building for professional programmers. Maybe it shouldn't be "move over" Peter Norton, maybe it should be that they team up, and as a dynamic duo they continue the pace of improving the use of computing devices with their special blend of experience, knowledge and mentoring.

Great book. I wish I had this knowledge years ago.

After reading the first section I reorganized my resume. Despite what you may think, the languages you code with account for only a small part of your job. Find out what your boss really wants from you (you'll be surprised). Learn the six most important questions to ask on a job interview.

Discover which type of vendor supplied software package will likely get you the highest compensation. See what types of productivity tools you should have. Included are tips on interacting with the new corporate culture, dealing with end-users, what to do when you get a really bad boss and knowing when it's time to move on. Also covered is what to expect when moving into management, consulting and going into business for yourself.

The author worked for 21 years at IBM and has more than 40 years experience as a corporate programmer giving you advise you cannot afford to be without.

This is one of the worst books I have ever read. A majority of the book is made up of stories about the author and his friends that serve no purpose other than to brag about how wonderful they all are. Every story revolves around a difficult working situation or complex programming problem which was solved because the author is such a talented programmer. He never gets into much detail after telling the story that would really explain how the problems were dealt with.

It also seems that all of the authors experience is with mainframe programming. He clearly knows nothing about modern development practices. He encourages copying and pasting as much code as possible, using goto statements, never checking over your code before compiling, as well as many other sloppy outdated practices. There are also at least two chapters that talk about making sure you get enough time allocated on the mainframe to compile and test your applications. If I was reading this book in 1975 it might be somewhat applicable, but the technology described in this book makes me wonder if the author has even touched a computer in the past 20 years.

Additonally some of the practices in this book are likely to get you fired. The author basically states that you should make every effort to NOT help your coworkers and to only work on the interesting high profile projects.

The only good pieces of advice in this book are to try to make your boss look good and to learn the business you are in. Using common sense would be much more effective than listening to the majority of the points made in this book.

After purchasing this book I immediately changed my entire attitude and philosophy towards my programming job. In fact, I rearranged my resume, applied for new jobs and start my new programming job next week! (Must I mention my significant salary jump?) This book is full of useful and practical tips for every programmer (and beyond!).

This book is a very mixed bag. On the one hand, it has a lot of useful advice (for example, providing your boss with a weekly summary of your work is a very good idea that I have since implemented; I also took his advice to study accounting and other business processes).

On the other hand, it was frustrating to read at times because many ideas are not explained in enough detail to be as useful as they could have been. For example, his chapter on starting your own consulting firm runs just a few pages - certainly not enough to give you what you need to run your own firm, but probably just enough to be dangerous. A little knowledge is a dangerous thing.

Some of his ideas seem downright bad, especially if misinterpreted. For example, he suggests re-using code. This is good advice if it prevents you from re-inventing the wheel but bad if it causes you to uncritically re-use badly written code (or code that was written for a different purpose than you're using it for).

Many things in this book also seemed hopelessly outdated or unrealistic - for example, he advises programmers to ask what their access to the computer is and to insure that they'll have immediate access to the compiler before accepting a job. Who on earth doesn't have their own computer and compiler anymore? Maybe they didn't in the era of mainframes when computers and computing time were still extremely expensive, but that's certainly not the case anymore. He also seems to treat debuggers as a great new development, to expect that all programmers will get their own office, and assume that people without a degree in a related field (or even without a degree at all) can just walk into a programming job without much trouble.

As I mentioned, this book has some really good advice that will help you advance in your career, but some of its recommendations can be really dangerous if applied improperly. Read it but take its advice with a grain of salt. It is a very mixed bag and consequently is rated 3 stars.

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."

Finally I found THE BOOK for the programmers. I would call this book 'A Programmer's Bible'. I suggested to procure multiple copies of this book in TCS library. This book has invaluable wisdom accumulated by Paul H. Harkins over 4 decades of his corporate career in programming. Even though it has serious concepts, it reads like a collection of small stories, his experiences, the situations he encountered, his colleagues etc. You wouldn't get bored even in a single chapter. This guy is programming from the dawn of the computers. Mainly into RPG. Most of the java/other technology developers out there can take the message out of this book's examples and apply it to their respective streams.

This book is divided into four sections, each deals with a specific purpose. The target audience of this book are from the freshers to the veterans in the top of their career hierarchy. The best part is that, every chapter has a summary at the end. If you are too busy to read a book, you could just flip through the "Bottom Line" summary at the end of each chapter.

Section 1: Starting a Successful Programming Career
This section is for the beginning programmers/freshers. Harkin advices the freshers on how to tackle the interview, what questions to ask, how to behave with the managers, how to learn and develop the coding skills, the importance of having the complete business process knowledge, using the borrowed code and the usage of productivity tools. Tight packed wisdom, which took close to 6 years for me to learn on my own, is presented in this first section. I am glad that I knew most of the tips in this section by experience.

Section 2: Thriving in a Competitive Environment
This section is for the programmers with few years of experience like me. Many programmers I knew gets frustrated with their work after few years and they begin to slog. Harkin tells us, how to avoid that pitfall and if we are already in to it, how to get out of that. Lots of practical advices on tackling a tough and high visibility projects, boosting your performance, handling stress, tips and tricks to master complex applications and business processes etc. He suggests us to keep changing the projects, spotting and utilizing the opportunities and how to stay at the top of our game. I enjoyed these chapters more, as I could relate to these text !

Section 3: Mastering the Corporate Culture
Harkin stresses the importance of having a mentor in your organization and encourages you to mentor others too. I liked this and I am doing this often. His tips on how to get adjusted to the corporate culture of the new company, how to get along with your boss, what to do If you get a bad boss and how to get a push in your pay check are really good. However, I do not agree with some of the concepts that he discusses in the name of corporate culture, to keep your manager happy. I find myself in trouble, time and again, just because I couldn't do it. I would not blame anyone at the same time I don't agree with some of the concepts discussed in this section.
Also, he stresses that a private office and a silent workplace is a must for efficient programming. I completely disagree. I cannot work in silence. Over the years in many different projects, I have observed that I perform efficiently in a most noisiest place with a lot of distractions from people around me. When I am alone, I do, may be quarter of my work. He should have put a disclaimer that it applies to him and may apply to others as well. Not as a mandatory one.

Section 4: Beyond programming
This section is for the programmers with an entrepreneurial bent. Mostly discusses on how to become a programming consultant, pros and cons of that career and how to develop your own company and market your own software product etc. He urges the importance of writing for the industry that you are working for. I like it very much. He sited examples of people shifting from programming to corporate positions in an interesting manner.

Even though this book targets four different categories of programmers, I would suggest everyone to read every chapter. Since I feel thats a logical career path for achieving programmers, unless you already planned your career path. This book has made a lasting impression on me and forced me to make some decisions in my life, which I would not have taken other wise. I am planning to blog on the mobile development arena. Thanks a lot Paul H. Harkins for writing this book for us.

This book might only work if you plan on becoming a Systems/370 or z/OS programmer. I still wouldn't recommend it.

Harkins gives advice that no doubt worked for him--but as another reviewer
stated, this advice is largely dated or downright personal. For example,
early in the book he warns against listening to music while you work,
because it bothers "other people." Clearly, this means him. I've found
that by first, asking my manager on their policy, and then checking with my
teammates, this isn't an issue.

Now, the reality is that Agile development is picking up alot of steam, and
as offices begin rearranging their work areas to account for the "new"
process that Agile represents, its highly doubtful that you'll get to
listen to music anyway, but I'm not alone in noticing that I work well not
in silence, but not in total noise.

Chapter 8 contains a slew of advice that is simply--avoided at all costs.

First and foremost Harkins neatly abandon's OOP. He writes,
"The programmer should not split one logical program of a business function
into 50 parts, calling the 50 sub-programs from the main program and then
having the called programs call more programs down many levels (in the call
stack). If the business logic, such as validating a customer number, is
truly unique to the program, then put it in the program, not in a
sub-program. "

Don't get me wrong, he still suggests separating business logic from data
access and ostensibly--presentation. But he flat out states to put all
business logic into a single program. For those of you that don't have
their alarm bells ringing--this destroys code reuse. Someone else in your
company can use the solution to your problem (or has already solved it) but
if its nested within the logic of a driver/main program, guess who will
never get to see it? My biggest criticism is that if you follow the
process of putting ALL business logic into your "main" program of some
kind, it's not going to be easy to test--at all. And the foundation of
trusting your code is built upon having extensively tested what you can at
every feasible level in your software.

I'm more of a follower of Uncle Bob, and share his opinion that if you need
to extensively document your code, it's probably poorly written. As much
as possible, code should be self-documenting. Harkins suggests the exact
opposite here.

Finally, he gives the "sage advice" of testing your program, and not
deleting your production code!!! Really? In the world of code
repositories with robust versioning systems, THIS is news? Even when this
was written in 2004, CVS was common. And what about CAT?

Much of the rest of the advice in the book follows these processes. The
guy has clearly never worked on a complex multi tiered application--most of
the advice that he gives is salient (maybe) for batch and utility programs. And then he
starts talking about the "virtues" of GOTO...

Harkins has written a highly opinionated very narrow book. In short, get
the job done as fast as possible.

If you REALLY want to learn "How to
Become a Highly Paid Corporate Programmer," read "Clean Coding," and
"Working Effectively with Legacy Code." These two books alone I credit for
giving me a top-paying job out of school.