biss boutiques-francophones Learn more snsflyour Furniture All-New Kindle Paperwhite Own the 2016 GRAMMY Nominee Album featuring the Biggest Hits from Music's Biggest Night s Tools ca_ty_gno

Customer Reviews

4.5 out of 5 stars11
4.5 out of 5 stars
5 star
4 star
3 star
2 star
1 star
Format: PaperbackChange
Price:$35.22+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on January 13, 2013
This book is an overview of the experience acquired by the author while he faced difficult situations. He often criticizes his young developer's attitude and/or actions when he looks back at situations with his current experience. It's about acting with profesionalism even in complicated and difficult situations.

Don't expect to find code. If you're looking for good pratices as a coder, I recommend Clean Code (from Robert C. Martin) that goes really deep into code and cover good/bad practices of almost every thing (from naming variables to formatting code or simply by making relevant comments.
0Comment2 of 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on August 2, 2011
I have been freelancing for a few years and this book was a refreshing look at my business. Many of the scenarios described in this book are true to life and things I have been through before. For the remainder, the lessons will certainly benefit my business. I've already changed my methodology for doing estimates after reading this.
0Comment1 of 1 people found this helpful. Was this review helpful to you?YesNoReport abuse
on June 6, 2015
His advice to work 40 hours and then study 20 hours a week may seem controversial, but it is a goal that I have been trying to hit for the past year. Simply put, it has completely changed my life and my abilities as a programmer. I wish I had received this advice 10 years ago.
0CommentWas this review helpful to you?YesNoReport abuse
on February 18, 2014
And the ideas in this book owe lots to many other great developers. Bob Martin has synthesized the core of the best practices of professional programmers in this essential book for all serious professional developers.
0CommentWas this review helpful to you?YesNoReport abuse
on April 21, 2015
Uncle Bob gives really good advises. It's a must read for every developer who wishes to ever become a professional in the Software development field. This book almost reads itself. Superb purchase.
0CommentWas this review helpful to you?YesNoReport abuse
on June 16, 2014
The book summarizes what every junior programmer should know. It reinforces what should be common sense and provides excellent advice.
0CommentWas this review helpful to you?YesNoReport abuse
on July 14, 2015
An excellent book for both the experienced and novice programmer. Insightful thoughts and a great read.
0CommentWas this review helpful to you?YesNoReport abuse
on February 3, 2016
Not done yet - half way only - but already impressed.
0CommentWas this review helpful to you?YesNoReport abuse
on August 7, 2014
Buy this book. Period.
0CommentWas this review helpful to you?YesNoReport abuse
on July 29, 2011
According to the subtitle, this book tries to define and advise on professional software development conduct. With this in mind, the title of the book sounds somewhat peculiar since there is more to professionalism in software development than being "clean", in any sense of the word.

The first chapters (Professionalism, Saying Yes/No, Coding) are the more interesting part of the book. In the chapter on professionalism, the author brings up the important concepts of individual responsibility, striving for defect-free outcome, the need to dedicate to the employer or client the time paid by the employer/client, the do-no-harm principle. Some of these topics deserve deeper treatment, however. For example, the do-no-harm principle is described in the context of structure and function of software. There is no mention of doing no harm to public, employers or colleagues (is coding and distributing a virus professional?). The author speaks about minimizing bugs, but there's no attempt to define or treat software quality in a more general way. Communication with management gets a bit digital coverage (Saying Yes, Saying No).

In the second part of the book the author gives advice on professional developers' practice. The advice is often questionable, however. A few examples:

- In the section on Test-Driven Development the author claims that the only way to achieve testability is to write tests first. While this probably works, we are not given any explanation as to why would this approach be the best or the only one. The TDD criteria could have been listed with more clarity: one needs to write unit tests first but should not write more of a unit test than it is sufficient to fail, and not compiling is failing. This begs the question whether anything that does not compile is a sufficient unit test to "allow" one to start with deliverable code?

- The author recommends constant changes to keep the code flexible, as if the code text is somehow going to become rigid if left alone. In reality, any change has more potential to introduce defects than no change, no matter how thoroughly we test, and this needs to be factored into the judgement call on whether something should be changed or not.

- In the author's words, the primary purpose of testing is actually documentation, in particular requirements and API documentation. This is in contradiction with the generally accepted view of testing as a way to uncover defects.

- Another unusual idea is that "exploratory testing", which happens without test plan, is the one that is supposed to confirm the expected behaviour of the system.

- When advising to overcome "writers' block" by finding a pairing partner, the author does not consider that this way of unblocking may effectively block the pairing partner.

The section on tools seems off-topic as the author himself explains that his intention is mainly to define his favourite tools. There definitely are tool selection, evaluation and recommendation considerations that are very relevant to professionalism, but they are not mentioned here. Yet, this section is not without controversy - the advice on two-tiered version control, with "enterprise" version control system that satisfies the management and "developer-friendly" system that meets developers' needs seems detached from the realities of configuration management on a software project of any significant size.

The the book is organized into loosely related chapters that do not appear to form a cohesive whole with the beginning and end. The book starts with the story of Challenger shuttle disaster, but the author does not relate this story to professionalism in software development in any way. The ending is abrupt and with no conclusion - the description of the author's workstation looks out of place.

This book should be credited primarily for an attempt bring into focus the complex subject. The treatment however is shallow and the advice too often sounds subjective and unsubstantiated.
0Comment6 of 13 people found this helpful. Was this review helpful to you?YesNoReport abuse