If you're reading this abstract, you're not awesome enough. Attend this session to unlock the secrets of Jeff Atwood, world famous blogger and industry leading co-founder of Stack Overflow and Stack ...
If you're reading this abstract, you're not awesome enough. Attend this session to unlock the secrets of Jeff Atwood, world famous blogger and industry leading co-founder of Stack Overflow and Stack Exchange. Learn how you too can determine clear goals for your future and turn your dreams into reality through positive-minded conceptualization techniques.* Within six to eight weeks, you'll realize the positive effects of Jeff Atwood's wildly popular Coding Horror blog in your own life, transporting you to an exciting new world of wealth, happiness and political power.
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.
Not only is failure an option, failure is the default
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.
Which is a more efficient use of your time? Duh.
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.
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.
The input box on twitter should be subtitled: BE INTERESTING. You are performing, not just being. So put some damn effort into it!
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!
How to stop sucking and be awesome insteadPresentation Transcript
How to Stop Sucking and BeAwesome InsteadJeff AtwoodCoding Horror, Stack Exchange, Stack Overflow
Q:What does it mean when something “Sucks”?
• This doesnt do what I need• I cant figure out how to do what I need• This is unnecessarily frustrating and complex• This breaks all the time• Its so ugly I want to vomit• It doesnt map to my understanding of the universe• Im thinking about the tool, instead of my work
And folks, lets be honest. Sturgeonwas an optimist. Way more than90% of code is crap. Al Viro
Q:Why do we suck?
A:Because we’re software, too.
“The main reason we tendto focus on the technicalrather than the human sideof the work is not becauseits more crucial, butbecause its easier todo.”
The common thread in allmy failed projects is…
The First Rule of Programming:It’s Always Your Fault. codinghorror
1. Embrace the Suck
We make shitty software… withbugs! Dave Winer 1995
“Software is a process, its never finished, itsalways evolving. Thats its nature. We knowour software sucks. But its shipping! Nexttime well do better, but even then it will beshitty. The only software thats perfect is oneyoure dreaming about. Real softwarecrashes, loses data, is hard to learn and hardto use. But its a process. Well make it lessshitty. Just watch!”
Version 1 Sucks, But Ship It Anyway codinghorror
3 months in development vs.3 months of user feedback
Boyd’s Law of Iteration:speed of iteration always beats quality ofiterationWhere you are today doesn’t matter somuch, compared to where you’re goingtomorrow.
My goal is to suck less every year. codinghorror
2. Do It In Public
One of my favorite business modelsuggestions for [web] entrepreneurs is to findan old UNIX command that hasnt yet beenimplemented on the web, and fix that. Marc Hedlund
Blogger = public email messages (1999)Instead of "Dear Bob, Check out this movie."its "Dear People I May or May Not KnowWho Are Interested in Film Noir, check outthis movie. If you like it, maybe we can befriends."
Flickr = public photo sharing (2004)"When we started the company, there weredozens of other photosharing companiessuch as Shutterfly, but on those sites therewas no such thing as a public photograph -- itdidnt even exist as a concept."
YouTube = public home videos (2005) Bob Saget was on to something. Viewed 456 million times… so far.
Twitter = public instant messaging (2006)I dont think its any coincidence that one ofthe people responsible for Blogger is alsoresponsible for Twitter.
GitHub = public source control (2008)“SourceForge is about projects. GitHub isabout people... A world of programmersforking, hacking and experimenting. There ismerging, but only if people agree to do so, byother channels... GitHub gives me my ownplace to play. It lets me share my code theway I share photos on Flickr.”
“Moreover, I’m sharing my code, for what it’sworth to me to share my code... I am sharingmy code. I am not launching an open sourceproject. I am not beginning a search for likeminded developers to avoid duplication ofefforts. I am not showing up at someoneelse’s door hat in hand, asking for commitaccess. I am not looking to do battle withBrook’s Law at the outset of my brainstorm.”
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
Maximize the value of your keystrokesIf nobodyknows you did{x}, did you getall the benefitsof doing {x}?
The onus of “interestingness” the freedom to totally suck in private vs. attempting to be awesome in public
If you you dont have any marketable skills, learnsome. Its the future. We have Khan Academy andWikipedia and Codecademy and almost the entireworlds collective knowledge at your fingertips.Use it. Carl Lange
In the information age, the barriersjust arent there. The barriers are selfimposed. John Carmack
“If you want to set off and go develop somegrand new thing, you dont need millions ofdollars of capitalization. You need enoughpizza and Diet Coke to stick in yourrefrigerator, a cheap PC to work on, and thededication to go through with it. We slepton floors. We waded across rivers.”
3. Pick Stuff That Matters
So what? everyone
The world just isn’t that into you. Unless whatyoure sharing …• solves their problem• provides useful information• entertains them• makes them feel like they rule… why would they care?
Every time you share something – askyourself “so what?”If you cant answer convincingly, reformulateand try again.
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)
This is TheInternet.Let your freak flagfly.Find youraudience.
Nobody should bemore excitedabout yourmission than you.
How do I know if this matters?What cool thing did you do for someone elsetoday?(psst… Stack Overflow isn’t really a siteabout programming, it’s where we trick peersinto reading, writing, experimenting, andlearning with each other.)
“Its better to be safe than sorry” issuch crap. You know whats betterthan being safe? Being AWESOME. codinghorror
1. Embrace the Suck2. Do It In Public3. Pick Stuff That Matters #atlassiansummit
Fredrik Magne
1–10 of 16 previous next Post a comment
1–10 of 16 previous next