What do you think?
Rate this book
How to Stop Sucking and Be Awesome Instead
A curated, printed collection of significant, highly rated blog entries from Jeff Atwood, long time blogger and co-founder of Stack Overflow and Discourse. Because we do this together.
Hardcover
First published March 12, 2013
61 people are currently reading
313 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 10 of 10 reviews
October 4, 2014
Another Blog-To-Book thingie - noticeable worse than the 1st one Jeff (famous @codinghorror) created few years ago. Some posts are remarkable, namely:
* "Are you an expert?"
* "On our project, we're always 90 percent done"
* "How to become a better programmer by not programming"
* "Who's your coding buddy?"
* "Computer crime, then and now"
but unfortunately the great-to-average ratio is not nearly as good as it was in the 1st book.
I think this still makes this book worth reading (and I can recommend Jeff's blog with a blink), but don't expect anything ground-breaking.
* "Are you an expert?"
* "On our project, we're always 90 percent done"
* "How to become a better programmer by not programming"
* "Who's your coding buddy?"
* "Computer crime, then and now"
but unfortunately the great-to-average ratio is not nearly as good as it was in the 1st book.
I think this still makes this book worth reading (and I can recommend Jeff's blog with a blink), but don't expect anything ground-breaking.
February 3, 2016
The book is a compilation of the best posts from the Coding Horror blog, and got my attention from several recommendations for developers I ran into. I've also read several blog posts there and was happy to get a book with the most popular posts in a book form.
As the book is a compilation of blog posts, it's a collection of essays, organized in several sections (How to suck less, Programming, Web Design Principles, Testing, Know your user, Causes we should care about, Gaming and Things to read) which contain the chapters, organized by the common theme.
The book starts with Author's annoyance about the TODO lists, where he says that the proliferation of TODO tools is masking the fact that for the most important things in life he never needed a TODO list.
The goof off time is important, and it wasn't invented by Google, apparently HP was the first known company to have a certain time off for their employees to play, invent and innovate. However, it only works if there's some slack in the schedule, if daydreaming and experimentation are allowed.
The section about programming has a number of insights and advice to programmers looking to get better. The first one is a bit paradoxical: How to become a better programmer by not programming? The answer is to become passionate about your users, about your business.
"To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming."
In the section about knowing your users, we're reminded that possibly the greatest sin software developers commit is consider themselves the average user. Nothing could be farther from the truth. The average user doesn't know what ALT+TAB does.
The book ends with a section on things to read, and it's shocking to discover most software developers don't read a single book in a year. Author lists several books he found extremely valuable, and they are a must-read list for every working programmer (Code Complete 2, Don't Make Me Think, Peopleware, Pragmatic Programmer & Facts And Fallacies).
While the book was mostly a enjoyable and enlightening read, some of the posts felt more like rants than informative essays. Fortunately, there were only a few and the remainder of the material was a no-nonsense wisdom of an industry veteran.
The relaxed, conversational writing style was refreshing and kept my attention very well. I would recommend the book to the novice and experienced developer alike.
More in-depth summary can be found here: https://github.com/arkon108/book-revi...
As the book is a compilation of blog posts, it's a collection of essays, organized in several sections (How to suck less, Programming, Web Design Principles, Testing, Know your user, Causes we should care about, Gaming and Things to read) which contain the chapters, organized by the common theme.
The book starts with Author's annoyance about the TODO lists, where he says that the proliferation of TODO tools is masking the fact that for the most important things in life he never needed a TODO list.
The goof off time is important, and it wasn't invented by Google, apparently HP was the first known company to have a certain time off for their employees to play, invent and innovate. However, it only works if there's some slack in the schedule, if daydreaming and experimentation are allowed.
The section about programming has a number of insights and advice to programmers looking to get better. The first one is a bit paradoxical: How to become a better programmer by not programming? The answer is to become passionate about your users, about your business.
"To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming."
In the section about knowing your users, we're reminded that possibly the greatest sin software developers commit is consider themselves the average user. Nothing could be farther from the truth. The average user doesn't know what ALT+TAB does.
The book ends with a section on things to read, and it's shocking to discover most software developers don't read a single book in a year. Author lists several books he found extremely valuable, and they are a must-read list for every working programmer (Code Complete 2, Don't Make Me Think, Peopleware, Pragmatic Programmer & Facts And Fallacies).
While the book was mostly a enjoyable and enlightening read, some of the posts felt more like rants than informative essays. Fortunately, there were only a few and the remainder of the material was a no-nonsense wisdom of an industry veteran.
The relaxed, conversational writing style was refreshing and kept my attention very well. I would recommend the book to the novice and experienced developer alike.
More in-depth summary can be found here: https://github.com/arkon108/book-revi...
June 3, 2016
Another nice book of blog entries from Jeff Atwood.
First few blogs are about how one should determine at a very early age if one can program or not and should drop out of a programming career if one is not. He speaks about "sheep that can program and goats that cannot program" should be separated out early in the career so that software can become better.
Some of the key observations that I liked are "You have to truly believe, as a company, and as peers, that crucial innovations and improvements can come from everyone at the company at any time, in bottom-up fashion - they aren't delivered from on high at scheduled release intervals in the almighty master plan.
In another blog he speaks about how important it is to persuade others to do something. He refers to a set of dialog from the movie based on Idi Amin. Idi Amin is speaking to his trusted aide a Scottish Doctor.
Idi Amin: I want you to tell me what to do!
Garrigan: "You want me to tell you what to do?
Amin: Yes You are my advisor. You are the only one I can trust here. You should have told me not to throw the Asians out in the first place!
Garrigan: I did!
Amit: But you did not persuade me, Nicholas. You did not persuade me!
Not a very atypical dialog one is likely to have with either one's manager or client. :-)
Another important advice with which I cannot agree more since I have given the same advice to many others who have asked me for my opinion. "Whatever project you are working on, consider it an opportunity to learn and practice your craft. It is worth doing because, well it is worth doing. The journey of the project should be its own reward regardless of whatever happens to lie at the end of that journey."
The corollary is another thing that I keep stressing on; "Never get attached to a project. Execute the project to the best of the abilities, learn along the way and if for some reason beyond your control the project fails or does not see the light of the day, so be it."
Speaking on merit based growth in an organization Jeff has to say the following "Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means [among other things] abolishment of annual or merit rating and management by objectives. "Even people who think of themselves as Deming-ites have trouble with this one. They are left gasping. What the hell are we supposed to do instead? Deming's point is that MBO and its ilk are copouts. By using simplistic extrinsic motivators to goad performance, managers excuse themselves from harder matters such as investment, direct personal motivation, thoughtful team formation, staff retention, and ongoing analysis and redesign of work procedures. Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect.
In one blog Jeff compares F-86 and MIG-15s. The latter was far more superior to the former, but the fighter pilots preferred the former. The difference was that F-86 had Hydraulic flight controller compared to the manual flight controller of MIG-15. This meant that each maneuver increased the fatigue of the MIG-15 pilot even though he might have out-maneuvered the F-86 pilot. The F-86 could maneuver quicker as compare to the MIG-15 as he was less fatigued and this tilted the pilots to favour F-86 despite its limited abilities. Jeff calls this the Boyd's Law of Iteration which states "Speed of iteration beats quality of iteration". Jeff argues the same is true for software development. Although he says in other places that quality cannot be sacrificed beyond a point.
There is a whole set of blogs in User Interface and Usability. One book the author highly recommends is Don't make me think by Steve Krug https://www.amazon.in/Dont-Make-Think... and another one is Rocket Surgery made easy again by Steve Krug https://www.amazon.in/Rocket-Surgery-....
He speaks about the Fitts law which states "Put all commonly accessed UI elements on the edges of screen. Because the cursor automatically stops at the edges, they will be easier to click on. Make clickable areas as large as you can. Larger targets are easier to click on". One should not ignore the corollary of rule which would read "Make all the clicks that the user must be kept safe from as difficult as possible". Jeff refers to this principle as the "seat ejector" button. This button should be easy to find in an emergency, but should not be place such that the pilot ends up turning this on instead of the navigation lights. Buttons like delete all my mails and such should be available, but should be placed such that the no user would click it by mistake.
Speaking on importance of saying not to demands, Jeff says "It is easy to dismiss Just say No as a negative mindset, but I think it is a healthy and natural reaction to observation that optimism is an occupational hazard of programming". Cannot agree with him more as I have been pulled up for saying no many a time in my career.
Speaking about usability Jeff argues that most users of the applications do not progress beyond the intermediary stage. He argues that most move from the novice to Intermediary stage quite quickly or drop off as an user of the system if they find it too difficult to use. Once they reach this stage they remain in this stage for a long time and only a very few move to the expert level. Given this he argues that software should be targeted towards these users rather than at the novices or the experts. He states that most marketing people would advocate making software for the novice as these would be the ones that the marketing people would encounter most of the times, while the software developer would want to address the experts as it is likely that they would be geeks themselves and would want maximum flexibility and most features.
Writing on security and hacking the author says that today to hack into a site one needs social skills and not technical skills. Technology has advanced to a level where hacking into a website has been made difficult enough, but people are not inure to social engineering and that it is much easier way of hacking into a system.
On the whole a very good read.
First few blogs are about how one should determine at a very early age if one can program or not and should drop out of a programming career if one is not. He speaks about "sheep that can program and goats that cannot program" should be separated out early in the career so that software can become better.
Some of the key observations that I liked are "You have to truly believe, as a company, and as peers, that crucial innovations and improvements can come from everyone at the company at any time, in bottom-up fashion - they aren't delivered from on high at scheduled release intervals in the almighty master plan.
In another blog he speaks about how important it is to persuade others to do something. He refers to a set of dialog from the movie based on Idi Amin. Idi Amin is speaking to his trusted aide a Scottish Doctor.
Idi Amin: I want you to tell me what to do!
Garrigan: "You want me to tell you what to do?
Amin: Yes You are my advisor. You are the only one I can trust here. You should have told me not to throw the Asians out in the first place!
Garrigan: I did!
Amit: But you did not persuade me, Nicholas. You did not persuade me!
Not a very atypical dialog one is likely to have with either one's manager or client. :-)
Another important advice with which I cannot agree more since I have given the same advice to many others who have asked me for my opinion. "Whatever project you are working on, consider it an opportunity to learn and practice your craft. It is worth doing because, well it is worth doing. The journey of the project should be its own reward regardless of whatever happens to lie at the end of that journey."
The corollary is another thing that I keep stressing on; "Never get attached to a project. Execute the project to the best of the abilities, learn along the way and if for some reason beyond your control the project fails or does not see the light of the day, so be it."
Speaking on merit based growth in an organization Jeff has to say the following "Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means [among other things] abolishment of annual or merit rating and management by objectives. "Even people who think of themselves as Deming-ites have trouble with this one. They are left gasping. What the hell are we supposed to do instead? Deming's point is that MBO and its ilk are copouts. By using simplistic extrinsic motivators to goad performance, managers excuse themselves from harder matters such as investment, direct personal motivation, thoughtful team formation, staff retention, and ongoing analysis and redesign of work procedures. Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect.
In one blog Jeff compares F-86 and MIG-15s. The latter was far more superior to the former, but the fighter pilots preferred the former. The difference was that F-86 had Hydraulic flight controller compared to the manual flight controller of MIG-15. This meant that each maneuver increased the fatigue of the MIG-15 pilot even though he might have out-maneuvered the F-86 pilot. The F-86 could maneuver quicker as compare to the MIG-15 as he was less fatigued and this tilted the pilots to favour F-86 despite its limited abilities. Jeff calls this the Boyd's Law of Iteration which states "Speed of iteration beats quality of iteration". Jeff argues the same is true for software development. Although he says in other places that quality cannot be sacrificed beyond a point.
There is a whole set of blogs in User Interface and Usability. One book the author highly recommends is Don't make me think by Steve Krug https://www.amazon.in/Dont-Make-Think... and another one is Rocket Surgery made easy again by Steve Krug https://www.amazon.in/Rocket-Surgery-....
He speaks about the Fitts law which states "Put all commonly accessed UI elements on the edges of screen. Because the cursor automatically stops at the edges, they will be easier to click on. Make clickable areas as large as you can. Larger targets are easier to click on". One should not ignore the corollary of rule which would read "Make all the clicks that the user must be kept safe from as difficult as possible". Jeff refers to this principle as the "seat ejector" button. This button should be easy to find in an emergency, but should not be place such that the pilot ends up turning this on instead of the navigation lights. Buttons like delete all my mails and such should be available, but should be placed such that the no user would click it by mistake.
Speaking on importance of saying not to demands, Jeff says "It is easy to dismiss Just say No as a negative mindset, but I think it is a healthy and natural reaction to observation that optimism is an occupational hazard of programming". Cannot agree with him more as I have been pulled up for saying no many a time in my career.
Speaking about usability Jeff argues that most users of the applications do not progress beyond the intermediary stage. He argues that most move from the novice to Intermediary stage quite quickly or drop off as an user of the system if they find it too difficult to use. Once they reach this stage they remain in this stage for a long time and only a very few move to the expert level. Given this he argues that software should be targeted towards these users rather than at the novices or the experts. He states that most marketing people would advocate making software for the novice as these would be the ones that the marketing people would encounter most of the times, while the software developer would want to address the experts as it is likely that they would be geeks themselves and would want maximum flexibility and most features.
Writing on security and hacking the author says that today to hack into a site one needs social skills and not technical skills. Technology has advanced to a level where hacking into a website has been made difficult enough, but people are not inure to social engineering and that it is much easier way of hacking into a system.
On the whole a very good read.
May 3, 2019
After reading the predecessor of this book, this seemed less novel in terms of insights about software development and management.
December 4, 2013
More of the same awesome stuff as his first book. Definitely read that one first! This book wasn't a compilation of his best blog posts. More like his second best, but I still enjoyed it. I like the mans insights and his commitment to quality and customer service are always spot on.
February 14, 2017
I read Jeff's first book "Effective Programming" and I like it more than this one, in the last 3 sections I start to feel bored and Jeff start to talk about thinks I find them not interesting, that's why I gave it 4 stars
January 16, 2016
Yes, it's a load of blog posts as a book. But I still enjoyed it.
I didn't enjoy the many hyperlinks - not useful on a Kindle far from the Internet (although there were quoted text in the book as well).
I didn't enjoy the many hyperlinks - not useful on a Kindle far from the Internet (although there were quoted text in the book as well).
November 15, 2014
It was great!!! I strongly recommend the chapter on usability.
January 22, 2016
Jeff's first book "Effective Programming" is better in my opinion. However this one was worth the reading.
June 5, 2016
Jeff gives a good advice: in order to succeed you have to just suck slighly less today than you did yesterday.
Displaying 1 - 10 of 10 reviews