back
18 comments
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.

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.
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.

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.

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.

The writing world might be coming around to the whole Lean Startup thing.
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.

over a long enough time horizon, quantity == quality
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.

Yes! I'm writing a book about this exact idea here: https://leanpub.com/lean

The first version of the Lean Publishing manifesto, which addresses this exact point, is here: https://leanpub.com/manifesto

Disclosure: I'm the cofounder of Leanpub, and our entire startup is a bet on this being true.

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.

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.
The best thing about failing at a wide variety of things is in learning how much they are "the same" in that there are rarely any tricks involved - you just have to find, understand, and practice the fundamental ideas a lot to become more skilled.
What did you learn?
I learnt the difference between an amateur and a master.
"A promiscuous imagination like this is dangerous for writers. As an editor, I can see that clearly."

I can't. Why?

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.
tl;dr: You have to give your self the chance to try things.