The ionate Programmer 6c426e

The ionate Programmer : Creating a remarkable career in software development. In 2008, one of my coworkers mentioned a book called My job went to India. I laughed at the funny title. But I did not realize it was written specifically for programmers and simply forgot it. Recently I bought a copy of Andy Lester's amazing Land the Tech Job You Love and immediately landed a new job partly by following the advice in that book. Andy finished his book by suggesting another book called The ionate Programmer. I looked in Amazon and found that this is the same book as My job went to India, but the title has changed in the second edition. With a recommendation from a coworker and then Andy Lester, it was now easy to make up my mind to order a copy. It did not take very long to understand why I have received two such strong recommendations about the book! It stands in the same row as The Pragmatic Programmers: From Journeyman to Master. The only difference is, Pragmatic Programmers is about programming and ionate Programmer is about the programming career. You cannot ignore such a book. So I read it a second time. And then I decided to summarize the book for future reference. The rest of this writeup is my summary of this great book. ionate Programmer has an important subtitle - "Creating a remarkable career in software development." So what is a remarkable career? According to section 54 (Remarkability), "remarkability means that people talk about you before they are asked." Think about Guido Van Rossum, Martin Fowler, David Heinemeier Hansson or Dries Buytaert. People regularly talk about them or their creation. That is remarkability. ionate programmer is arguing that we're all looking for happiness. Once we have our basic human needs like food and shelter taken care of, most of our goals are geared toward finding happiness. Happiness depends on many factors in life and not just one's career. But we all spend a lot of time at work. So work is a major factor in happiness and a remarkable career thus becomes a vital component of our happiness. That is why we should seek a remarkable career. This all sounds good. I do not fully agree with the subtitle of ionate Programmer though. When I finished the book, I found that most of the book material is geared towards being successful at one's workplace. In my opinion, that does not really equate to being remarkable. There are some tips on being known for your work in the outside world, but the major portion of the book is about being a highly successful, efficient, up-to-date, and valuable staff member in the IT department. The subtitle of the first edition of this book was "52 ways to Save Your Job." That theme still dominates the second edition. It does, however, tells you the best bit about the remarkable programmers. They are knowledgeable and they have put their knowledge to use to make a dent in the world. David Heinemeier Hansson says best in the foreword - I hate the feeling that my presence doesn't really mater and that the world would have been exactly no different in a meaningful way if my work hadn't been done. To become remarkable, you have to believe that you're making a significant dent in the universe. I have some doubt that when Guido (or say Gandhi) started his work, he was doing it to be remarkable, It is more likely that remarkable people want something that they think society

should not live without, and then they work tirelessly to make it happen. What they achieve does more good to the world then themselves and that makes them remarkable. So the recipe is - do something that the society needs and work really hard to achieve it even if you do not have to go that far for your personal benefit. If Linus Torvolds had stopped adding device drivers for hardware he does not own, I doubt Linux would have been this much successful. ionate Programmer briefly touches the subject of helping Open Source projects and writing books. But most of it is about helping yourself. After all, ionate Programmer is a self-help book. But my idea is that remarkable people become remarkable not only by helping themselves but also helping everyone else (although not always by intention :). So a better subtitle for ionate Programmer would have been "Creating a HIGHLY SUCCESSFUL career in software development." And as a book on achieving a highly successful software development career, it is only full of good advice. What follows is my summary of these good advices. [Note: All quotations from ionate Programmer are wrapped in quotation marks below. Everything else is my own comment.]  

  

  





Love it or leave it. ionate Programmer expects you to be ionate about software development. If you are not, then you're probably in the wrong profession. Treat your career like a product. o Choose your market. Decide that you want to be an expert on Foo. o Invest in your product. Gain expertise on Foo. o Execute. Use your expertise on Foo at work. o Market! Make sure everybody knows you are The Foo expert. Be a generalist. Learn lots of things. For example, if you know Apache, learn IIS as well. If you are a programmer, learn some system istration too. Be a specialist in at least on technology (e.g. Drupal). A single minded investment in one particular technology is almost always a bad idea, if you must do so, consider focusing on an open source option, as opposed to a commercial one. You can choose to either be a leader or manager type or be a technical person. Learn the business rules of your organization even if nobody tells you to learn these. Learn how the tools work even if nobody tells you to learn these. For example, if you are using the Zend PHP framework, try to understand how the framework itself functions. If you know how the business works, you can suggest new use of software to increase the efficiency of the business. For example, my current workplace runs lots of events and attendees have to book a place before attending. One of my coworkers recently introduced the use of bar code scanners for keeping track of which people are actually attending. He also wrote a small piece of software to integrate the scanner with MS Excel. Nobody asked him to do that. He just saw a great use case and went ahead. Everybody loved it at the end ! The good thing about having a mentor is, you can follow their style of doing things and improve yourself easily. Mentors are living examples and it is a lot easier to learn by example.

   

     



 



 



A good way to learn things is to teach it to others. This is an advantage that comes with mentoring. Musicians, artists, etc. practice a lot. Programmers need to practice outside their jobs too. We have to stop treating our jobs as a practice session. Learn a software development process, e.g. Extreme programming. Study existing code. Styding the work of masters is an essential part of becoming a master. This tip is my personal favourite. Maybe we should have a museum of source code :-) Automate as much of your work as possible. You might be the coolest Z# programmer around, but if you are not good at solving your employer's problems with Z#, you are not really that cool :-( Parkinson's law states that "work expands so as to fill the time available for its completion." especially when there are tasks you don't really want to do. Have an accomplishment to report everyday. Solve your manager's problem, and you've solved a problem for the team. If you are not good at your current role, you won't be good at the next upper level role either. So if you are a bad junior developer, you will also be a bad senior developer. Do not wait to improve yourself until you get the next promotion. One way to get over with boring tasks is to make them interesting! For example, if you have a boring pointy-clicky task to do, why not write a programme to do it? Sure it will take longer, but it will be less boring. Every staff usually costs their employer twice their salary. Ask yourself if you are helping your employer earn a lot more than that. All employees are replaceable. Some are more replaceable than others, but eventually all are replaceable. Some programmers has the tendency to create cryptic systems and then feel that they are irreplaceable. Nothing comes out of it except bitterness. Even in my own experience, people tend to avoid maintenance programming. As long as you're keeping it running and responding to requests in a timely fashion, maintenance mode is a place of freedom and creativity. Maintenance programmers tend to get more exposure to customers. So if you like interacting with lots of people, maintenance is the way to go. It also puts you in a prime spot for truly learning the inner workings of your business. Do not work more than 8 hours a day. But you should work so relentlessly that there is no way that you could continue longer than eight hours. Fail gracefully. we don't judge each other on the mistakes we make. We judge each other on how we deal with those inevitable mistakes. the following four points after making a mistake: o Don't hide the issue, please raise it. o Accept the blame. o offer a solution. If you don't have one, offer a plan of attack for finding a solution. o Do not hesitate to ask for help in clearing the mess. The difference between how a company treats us when they make a mistake can be the ultimate in loyalty building (or destroying).



   

   







   

Do not promise what you cannot deliver. If you are from the Indian subcontinent like me, then that The inability to say "no" happens to be a common part of the Indian culture. Heroes never panic. Have you even seen MacGyver panicking? Be like the heroes when you have landed in a mess. Deadlines actually help us get things done on time. So do not hate deadlines. Prepare a daily plan in the morning. Plans help avoid ambiguity. Sometimes send unsolicited emails to your manager telling them about your plan or what you are working on. People who are managing tend to like this type of inputs. I have tried this on my manager and I can tell that this actually works. If you have a complain, do report it to your manager. But even better, if the complain is accompanied by proposed solutions. Among other things that you learn from a commercial failure, you learn the importance of conserving cash. We all know it, There's a lot more to success in the marketplace than having a great product. So the best programmer is not always the winner. Beauty is in the eye of the beholder :-) Being a good programmer is not enough. You need other qualities too. If I'm a project manager, the quality of your source code is a lot less important to me than the quality of your communication. If I'm a fellow programmer, your raw ability and creativity drives my perception of you more than, for example, your follow-through. Understanding what's important in each of your relationship is an important part of building credible perceptions with those you interact with. Nonprogrammers are, on the average, as intelligent as programmers. There is no reason for them not to be. After all, programmers do not eat any special magic diet that enhances intelligence. So please respect nonprogrammers. They also represents the needs of the business, and you are paid to provided for those needs. Improve your writing skills as written communication is getting more common. You may be a great coder, but if you can't express yourself in words, you won't be very effective on a distributed team. Here might be a gem for hiring managers - If you can't organize your thoughts in your mother tongue so that others can clearly understand them, how can we expect that you can do it in a programming language? The ability to shape an idea and lead a reader through a thought process to a logical conclusion is not much different from the ability to create a clear design and system implementation that future maintainers will be able to understand. Have as much face-to-face communication with others involved in the development of your software project. If that is not possible, talk to them over the phone. Try to be known outside of your company for your excellence. Write blogs, give presentations at local technical meetings and even better in large conferences. Having Open Source code under your belt is an excellent way to move up the social chain of the programmer community. The subtitle of the book is "Creating a remarkable career in software development." So what is remarkability? Remarkability means that people talk about you before they are asked. Think of Dries Buytaert. Releasing successful Open source software, writing books and articles, and speaking at conferences may all increase your

 

  





remarkability. All of these involves actually doing something as opposed to just reading or watching others. just being good isn't enough. You have to be doing. It is okay to be goal oriented. But only Focusing on the ending makes you forget to make the process good. And, bad processes create bad products. Have some kind of roap. For example, over the next year, I will learn X, Y, and Z which will make me a better Foo developer. However, do not hesitate to amend the roap based on your ongoing experience. Keep a close eye on technology news. This will help you to catch the next wave (e.g. Java in the late 90s). Ask others to do a review of yourself. That will tell you of your growing weaknesses. There is a good story about South Indian monkeys in section 50 called "The South Indian Monkey Trap". It is from Zen and the Art of Motorcycle Maintenance. I have heard of this book many times before, but now I have ordered one. I hope the whole book will be as good as this story. The summary of the story is, we might have some strong beliefs which could be the cause of our downfall. Many Linux s would put Linux on the desktop of every receptionist, office assistant, and corporate vice president with no regard for the fact that, in of usability, the toolset just doesn't compare to much of the commercial software that's available for a commercial operating system. You look foolish and make your customers unhappy when you give the right software to the wrong people. When faced with seemingly unsurmountable tasks, use the divide-and-conquer strategy. think about doing better in your efforts toward that goal than yesterday. Say you need to write fifty unit tests which is a large task. If you decided to go from zero to fifty tests on the first day of your improvement plan, the first day would be hard, and the second day probably wouldn't happen. There is a fair chance that the safety blanket of corporate hierarchy slows you down. So to be remarkable, Go independent! Becoming an independent contractor is one of the ultimate tests. Going independent is hard. And I can tell you from my limited experience of freelancing that it is indeed hard. But then, no pain no gain :-( A compromise would be to work for a startup. If you currently work for a big company, consider ing a small one. If you work for an established company, try a startup.

That's all. So ask what impact you are having on the world? A remarkable career should provide a happy answer.