Science Fiction - "Ender's Shadow"
This book is a co-sequel to the well known "
Ender's Game" by Orson Scott Card. It's a "co-sequel", because it tells the same story as "
Ender's Game", but through the eyes of another character - Bean. At the start of the book Bean is a tiny street rat barely surviving on the streets of Rotterdam. However, he appears to be extremely smart - he learns to read by age 3.
Eventually Bean winds up in Battle School, where he is trained along with other children to be future commanders of the Earth's space fleet in the upcoming war with the Buggers. Buggers are hive-insect beings that have once attempted to attack Earth, but weremiracously defeated.
In any case, Bean becomes one of Ender's most capable and trusted lieutenents. And, they both go on to lead the Earth's fleet to defeat the Buggers. However, whereas Ender thinks the entire campain is just a simulation - Bean early on figures out that in the children are not playing games, but fighting the actual war.
"
Ender's Shadow" stands on its own. You can enjoy it without having read "
Ender's Game". However, for me it was fun to go back to the original book and re-read some of the sections that covered the same events. I've read "
Ender's Game" several times by now.
Besides these two books, there are number of other Ender books and my favorite is the direct sequel to "
Ender's Game", the book titled "
The Speaker for the Dead". However, I must say that "
Ender's Shadow" comes in a close second.
Non-fiction - "My Job Went To India (and all I got was this lousy book)"
Cover of this book shows a picture of a dishsheveled looking street person holding a sign "Will Code for Food". We all hope that this is not the fate of software developers in the USA. But hope is not enough and this book presents ideas and strategies of what you can do to not only preserve your job, but flourish as well.
The author, Chad Fowler, is a software developer who wrote this book after spending year and half in India training remote development teams for his company - he knows what he is talking about.
To begin with, outsourcing is not going away. As the communication infrastructure improves more and more intelligent and motivated people will become software developers. Some of these people are seriously motivated - as they maybe the only ones putting food on their extended family table. Work can easily move around the world to find these people, and we need to adapt.
The author presents 52 essays with specific advice in each, including action items for you to follow. Many of the ideas are self-evident, others are little suprising, but it is hard to disagree with any of his suggestion.
The book divides the essays into six parts, each on a specific theme. For example, Part I is titled "
Choosing Your Market". Clearly there is too much technology out there for a single developer to learn. Therefore you need to pick some area in which to become an expert. One suprizing suggestion the author makes is not to pick the most popular technology there is. There will be plenty of people who know the same stuff and the laws of supply and demand will keep prices for your services low. In the worst case popular technologies are the easiest to outsource. Instead pick some less popular, perhaps more bleeding edge technology to learn. This strategy is more risky, but can lead better work.
Whatever technology you concentrate on, even if it becomes a hit, you know it will be obsolete in five years, so you need to keep on learning. This is the theme of the Part II - "
Investing in your product". There are several obvious suggestions: try to work with people better than you, teach to learn things really deeply, and constantly practice. A less obvious suggestion is to learn more about the business in which you work, learn how companies work and why sometimes they do things in seemingly (to us) illogical ways.
Where as Part II talks in more general terms, Part III, "
Executing", suggest some concrete things you can do to keep your skills sharp. For example, rather than surfing the web while some long build is running - read a technical article. Always have something new to learn and explore. In the essay "
A Pebble in a Bucket of Water" the author talks about job security and being irreplacable. Well, there is no job security and no one is irreplacable. A company is group of people working together and when you leave, everything else will continue without you and with fewer problems than you'd expect. Think how the level of water in a bucket changes when just one pebble is removed.
Even if you are the hottest programmer since Bill Joy, people will not beat down your door with bags of money. You need to market yourself. This simply means that you and your work should be visible. This can be done in many ways - for example by writing status reports for you boss, or developing open source software, or by writing book reviews for your blog. People should know who you are and good things about you should appear when your name is entered in Google. All this is covered in Part IV - "
Marketing... not just for suits".
Part V is about maintaing your edge. One of the essays here discusses the story from "
Zen and Art of Mortocyle Maintanence" on the south Indian monkey trap. That's the one where a monkey reaches into a whole to get some rice, but cannot take its hand out because the opening is too small to fit the fist through. Do not get stuck like this with a particular technology or a job, expecting it to last forever. You need to keep an eye out for new stuff that will became the next great wave. Java or .Net seem to be market leaders today, but maybe you should be learning Ruby.
The final part is called "
If you can't beat 'em...". Instead you can "
Lead 'em" or "
Manage 'em...". In software development globalization is here to stay so learn to deal with it. Being able to lead, train or manage remote teams is a skill that is and will be in demand.
The book is a fun and a quick read. It makes you think about your work and what you can do to get better. These days, instead of spending too much time on Slashdot I've been brushing up on regular expressions and writing small apps using Ruby in Rails.
You can get a copy of this book from
Pragmatic Programmer web site.
