The book, written by Chad Fowler, a well-known Ruby expert, is a second edition of a book that was previously titled “My Job Went to India: 52 Ways To Save Your Job”. The first edition’s main idea was helping US developers find a new place for themselves in the globalized world where more and more projects are outsourced to some remote countries. The second edition is more of a redesign than an update, and instead of showing you how to be good enough not to be fired, its aim is to show you how to be awesome: how to become an expert in your field, a well-known, respected developer, and how to have fun on the way.

I’ve found a lot of great ideas and made tons of notes, but if I shared everything that would be definitely TLDR, so instead I’ll try to sum it up in a few points which were repeated in various forms throughout the book. (If some of these seem too obvious to you, I’m pretty sure you’ll find some other tips that will make more sense for you in the book.)

To become an awesome developer, first you have to decide you want to become one. You have to accept that one day you want to be like those people you admire, and that you’re going to spend time and make effort working towards that goal. You can’t just wait for opportunities to appear and do nothing, you need to actively start looking for them. Just like “programming by coincidence” is a bad practice, so is “career by coincidence”. You need to aim high or you won’t get anywhere.

You don’t win a race by trying not to lose. And you don’t win at life by trying not to suck.

Have an open mind and don’t be afraid to learn new things. If you’re an iOS developer and Apple fanboy, learn something about Android too (and vice versa :). If you’re a Ruby guy, take a look at Python too. Read that article about Ruby interpreter or garbage collector, even if it seems too low level. Don’t avoid a part of your project because it’s some other guy’s or girl’s turf – try to learn something from them.

Keep an eye out for new technologies. Some of them will get big in a year or two – be prepared when it happens (and a lot of them won’t, of course). At some point the technology that you use for everything and can’t live without will get old and obsolete – don’t miss that moment and don’t stay on a sinking ship.

Don’t be afraid to teach others either. Don’t hog knowledge, information or tricks for yourself. People that are trying hard to be irreplaceable will be much less appreciated than those who are trying to make it easier to replace them, and easier for other developers that follow them to pick up where they left off. And as a bonus, by teaching others you can learn a lot yourself too.

Also, don’t get the misconception that if something is obvious for you, it’s obvious for everyone and no one will be interested in hearing about it. The more you know, the more things there will be that will be obvious for you but quite interesting for others.

Try to constantly improve your work, tools, processes and environment. Find things that don’t work and fix them. Find things that could be simplified by writing a script, generator, library or framework, write something that would make it easier for you or others to make similar projects or implement similar features. Anything that you have to repeat over and over? Anything that really annoys you or makes you work less efficiently that you possibly could?

If you’re stuck in a shitty project, treat it as a challenge and see how many things you can improve. Try to leave the project every day a tiny bit better than it was in the morning – in a month you’ll see a difference.

Also, if something doesn’t involve writing code, don’t assume it’s not your problem. If you see that your project is going in a wrong direction, that there’s a problem with your process or methodology, say it aloud and suggest improvements. Try to think on a higher level too, understand your company as a whole, how it works from the business perspective, and if you have any good ideas – share them.

If you do something right, make sure the world knows. Programmers often tend to be too modest about their work, perhaps from the fear of appearing like an arrogant douchebag. But if you don’t tell the world about you, it won’t find you by itself.

We have a running joke in our company about the project we’ve done some time ago; after we had finished it, the owners have put it online, and then did nothing more about it. Months later, that project – which was publicly available on the web – still had only 4 users, all of them either product owners or members of the team (and there was one dog too…). It’s as if they assumed that it’s enough to put something on the web and everyone will hear about it immediately – well, the thing is, no one did.

That applies to a lot of things you do. If you write a cool library, promote it where you can – look at it this way: the more people hear about it, the more people you will help, right? You shouldn’t also hide the things you do inside your company. There is no formal, objective way to judge or measure if you’re a good or bad developer, so the only way you will be judged will be based on other people’s opinion about you. Now, how can they they judge you correctly if they don’t know what you’ve done or what your skills or strengths are?

A great way to be heard is to have some kind of “mission”, something that you’re crazy about and want to tell everyone about. I know one guy who does everything he can to teach other developers how to write Android apps and make them interested in that. Another guy does the same with DataMapper. Yet another does it with testing and TDD. If you know the same people I know, you can probably guess who I’m talking about. These people are so passionate about the things they love and believe in that they just can’t help sharing them with everyone. Can you find something that you can be as passionate about?

“If you kick ass and no one is there to see, did you really kick ass? Who cares?”

I really recommend anyone who is serious about software development to read this book. And if you haven’t read the other two from this series – “Pragmatic Programmer” and “Pragmatic Thinking and Learning” – go read those too. The former will make you a better coder and developer, and the latter will teach you how to hack your brain to make it work more efficiently and get better ideas.