
Be Wrong as Fast as You Can - haberdasher
http://www.nytimes.com/2013/01/06/magazine/be-wrong-as-fast-as-you-can.html?_r=0
======
SatvikBeri
The key to learning quickly is to iterate quickly and get feedback
immediately. I don't think this point is particularly controversial-it's a lot
easier to learn from a REPL than from a system where you have to wait
overnight to compile anything.

The question is how to structure your work to get feedback quickly. Feedback
can be self-directed. Bob the Builder has an idea for a building, draws up
some preliminary blueprints, and sees that his idea is unfeasible. Or it can
be external-Bob's satisfied with the design and shows it to his customer, who
then realizes that having 17 spires arranged in a heptadecagon looks stupid
after all.

This is why outlines, specs, designs, etc. are so important. The goal is not
to achieve 100% accuracy with the spec and then build the software. It's to
iterate quickly to get to 70% accuracy, and then switch to a finer level of
detail once you're not learning rapidly from the outline. It's not just about
saving time or building a higher-quality product, it's about learning as
quickly as possible.

Another fun, famous example is the Wright brothers: they had less funding and
less education than most people trying to achieve flight, but they came up
with a way to iterate in days instead of months, which meant that in a few
months they made more progress than others had made in years.

If you want to get incredibly good at what you do, find a way you can iterate
faster and learn more than others in your field. You're effectively buying
time and experience. And if you create a structure that allows _others_ to
iterate faster, you can allow a swathe of people to become massively smarter
and learn more, which to me is one of the greatest feelings in the world.

~~~
oliao
I totally agree with you there, but wouldn't it be even better if we limit the
amount of new stuff we haven't tried yet to a size small enough to keep it in
our heads? This way, we can eliminate the need for specs; discussing ideas
though speech.

~~~
SatvikBeri
Keeping it small is definitely a good idea when it's possible, but whether
that can be done depends on what you're creating.

I've found that this works when making small feature changes/additions to a
consumer web app, but fails catastrophically with B2B software that has to
interact with client systems (especially old ones!) or legal regulations. If
you start writing code after talking to the client, you'll find it's about 30%
right and often requires major architecture changes. If you iterate through a
spec you can spot a lot of problems right away, especially ones that have to
do with obscure quirks in the client's systems.

Note that a spec is essentially an outline designed to be read by and solicit
feedback from multiple people. A spec only needs to cover the things that
everybody involved can read and discuss. A developer-client spec for a product
with no UI might just be a few flow charts + a few words of explanation. A
Data Scientist-Developer spec should go into algorithms and math. A spec for a
UI-based product should primarily consist of wireframes. Etc.

------
amolsarva
What I liked most about this article is the first-person account of what it
feels like to have startup ideas. It's so exciting! Your friends love them!
It's super fun!

I guess ideas for movies and creative stuff are similar.

And for those who follow startup culture we all know there is a massive gulf
between those who try to actually do stuff and those who just tinker forever.
This guy in the article is the sad "I never tried" type.

As a guy who has built a bunch of big startups myself (a.sarva.co) I meet
these guys all the time and feel bad when I do. The only advice is DO IT!!!

It's a whole other ball of wax once you meet those guys who DO start -- it's
not just DO IT DO IT till it works (repetition). At that point you have
someone who DOES stuff. So now they/we/me must work intelligently to do
successful stuff.

I think folks in the comments here may be missing that distinction.

------
elliott99
To anyone that read this and identified strongly: I highly recommend you pick
up 'The War of Art' and 'Turning Pro' by Steven Pressfield.

Essentially,accordingly to Pressfield, those writers who identify strongly
with problems the writer has in the article would do well to adopt a "hard
hat" mentality of doing creative work; grab your lunch pale, sit in front of
the computer and suffer, and don't worry about whether what you write is good
or not-just do the damn work. 'Pretend' that you only write for money (you
don't, but money is nice).

The problem for me and I think for the writer is identifying one's ego and
with one's work. You start to worry you're not cut out, good enough, etc. But
when you start thinking of creative endeavors like grabbing your lunch pail
and heading off to the construction cite to put in a hard day's work,
everything changes. It's kinda zen like in that way. Success or failure-the
construction worker doesn't take it personally-he still has a beer at the end
of the day and laughs with his family.

That's the way I see it anyway.

------
haberdasher
The writing world might be coming around to the whole Lean Startup thing.

~~~
codewright
You don't even really have to put in those terms. The best thing you can
possibly do for your career is to be as prolific as you possibly can.

Whether it's writing, writing for comedy, programming, etc.

~~~
ludflu
over a long enough time horizon, quantity == quality

~~~
codewright
I'd take it a step further and say that quality requires quantity to come
forth.

That's partly why people who have merely dabbled in programming over a long
period of time will have a very hard time catching up to somebody that has
truly immersed themselves.

I'll hire a passionate aspirant with a cool portfolio spanning only two years
over a 20 year professional with zero side projects in most cases. (Save for
when expertise cannot be expected to be "picked up" in a reasonable amount of
time.) The word portfolio here is key.

------
intenex
One further point:

The withering self-criticism might even be merited the first few times around,
but every iteration of creation hones our skills.

Perhaps, instead of hoping that our first work is a masterpiece, we commit to
putting it out as fast as we can and aim to learn from it what we can to make
our next reiteration better.

After we commit enough atrocities, perhaps it's actually possible to hit a
place where we no longer have that withering self-criticism as it's no longer
merited. Perhaps that withering self-criticism isn't just unwarranted
insecurity - it's accurate, but the only way to get rid of it is to keep
creating crap until we learn not to create crap.

------
realrocker
I have proved myself wrong as being a professional cricketer, roboticist,
hustler businessman and lot of the other gigs. All in the quest for learning
from failing. I did learn, but after a while you realize that sometimes you
need to work on a skill/goal to the point of absolute failure before positive
results come out of it.

~~~
jimbokun
What did you learn?

~~~
realrocker
I learnt the difference between an amateur and a master.

------
tedmiston
"A promiscuous imagination like this is dangerous for writers. As an editor, I
can see that clearly."

I can't. Why?

~~~
SiVal
Because it lacks the focus needed to _ship_ something. There's a very real
danger of being so enthralled by everything--all the great possibilities--that
you can't do what it takes to ignore everything else long enough to deliver a
finished product. No matter what you're working on, it's never as interesting
as _everything else_ you could be working on.

------
cateye
tl;dr: You have to give your self the chance to try things.

