How to stop sucking and be awesome instead
Download as PPTX, PDF261 likes57,260 views
The document discusses improving software quality by embracing flaws, sharing work publicly, and focusing on meaningful projects. It emphasizes the inevitability of imperfection in software development and advocates for user feedback and public sharing to enhance skills and learning. Ultimately, it encourages creating content that addresses real-world problems and resonates with audiences.
![One of my favorite business model
suggestions for [web] entrepreneurs is to find
an old UNIX command that hasn't yet been
implemented on the web, and fix that.
Marc Hedlund](https://image.slidesharecdn.com/howtostopsuckingandbeawesomeinstead-120601013410-phpapp01/85/How-to-stop-sucking-and-be-awesome-instead-23-320.jpg)
How to stop sucking and be awesome instead
- 2. How to Stop Sucking and Be Awesome Instead Jeff Atwood Coding Horror, Stack Exchange, Stack Overflow
- 4. Q: What does it mean when something “Sucks”?
- 5. • This doesn't do what I need • I can't figure out how to do what I need • This is unnecessarily frustrating and complex • This breaks all the time • It's so ugly I want to vomit • It doesn't map to my understanding of the universe • I'm thinking about the tool, instead of my work
- 6. And folks, let's be honest. Sturgeon was an optimist. Way more than 90% of code is crap. Al Viro
- 8. Q: Why do we suck?
- 9. A: Because we’re software, too.
- 10. “The main reason we tend to focus on the technical rather than the human side of the work is not because it's more crucial, but because it's easier to do.”
- 11. The common thread in all my failed projects is…
- 12. The First Rule of Programming: It’s Always Your Fault. codinghorror
- 13. 1. Embrace the Suck
- 15. We make shitty software… with bugs! Dave Winer 1995
- 16. “Software is a process, it's never finished, it's always evolving. That's its nature. We know our software sucks. But it's shipping! Next time we'll do better, but even then it will be shitty. The only software that's perfect is one you're dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it's a process. We'll make it less shitty. Just watch!”
- 17. Version 1 Sucks, But Ship It Anyway codinghorror
- 18. 3 months in development vs. 3 months of user feedback
- 19. • better side visibility • hydraulic flight controls • climbs faster • turns faster • better distance visibility
- 20. Boyd’s Law of Iteration: speed of iteration always beats quality of iteration Where you are today doesn’t matter so much, compared to where you’re going tomorrow.
- 21. My goal is to suck less every year. codinghorror
- 22. 2. Do It In Public
- 23. One of my favorite business model suggestions for [web] entrepreneurs is to find an old UNIX command that hasn't yet been implemented on the web, and fix that. Marc Hedlund
- 24. talk, finger ICQ LISTSERV DejaNews ls Yahoo! directory find, grep Google rn Bloglines pine Google Mail mount Amazon S3 bash Yahoo! Pipes wall Twitter
- 25. Blogger = public email messages (1999) Instead of "Dear Bob, Check out this movie." it's "Dear People I May or May Not Know Who Are Interested in Film Noir, check out this movie. If you like it, maybe we can be friends."
- 26. Flickr = public photo sharing (2004) "When we started the company, there were dozens of other photosharing companies such as Shutterfly, but on those sites there was no such thing as a public photograph -- it didn't even exist as a concept."
- 27. YouTube = public home videos (2005) Bob Saget was on to something. Viewed 456 million times… so far.
- 28. Twitter = public instant messaging (2006) I don't think it's any coincidence that one of the people responsible for Blogger is also responsible for Twitter.
- 29. GitHub = public source control (2008) “SourceForge is about projects. GitHub is about people... A world of programmers forking, hacking and experimenting. There is merging, but only if people agree to do so, by other channels... GitHub gives me my own place to play. It lets me share my code the way I share photos on Flickr.”
- 30. “Moreover, I’m sharing my code, for what it’s worth to me to share my code... I am sharing my code. I am not launching an open source project. I am not beginning a search for like minded developers to avoid duplication of efforts. I am not showing up at someone else’s door hat in hand, asking for commit access. I am not looking to do battle with Brook’s Law at the outset of my brainstorm.”
- 32. Stack Overflow = public learning (2008) • Fun-size units of Q&A “work” • Document how much we suck, so that others might learn from it! • Leave breadcrumb trails of our awesomeness
- 33. Maximize the value of your keystrokes If nobody knows you did {x}, did you get all the benefits of doing {x}?
- 34. The onus of “interestingness” the freedom to totally suck in private vs. attempting to be awesome in public
- 35. If you you don't have any marketable skills, learn some. It's the future. We have Khan Academy and Wikipedia and Codecademy and almost the entire world's collective knowledge at your fingertips. Use it. Carl Lange
- 37. In the information age, the barriers just aren't there. The barriers are self imposed. John Carmack
- 38. “If you want to set off and go develop some grand new thing, you don't need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.”
- 39. 3. Pick Stuff That Matters
- 40. So what? everyone
- 41. The world just isn’t that into you. Unless what you're sharing … • solves their problem • provides useful information • entertains them • makes them feel like they rule … why would they care?
- 42. Every time you share something – ask yourself “so what?” If you can't answer convincingly, reformulate and try again.
- 43. If your thing in public isn’t awesome enough (or sucks) that’s OK. People won’t go out of their way to mock you. They’ll just ignore it. (people do remember successes, though)
- 44. This is The Internet. Let your freak flag fly. Find your audience.
- 45. Nobody should be more excited about your mission than you.
- 46. How do I know if this matters? What cool thing did you do for someone else today? (psst… Stack Overflow isn’t really a site about programming, it’s where we trick peers into reading, writing, experimenting, and learning with each other.)
- 47. “It's better to be safe than sorry” is such crap. You know what's better than being safe? Being AWESOME. codinghorror
- 48. 1. Embrace the Suck 2. Do It In Public 3. Pick Stuff That Matters #atlassiansummit
- 49. Thank you!
Editor's Notes
- #3: http://www.scottberkun.com/essays/46-why-software-sucks/
- #5: http://www.scottberkun.com/essays/46-why-software-sucks/Most software sucks
- #6: http://harmful.cat-v.org/software/
- #7: As seen in Breaking Bad and Code Complete
- #10: http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.htmlLet’s endeavor to fix ourselves before accusing the world of being broken.
- #12: Not only is failure an option, failure is the default
- #13: Instead of spending three months fixing up this version in a sterile, isolated lab, you could be spending that same three month period listening to feedback from real live, honest-to-god,annoyingdedicated users of your software. Not the software as you imagined it, and the users as you imagined them, but as they exist in the real world. You can turn around and use that directed, real world feedback to not only fix all the sucky parts of version 1, but spend your whole development budget more efficiently, predicated on hard usage data from your users.Now, I'm not saying you should release crap. Believe me, we're all perfectionists here. But the real world can be a cruel, unforgiving place for us perfectionists. It's saner to let go and realize that when your software crashes on the rocky shore of the real world, disappointment is inevitable -- but fixable! What's important isn't so much the initial state of the software -- in fact, some say if you aren't embarrassed by v1.0 you didn't release it early enough -- but what you do after releasing the software.The velocity and responsiveness of your team to user feedback will set the tone for your software, far more than any single release ever could. That's what you need to get good at. Not the platonic ideal of shipping mythical, perfect software, but being responsive to your users, to your customers, and demonstrating that through the act of continually improving and refining your software based on their feedback. So to the extent that you're optimizing for near-perfect software releases, you're optimizing for the wrong thing.There's no question that, for whatever time budget you have, you will end up with better software by releasing as early as practically possible, and then spending the rest of your time iterating rapidly based on real world feedback.
- #14: Which is a more efficient use of your time? Duh.
- #15: http://www.codinghorror.com/blog/2007/02/boyds-law-of-iteration.htmlColonel John Boyd was interested not just in any dogfights, but specifically in dogfights between MiG-15s and F-86s. As an ex-pilot and accomplished aircraft designer, Boyd knew both planes very well. He knew the MiG-15 was a better aircraft than the F-86. The MiG-15 could climb faster than the F-86. The MiG-15 could turn faster than the F-86. The MiG-15 had better distance visibility.The F-86 had two points in its favor. First, it had better side visibility. While the MiG-15 pilot could see further in front, the F-86 pilot could see slightly more on the sides. Second, the F-86 had a hydraulic flight control. The MiG-15 had a manual flight control.The standing assumption on the part of airline designers was that maneuverability was the key component of winning dogfights. Clearly, the MiG-15, with its faster turning and climbing ability, could outmaneuver the F-86.There was just one problem with all this. Even though the MiG-15 was considered a superior aircraft by aircraft designers, the F-86 was favored by pilots. The reason it was favored was simple: in one-on-one dogfights with MiG-15s, the F-86 won nine times out of ten.Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.The next question Boyd asked is this: why would the F-86 iterate faster? The reason, he concluded, was something that nobody had thought was particularly important. It was the fact that the F-86 had a hydraulic flight stick whereas the MiG-15 had a manual flight stick.Without hydraulics, it took slightly more physical energy to move the MiG-15 flight stick than it did the F-85 flight stick. Even though the MiG-15 would turn faster (or climb higher) once the stick was moved, the amount of energy it took to move the stick was greater for the MiG-15 pilot.With each iteration, the MiG-15 pilot grew a little more fatigued than the F-86 pilot. And as he gets more fatigued, it took just a little bit longer to complete his OOPA loop. The MiG-15 pilot didn't lose because he got outfought. He lost because he got out-OOPAed.
- #16: http://www.codinghorror.com/blog/2007/02/boyds-law-of-iteration.html
- #17: By “embrace” I mean acknowledge that the sucking will always be there in some form, so the challenge is to learn from it, adapt and improve on it. That is what you should be optimizing for, the process of improvement.
- #19: http://www.codinghorror.com/blog/2007/04/when-in-doubt-make-it-public.html
- #20: http://www.kottke.org/07/03/public-and-permanent/
- #21: http://www.kottke.org/07/03/public-and-permanent/
- #22: http://www.youtube.com/watch?v=_OBlgSz8sSM
- #23: http://www.kottke.org/07/03/public-and-permanent/
- #24: Given enough breadcrumb trails, you get Wikipedia and Stack Overflow.
- #25: http://www.codinghorror.com/blog/2007/05/maximizing-the-value-of-your-keystrokes.html
- #26: The input box on twitter should be subtitled: BE INTERESTING. You are performing, not just being. So put some damn effort into it!
- #27: You don’t need to be John Carmack. This self-perpetuating cycle of people helping other people in public. Carmack shared his code; Quake, Doom, Wolf3D are all open source now!
- #29: http://www.codinghorror.com/blog/2006/03/users-dont-care-about-you.html
- #30: http://www.codinghorror.com/blog/2006/03/users-dont-care-about-you.html
- #31: http://www.codinghorror.com/blog/2006/03/users-dont-care-about-you.html
- #32: you will be remembered for your successes; the more things you try, and learn from, the more likely you are to get to a success.
- #34: You should be just shy of religious about your mission from God.
- #35: http://www.codinghorror.com/blog/2011/02/how-to-write-without-writing.htmlWorks on a selfish level, works on a micro level, works on a macro level.
- #36: Safety is a trap.