A few days ago I finished reading Chad Fowler’s The Passionate Programmer – Creating a Remarkable Career in Software Development, one of the first eleven books my boss recommended and the best one I’ve ever read so far. As I picked up the book to continue reading day by day, I’d look back at the chapters’ names and try to remember what they talked about since the book mentions a lot of important tips and reflections about, mostly, life and work. Due to the fact that I have a whole load of book to read, I figured that by the time I was done with them I’d hardly remember what I read in this one, so this post will serve me as a memory guide so I can always look back at it once in a while and remember all the cool things the book mentioned, and, at the same time, it will serve as a book review to whomever is thinking about buying it or to people who have no idea this book existed and stumbled across this page by fate.
The book is divided into five sections, each one covering an important matter regarding the steps to creating a remarkable career, and each of these sections have a whole bunch of chapters, which I will review one by one by pointing out the main factor the author wanted the reader to focus on. Each chapter has an ‘Act on It’ part which gives practical tips on what you should do to boost up your career, and this is one of the huge differences between reading this review and reading the book.
As said, this will only be a review, the book is 200 pages long and nothing can be as complete as that, so I recommend buying it even if you think this review looks like it’s enough. It’s not, to me it is because I’ve read the book, so go buy it, your career thanks you. Enough foreplay, let’s get started, shall we?
The book starts by pointing out something obvious but rarely thought about: we spend, if not more, half our time awake working, which means that our lives are basically our work, so, loving your work is one of the key things to loving your life, and this is what the book is all about, as the author points out:
“This book is about finding fulfillment and happiness in your career. [...] Throughout this book, I’m going to give you advice that I hope will lead you to a happier and more rewarding career.”
The book’s whole philosophy is also mentioned in this section, and which is really simple but made me think differently about things: you should focus on winning, and not on not losing. The whole idea is to be great, or, as the book titles, remarkable, and not just some person trying to save his or her job. If you stop to think about it, most people are just comfortable with not losing and therefore hardly gain success or find the grand happiness we all go for, because the first step to grow in life is to actually have your mind focused on that growth.
“You don’t win a race by trying not to lose.”
The chapters are then traced out as facets of a business, which is…you! A software developer’s career needs to be planned out as a business, because we are businesspeople, our employers invest on us and it is our duty to maintain the value of that investment by honing our skills to help the company make money (which, trust me, is what it’s meant for). You are the one responsible for this plan, which the book helps you trace with its chapters: choosing your market by making choices such as business domains and technologies, investing on these choices, executing them and getting them recognized.
- Lead or Bleed?
- Supply and Demand
- Coding Don’t Cut It Anymore
- Be the Worst
- Invest in Your Intelligence
- Don’t Listen to Your Parents
- Be a Generalist
- Be a Specialist
- Don’t Put All Your Eggs in Someone Else’s Basket
- Love it or Leave it
- Learn to Fish
- Learn How Businesses Really Work
- Find a Mentor
- Be a Mentor
- Practice, Practice, Practice
- The Way That You Do It
- On the Shoulders of Giants
- Automate Yourself Into a Job
- Right Now
- Mind Reader
- Daily Hit
- Remember Who You Work For
- Be Where You’re At
- How Good a Job Can I Do Today?
- How Much Are You Worth?
- A Pebble in a Bucket of Water
- Learn to Love Maintenance
- Eight-Hour Burn
- Learn to Fall
- Say “No”
- Don’t Panic
- Say It, Do It, Show It
- Perceptions, Perschmeptions
- Adventure Tour Guide
- Me Rite Reel Nice
- Being Present
- Suit Speak
- Change the World
- Let Your Voice Be Heard
- Build Your Brand
- Release Your Code
- Making the Hang
- Already Obsolete
- You’ve Already Lost Your Job
- Path with No Destination
- Make Yourself a Map
- Watch the Market
- That Fat Man in the Mirror
- The South Indian Monkey Trap
- Avoid Waterfall Career Planning
- Better Than Yesterday
- Go Independent
Part I – Choosing Your Market
This section covers ways that can help you choose with technologies to work with and which business domains we should settle on. This is important due to the fact that we should be in control of our choices, and not just let them be taken by someone else, such as our companies. Most people just happen to start programming in Java for instance, and just follow the flow into something else they get throwed upon without actually having put some thought on whether that is that right thing to do or if it is what they want.
This chapter is all about risk and reward. In most life situations we find ourselves in, the biggest reward requires the highest risk being taken, and it’s no different in software development. The author compares Java(high risk) with COBOL(low risk) in the past: knowing COBOL would certainly get you a stable job, there was market for every COBOL programmer back then, whereas Java was a complete uncertainty, who knew that Java would become the most used programming language nowadays? Investing on Java back then was risky, but the people who did it sure got a huge head start and probably found success. These things are happening all the time, the investors in Java had a hunch that it could lead somewhere, it wasn’t, of course, a complete shot in the dark. It’s your job to keep an eye out for new things in the market that might have a future and possibly invest on them.
Supply and demand is the basic market factor: if there are more people supplying a product than there are people demanding it, the product’s price will go down in an attempt to sell the product by any means or to make the product more obtainable. Not surprisingly, this happens in software development, and it’s called the offshore market. In India, there are thousands of programmers willing to do the same job as you for much, much less, and this is attractive to software companies. It sounds like a nightmare, but it can be dealt with.
When choosing a technology to work with, you have to consider the supply and demand factor. Is your technology abundantly used in the offshore market? If so, the only way to compete is by going way up by supplying quality work. Or you can exploit market imbalances. The offshore market doesn’t risk much, the mass only works with stable and commonly used technologies, so if you manage to always avoid the mainstream, your product (skills) will be more valuable since the supply won’t be that big. As the author points out:
“You can’t compete on price, in fact, you can’t afford to compete on price.”
Business domains should have the same importance to you as your programming technologies, if you are to be a coding robot, the offshore market is there to beat you, so knowing what you’re getting into is a huge investment. Wouldn’t it be easier if you were developing a real estate application and you knew how the whole real estate business works? Aside the fact that you’d know exactly what you’re doing, it becomes easier to even deal with clients because you’d have no trouble understanding what they want or why they want it, and better, by understanding the process it would be easier to guess what the client wants and suggest things, which would result ina huge confidence gain.
As unlogical as it may sound, this is actually important. By telling you to be the worst in whatever group you’re in, the author is not telling you to suck, he’s telling you to always look to work with people who are way better than you. As the author states (as I’ve never been able to experience this), being in a group of people who are alot better than you tunes you up to their level. It makes sense, I mean, if you’re seeing a bunch of well developed code, you will want to code the same way, and eventually will. This also helps you not to underestimate yourself due to fear, sometimes you let go of an opportunity because you think you can’t handle it, and overcoming that fear will just show you that you’re not that bad at all.
Take your time to learn new things. Be interested in knowing everything there is to know in the software development industry. Invest in yourself, in your skills. Don’t just wait for an opportunity of learning, go after it. Trust me, this will be the main difference between you and the other job applicants who only know a single technology, concept or methodology.
The chapter title refers to the fact the parents often give you fear-driven advice, they want you to turn out OK, which means not losing . As mentioned in the Introduction section, this is not the way to go. Fear-driven decisions are often taken for comfort, it’s more comfortable to chose a low-risk technology, it’s more comfortable to stay at the same job until the end, etc. This pattern will not lead you on a remarkable career. A great software developer takes risks (as mentioned in the first chapter) and is often changing jobs to have a global vision of the software industry. Beware of fear-driven advices/decisions, they will only hold you back on your path to remarkability.
The author starts this chapter with a comparison that is often made between software and manufacturing, where employees are specialists and just sit at their place in the assembly line waiting for their turn to do their share of the work. As I’ve read in the Head First OOA&D book, there is only one constant in software development, and that’s called change. You can’t possibly compare software to manufacturing because software is malleable and needs to be retunned all the time. Thus, an employee shouldn’t just know one piece of the puzzle and just sit back when his job isn’t needed, he should fix a problem when a problem appears, regarding any part of the ‘software assembly line’, this includes climbing up or down the career ladder when needed, knowing multiple operating systems and administrating databases, setting up environments and getting to know the business, etc. Be sure to be the guy your boss first asks for assistance when something goes wrong.
Dead simple: be the authority at whatever you do. If you claim to be a specialist, then be, in fact, a specialist. Know every single detail there is to know about what you do, be the person to whom other people ask for help regarding the subject you’re the master in and the person who can solve any problem regarding that subject.
Don’t invest all your work at a single technology or a specific software implementation, by doing this you’re like to fall when what you’re depending on falls too, aside from the fact that you’re limiting your knowledge to a single purpose. Be a Web developer, not a Rails or a PHP developer.
Be passionate about your job. Period. You won’t be great if you don’t love what you spend half your life doing.
Part II – Investing in Your Product
This section covers some strategies that you can take to invest on your career, which means, basically, getting better at what you do. Just going to work everyday is like practicing something, it’s important and it gets your sharper, but it only goes so far to what you already know, so the important thing is to always keep learning new things so you can practice those things and eventually become a master.
The title obviously refers to the famous saying “Give a man a fish, feed him for a day. Teach a man to fish, feed him for a lifetime”, difference is, you shouldn’t wait to be taught, you should go after the information by yourself, this is where the learning comes in. Problem is that most people don’t want to learn, they just hand over the responsability to someone else “oh, that’s not me, I’m not the one responsible for that, talk to that guy”. You can’t take the risk of depending on someone to do your job, I mean, aren’t you supposed to be the expert? Go learn at least the basics of things that surround your work, know how and why it’s done.
It was mentioned that it is important to wisely choose your business domains, but as crucial as the choice is, so in the investment on it. Learn how your business works bottom through top, know what the finance people are talking about when you overhear them, read a book on financial business, and, most importantly, know how your work influences the business you’re in.
At least in my case, finding a mentor was the crucial thing. Having someone to guide you to the right path can be very helpful in many ways. First, you will always have an incentive of getting better, because that person that knows more than you will open your head to alot of things you hadn’t even thought about. Second, a mentor will structure your learning, pointing you to a direction where you can the kick off and continue by yourself, there’s a lot of skills you could be learning, but only a few that you actually will learn. Third, your mentor will get you connected with even more people that could get you a wide set of opportunities. Don’t that finding a mentor is a sign of weakness, from what we seen, it’s a least a smart move. The author states:
It’s OK to depend on someone, just make sure it’s the right person.
Teaching is the best way to learn, it’s been proven by science, and I do it all the time. Whenever I want to know if I really know something, I try explaining it to someone else, even if that someone isn’t interested. You sure have experience enough on something, so go teach someone who doesn’t, the best place to start is at a local user group or an online group. Trust me, only good things will come out when you have the intention of helping.
Practicing means stretching your limits, which are bound by the usualness of your work. When you’re coding a real application, you’re not supposed to test new techniques on it, you’re supposed to use the best you’ve got and make it as pretty as possible. This is where practice comes in, here you can test and use all the things you haven’t tried out yet, such as different libraries in your coding language. Another good way to practice is to read a bunch of different code and try to understand them, surely you will learn at least one new technique and wonder why you never thought about it before. Lastly, put yourself to the test, try coding a project with uncommon limitations to see how far you can think and how well you can improvise.
Software development is a process, it’s not just a result, and that process deserves attention, which is, most of the time, overlooked. The types of processes on making good software has been grouped into methodologies, which are often dealt with as tiresome paperwork that are mostly useless. But you can’t run from them, because they are crucial to software development, as said, you can’t just focus on the end product, and like it or not, you are part of the process, so you need to understand it on top of everyone else. In fact, the best way to embrace a certain process is to help implement it, take the initiave, research.
The giants, in this case, are all the programmers that came before you who developed ways of solving much of the same problems as you have. Studying pre-existing code has been formalized by Design Patterns, but that’s not all to it, by seeing what other people have done, you can compare it to your own work and scale yourself in a level of greatness: how well would you solve that specific problem? The first thing I always did was watch people do something people I tried it myself, by analysing what came before you, the harder it gets to fail when doing the same thing, and the easier it is to get better at it.
The main focus here is to avoid repetitive coding and always try to write generators for whatever you do to save time. Want to beat the offshore market? Write robots, I’ll bet they’re faster.
Part III – Executing
The last sections were about making the right choices and investments, but when you come to think about it, you don’t get payed for that. You get payed to create value, which means executing. You can be known as the best coder, but if you don’t get things done and don’t generate the company some money, you’re worth nothing to it. This section will be about delivering the right value to your company.
This chapter mentions a law stated by Parkinson: “Work expands so as to fill the time available for it completion.”. This becomes relevant when you start delaying work just because of the huge time gap you have to do them, whereas you wouldn’t do it if you had no time to do them. I’ll just quote a whole paragraph on this one:
If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell. Create movement. Be the one who pushes. Don’t get comfortable.
Always be the one to ask, “But what can we do right now?
The art of taking good guesses based on the information you’ve already gathered and doing them before someone asks you is greatly appreciated, not only by managers, but by customers too, because it shows you’re really engaged in the process, and that you don’t have to be told what to do all the time. But don’t go too far, remember, it’s the company’s money you’re wasting by doing work nobody asked you to do.
Simple tip: set a number of goals so that you can complete one everyday and report to your manager, and by knowing you have to finish it in a day, you won’t delay it as in to get stuck in the process. Try it, it becomes a habbit.
It’s hard to align your working goals with the company’s goals, it’s just too big a chain and most of the times you won’t even have access to everything or everybody. So the best place to start is your team. The goals of your team are usually the same goals as your manager, so working towards the goals your manager sets is the best way to focus your work. By doing your small part you’ll feel that you’re being useful to your company, it gives you a reason to work.
Ambition is important, but it becomes dangerous when you start focusing more on what you could achieve than on what you should be achieving at the moment. Keeping your mind focused on the process is more important than the goal, in fact, that’s the whole philosophy of software development. By keeping yourself on the present, you’ll enjoy the small things at work, and, eventually, the big one (promotion) will come.
Being recognized as a good worker is always pleasant, but we are sometimes too selective about the things we want to excel at. I mean, who doesn’t want to be known as the guy who designed ‘that huge important system’. The problem is that this kind of work is not that usual in most workplaces, so we should try to excel ourselves in even the boring tasks that often don’t require creativity, and are often treated as not fun. Try to do the most perfect job at everything, and you’ll surely be challenging yourself at every task.
Start thinking about how much you deliver to your company. Basically think about how much you make and double that value, and that’s approximately how much your company is spending on you. Remember that you are an investment, so ask yourself everyday if the work you did was worth that investment.
The title refers to the fact that all of us are just a pebble in the bucket of water that is our company, if you remove one, it won’t make such a difference, and why is that important? Basically, because you’re replaceable, we all are. In fact, we should aim to be replaceable, because when we do the contrary we get so blinded thinking that no one is as good as us that we don’t pay attetion to an iminent fall that could happen at any time.
Programmers usually hate maintenance, and it’s basically because maintenance involves old systems and grumpy users, where in project work you get to start off clean. The good thing about maintenance, though, is that you are only expected to keep the system running, whatever extra work you do will be well-seen. As long as you keep everything running smoothly, you can be as creative as you want and even refactor the whole thing to your tastes. Having the freedom of being a designer, architect, coder, tester and even talking to clients directly (which happens alot in maintenance) can be a very interesting experience, so learn to enjoy it.
A simple concept involves this chapter: the less you work, the more you work. It’s logic, if you work 12 hours a day you won’t be as rested as if you worked 8 because you’d have less time to do every thing else, including sleep. Another thing that a long work journey, your work hour is less valuable, thus, you spend more time doing unuseful things than if you were in a shorter journey being paid the same. On an eight-hour working burnout, you think “I only have 8 hours, let’s finish this!”, instead of “I have plenty of time, gonna go check my email and tweet something”.
The same principles we learn from error handling in programming are applyable to our jobs. The best thing is to encounter and deal with errors early on instead of letting them sum up to a stack. Making mistakes is OK as long as you manage them correctly, and there are a few steps to take to help you: raise the issue as early as you encounter it (hiding it will only make it worse), take the responsability if it is yours to take, offer a solution to the problem and ask for help case you can’t manage to solve it alone. A mistake well handled builds up loyalty between both parties, so take the opportunity to turn something seemingly bad into something good.
Making commitments that you know won’t be possible to meet is a bad thing, in fact, it’s lying. We sometimes do it for a good reason as in to avoid disappointment, but then, at the cost of being a temporarily hard worker that can do anything at any time, you’ll then later be a worker with no word who no one can trust, which turns out to be way worst than if you just say “no, I won’t be able to do that”, because people will know that when you do accept a commitment, you will finish it on time. The same thing applies to “I don’t know”, because when you do say you know when you’ll finish, for example, people will give you more credit due to your past honesty.
The whole deal about panicking is that we focus too much on the problem that’s going on and lose perspective. We think we’ll never be able to solve it and that things will just go wrong all the way down the abyss of darkness. By understanding what panicking is, it becomes easier to dodge it, if you know that a specific problem is happening, instead of focusing all your brain power on it and go nuts, just look at the big picture, your tiny little problem is not even that big a deal, you know you’ll be able to solve it, most of the times it’s staring you right in the face.
Some people hate to plan stuff out. I love planning, sometimes I even plan what I’m gonna do in the next few hours, it’s a habbit. By planning things you spend less time doing nothing and will even get the joy of writing DONE down, it’s always nice to finish something you wanted. Then tell those plans to your manager, along with what you’ve accomplished, by doing this regularly your work will become much more visible to your management and your productivity will be at its top.
Your leaders want you to have independence and ownership. Making, executing, and communicating plans will help you attain both.
Part IV – Marketing…Not Just for Suits
Despite all your knowledge and hard work, if you don’t know how to show all that to the world than it really doesn’t matter to anyone if you’re so good. Showing off your skills is something smart, and necessary. Place yourself in an employer’s shoes, how will he know you will be worth an investment if you are just too “humble” to show him what you can do? And it’s not even that hard to do, all you have to know is how to let people know you exist and that you’re the guy that can solve their problem. This chapter will go into that more closely.
In a workplace, what people think about you matters. It really matters. Matters enough to influence on your salary and on whether you get promoted or not. It’s all based on perceptions. It doesn’t matter what you really are, it matters on which perception your superiors have of you, so if you truly are a hard working person but show up lazy and do nothing, then guess what? But this is all really subjective, each person has a different view of another person, what you have to do is find out the best way to fit well into different perceptions.
Knowing how to communicate is key, it’s what companies look for in any worker nowadays, and you can’t be different. The most important thing about communication is being able to talk with people in a non-computer language. Just because some people don’t get your code-speak doesn’t mean they’re stupid, it means you’re failing in making them understand something that might be important to them. Don’t be a condescending code ogre, you’ll scare your job off.
Learn to write. There’s nothing worse than not being able to express yourself in the form of words, specially when most workplace communications are through text such as e-mails or instant messaging. Most importantly, knowing how to write creates a superficial perception as in how your mind works, if you can’t even organize thoughts into common words then it’s hard to believe that you can do it on your work.
Speaking for myself, the fact that good writing reflects a good mind has proven to be almost an absolute truth. For 5 years I have been a member of a variety of internet forums and the people who always stand out amongst the trolls with dumb opinions were the ones able to write efficiently. Good writing represents a good sense of communication and gives positive perceptions, so learn to write.
Despite the fact that the world is getting more technological by the minute, human relationship is still important in a workplace. Personal contact is the major difference between an onsite and an offshore developer. Humans like working with other humans, so make your work personal, learn about your colleagues and just be there. Most important decisions are made in person, in side conversations or coffee brakes, so take advantage of being present in your workplace.
Businesspeople aren’t interested if you’ve just implemented the latest design pattern in your current project, they’re interested in how that will affect the company’s profit. The catch is simple: translate your accomplishments into something relevant to your business and be ready to talk about them in that specific business language to whomever asks, or else it could just blankly mean a waste of company money to people who aren’t directly in tune with your work.
Have a mission. Make sure people know it.
Be sure that everyone knows what you do in the company, and the best way to do this is to implement changes. Look for things that you think are wrong on your team or that could be better. Be the guy responsible for changing them. Do it because you have to make things better. Don’t just go to work, do what you have to do and then go home. Make the change.
So far we’ve talked about things to do that will get you noticed at your workplace, but you can’t stop there. On some industries it’s hard to spread the word out on something you’ve done, on the software industry, however, we have the internet. Create a blog, write stuff on it (you surely have something to talk about), link it to people. And yes, I am following this advice. Remember, better than having a kickass résumé to show to an employer is having the employer already know you.
A brand is associated with 2 things: recognition and respect. The brand we’re talking about here is you, so make sure your name is associated with something good and that people talk nice things about it, the last thing you want is people referring you because of some dumb thing you said, so be careful with what you’re doing out there.
Contributing to open source projects is a very nice way to get your name on the field. It demonstrates skill, specially if you get involved in a huge project that everybody uses. Wouldn’t you want to hire the guy who helped write the code on the technology you’re using in your company?
This chapter summarizes something that has been mentioned the whole book, which is remarkability. I found no better way to review this than to quote some of the key sentences:
To be remarkable means that something is worthy of attention.
[...] Remarkability means that people talk about you before they are asked.
To be remarkable, you have to be significantly different from those around you.
Most of us are sometimes affraid to make contact with the ones we consider ‘pros’ due to fear, the thing is that these pros have alot to teach and wouldn’t mind answering questions or being thanked for something they did. As the author mentions, ‘Making the Hang’ is this exact connection between an amateur, you, and someone you admire, by doing it you have nothing to lose, quite the contrary, fitting in with the pros is smart (as we’ve seen in chapter 4) so don’t let fear stand in your way on making some professional contact.
Part V – Maintaining Your Edge
What we’ve seen so far isn’t supposed to be done just once, you need to be researching, investing, executing and marketing over and over again, or else you become obsolete. Stagnation doesn’t warn you that it’s coming, it just does and when you’re least expecting, your back on the ground again. This section will cover things that you should do to maintain your remarkable career on its feet.
Technology is always changing, what’s good today might be a piece of junk tomorrow, and the same things happen to the technology industry. You might feel comfortable with something your working today, it’s a good business, you’re making money and all, until it starts being old and things start doing not so good. If you’re not on the edge of what’s happening right now, you’re already in the past, so it’s time to start thinking ahead and gambling your way through new things to see what works. The worst thing that will happen is that you’ll learn something interesting.
This chapter talks about the danger of identifying too much with your job due to the fact that everything is always changing, and that you could lose it at any time or even be moved to a new one. Our industry is not stable because technology is not stable, so neither should you treat your job or plans with stability.
You can’t afford to have tunnel vision with something too far off in the future. If you want to hit a moving target, you don’t aim for the target itself. You aim for where the target is likely to go.
As we’ve talked about, software development is about the process of making something, basically because software is a living thing and is never ‘done’. The same thing should be thought about in your career, if you spend too much time working for an objective, such as a promotion, then you move your focus that should originally be on the work toward those objectives.
It’s how you transverse the path that’s important — not the destination.
Having a road map to what you should do next is the best thing to know if you’re stagnating in your career, if you don’t put things down then you’ll never know if you’ve actually made a change.A brilliant analogy made by the author to understand this concept is by relating your career an application, whereas each set of knowledge would be a feature. By mapping out features, you’re sure that your application won’t keep doing the same things forever, and this is exactly how you should treat your career.
Even after making your choice, it’s important to keep your eyes in the market at all times. While you’re all happy working with some technology you’ve chosen, some big thing could happen that could nullify that choice, and you wouldn’t notice it until it’s too late. You wouldn’t make an investment in the stock market and just leave it be, you’d be careful to watch for every opportunity of making more out of it, and this investment is no different from the one we’ve been talking about throughout the book.
It’s hard to notice change when you’re looking at something everyday, and it’s specially hard to measure something as subjective as your career. The tip here is to make periodical reviews of yourself, using a trusted group of people to discuss your abilites, weaknesses or anything else involving you. The key here is to know your weaknesses, fixing them could work, but knowing them is already a huge leap.
The chapter title refers to a little story the author tells to symbolize the rigidness of the value monkeys give to food, prefering to die in a trap than to let go of it and be set free. The analogy is made to make us understand the weakness that is holding on rigidly to a value without listening to reason. An easy example is a technology choice, you defend it so hard that even when it is clearly the wrong choice for an occasion you just don’t let go. Be careful not to hold on tightly to anything, keep an open mind.
“Waterfall” refers to the term ‘waterfall processes’, that are the type of processes that would try to foresee every single project specification and be inflexible to changes, which tend to happen in every software project. The same thing can be applied to your career as in you shouldn’t treat it as something planned from the beggining to be followed strictly, it should be open to change, in fact, change is necessary. Setting goals is a part of mapping your career, but nothing stops you from making corrections along the way.
As discussed in chapter 49, it’s hard to see change when you deal with something everyday, including progress. Sometimes we kind of give up on something due to the large ammount of effort to make it happen, an effort that makes almost no difference to that something in a small scale. The trick is to be happy with “small ammounts of better”, and always trying to accomplish something more than you did the day before. If you did something that made what you’re working on better than it was yesterday, than that’s already good, big things don’t just happen, they’re built day by day.
The author states the importance of sometimes not working for a corporation. It’s safer to get your fix ammount of money every month or having the comfort of sometimes doing nothing or just taking things slow because you have the luxury to do so, but it slows you down. Working for yourself is the ultimate test of remarkability. It’s the best way to test the skills you’ve honed and to burn out your capabilities because there’s no team to split your work with and there’s no one to blame, it’s all you.
These are all the 53 chapters of the book, the right thing to do now would be to make a conclusion, but, concluding something with no basis of experience, in a book like this, would make no sense. As you can see in the ‘About Me’ page, I’m currently an intern working with Ruby on Rails, a career is something I just started to think about and luckily I’ve something to guide me with. If you are, like me, just starting, don’t miss the chance on buying this book, you’d have to be pretty blind to neglect most of the advice that I’ve tried to cover in this review.
Hope you enjoyed it, and please, comment if you feel the urge to say something, and you must feel that urge after reading this wall of text :P