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.
Start before you think you’re ready
11–20 of 80 posts
Re: Start before you think you’re ready
#12The counterpoint being that "months in the lab saves hours in the library" (Westheimer)
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 si…
[deleted]
Re: Start before you think you’re ready
#13The counterpoint being that "months in the lab saves hours in the library" (Westheimer)
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 si…
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.
Re: Start before you think you’re ready
#14Even if you fail, you might just be able to walk away with a $1 billion exit package.
Re: Start before you think you’re ready
#15Struggled 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 "recommend…
You don't really want to waste your time trying to understand why you made a choice.
If you're like me and like learning through trial and error, then try to think of it this way.
When you are trying to choose between several different methods to learn something, you're probably going to pick the most efficient method that you could understand.
If you've decided to study with "free" study tools or a free textbook, then you're probably going to pick the one that you have the least knowledge about.
Re: Start before you think you’re ready
#16The 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...
Re: Start before you think you’re ready
#17same with code
Re: Start before you think you’re ready
#18> 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.
Re: Start before you think you’re ready
#19The counterpoint being that "months in the lab saves hours in the library" (Westheimer)
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 si…
The challenge is that it's often not possible to understand which few extra hours at the whiteboard will save you the refactoring, or even which code will be worth keeping around long enough to be worth refactoring.
I've experienced both of these extremes - days of refactoring that could've been avoided by a few extra hours thinking about the problem, and days of refactoring that could've been avoided entirely by shipping the product early and realizing it was a bad idea to begin with. I think the optimal approach is actually to sketch out a simple solution first, ship it with bugs and all to a group of small trusted testers (or even just use it yourself), and then reevaluate which parts of the product are actually useful. Then throw out the 80% that's of marginal utility and really think through how to implement the remaining 20% in a solid way that you can build upon. Repeat once you have that launched, building out additional features in the same way.
Re: Start before you think you’re ready
#20The 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 advocatin…
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.