What do you think?
Rate this book
Robert C. Martin Series
The Clean Coder: A Code of Conduct for Professional Programmers
Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common They care deeply about the practice of creating software. They treat it as a craft. They are professionals. In The Clean A Code of Conduct for Professional Programmers, legendary software expert Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing. It covers much more than It is about attitude. Martin shows how to approach software development with honor, self-respect, and pride; work well and work clean; communicate and estimate faithfully; face difficult decisions with clarity and honesty; and understand that deep knowledge comes with a responsibility to act. Readers will learn Great software is something to marvel powerful, elegant, functional, a pleasure to work with as both a developer and as a user. Great software isn’t written by machines. It is written by professionals with an unshakable commitment to craftsmanship. The Clean Coder will help you become one of them–and earn the pride and fulfillment that they alone possess.
210 pages, Paperback
First published January 1, 2011
1,001 people are currently reading
15k people want to read
About the author
Robert C. Martin
62books1,846followersRobert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 671 reviews
May 3, 2013
Uncle Bob is again extreme and depicts a person, who is our asymptotical goal, not something anybody can achieve.
The super-human (a.k.a. The Clean Coder) is always responsible for her actions, can say No even in the toughest times and to the toughest managers and clients, sleeps at least 7 hours per day, spends 20 hours per week for her personal professional development, regularly does programming kata, does TDD 100% of the time, doesn't write features unless there are acceptance tests, doesn't need the zone, cares about the business goals as much for the technical quality, writes checks if she caused problems, refactors mercilessly.
In a couple of places Uncle Bob mixed up levels of abstraction and implying implementation details (TDD), when the higher goal of having working code should have been the primary focus. Also, some of the stories weren't the best examples. 70s were different times :-)
In general I liked it a lot. Learned a few things, but I had heard the most in some form before. It's good recommendation for friends, though.
The super-human (a.k.a. The Clean Coder) is always responsible for her actions, can say No even in the toughest times and to the toughest managers and clients, sleeps at least 7 hours per day, spends 20 hours per week for her personal professional development, regularly does programming kata, does TDD 100% of the time, doesn't write features unless there are acceptance tests, doesn't need the zone, cares about the business goals as much for the technical quality, writes checks if she caused problems, refactors mercilessly.
In a couple of places Uncle Bob mixed up levels of abstraction and implying implementation details (TDD), when the higher goal of having working code should have been the primary focus. Also, some of the stories weren't the best examples. 70s were different times :-)
In general I liked it a lot. Learned a few things, but I had heard the most in some form before. It's good recommendation for friends, though.
December 28, 2015
There is a tons of similar books in the market. The most remarkable one is "Pragmatic Programmer" by Andy Hunt and Dave Thomas. Both books cover pretty similar set of topics -from design aspects to some specific practices. The main difference between them that "pragmatic programmer" covers broader set of topics and with much more depth.
I see few issues with "The Clean Coder":
1. Tons of useless stories from authors' personal life.
In most cases they're not that relevant to chapters' topic and almost all the time they just too long
2. Book about perfect "coder" and dump manager
Throughout several chapters you can see similar discussions between manager and developer where manager tries to enforce deadline that should be achieved by all means by sole developer. In many cases author assumes that “coder� should be patient, wise, should know about different planning practices and drive the business.
3. Lack of coding practices
The title of the book assumes that regular developers are the target audience of the book. But this book has only one chapter devoted to coding (chapter 4) but that chapter does not cover any coding practices or coding related topics. NOTHING!
4. Tons of repetition
Book contains at least 3 places with almost identical paragraphs about FitNess. Some stories are repeated for more than one time. I know that DRY is a very hard principle, but repetition of some irrelevant stuff does not sounds professional.
5. Arrogance and lack of arguments
In some cases there is no arguments that proofs some authors� thoughts. For instance, author claims that everyone should strive for 100% code coverage, use TDD and pair programming all the time. I do value reasonable code coverage, good design and automated tests and do believe that pair programming is useful. But 100% code coverage is harmful, TDD as a practice is subjective (artifacts of this practice is not, but no one should enforce how those artifacts would be produced) and pair programming is only useful in certain circumstances.
This book is relatively small and if you’ll exclude almost useless narratives you’ll get very small set of topics to think about. There is plenty of books with much better quality (like “Pragmatic Programmer�) that will really encourage you and will open your “coder’s� mind much better.
More thorough review in russian:
I see few issues with "The Clean Coder":
1. Tons of useless stories from authors' personal life.
In most cases they're not that relevant to chapters' topic and almost all the time they just too long
2. Book about perfect "coder" and dump manager
Throughout several chapters you can see similar discussions between manager and developer where manager tries to enforce deadline that should be achieved by all means by sole developer. In many cases author assumes that “coder� should be patient, wise, should know about different planning practices and drive the business.
3. Lack of coding practices
The title of the book assumes that regular developers are the target audience of the book. But this book has only one chapter devoted to coding (chapter 4) but that chapter does not cover any coding practices or coding related topics. NOTHING!
4. Tons of repetition
Book contains at least 3 places with almost identical paragraphs about FitNess. Some stories are repeated for more than one time. I know that DRY is a very hard principle, but repetition of some irrelevant stuff does not sounds professional.
5. Arrogance and lack of arguments
In some cases there is no arguments that proofs some authors� thoughts. For instance, author claims that everyone should strive for 100% code coverage, use TDD and pair programming all the time. I do value reasonable code coverage, good design and automated tests and do believe that pair programming is useful. But 100% code coverage is harmful, TDD as a practice is subjective (artifacts of this practice is not, but no one should enforce how those artifacts would be produced) and pair programming is only useful in certain circumstances.
This book is relatively small and if you’ll exclude almost useless narratives you’ll get very small set of topics to think about. There is plenty of books with much better quality (like “Pragmatic Programmer�) that will really encourage you and will open your “coder’s� mind much better.
More thorough review in russian:
September 24, 2013
Mostly this book is pretty good. It's a series of anecdotes from the author's lifetime of working in the software industry. They are reminiscent of things you might see on thedailywtf, but they are followed up with an explanation of what the correct response to each situation would be. This actually makes the book more readable than the previous one in the series, which was much more technical. It also makes it rather harder to apply to one's own life. It's not just a matter of running down a checklist of code style points anymore. I guess overall the reader is left with a sense of the 'right' way to handle business interactions, but I fear it might be very quickly forgotten if he doesn't read it again and take notes.
It's interesting that many of the examples feature miscommunication caused by someone using ambiguous language to avoid a confrontation. E.g. the boss insists the programmer finish the projecy within a week even after being told this is impossible, so the programmer says he will 'try to do that'. The boss hears what he wants to hear and goes away. The author considers this morally the same as lying. I think in England this use of language to avoid conflict is actually seen as a virtue, so I doubt we can stop doing it, but maybe he is right and we should be more direct.
Of course I'm not convinced that project estimates are really the thing that should have been used in all the examples of programmers sticking to their guns against bosses, because I think the bosses must know that estimates are frequently out by a factor of ten and so it's not completely ridiculous to expect the programmer to shorten his estimate.
There is one problem which runs throughout: the nebulous definition of 'professional'. The reader is constantly reminded that as a professional he ought to be autonomous and not afraid to say no to his boss when he knows more than the boss, or when asked to do something 'unprofessional'. Comparisons are made to doctors and lawyers. The problem is that these professionals are self employed. They are hired by clients but do not work for bosses. While it is possible for a programmer to be a self employed consultant in the same way, it is not the norm, and all of the examples featured in the book are programmers who are employees. There are examples of developing software for clients, but the programmers here are still employees of a consultancy firm and not directly engaged by the clients.
The confusion is worst in the first chapter, which almost made be abandon the book. The author seems to have completely bought into the propaganda used by American capitalists to justify treating their employees like shit. He tells us that we have a duty to work 60 hours per week - because we are 'professionals' and hence owe it to ourselves - but that since we are professionals we are also responsible for our own well being and hence we have no right to expect any sort of benefits from our employer. Basically, he is expecting the wage slaves to work with the same fervour as the owners of the business. An excellent example of the truism "Socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires."
It's interesting that many of the examples feature miscommunication caused by someone using ambiguous language to avoid a confrontation. E.g. the boss insists the programmer finish the projecy within a week even after being told this is impossible, so the programmer says he will 'try to do that'. The boss hears what he wants to hear and goes away. The author considers this morally the same as lying. I think in England this use of language to avoid conflict is actually seen as a virtue, so I doubt we can stop doing it, but maybe he is right and we should be more direct.
Of course I'm not convinced that project estimates are really the thing that should have been used in all the examples of programmers sticking to their guns against bosses, because I think the bosses must know that estimates are frequently out by a factor of ten and so it's not completely ridiculous to expect the programmer to shorten his estimate.
There is one problem which runs throughout: the nebulous definition of 'professional'. The reader is constantly reminded that as a professional he ought to be autonomous and not afraid to say no to his boss when he knows more than the boss, or when asked to do something 'unprofessional'. Comparisons are made to doctors and lawyers. The problem is that these professionals are self employed. They are hired by clients but do not work for bosses. While it is possible for a programmer to be a self employed consultant in the same way, it is not the norm, and all of the examples featured in the book are programmers who are employees. There are examples of developing software for clients, but the programmers here are still employees of a consultancy firm and not directly engaged by the clients.
The confusion is worst in the first chapter, which almost made be abandon the book. The author seems to have completely bought into the propaganda used by American capitalists to justify treating their employees like shit. He tells us that we have a duty to work 60 hours per week - because we are 'professionals' and hence owe it to ourselves - but that since we are professionals we are also responsible for our own well being and hence we have no right to expect any sort of benefits from our employer. Basically, he is expecting the wage slaves to work with the same fervour as the owners of the business. An excellent example of the truism "Socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires."
August 26, 2018
Review: The Clean Coder � and why I don‘t like it
Robert C. Martin as an author is probably most known for “Clean Code�
which is nowadays seen as a must-read for new colleagues.
His book “The Clean Coder: A Code of Conduct for Professional Programmers� from 2011 looks at another perspective of today’s coding and tries to teach “what it means to behave as a true software craftsman�. In my own words: the social aspects of the daily work of a programmer.
What I like about the book
The real life stories of Martin reaching back into the 70s give a view into what it was like to be a programmer in those times � and how much more manual work it involved. Furthermore, he is open about how he failed and why.
I like the general idea of the chapters “Saying No� and “Saying Yes�. This is something important to learn. However, the examples are very artificial and hard to generalize...
Why I don’t like the book
Basically, I have 3 main complaint points about this book. Please be aware that they are my subjective opinion and bound to my everyday situations and experience as a Product Owner.
1. I think the author sees Agile as a process to improve development and developers, not a way to change companies into a more human-centric and successful place. In particular, the book does not even go into the direction of Scrum mechanisms to cope with typical situations between stakeholders and development teams.
2. the examples for talks between “management� and “coders� are so extreme that I would rather change the project than recommending any technique to deal with these kind of unrealistic expectations.
3. the book does not teach any techniques of reflection, how to give feedback, how to deal with conflicts, how to communicate, not even a slight bit of psychology. For me, this is a main aspect that every developer should look into. Personally, I benefited the most from learning about these.
Summary
To be honest, I think the whole learning point of this book could be brought down to 2 blog posts of maybe 10 pages with lots of links to people who explained the details much better than Martin. And 2 statements to keep in mind.
For a beginner, this book might be suited. Talking to your colleagues works much better, in my opinion.
Blog Post 1
These are the 10 things you should think and read about as a professional software developer
Blog Post 2
Why I failed in my professional software developers life and what I learned from it
Statement 1
Say NO when you would like to say maybe
Statement 2
Usually, a YES comes with a set of conditions. Make them transparent.
Robert C. Martin as an author is probably most known for “Clean Code�
which is nowadays seen as a must-read for new colleagues.
His book “The Clean Coder: A Code of Conduct for Professional Programmers� from 2011 looks at another perspective of today’s coding and tries to teach “what it means to behave as a true software craftsman�. In my own words: the social aspects of the daily work of a programmer.
What I like about the book
The real life stories of Martin reaching back into the 70s give a view into what it was like to be a programmer in those times � and how much more manual work it involved. Furthermore, he is open about how he failed and why.
I like the general idea of the chapters “Saying No� and “Saying Yes�. This is something important to learn. However, the examples are very artificial and hard to generalize...
Why I don’t like the book
Basically, I have 3 main complaint points about this book. Please be aware that they are my subjective opinion and bound to my everyday situations and experience as a Product Owner.
1. I think the author sees Agile as a process to improve development and developers, not a way to change companies into a more human-centric and successful place. In particular, the book does not even go into the direction of Scrum mechanisms to cope with typical situations between stakeholders and development teams.
2. the examples for talks between “management� and “coders� are so extreme that I would rather change the project than recommending any technique to deal with these kind of unrealistic expectations.
3. the book does not teach any techniques of reflection, how to give feedback, how to deal with conflicts, how to communicate, not even a slight bit of psychology. For me, this is a main aspect that every developer should look into. Personally, I benefited the most from learning about these.
Summary
To be honest, I think the whole learning point of this book could be brought down to 2 blog posts of maybe 10 pages with lots of links to people who explained the details much better than Martin. And 2 statements to keep in mind.
For a beginner, this book might be suited. Talking to your colleagues works much better, in my opinion.
Blog Post 1
These are the 10 things you should think and read about as a professional software developer
Blog Post 2
Why I failed in my professional software developers life and what I learned from it
Statement 1
Say NO when you would like to say maybe
Statement 2
Usually, a YES comes with a set of conditions. Make them transparent.
May 26, 2018
I have no idea who this author is and why this book has such a good rating, but the author seems to be pretty full of himself and repeats the same 3 stories over and over again which he seems to find relevant in every situation. He is of the opinion (and his opinions are all over this book without much backing) that coders should be ‘professional� like engineers and lawyers and doctors, which to him means working 60 hours a week, by adding ‘just� 3 hours of self study every day. Do you really think all lawyers work 60 hours a week?
Besides his personal opinions I think this book might only be relevant to you if you’ve been living under a rock for the past decade and only now discovered things like ‘testing� and ‘continuous integration�. The book is basically outdated already and won’t teach you anything if you’ve worked at a modern tech company in the past five years.
Side note; I get that the author wants this book to fit in with his other book ‘clean code� but he should’ve just called it ‘the professional coder� because that’s what this book wants to be about. If you want to be a clean coder just take a bath or something.
Did not finish, refunded.
Besides his personal opinions I think this book might only be relevant to you if you’ve been living under a rock for the past decade and only now discovered things like ‘testing� and ‘continuous integration�. The book is basically outdated already and won’t teach you anything if you’ve worked at a modern tech company in the past five years.
Side note; I get that the author wants this book to fit in with his other book ‘clean code� but he should’ve just called it ‘the professional coder� because that’s what this book wants to be about. If you want to be a clean coder just take a bath or something.
Did not finish, refunded.
January 1, 2018
Chapeau Robert Martin!!
Amazing. Clicked me. It is really fantastic to find yourself saying "Yea, exactly. This is what I was searching for." with every single line you read.
I consider this book the complement or the other face of Clean Code book. Clean code handles the technical side and this one handles the personal one. You need to read them both!
The part I appreciated the most is Practicing and Estimation. Estimation is indeed not an easy task at all. I have faced many hard situations in which estimation was the bottle neck of it.
Also Test Driven Development and Testing Strategies are the fuel for me now to start working with this trend and I have great expectations regarding it.
I highly recommend this book for every developer who wants to be professional - and who doesn't?!! -.
Amazing. Clicked me. It is really fantastic to find yourself saying "Yea, exactly. This is what I was searching for." with every single line you read.
I consider this book the complement or the other face of Clean Code book. Clean code handles the technical side and this one handles the personal one. You need to read them both!
The part I appreciated the most is Practicing and Estimation. Estimation is indeed not an easy task at all. I have faced many hard situations in which estimation was the bottle neck of it.
Also Test Driven Development and Testing Strategies are the fuel for me now to start working with this trend and I have great expectations regarding it.
I highly recommend this book for every developer who wants to be professional - and who doesn't?!! -.
November 14, 2020
A book of work ethics for professional developers.
July 12, 2022
I strongly disagree with the suggestion that the employer has absolutely zero responsibility for their employee's professional development and that as a programmer you need to spend a minimum of 20 hours a week at home doing professional development. An employer who doesn't invest in their people is incredibly short-sighted and (in general) not someone you want to be working for. If he was talking about personal development I might agree, but not professional development that I need to do my job and that my employer needs me to have to continue to be a valuable employee.
For example, I personally spend over 20 hours a week reading (or going to University) for personal interests including philosophy, sociology, feminism, religious studies, minority studies, psychology, etc. Do I consider this professional development? No. Do I think they make me a better employee and possibly a better programmer? Yes, absolutely and without reservation.
I also wonder if 20 hours is really as realistic as claimed. Junior programmers in small business settings can be incredibly poorly paid in relation to what they actually do (I had to hold down 2 jobs and worked 60 hours a week for part of my career). Is it also realistic for single-parent families with children where you have so many other obligations (cooking, cleaning, appointments, clubs/sports, etc.)? Wouldn't that be challenging even for a dual-income family? I have to wonder. This appears to me like a recipe for burn out.
For example, I personally spend over 20 hours a week reading (or going to University) for personal interests including philosophy, sociology, feminism, religious studies, minority studies, psychology, etc. Do I consider this professional development? No. Do I think they make me a better employee and possibly a better programmer? Yes, absolutely and without reservation.
I also wonder if 20 hours is really as realistic as claimed. Junior programmers in small business settings can be incredibly poorly paid in relation to what they actually do (I had to hold down 2 jobs and worked 60 hours a week for part of my career). Is it also realistic for single-parent families with children where you have so many other obligations (cooking, cleaning, appointments, clubs/sports, etc.)? Wouldn't that be challenging even for a dual-income family? I have to wonder. This appears to me like a recipe for burn out.
May 29, 2011
In popular culture, computer programmers, sometimes confused with sysadmins, are often described as teenage punks, sitting in a dark, lit only by the glow of their monitor, empty cartons of pizza and Mountain Dew bottles scattered strategically around, frantically hacking away on their keyboard.
What does it mean to be a professional programmer? Is it wearing a suit and tie to work? Is it having certifications or diplomas decorating the walls of your office? Is it working hard, sometimes overtime and weekends, just to show your dedication?
To Uncle Bob, this is not what professional programmer means. The things commonly mistaken for professionalism, such as a dress code, are not what's important, at the end of the day. Having developers act professionally towards the code and towards each other, however, is.
"Clean Coder" is a collection of anecdotes and stories about the 42-year programming career of Robert Martin, and he shares his rich experience of what it means to be a professional programmer. It's knowing when to say no even to the most persistent of managers, and saying yes by committing to a task, and standing behind your commitment. It's writing the best code possible by not sacrificing any of the principles of good coding practices, even in times of pressure. It's asking for help and helping others, instead of hacking away with your headphones on.
If you value your chosen profession, you should definitely read this book, especially if you are working in less-then-ideal corporate environment - it's up to you to drive changes in your work place, if the settings do not allow you to act professionally. If your company is not using source control - set it up yourself, and make sure to teach your team how to use it. If you're not writing unit tests or waiting for QA to test for bugs - learn how to test your code, so that you'll be able to know for sure that it works. Keep your skills sharp and your tools sharper. That's what it means to be a professional programmer!
What does it mean to be a professional programmer? Is it wearing a suit and tie to work? Is it having certifications or diplomas decorating the walls of your office? Is it working hard, sometimes overtime and weekends, just to show your dedication?
To Uncle Bob, this is not what professional programmer means. The things commonly mistaken for professionalism, such as a dress code, are not what's important, at the end of the day. Having developers act professionally towards the code and towards each other, however, is.
"Clean Coder" is a collection of anecdotes and stories about the 42-year programming career of Robert Martin, and he shares his rich experience of what it means to be a professional programmer. It's knowing when to say no even to the most persistent of managers, and saying yes by committing to a task, and standing behind your commitment. It's writing the best code possible by not sacrificing any of the principles of good coding practices, even in times of pressure. It's asking for help and helping others, instead of hacking away with your headphones on.
If you value your chosen profession, you should definitely read this book, especially if you are working in less-then-ideal corporate environment - it's up to you to drive changes in your work place, if the settings do not allow you to act professionally. If your company is not using source control - set it up yourself, and make sure to teach your team how to use it. If you're not writing unit tests or waiting for QA to test for bugs - learn how to test your code, so that you'll be able to know for sure that it works. Keep your skills sharp and your tools sharper. That's what it means to be a professional programmer!
April 24, 2020
شاید « کلید کدر » رو بشه بیشتر به عنوان یک کتاب « خودیاری » در نظر گرفت تا « تکنیکال ». پر از تجربه، قصه، و حرفها� خوب، اما خب بدون توضیح یا ریزنینگ دقیق در موردشون ( هر چند که به نظرم نیازی هم نیست بهش خیلی ).
اول از همه اشاره کنم که شخصا از خوندن داستان و بیوگرافیطو� آدمای مرتبط خوشم میاد، و خب مشکلی با قصهها� بلند وسط کتابا ندارم، بیشتر حال هم میکن� باهاشون، و خب کلید کدر پُر هست از این قصهه�. به نظرم این قصهه� به آدم دید بهتری میدن� حس خوبی همراهشون میاد و خب میش� تریکه� و روشها� آدمه� رو دید و باهاشون آشنا شد و بعدا به کارشون گرفت. یه بخش خوبی از این مدل تکنیکه� و لایفاستایله� تو زندگی آنکلبا� هست، و خب چه لایفهک� بهتر از لایفهکها� یه پروفشنالی مثل آنکلبا� که حوزه� کاریش یکسانه باهامون؟ چرا نخونیمشون؟ هر چند یه درصدیش از نظرمون منطقی به نظر نیاد یا به تیپ ما نخوره؟ یا حتی اگه تردیدی هم داریم در موردشون خب نخ میگیری� و دقیقت� میری� سراغشون.
و اما بیشتر در مورد خود کتاب: کلین کدر خیلی حرف تکنیکالیا� در مورد خود توسعه نرمافزا� و اینجو� حرفا نمیزنه� از تایتلش هم مشخصه. بیشتر سعی در بیان یه سری دیسیپلینه� و رویکرده� داره، و حتی صرفا گفتن همین که « دیسیپلینهای� هستن و ما باید بریم سراغشون ». اینجا قرار نیست توضیح دقیقی در مورد فرضا تیدید� بهمون داده بشه صرفا قراره گفته بشه یه تیدیدیا� هست، خوبه، و آدمها� حرفها� میر� سراغش، پس شما هم برین سراغش! در کنار داستانهای� که یه حس مشترکی هم ایجاد کنه :دی قرار هم نیست و قول هم نداده خیلی به روز باشه. مشخصه یه سری از رویکرده� ممکنه تغییر کرده باشن، اما خب بیشترشون نکردن :دی
در نهایت به نظرم خوندنش خوبه، نمیش� گفت نمیارزه، خیلی هم روون هست متن کتاب و با سرعت نسبتا خوبی میش� خوندش ( حداقل برای من ۲/۳ زمانی که یه کتاب عادی انگلیسی رو میخون� طول کشید ) و فوکس خیلی خاصی هم روش نمیخواد� میش� حتی تو مسیر رفت و آمد هم خوندش! یا شبه� :دی
اول از همه اشاره کنم که شخصا از خوندن داستان و بیوگرافیطو� آدمای مرتبط خوشم میاد، و خب مشکلی با قصهها� بلند وسط کتابا ندارم، بیشتر حال هم میکن� باهاشون، و خب کلید کدر پُر هست از این قصهه�. به نظرم این قصهه� به آدم دید بهتری میدن� حس خوبی همراهشون میاد و خب میش� تریکه� و روشها� آدمه� رو دید و باهاشون آشنا شد و بعدا به کارشون گرفت. یه بخش خوبی از این مدل تکنیکه� و لایفاستایله� تو زندگی آنکلبا� هست، و خب چه لایفهک� بهتر از لایفهکها� یه پروفشنالی مثل آنکلبا� که حوزه� کاریش یکسانه باهامون؟ چرا نخونیمشون؟ هر چند یه درصدیش از نظرمون منطقی به نظر نیاد یا به تیپ ما نخوره؟ یا حتی اگه تردیدی هم داریم در موردشون خب نخ میگیری� و دقیقت� میری� سراغشون.
و اما بیشتر در مورد خود کتاب: کلین کدر خیلی حرف تکنیکالیا� در مورد خود توسعه نرمافزا� و اینجو� حرفا نمیزنه� از تایتلش هم مشخصه. بیشتر سعی در بیان یه سری دیسیپلینه� و رویکرده� داره، و حتی صرفا گفتن همین که « دیسیپلینهای� هستن و ما باید بریم سراغشون ». اینجا قرار نیست توضیح دقیقی در مورد فرضا تیدید� بهمون داده بشه صرفا قراره گفته بشه یه تیدیدیا� هست، خوبه، و آدمها� حرفها� میر� سراغش، پس شما هم برین سراغش! در کنار داستانهای� که یه حس مشترکی هم ایجاد کنه :دی قرار هم نیست و قول هم نداده خیلی به روز باشه. مشخصه یه سری از رویکرده� ممکنه تغییر کرده باشن، اما خب بیشترشون نکردن :دی
در نهایت به نظرم خوندنش خوبه، نمیش� گفت نمیارزه، خیلی هم روون هست متن کتاب و با سرعت نسبتا خوبی میش� خوندش ( حداقل برای من ۲/۳ زمانی که یه کتاب عادی انگلیسی رو میخون� طول کشید ) و فوکس خیلی خاصی هم روش نمیخواد� میش� حتی تو مسیر رفت و آمد هم خوندش! یا شبه� :دی
March 28, 2019
Well this book is a must read for all developers who aim to be professionals and not just technicians.
It's not a technical book, it's a simple easy read explaining the topics with real life examples. I loved the chapter that defines estimation from different sides ("Business likes to view estimates as commitments. Developers like to view estimates as guesses"). I also liked the chapter that discusses dealing with pressure and how a person should rely on his disciplines in such cases. Uncle Bob stresses on the importance of collaboration, pair programming, and mentorship in other great chapters and I can't agree more.
It's not a technical book, it's a simple easy read explaining the topics with real life examples. I loved the chapter that defines estimation from different sides ("Business likes to view estimates as commitments. Developers like to view estimates as guesses"). I also liked the chapter that discusses dealing with pressure and how a person should rely on his disciplines in such cases. Uncle Bob stresses on the importance of collaboration, pair programming, and mentorship in other great chapters and I can't agree more.
March 18, 2018
This is the right book to understand:
What is a software professional?
How does a professional behave?
How does a professional deal with conflict, tight schedules, and unreasonable managers?
When, and how, should a professional say “no�?
How does a professional deal with pressure?
What is a software professional?
How does a professional behave?
How does a professional deal with conflict, tight schedules, and unreasonable managers?
When, and how, should a professional say “no�?
How does a professional deal with pressure?
July 31, 2015
Robert C. Martin (1952- ) has been programming professionally since 1970 but started making his mark as an exceptional software engineering practitioner and consultant once he started developing object-oriented software in the 1980s and later when he was amongst the Agile Manifesto signatories (2001), distilled part of his design experience into the five well-known SOLID principles (2003) and co-developed the acceptance testing framework FitNesse. He is also a much sought after and forceful keynote speaker. This book constitutes Robert C. Martin´s personal reflection on what it means to be a professional software developer -given his extensive experience in the field and his articulateness, any object-oriented agile software engineer or student worth his salt should pay attention to his words.
For Martin being a software professional is a bundle comprising attitude, behaviour, work ethics and habits, mentoring and lifelong, continuous learning. It is about working forty hour weeks for your employer and devoting another twenty hours a week to keeping up with your chosen field, it is about knowing when to say yes and, more importantly, when (and how) to say no to your employer and your clients. It is about making honest estimations of efforts, taking full responsibility for your work, making binding commitments, great craftmanship, teamwork and collaboration, clear communication with your team mates, your colleagues, your employer and your clients. It is about disciplined time management, incessant practice, mastery of the right tools and taking a break when it is needed.
Of course, you may not agree with everything Martin says; in a rare caveat, he does warn the reader that what he presents works for him. For example I do not agree with his sweeping and cavalier dismissal of MDA (Model Driven Architecture) and UML. I suggest that you give some of his suggestions -pair programming, test-driven development (TDD), programming katas, timeboxing, planning poker with Pert-based estimates- a go with an open mind; the experience will be enlightening even if you find the techniques he recommends do not work for you. Martin is more of an evangelist for agile object-oriented development techniques than an objetive evaluator, but I did not find this detracts from the book -but this may be because I happen to agree with the main thrust of his recommendations ;-)
Personally I found the last chapters flagged and the appendix on the tools he favours interesting but a little too brief; for example, his description of the distributed version control system Git will leave readers unfamiliar with it feeling somewhat left out.
If you have not seen “Uncle Bob� Martin´s larger than life persona in action, look up a couple of YouTube videos of his keynote speeches -he is a superb showman of the fire and brimstone variety. Be warned that some readers may find Martin´s explanations too shallow, his forceful style too self-centered and righteous and thus uncongenial .
An added plus for me as a near contemporary of Martin´s was the trip down memory lane when relating his anecdotes on what for younger readers are probably ancient computing history: typewriter and teletype carriage returns and line feeds, punched cards, minicomputers and ties as mandatory business requirements for programmers, just to name a few.
There is plenty of sound advice in this book, but, as always, remember to exercise your critical faculties -wrestling intellectually with Martin is, in my opinion, an excellent way of building the character you need to succeed professionally...
For Martin being a software professional is a bundle comprising attitude, behaviour, work ethics and habits, mentoring and lifelong, continuous learning. It is about working forty hour weeks for your employer and devoting another twenty hours a week to keeping up with your chosen field, it is about knowing when to say yes and, more importantly, when (and how) to say no to your employer and your clients. It is about making honest estimations of efforts, taking full responsibility for your work, making binding commitments, great craftmanship, teamwork and collaboration, clear communication with your team mates, your colleagues, your employer and your clients. It is about disciplined time management, incessant practice, mastery of the right tools and taking a break when it is needed.
Of course, you may not agree with everything Martin says; in a rare caveat, he does warn the reader that what he presents works for him. For example I do not agree with his sweeping and cavalier dismissal of MDA (Model Driven Architecture) and UML. I suggest that you give some of his suggestions -pair programming, test-driven development (TDD), programming katas, timeboxing, planning poker with Pert-based estimates- a go with an open mind; the experience will be enlightening even if you find the techniques he recommends do not work for you. Martin is more of an evangelist for agile object-oriented development techniques than an objetive evaluator, but I did not find this detracts from the book -but this may be because I happen to agree with the main thrust of his recommendations ;-)
Personally I found the last chapters flagged and the appendix on the tools he favours interesting but a little too brief; for example, his description of the distributed version control system Git will leave readers unfamiliar with it feeling somewhat left out.
If you have not seen “Uncle Bob� Martin´s larger than life persona in action, look up a couple of YouTube videos of his keynote speeches -he is a superb showman of the fire and brimstone variety. Be warned that some readers may find Martin´s explanations too shallow, his forceful style too self-centered and righteous and thus uncongenial .
An added plus for me as a near contemporary of Martin´s was the trip down memory lane when relating his anecdotes on what for younger readers are probably ancient computing history: typewriter and teletype carriage returns and line feeds, punched cards, minicomputers and ties as mandatory business requirements for programmers, just to name a few.
There is plenty of sound advice in this book, but, as always, remember to exercise your critical faculties -wrestling intellectually with Martin is, in my opinion, an excellent way of building the character you need to succeed professionally...
June 14, 2011
Simply phenomenal. I liked this book so much that I literally read the entire thing in a single sitting in about 4 hours. I simply could not put it down.
I'm adding this book to my list of "absolute must-reads for programmers" right alongside The Pragmatic Programmer.
Uncle Bob's new book, The Clean Coder, is a perfect companion to Clean Code. Whereas Clean Code dealt specifically with how a professional programmer treats his or her code, The Clean Coder is more about how a professional programmer conducts him or herself.
Reading this book was simply a wonderful experience. I agree with almost everything Bob says in the book, and I found myself often pumping my fist thinking "hell yeah, that's what I've been trying to tell my co-workers!"
The Clean Coder puts into elegant words a number of thoughts I've had, and it demands I rise to a higher level of professionalism. If I were to compile a bible of programming, The Clean Coder would be one of the books.
If you're a programmer and you take your job seriously, you owe it to yourself to read The Clean Coder.
I'm adding this book to my list of "absolute must-reads for programmers" right alongside The Pragmatic Programmer.
Uncle Bob's new book, The Clean Coder, is a perfect companion to Clean Code. Whereas Clean Code dealt specifically with how a professional programmer treats his or her code, The Clean Coder is more about how a professional programmer conducts him or herself.
Reading this book was simply a wonderful experience. I agree with almost everything Bob says in the book, and I found myself often pumping my fist thinking "hell yeah, that's what I've been trying to tell my co-workers!"
The Clean Coder puts into elegant words a number of thoughts I've had, and it demands I rise to a higher level of professionalism. If I were to compile a bible of programming, The Clean Coder would be one of the books.
If you're a programmer and you take your job seriously, you owe it to yourself to read The Clean Coder.
August 6, 2020
I attempted to read this book more than three years ago and for some unknown reason (maybe short attention span?), I couldn't continue after 33 pages. How do I remember the page number where I stopped? I underline words and sentences while reading book, be it fiction, non fiction, technical books, anything. The last marking ended at page no 33.
My professional journey started three and half years ago and I think I am not that late reading this book. I have a lot to say about this book and I'll try to say it with a detailed review. For now, all I can say is this is by far one of the most important books in my professional career and also in my life.
[Will be updated soon]
My professional journey started three and half years ago and I think I am not that late reading this book. I have a lot to say about this book and I'll try to say it with a detailed review. For now, all I can say is this is by far one of the most important books in my professional career and also in my life.
[Will be updated soon]
February 10, 2020
Anlatılanların bir çoğu mesleğimizi icra ederken yıllar içinde edindiğimiz ve Uncle Bob’ın da benzer şekilde kariyeri boyunca kazandığı tecrübeleri içeriyor. Kitaptaki bazı öneriler biraz extreme olmuş ama genel olarak profesyonel olmanın ne olduğunu güzel bir şekilde özetlenmiş. Bu esnada bazı konuları (TDD, pair, programming, coverage etc.) vurgulamak için birçok kez tekrar etmiş ama amaç bazı fikirleri ön plana çıkarmak olduğu için çok da rahatsız etmiyor. Günün sonunda okumakta fayda olduğunu düşünüyorum ama okumazsanız da çok kaybınız olmaz.
September 18, 2022
A quick and useful guide for transforming oneself from being a "typical dev" to a professional software developer. I found the author's anecdotes from his long career in software development very interesting and at times enlightening!
July 25, 2022
محشر بود، مهارت های نرم که یه برنامه نویس باید داشته باشه
مثل روراست بودن، وقت شناس بودن و خیلی چیزای دیگه و واقعا خوندش بر هر برنامه نویس واجب عینیه
خیلی هم انگیزه بخشه، من بعد خوندنش تصمیم گرفتم کل کد های شرکتمونو ریفکتور کنم
مثل روراست بودن، وقت شناس بودن و خیلی چیزای دیگه و واقعا خوندش بر هر برنامه نویس واجب عینیه
خیلی هم انگیزه بخشه، من بعد خوندنش تصمیم گرفتم کل کد های شرکتمونو ریفکتور کنم
February 12, 2020
I really enjoy it. I like the style in which the book is written and I think that the majority if not all of the people in this field should read it to gain some insights about a little bit of history, experience and what to do to become a professional. :)
September 22, 2023
I work with colleagues who lack knowledge in dynamic programming or backtracking. Some of them, with over 10 years of experience, don't even know that we can declare variables in CSS. Most individuals struggle with performing a binary search. I think my point is that I despise people who don't know data structures and algorithms
July 1, 2016
If only I could award 6/5 stars to this! This os a very useful book for programmers willing to commit to a professional work ethic. It was the first Uncle Bob book I've read, and I'm now excited about buying and reading more of his work.
August 11, 2021
4.3/5 This should be mandatory read for everyone looking to level up their programmer craftsmanship.
February 22, 2021
For whoever thinks this is a book where you will see lots of good code examples, code standards, code references...THIS IS NOT.
Instead this book tries to explain what it means to be a professional not only as a developer, but for any computer science related work.
If you are someone who is starting on the field of computer science, or someone already with some experience, if you never read this book...READ IT NOW.
This should be a reference for our area. And universities that require so many technical books, this should be something students in computer science should be told to grab and read as it will teach them what they will face on real word and how to perform it correctly.
Congratulations for this excellent book and thank you.
Instead this book tries to explain what it means to be a professional not only as a developer, but for any computer science related work.
If you are someone who is starting on the field of computer science, or someone already with some experience, if you never read this book...READ IT NOW.
This should be a reference for our area. And universities that require so many technical books, this should be something students in computer science should be told to grab and read as it will teach them what they will face on real word and how to perform it correctly.
Congratulations for this excellent book and thank you.
June 25, 2024
3.6 stars rounded up.
Most of this book is a solid 4 stars but the last four chapters were not up to par with the others, as a matter of fact, the last four chapters where rambling torture. But, overall, I enjoyed most of it and hence the rating.
Most of this book is a solid 4 stars but the last four chapters were not up to par with the others, as a matter of fact, the last four chapters where rambling torture. But, overall, I enjoyed most of it and hence the rating.
September 18, 2019
Điều hay nhất t� thấy � cuốn sách này � ngay � chương 1, bác Bob đã đặt ra 5 câu hỏi mà bất c� lập trình viên chuyên nghiệp nào cũng phải tr� lời được (không trích vì spoiler), rất c� th� và d� áp dụng. Điều làm t� bất ng� nhất mà t� biết là cần phải viết test trước khi viết code vì t� chưa bao gi� làm th� và gần như không hiểu nổi cho đến khi t� đọc bài tr� lời của bác Mario Galindo trên Quora cho câu hỏi "As someone who works with interpreted programming languages, I do not quite understand. How do you debug large C and C++ programs?"
T� thích câu chuyện ngh� việc của bác Bob và bài học t� nó: "Bạn ch� ngh� việc khi sẵn sàng một công việc khác và lúc thôi việc bạn phải bình tĩnh, ngầu (cool) và đơn độc. T� đã làm đúng điều này � công ty gần nhất t� ngh� việc và mọi chuyện êm thấm, thật khác cuộc cãi lộn ủm tỏi � công ty trước đó.
T� thích ý tưởng và luận điệu của bác Bob v� pair programming và Coding Dojo hay Kata. Hy vọng một ngày nào đó t� có th� chơi trò này cùng bạn mình.
Một ý hay v� Tranh luận và Bất đồng quan điểm là ch� giành ra 5 phút đ� x� lý. Nếu ko được c� 2 người trình bày ý tưởng và đ� team biểu quyết. Rất nhiều người đ� thỏa mãn tính cá nhân mà la hét cáu gắt cốt đ� uy hiếp người khác nghe lời mình hoặc ngược lại, gi� v� đồng tình sau đó bất hợp tác. Suy cho cùng cuộc sống bao gi� cũng có lúc thắng lúc thua, quan trọng là giải quyết vấn đ�.
Một ý hay khác là d� án nên xoay quanh nhóm thay vì ngược lại. Các công ty dù lớn hay nh� đều đi theo hướng ngược lại, biến con người ch� thành bánh răng của h� thống và d� thay th�. Nhưng nhóm làm việc cần tối thiểu 6 tháng đ� có th� làm việc hiệu qu� với nhau. Một nhóm bền chặt s� d� dàng qua lại giữa các d� án và phối hợp ăn ý hơn việc chia tách mọi người theo từng d� án. Tuy nhiên ý này cũng không hẳn là thực t� chưa k� một khi s� phân rã xảy ra, mọi người s� đều rất đau lòng. Con người thật không giỏi sống gần và lâu với nhau.
Điều t� cảm thấy khắc nghiệt là đòi hỏi cao của cuốn sách v� một lập trình viên. Bác Bob v� ra hình mẫu lý tưởng của một lập trình viên hoàn hảo phần nào khiến t� thấy mặc cảm và căng thẳng vì chắc còn rất lâu nữa t� mới với tới trình đ� đó. Chưa k� cách làm việc như vậy không thực t� với tình hình trong nước khi mà d� án thường không rõ sống chết và thiếu những người lãnh đạo hiểu rõ c� v� kinh doanh lẫn công ngh� đ� biết chắc điều gì là có th� còn điều gì là ng� ngẩn.
Cuối cùng là s� khắt khe trong việc fix bug và ngăn chặn bug thực s� khiến t� không thoải mái. Nếu lập trình viên nào cũng làm th� thì các bạn QA thất nghiệp hết mất. Lời này ch� là t� an ủi, có l� s� không thoải mái này có lợi cho t�.
Một cuốn sách ngắn và hay!
T� thích câu chuyện ngh� việc của bác Bob và bài học t� nó: "Bạn ch� ngh� việc khi sẵn sàng một công việc khác và lúc thôi việc bạn phải bình tĩnh, ngầu (cool) và đơn độc. T� đã làm đúng điều này � công ty gần nhất t� ngh� việc và mọi chuyện êm thấm, thật khác cuộc cãi lộn ủm tỏi � công ty trước đó.
T� thích ý tưởng và luận điệu của bác Bob v� pair programming và Coding Dojo hay Kata. Hy vọng một ngày nào đó t� có th� chơi trò này cùng bạn mình.
Một ý hay v� Tranh luận và Bất đồng quan điểm là ch� giành ra 5 phút đ� x� lý. Nếu ko được c� 2 người trình bày ý tưởng và đ� team biểu quyết. Rất nhiều người đ� thỏa mãn tính cá nhân mà la hét cáu gắt cốt đ� uy hiếp người khác nghe lời mình hoặc ngược lại, gi� v� đồng tình sau đó bất hợp tác. Suy cho cùng cuộc sống bao gi� cũng có lúc thắng lúc thua, quan trọng là giải quyết vấn đ�.
Một ý hay khác là d� án nên xoay quanh nhóm thay vì ngược lại. Các công ty dù lớn hay nh� đều đi theo hướng ngược lại, biến con người ch� thành bánh răng của h� thống và d� thay th�. Nhưng nhóm làm việc cần tối thiểu 6 tháng đ� có th� làm việc hiệu qu� với nhau. Một nhóm bền chặt s� d� dàng qua lại giữa các d� án và phối hợp ăn ý hơn việc chia tách mọi người theo từng d� án. Tuy nhiên ý này cũng không hẳn là thực t� chưa k� một khi s� phân rã xảy ra, mọi người s� đều rất đau lòng. Con người thật không giỏi sống gần và lâu với nhau.
Điều t� cảm thấy khắc nghiệt là đòi hỏi cao của cuốn sách v� một lập trình viên. Bác Bob v� ra hình mẫu lý tưởng của một lập trình viên hoàn hảo phần nào khiến t� thấy mặc cảm và căng thẳng vì chắc còn rất lâu nữa t� mới với tới trình đ� đó. Chưa k� cách làm việc như vậy không thực t� với tình hình trong nước khi mà d� án thường không rõ sống chết và thiếu những người lãnh đạo hiểu rõ c� v� kinh doanh lẫn công ngh� đ� biết chắc điều gì là có th� còn điều gì là ng� ngẩn.
Cuối cùng là s� khắt khe trong việc fix bug và ngăn chặn bug thực s� khiến t� không thoải mái. Nếu lập trình viên nào cũng làm th� thì các bạn QA thất nghiệp hết mất. Lời này ch� là t� an ủi, có l� s� không thoải mái này có lợi cho t�.
Một cuốn sách ngắn và hay!
August 25, 2020
I picked this book to understand what being a "professional" software engineer means. Author touched some useful concepts : Test Driven Development, Programming Kata, types of tests, estimating tasks, Being a team player, mentorship etc.
September 2, 2018
Ca de obicei, îmi place ceea scrie cel ce acum a devenit ca un mentor pentru mine: Uncle Bob. Dar în această carte m-a surprins subiectul pe care l-a abordat: profesionalismul pentru programatori. Cu siguranță nu m-am gândit că ar putea exista un cod de comportament pentru software developeri, dar toate argumentele pe care autorul le-a oferit sunt copleșitoare. De ce nu ne angajăm să suportăm consecințele a ceea ce spunem în aceeași măsură pe care un doctor o face? Cu toate că viața nimănui nu este în pericol datorită unor estimări false sau unor angajamente neoneste, cu toate acestea angajatorul pierde o sumă considerabilă. Iar dacă interesele angajatorului nu sunt respectate, nici nu programatorii nu pot fi considerați ca fiind profesioniști.
Ce recomandă Uncle Bob? Să scriem clean code și să nu ne abandonăm disciplina nici în crize, când stresul ne copleșește; să nu facem estimări și angajamente neoneste, chiar dacă există presiuni de la manageri, căci toată lumea are de pierdut de la acestea: clienții, angajatorul, programatorii, proiectul etc. E cu mult mai preferabil să informezi din timp dacă nu poți respecta un deadline; să lucrezi în echipă și să îi ajuți pe cei noi mereu. Metoda preferată a lui Uncle Bob este pair programmingul și o recomandă nu numai pentru a-ți ajuta colegii, ci chiar și când tu ești blocat și ai nevoie de ajutor; să respecți interesele angajatorului și multe, multe altele.
Consider că ”The Clean Coder� ar trebui să fie la fel de populară și de obligatorie pentru orice programator ca și ”The Clean Code�, a cărei idei, deși nu am citit-o încă (e următoarea pe listă!), le-am găsit din plin și în video-urile sale.
Ce recomandă Uncle Bob? Să scriem clean code și să nu ne abandonăm disciplina nici în crize, când stresul ne copleșește; să nu facem estimări și angajamente neoneste, chiar dacă există presiuni de la manageri, căci toată lumea are de pierdut de la acestea: clienții, angajatorul, programatorii, proiectul etc. E cu mult mai preferabil să informezi din timp dacă nu poți respecta un deadline; să lucrezi în echipă și să îi ajuți pe cei noi mereu. Metoda preferată a lui Uncle Bob este pair programmingul și o recomandă nu numai pentru a-ți ajuta colegii, ci chiar și când tu ești blocat și ai nevoie de ajutor; să respecți interesele angajatorului și multe, multe altele.
Consider că ”The Clean Coder� ar trebui să fie la fel de populară și de obligatorie pentru orice programator ca și ”The Clean Code�, a cărei idei, deși nu am citit-o încă (e următoarea pe listă!), le-am găsit din plin și în video-urile sale.
June 12, 2011
Yes, "The Clean Coder" is a sequel to Uncle Bob's "Clean Code." This is a great book and drills what being a professional developer really means as delivered by a well respected source.
The book is very readable and contains advice mixed with stories from the author's past and dialog. I like the use of dialog to show communication issues like saying "done" or over committing. Even the foreword was a story.
I think there was too much repetition of the stories across chapters. Almost like the chapters were written in standalone form. I felt like I read about the same employer (introduced from scratch) a few times. It was interesting hearing about the punchcard world with lessons and how things have changed. Same for FitNesse. I get that it has unit tests.
The advice is excellent. My favorite three (that were fairly unique for computer literature):
1) difference between performance and practice
2) TDD on offense vs defense
3) focus manna on time management
The only advice I felt strongly against is being in the "flow" being a bad thing. As long as you define the problem out of the flow, I don't see the problem with isolating yourself from the big picture temporarily.
---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
The book is very readable and contains advice mixed with stories from the author's past and dialog. I like the use of dialog to show communication issues like saying "done" or over committing. Even the foreword was a story.
I think there was too much repetition of the stories across chapters. Almost like the chapters were written in standalone form. I felt like I read about the same employer (introduced from scratch) a few times. It was interesting hearing about the punchcard world with lessons and how things have changed. Same for FitNesse. I get that it has unit tests.
The advice is excellent. My favorite three (that were fairly unique for computer literature):
1) difference between performance and practice
2) TDD on offense vs defense
3) focus manna on time management
The only advice I felt strongly against is being in the "flow" being a bad thing. As long as you define the problem out of the flow, I don't see the problem with isolating yourself from the big picture temporarily.
---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
July 13, 2021
60 hours a week for the rest of your working life. Seriously? 60 hours in front of a screen, when all health evidence says we should be spending more of our day away from the screen in more active physical persuits. And you have to do all this to be a called a 'professional'?
60 hours / week screen time when you're in your 20s = fine
60 hours / week screen time when you're in your 30s = mostly fine but your health starts to suffer
60 hours / week screen time when you're in your 40s = starting to have serious health problems
60 hours / week screen time when you're in your 50s = heart attack
60 hours / week screen time when you're in your 20s = fine
60 hours / week screen time when you're in your 30s = mostly fine but your health starts to suffer
60 hours / week screen time when you're in your 40s = starting to have serious health problems
60 hours / week screen time when you're in your 50s = heart attack
September 5, 2018
Ugh. This book was miserable. There are so many anecdotes from "Uncle Bob" it is hard to read. There is some good advice in the chapters, but this book could've been a 5 page leaflet instead of an entire book with the actual information provided. Also, there are tons of hints of sexism in the book, which drove me mad. Overall, there are better ways of learning how to be a professional software developer. I think that some of his advice is incredibly antiquated, and although they might have been true in the past, it's not necessarily indicative of today's culture.
Displaying 1 - 30 of 671 reviews
Can't find what you're looking for?
Get help and learn more about the design.