Many software projects get delivered late, if at all. Why? Because we programmers waste a lot of time and energy. We also put our health at risk for repetitive strain injuries (or RSI) without being aware of it. Pain in the hands, wrists, forearms, neck and shoulders is common among programmers. I struggled with RSI for a year and half and finally managed to recover. And that’s what inspired me to write this book: to share what I’ve learned over 14 years of my professional experience to help you:
•Become a better and more productive programmer •Write better code in less time •Maintain your mental and physical health
In particular, you’ll learn:
•Common productivity killers amongst programmers •Real world examples of successes and failures •Simple tips that you can apply immediately to increase your productivity •Techniques to stay focused and minimize distractions •Ergonomics, posture, and exercises to prevent injuries at work or reduce your pain if you’re already suffering •How to build better relationships with your employer and coworkers
The Blueprint for a Productive Programmer is a short, easy read with pragmatic suggestions that will be useful regardless of the platform you use and your level of experience. Whether you’re a pro with years of experience or just starting out in the field, you’ll benefit from these tips. Reading this book may take less than one hour of your time, but will save you months and years of frustration.
Well, it wasn't bad but most of the stuff was obvious and known to me. Book gives you small tips to be more productive but most of the tips given cannot be implemented or possible most of the times like breaking tasks into smaller 40 minutes tasks, meetings into 30 minutes quick discussions, increase typing speed just to show off, take a 10 or 15 minute break every 40 minutes etc.
How choosing carefully your tools, environment and software paradigms can increase your productivity as a programmer and how some bad habits in coding can decrease the quality of your products. The author gives also other techniques to stay focused and minimize distractions and reduce health risks (especially repetitive strain injury risk).
This book included a few useful tidbits here and there. The writing felt a bit unprofessional, especially toward the end when I started to feel like I was drowning in exclamation points, and I think the error rate -- not very high throughout the book, overall; in that respect, the editing seems good -- increased toward the end.
The highest density of good advice seems to be at the beginning of the book. Some of the book's advice seems like it should be very obvious, but I suppose not many people actually do pretty much anything the book advises, so perhaps it's needed anyway. Some of the advice is very context-dependent, and may be inappropriate in some circumstances. Some is downright questionable, and outright wrong for large percentages of the time.
One interesting case is the way the author asserts the universal importance of having exactly one point of focus at a time. This is generally a great idea. The real world, however, sometimes intrudes. For instance, in some organizations, not addressing a bug the moment you find it means it never gets addressed. Sometimes, things the author admonishes against doing when you find the problem because it distracts from the task in front of you are actually useful for helping you complete a task. For instance, refactoring a body of messy code is sometimes necessary to even understand it well enough to change it without breaking the whole application, but the author says you shouldn't refactor until after you're done adding a feature; sometimes, refactoring makes it easier and faster to add a feature. I once implemented a feature in an application mostly by refactoring and adding a couple UI elements -- and that's it. Sometimes, a bug in your code that the author would tell you to put off fixing until later would actually prevent the implementation of the new feature you're supposed to add now.
Without going into excruciating detail, fisking the entire book, I'll just say that there's some very good stuff in here, but there's also some stuff that is potentially counterproductive in almost all scenarios. Let the reader beware.
On the plus side, it's extremely short, so if you're good at thinking through the details and recognizing when advice isn't ideal, the time investment is low compared to the value gained from the good points.
To be sincere I wasn't expecting much from a so small book, I was thinking: How is it possible that the author can commit to so many details in so few pages? And surprise for me, he did it. And in a way so clear and easy to understand that really made my day. Awesome book and would say, if you are someone starting on the computer science area or someone with already some experience, this is a must read book. You won't get technical details, but more a set of helpful tips on being more productive, organized, efficient and the cherry on top of the cake, your health. Thank you for the great book.
Even two pages of a summary could be written as one page. Read that one and safe time to be more 'productive coder' and do/learn other more informative/useful things.