Slashdot Mirror
My Job Went To India
Josh Skillings writes "The author, Chad Fowler, draws upon his experiences as a software engineer, a team leader over a group of Indian developers, and as a jazz musician, to describe 52 ways or tips that will help you to become a more valuable employee. These tips are described in two or three pages each, and are usually illustrated by a practical example or story. The tips are well thought-out, well-explained and make sense. Chad draws upon the open source movement as well, highlighting ways that contributing to and learning from open source can improve your career. These tips gave me greater respect and appreciation for the open source movement in general." Read on for the rest of Josh's review.
My Job Went To India (and All I Got was This Lousy Book)
author
Chad Fowler
pages
185
publisher
The Pragmatic Bookshelf
rating
8
reviewer
Josh Skillings
ISBN
0-9766940-1-8
summary
Offers 52 ways you can keep your software engineering job, or grow yourself into an even better job.
Chad encourages the you to think of your career as life cycle of a product, and as such divides the 52 tips into the four areas of "Choosing Your Market", "Invest in your Product", "Execute", and "Market", and then two extra groups called, "Maintaining Your Edge", and "If you Can't Beat 'Em". This grouping works surprisingly well and provides an overarching context that makes sense. Many of the tips have specific calls to action at the end, which are useful if you don't already have ideas on how to apply the tip.
For example, under "Choosing Your Market", tip #7 "Don't Put Your Eggs In Someone Else's Basket", Chad encourages you to refrain from learning vendor-specific technologies that can disappear with the vendor, and then calls you to action by suggesting you write a small project in a technology that competes with the technology you are used to using. This will help you understand why the technology exists to start with and what opens your horizons for what might be coming next.
Under the section "Investing in your Product", tip #14 called "Practice, Practice, Practice", Chad offers suggestions on how software engineers can get even better by specific kinds of focused practice. The action items at the end of the section suggests practicing "Code Katas" katas similar to martial artists, but instead in code and in different languages.
With 52 tips, this book has a lot of tips, a tip for every week of the year, but you should expect to spend much longer than a week on most of them. A few of the tips you are probably doing already, but many of them you aren't. Some of the tips are fairly straight forward and easy to put in to practice. You could spend your entire life attempting and never achieve some of the other tips, such as tip #39, "Release Your Code." The ultimate goal of this tip is to be able to say in a job interview, "Oh, are you running Nifty++? I can help you with that- I wrote it." Chances are this scenario won't ever happen to you, but by working towards this goal in the ways the book outlines, you will definitely become a better, more valuable software engineer. Many of the tips will make you a better person in general, regardless of your career, such as tip #28, "Learn How To Fail", where Chad emphasizes how to fail gracefully and the rewards that can be learned from failure. This wide range of time, difficult, and application of the tips gives you something to work on today, next week, and next year.
The title of the book is silly. Yes, it was catchy enough for me to notice in the bookstore, with the red cover and the homeless (software engineer?) holding a sign, "Will Code For Food". So from that point of view, the cover worked. However, unless you've read the book, you might think it's as campy as the cover and wonder if it is somehow anti-Indian. I think a better title would be along the lines of "How to Get Any Job You Want", since if you can master all of these tips, you'll be the best there ever was.
While I didn't expect any specific technical advice, I would have liked some. I understand that an author needs to be sensitive to how fast technology changes, however just one tip with a warning: "This information is my opinion on April 11, 2007 and will probably change tomorrow". And then describes about how Subversion is a great tool, Python is a great language to learn, and learning design patterns can make your life easier, would have been appreciated. A tip like this would help you to understand the author a bit better and further encourage you to learn more.
If you want to improve yourself and you can accept advice, this book is for you. You will find things you can do better and skills you've never considered. Like some of the other Pragmatic Programmer books, I will never be able to master everything in this book, so I'll be reading this book again and again, trying to get better every time. Don't let the cover put you off, this is a great book.
You can purchase My Job Went To India (and All I Got was This Lousy Book) from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
For example, under "Choosing Your Market", tip #7 "Don't Put Your Eggs In Someone Else's Basket", Chad encourages you to refrain from learning vendor-specific technologies that can disappear with the vendor, and then calls you to action by suggesting you write a small project in a technology that competes with the technology you are used to using. This will help you understand why the technology exists to start with and what opens your horizons for what might be coming next.
Under the section "Investing in your Product", tip #14 called "Practice, Practice, Practice", Chad offers suggestions on how software engineers can get even better by specific kinds of focused practice. The action items at the end of the section suggests practicing "Code Katas" katas similar to martial artists, but instead in code and in different languages.
With 52 tips, this book has a lot of tips, a tip for every week of the year, but you should expect to spend much longer than a week on most of them. A few of the tips you are probably doing already, but many of them you aren't. Some of the tips are fairly straight forward and easy to put in to practice. You could spend your entire life attempting and never achieve some of the other tips, such as tip #39, "Release Your Code." The ultimate goal of this tip is to be able to say in a job interview, "Oh, are you running Nifty++? I can help you with that- I wrote it." Chances are this scenario won't ever happen to you, but by working towards this goal in the ways the book outlines, you will definitely become a better, more valuable software engineer. Many of the tips will make you a better person in general, regardless of your career, such as tip #28, "Learn How To Fail", where Chad emphasizes how to fail gracefully and the rewards that can be learned from failure. This wide range of time, difficult, and application of the tips gives you something to work on today, next week, and next year.
The title of the book is silly. Yes, it was catchy enough for me to notice in the bookstore, with the red cover and the homeless (software engineer?) holding a sign, "Will Code For Food". So from that point of view, the cover worked. However, unless you've read the book, you might think it's as campy as the cover and wonder if it is somehow anti-Indian. I think a better title would be along the lines of "How to Get Any Job You Want", since if you can master all of these tips, you'll be the best there ever was.
While I didn't expect any specific technical advice, I would have liked some. I understand that an author needs to be sensitive to how fast technology changes, however just one tip with a warning: "This information is my opinion on April 11, 2007 and will probably change tomorrow". And then describes about how Subversion is a great tool, Python is a great language to learn, and learning design patterns can make your life easier, would have been appreciated. A tip like this would help you to understand the author a bit better and further encourage you to learn more.
If you want to improve yourself and you can accept advice, this book is for you. You will find things you can do better and skills you've never considered. Like some of the other Pragmatic Programmer books, I will never be able to master everything in this book, so I'll be reading this book again and again, trying to get better every time. Don't let the cover put you off, this is a great book.
You can purchase My Job Went To India (and All I Got was This Lousy Book) from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Also, start your own company and show what you can do, let it become a battle on your turf, make it about software and products, not about bottom lines and the bosses fancy yacht and head count. The US was built by entrepreneurs, it's time to start building again!
Same goes for anyone else in any other country where a crap company outsources your job or your mates jobs from a company you helped build. Start up your own company, it's the best way to 1. get back 2. do things your way.
...but if your job went to India, you're expendable. Learn some new skills, get better at what you do, etc.
what an insensitive BS answer!
I'm an expert in my field, I have over 20 yrs doing what I do (netmgt) and yet companies are not respecting actual field experience anymore - they prefer to cheap-out EVERY TIME ;(
there is nothing I can do about it. 'get better' at what I do? I'm already a leader in my company, for this technology.
actually, my job didn't go to india. it went to 'eastern europe' (country name withheld). the labor is MUCH cheaper there but I'm not at all convinced they have better experience or understanding of the field. it was PURELY for cost reasons.
when its for cost reasons, there is nothing an employee can do. can I live on the same pay rate that east europe can live on? surely, I can't (I live in the US).
no matter how you cut it, its unfair and its NOT the employee's fault. grow up and you'll see this - and stop blaming US workers, its NOT our fault most of the time. its the bean counters.
--
"It is now safe to switch off your computer."
Lol, that's their own fault. The managers probably said: "code me something that does x" instead of "code me something that we can support" or the sales person offered: we can do your coding project for USD XXXXX which appeared cheaper than what they were paying for the local coders. The long term cost of course, they didn't plan for.
I had something similar happen at one of the companies I used to work for a while ago (precision measurement instruments for industrial processes). They outsourced their lab and prototyping to China as to profit from the cheap scientists. As soon as the branch in China got hold of the blueprints of quite some high tech products (5 and up digit retail value) the whole department literally vanished. Nothing was heard from them for a while until somebody went over just to see an empty building with the offices. All original equipment was still there, the people had started their own little company selling the same product for a lot less down the road, they took all the contacts and copies of plans with them.
Custom electronics and digital signage for your business: www.evcircuits.com
This is exactly right. If you have to gain all these other "soft skills" or business skills in order to just be a regular software engineer, then why keep working for someone else? One of the main reasons for being an employee is because it's (supposed to be) both easier and safer than striking out on your own. Instead of long hours and having to wear many hats, you can just concentrate on your own skill, and leave the business stuff to the people who specialize in that. Anyone familiar with the idea of specialized labor should understand this. The downside is (supposed to be) your pay is lower than it could potentially be by owning and operating your own business.
If today's corporations want their regular rank-and-file employees to wear many hats, be multi-talented, and have a lot of business skills, then they're simply not doing their own jobs correctly.
What I noticed in my experiences with code written by outsourced coders was that while it worked, it just wasn't that good. They knew the LANGUAGE, but they didn't know how to PROGRAM. Not very well, anyway.
While working with the outsourced coders for a client of a managed hosting company I was sent a 250-line SQL query (for MySQL, no less) and asked why the query was running so slow. It was a mess. The guy obviously didn't understand SQL or database design and was using brute force to get the data.
If you stop and look around at what's happening, it terrifies you. So you quit looking and try to kill or at least discredit the messenger.
The last time I was in an emergency room I was escorting someone with uncontrolled bleeding. I had done my boy scout best, but I am not a medic. It was a three-hour wait while the orderlies joked about how much weed they were planning to smoke that weekend. When I asked for a doctor, they referred me to a security guard. I mentioned the incident to my doctor at my next visit. She winced and said "Yeah, we avoid that place like the plague when we can." It's the largest, best-funded hospital in the area.
The last time I asked a cop for directions in a strange city -- wearing business casual clothes, mind you -- he placed his hand on his weapon and told me in rude terms he wasn't a tour guide. I'd like to think he was just a random jackass, but the attitude smelled like he was trying to bluff through insecurity and fear.
The last time I went on a business trip, I watched a TSA agent browbeat and threaten a small clumsy woman with incarceration if she didn't take her shoes off faster. When I spoke to his supervisor, he called over an armed officer in uniform and threatened to arrest me. The supervisor caved and apologized when I pointed out the surveillance camera recording the incident.
My kids' teachers have that vacant look of learned helplessness in their eyes. They were idealists once. It's been beaten out of them.
There's a major elevated highway in my city. It's been basically condemned and it's still in use. When it falls, there's a large number of buildings and thoroughfares that it will take with it. Everybody knows. No one can do anything. I try to avoid it when I can.
Forget McCain and Obama. We need a seance with Washington, Jefferson, Franklin, Lincoln and both Roosevelts, Teddy and Frank. I honestly think it would take all six to get us out of this mess, after they kicked all of our respective asses for letting it get this bad.