
Start before you think you’re ready - ingve
https://austinkleon.com/2019/11/05/start-before-you-think-youre-ready/
======
DayDollar
Encourage others to take impossible risks. Theire failure and corpses build a
bridge to your success. Try to see obnoxious "You-can-do-it-talks" not as ego-
pumping, but as leveraging of stupid people into free R&D. Do not be first,
find others who are stupid enough to develop and research for you- invest just
enough, to become a goto adress once they are desperat- skin the carcasses. Be
the general in the fifth row of the army, who will be painted as victorious,
while all those "inspired" men, are laying dead and dieing at his horses feet.

~~~
RobertRoberts
Some people have bad motivations, but that is not true for everyone saying
these things.

I had no choice, I couldn't do anything but start a business, I was a failure
as an employee because of how I looked at life and the process of
building/creating. I was always at odds with my employers to make things work
better. (I was told to work slower and less hard because I made others look
bad _sigh_ )

So what do you say to someone like me? I need to hear "you can do it" because
even though I am inclined to do it anyways, it's still really hard to build
your own business.

This kind of information is incredibly helpful (encouraging) for me in my
situation at this point in time. For many others it's not good advice.

~~~
throwaway35784
> So what do you say to someone like me?

Welcome to the club! You are an entrepreneur. It is really hard. Depressingly
so sometimes. You are on your own because you can do it!

Learn to sell. Learn what selling is. Find a problem you have. Solve it in a
repeatable way. Sell the solution.

Talk to people. What are their problems?

Repeat. Build up multiple cash flows. Software. Real estate. Consulting. Find
entrepreneurs near you. Team up.

You can do it. Many people way less capable than you are already have.

Find an existing solution. Solve it better. You don't have to be first. Just
be better. You already are.

You can do it. I know you can. Be relentless in the face of overwhelming odds.

You can do it! I did. We did. Everyone you know will think you are crazy. You.
Are. Not.

You are wonderful. You make the world a better place. Keep at it!

~~~
Answerawake
I wanna be like this...but I just don't have the energy and discipline so I
have failed before I even began.

~~~
ozzmotik
we are all born lacking all the things that we currently possess. just because
you don't have something right now doesn't mean you can't develop and
cultivate it over time. all it takes is being willing to grind and even suffer
a little bit if necessary to develop it. i have the same problem myself but im
at a crossroads in my life where i just can't sit around being upset with
myself for not having the skills and such that i desperately need to live a
functional and fulfilling life, so i understand the difficulty. you're not
alone. just know that you can do it if you keep on keeping on, i believe in
you!

------
kaycebasques
> Dude, sucking at something is the first step towards being sorta good at
> something.

\--- Jake the Dog [1]

Maybe not exactly on-topic, but ever since I heard this quote it's been my
mantra whenever I'm learning something new. For example I took a beginner's
hip hop dancing class last night. A younger me would have been very
embarrassed at how uncoordinated I was. That embarrassment probably would have
kept me from going back to the class. That mantra helps me remember that it's
natural to be bad at first, and you simply have to be at peace with the fact
that you're going to suck for a while if you're ever going to actually build
the skill.

[1]
[https://www.youtube.com/watch?v=Gu8YiTeU9XU](https://www.youtube.com/watch?v=Gu8YiTeU9XU)

~~~
wsinks
Congrats on taking the first class! I forced myself to do something similar
after a nasty breakup, and the first 4-6 classes were brutal. Then I finally
got the hang of it!

Glad you aspire to be more like Jake the Dog.

~~~
kaycebasques
> the first 4-6 classes were brutal

I’ve also been thinking about this a lot lately as I play piano more
consistently. When I first learn a song it’s _agony_. I’m straining my brain
so hard to figure out a reasonable fingering. The first week or two (assuming
practice every day) is likewise quite tough or draining. And then muscle
memory kicks in and I’m amazed that I’m able to play the song faster than
expected. I feel like this process is way more applicable to learning in
general than I used to give it credit. For some reason piano just makes the
entire process crystal clear.

~~~
otterpop
Learning is such an incredibly interesting topic for me. The concept behind
something like machine learning is easy enough to understand- especially since
you can implement everything by yourself and know exactly how it works. 'Human
learning' is just so spectacularly abstracted from these models that it leaves
me wondering how the heck we actually learn anything. Some examples like your
piano playing and muscle memory are some of the more straightforward ones,
where we figure something out like 'oh, this section is easier to play with
this fingering'. But, like, you're not _consciously_ drawing on all your
previous conversations whenever you talk with someone and you don't think
'that conversation went well, time to add this to my corpus of conversations
and retrain my "how to speak" module.'

I think it's beautiful that we'll never figure out exactly how learning works.

------
riazrizvi
The question is prepare more vs take a shot. Rules of thumb advocating one
versus the other are abound. Sun Tzu extols the virtue of more preparation to
defeat the enemy before engaging, while also recommending the warrior that
does not load his supply wagons twice nor wait for a second group of
reinforcements. Fools rush in where angels fear to tread, Faint heart never
won fair lady etc.

So there is advice advocating both, what to do?

I find that when you have an endeavor with several essential areas, example
with a triathlon you need to swim bike and run to complete it. Similarly for a
business you need a product-service and you need customers to sell it to etc.
Then the best approach is to get your toe wet in each area to get a feel for
what is involved. So a mistaken approach is to spend all your time building a
product that you think is good enough before starting to talk to customers.
You need parallel efforts so that you can determine the right ratio of effort
in each area to succeed. In war you would prepare your army but you would also
have a few guys harassing the enemy to feel them out...

~~~
derialstrazus
It depends on what are the consequences for failure. In war, lack of
preparation means death of your men at minimum, and the collapse of your
nation at worst. In training, failure makes you stronger. It's a good argument
for managers to create a working environment where employees are not afraid to
fail. I absolutely agree that starting early is the best and fastest way to
learn. Too many people avoid it because of the negative consequences for
making mistakes.

~~~
riazrizvi
> In war, lack of preparation means death of your men at minimum, and the
> collapse of your nation at worst.

This is the fallacy that keeps people locked in over preparing. The way past
it is to identify less risky goals that are still aligned with that particular
objective. So in war your objective is to learn the enemy's weaknesses. So you
could try trading with them, to survey their defenses. Imagine the Vikings at
Lindisfarne, they are not going to go in blind. They first build a trading
relationship, selling fish, and as friends they can see how strong the Abbey
is, how many monasterial guards there are, or when the collection trays are
the most full etc. Very little risk right? Similarly with sales, where your
risk is your reputation. Say, you can't afford to jeopardize it with your one
big connection because you spent a decade building the relationship. Well then
you go in asking for advice on your idea, something low risk, instead of
trying to make a yes-no sale.

~~~
derialstrazus
I would say that all these alternative goals you mentioned can be classified
as preparing.

~~~
riazrizvi
(Over) Preparing in the context of war or business is where you keep working
without engaging the enemy or the customer. The classic problem in startups,
which i’ve been through myself, is where you keep working on making your
product without developing your market. If you are doing sales interviews in a
startup without a product yet, then you are engaging with the customer, and by
coordinating with your product team, you will reduce the problem of over
building the product. You need to partition the problem space (the goal space,
the overall objective space) in terms of the separate essential pieces that
need to be accomplished, once you have this partition of endeavors, then you
start making progress in each channel. Over-Preparing is not defined (IMO) as
a problem of inadequate rate of progress, rather it is that you can _never_
succeed with your activities because you are not making any progress in a
critical channel, and this weirdly magnifies the perceived difficulty of the
missing piece, leading to more and more effort in the other channels. A bit
like France overbuilding their defenses with the Maginot line when instead
aggressive military action in some theater of war before WWII would have
exposed the extreme inadequacy of their tank and soldier communication
methods.

I feel like this would be a lot easier to explain by phone. My email is
riazrizvi at gmail, if you want to set that up. I’m on Pacific Standard. Open
invite to anyone.

------
paulryanrogers
The counterpoint being that "months in the lab saves hours in the library"
(Westheimer)

~~~
eindiran
In the world of software, I think this counterpoint definitely applies. When
faced with a new problem, especially when greenfielding, I sometimes have the
impulse to just jump in and start writing code. Almost every time that I
succumb to that impulse for a complex problem, I discover weird edge cases and
lots of little issues which could have been avoided by further contemplation
at the drawing board. Stated in a similar format: a lot of refactoring can be
prevented by a few extra hours at the whiteboard.

~~~
tstrimple
I've also seen people do a ton of up front design, only for things to fall
apart quickly during the implementation. I'm still largely a proponent of
writing code sooner rather than later. Iterative development. Prove out
concepts in isolation along the way. Rewrite and integrate as appropriate. But
obviously you've got to do some upfront work, otherwise you might write custom
software for things which have off the shelf solutions.

~~~
bballer
I find that as long as you start with the DB schema and core interfaces
(system level rather than code level) and then move to framing out the general
pillars of the code that you often will get 80-90% right. Refactoring will be
a plenty but that is true in every project no matter the upfront planning.
Just don't miss any edge cases which rewire your schema and you generally can
keep a good pace on forward progress. Also it's generally true that the larger
(see more complicated) the problem the more planning one should generally do.

------
chipotle_coyote
It's perhaps worth keeping in mind that Kleon is giving this advice about
_writing books,_ and that in context, this isn't "you can do it" pithy advice
of the sort that DayDollar's comment is mocking. The quote from David
McCullough seems to be at the heart of his point:

 _" When I began, I thought that the way one should work was to do all the
research and then write the book. In time I began to understand that it’s when
you start writing that you really find out what you don’t know and need to
know."_

You _do_ have to do some research; you don't charge into your project with no
plan. But not only does trying to make the Most Bestest Completest Plan Ever
end up being a form of procrastination (see all those folks who've spent years
doing worldbuilding for their great epic fantasy novel but still can't tell
you what the protagonist's character arc is, or possibly even who the
protagonist is, period), it turns out that once you start actually working on
the project you get a much, much better sense of what the plan needs to be.
You figure out what to write in that part of your outline that says "subplot
about Gail's past starts here". You start figuring out more about what the
Thing your [Insert Thing] as a Service startup actually needs to insert and so
on.

~~~
kpennell
Exactly. People somehow mis-read this as generic advice perseverance porn or
something like that when the original essay is just about starting something
like an essay/noel (while feeling underprepared) vs. justifying delays through
excessive research

------
kstenerud
I've always taken this approach. Before I wrote KSCrash [1], I didn't have a
CLUE how crash managers worked. In fact, here's my first implementation of a
crash handler [2], which did EVERYTHING wrong. I ended up innovating a number
of things that were thought impossible at the time, but are commonplace today
(such as tapping into the Mach error handlers).

It was the same for the Musashi 68000 emulator [3]. Before I wrote this, I had
no experience with emulation other than playing one of the Pac Man emulators
in the 90s, and yet the first iteration outperformed the x86 assembler core in
Mame by 15%, and thus replaced it in the next version.

6 months ago, I didn't have a CLUE how ieee754 floating point worked. Now I've
developed a floating point compression algorithm [4], which is being used in
Concise Binary Encoding [5], also something I've never tried before.

You absolutely should try diving into things before you know what you're
getting into. Even if it doesn't turn out the way you wanted, you're in for
one hell of a ride, and what you'll learn is priceless.

[1]
[https://github.com/kstenerud/KSCrash](https://github.com/kstenerud/KSCrash)

[2] [https://github.com/kstenerud/Crash-
Manager](https://github.com/kstenerud/Crash-Manager)

[3]
[https://github.com/kstenerud/musashi/](https://github.com/kstenerud/musashi/)

[4] [https://github.com/kstenerud/compact-
float](https://github.com/kstenerud/compact-float)

[5] [https://github.com/kstenerud/concise-binary-
encoding](https://github.com/kstenerud/concise-binary-encoding)

------
tentboy
Struggled with this a lot when I started studying foreign language.

I spent way too much time deciding between Turkish, Russian or Japanese and
trying to justify my decision with arbitrary metrics of usefulness.

In the end I went with Japanese as I had the most interest in the culture, but
then ran into another phase of paralysis by analysis in determining the most
efficient study methods.

Finally bought a "recommended" textbook, instead of endlessly searching for
the perfect learning resource and just got to it

~~~
tombert
I'm going through this now; I've wanted to learn Esperanto for awhile now, had
similar experience going through YouTube trying to find the most optimal way
of learning it, looking at reviews of different methods, when in reality I
would have been better off choosing virtually _any_ of the tutorials out there
and just going with it.

To those curious, I've settled on Duolingo just because I realized I should
just choose something, and it's free.

~~~
jodrellblank
Felicxajn studojn! Check out the KernPunkto podcast for themed audio,
"Esperanto Variety Show" Youtube channel for vlog audio, and Reddit
/r/Esperante for text shorter than a book, and the /r/Esperanto [1] Discord
("Diskordo" in the sidebar) for text chat, and very occasional voice chat, but
I suspect other tools are better for that (Amikumu?).

[1] /r/Esperanto is about Esperanto the language, meta-commentary or learning,
often discussed in English. /r/Esperante is any topic, where the content is in
Esperanto.

~~~
tombert
I will definitely check out the podcast; at what level do you feel I'll be
able to listen to it and understand a reasonable percentage of what they're
saying?

I've only been doing the Duolingo course for a little more than a week, and
while I have enough grammar to do some _very_ basic sentences, I'm far from
fluent.

~~~
jodrellblank
I don't know how to guess, I'd been learning on and off for a long time before
I started listening, and I still can't understand all of it fluently. The
things I like about their podcast particularly to recommend it is that it's a
lot of content - 30 minutes or more at a time and loads of episodes, of
consistently good recording quality, it's two people and sometimes a guest
talking quite clearly so it's very regular speed and accents to get used to,
and they talk about a topic each time so there's quite a lot of repeated
vocabulary during one episode, and it's all talking no cuts to music.

------
ergothus
Some people need a push to dive in, because they'll never feel ready. That's
whom the article uses as examples.

OTHER people though, they know that, from where they are at now, they'll be
past the "challenged" stage and be put into the "fear" response - overwhelmed,
unable to make progress forward because the anxiety is crippling. The constant
pushing from those who have been in the first group just makes the people in
the second group feel worse.

We should all consider if we're delaying for good/effective/self-helping
reasons, or if we're doing so for bad/ineffective/procrastination reasons, and
then we should act appropriately.

And no one should shame anyone for their choices. Maybe the choice is wrong,
maybe we're identifying ourselves as having the wrong quality of
reasoning...but who would know better than ourselves?

Imposter Syndrome sucks - but the reality of it is no reason to cripple
yourself by diving into situations you know you aren't ready for, and then
flailing and validating the feelings you had.

------
FillardMillmore
I think the message of this article is a good one, perhaps not always
applicable depending (of course) on the individual scenario and circumstances,
but a worthwhile message nonetheless. I think a large part of whether or not
it applies is the risk assessment. If the risk is extremely great should
failure occur and there are not major time constraints, preparation should be
careful and considered. As the idiom goes, "Fortune favors the prepared".

Many, like myself, have been struck by this particular paralysis of analysis,
stuck in a studious stupefaction of research and preparation, in part due to
fear of failure and in part due to never feeling prepared enough. My
particular case is of pursuing the Red Hat Certified System Administrator
certification. I have yet to take the exam, but have put in a fair bit of time
of study with books and with online resources (some of which were paid
subscriptions, like LinuxAcademy). Of course, the stakes aren't extremely high
- if I were to fail, I'd be out $400. Not a huge amount of money but not small
change either. Needless to say, I still want to get the certification but have
yet to motivate myself to commit to it. Suffice it to say, I'm one of those
people that thrives and prospers under deadlines, whether said deadlines are
artificial or are a true limitation on my window of preparation.

~~~
freedomben
I'm also preparing for the RHCSA! It's grueling but now that I'm getting close
I feel way more confident in Linux. I'd always heard it was the "entry level"
cert (which is technically true) but at least in my eyes it really means
something. It's not something you can cram for and wing and still pass.

------
geniium
That's really just like creating a business : get out of the building and
start experimenting as soon as possible.

~~~
bdcravens
However this quote is referencing writing, and the author is primarily in
print. Getting started is definitely key, but the kind of work being referred
to here isn't typically experimented and iterated on once it's published.

~~~
geniium
And in writing you experiment too : you write things down, you read again,
correct, ask a friend to read a chapter for feedback, etc...

------
algaeontoast
This can potentially fatal for the career of a junior engineer. For personal
projects it’s fine, but taking too much risk or too big a task on without
clear boundaries can make you look like you can’t deliver or learn too slowly.

Unless I really trusted my boss I wouldn’t try this :(

------
thrifter
Perfectionism and analysis paralysis are common obstacles to progress. Also
fear of failure. In June of this year I decided to learn music theory and to
play piano, almost on a whim, and write a blog post daily about what I learned
that day[1]. I've named this year-long project "Poseur to Composer".

I'm almost halfway through and realise I have no innate abilities in music.
Fortunately the application of music is very broad and there are many kinds of
composers, so I can still achieve my goal. Also taking a lot of personal
analytics with DailyDiary.com that I can learn from once the project is over.

[1] [http://poseurtocomposer.com/](http://poseurtocomposer.com/)

------
asdfman123
Even if you fail, you might just be able to walk away with a $1 billion exit
package.

------
kureikain
man, this is so true. I have been working on a side project off and on for 5
years. sometimes I take months off, other I take 1 year, just to wait for
right time...

This month I said f*ck it and started to work on it again.

------
nbrempel
I can’t agree more. The process of struggling through the _doing_ part is one
of the best ways to learn the subject matter. Read up on the fundamentals and
get started.

------
tempodox
That depends on your area of activity. If others have to pay for your failures
with their time, money, health or lives, this is just somewhere between
ruthless and unconscionable.

------
masterrobot
why is this phrase "start before you're ready ironically show up in multiple
blogs. ex: [https://chrisachard.com/how-to-find-consulting-
clients](https://chrisachard.com/how-to-find-consulting-clients)

------
bradgnar
same with code

~~~
gwambold
Planning can be helpful when it comes to writing code

------
m463
deadlines help me, several of them.

