When you talk to hackers who’ve just finished an epic project, they’ll often start off with a very familiar refrain: “I had no idea what I was getting into.” And maybe they’ll even follow up with the traditional second line “If I knew how hard this was going to be, I probably wouldn’t have tried.” And that’s from people who have just finished wiping the sweat from their brow.
Don’t get me wrong, sometimes you do get in over your head and take on more than you can chew. But let’s be honest, how often does that really happen relative to how many projects end up looking easy at first, and then end up teaching you a lot along the way, often the hard way? If you’re like me, the latter happens more than the former, and I don’t think I’m particularly clever.
Instead, it’s just the nature of learning. In the beginning, you don’t know something, so you don’t realize how difficult it is, hence the first classic line. And of course it’s going to be hard, because learning is always hard. If you knew it already, it would be easier, but it wouldn’t be learning!
Whether you get through or not depends on your own stubbornness and of course the nature of the hurdles. But whether you learn or not depends entirely on you not knowing what you’re doing in the first place.
Pay good attention to the second line in the post-hack couplet, and heed its advice. Starting off on something that you don’t already know how to do provides you with a fearlessness, and the courage to try something that you might not have otherwise dared. It’s good to get in over your head sometimes. That’s where you learn, and those are the audacious projects that end up being the most successful.
Or they end up as horrendous failures, but we’re crossing our fingers for you. Be brave! And if you can’t be brave, be incompletely informed.
Lately I’ve completed many of my projects, as opposed to earlier days when I’d frequently let feature creep get the best of me.
The beauty of my main hobby, home automation is that it’s very modular and you can build many small, single purpose things and integrate them into something bigger.
Yay for finishing small projects. I’ve increasingly moved to the Linux approach: do one thing and do it well.
That’s the UNIX philosophy. Linux philosophy is more like “Have it 80% done and then abandon it.”
Then there’s the Microsoft philosophy… have it 20% done, convince everyone it’s the best thing ever, push out updates of unfinished features, and then announce it’s end of life and end support.
That’s the way I do most things. I’m not proud of it, but when I have learned what I wanted to learn, I leave “the easy part” undone. Not always the easy part is as easy as it seems…
Well, among my friends “I had no idea what I was getting into.” is already often followed by “But man, I learned so much along the way!”, so no objection from me
“If I knew how hard this was going to be, I probably wouldn’t have tried.”
If you don’t get in over your head, you’ll never get anything done. Feeling just this way about attempting an ongoing project with all analogue circuits and no microcontrollers, but I’m sure I’ll be proud when its done.
Analysis paralysis is the bane of making. You can spend too much time thinking how you would do it right, instead of just doing it come hell or high water.
> learning is always hard
Except sometimes it isn’t. Often the work itself reveals the solutions to you and it turns out to be easier than you thought.
That’s correct, but not complete.
The old saying “four hours in the lab will save you a half hour in the library” holds true. When you are actually building something physically, you should know everything you have to do and what the expected results are. If you don’t know the steps you need to take to build something, you haven’t put enough time into design.
The rule is that you don’t make design choices while building. The steps can be low resolution. “design and 3-d print an enclosure” isn’t very specific, but is tangible enough that you can knock it off without making design decisions during the process.
One form of analysis paralysis is going back-and-forth over a design choice, should I do it *this* way or *that* way, and there are pros and cons to each side and you can’t decide which is best. In that instance, you should choose one side and proceed with the build as rapid development, expecting to fail and learning why the other side was the better choice. Choosing the side based on cost (cheapest to try) or time and effort (fastest build) is a good method.
The other form of analysis paralysis is the “I don’t know how to start” form. In that case, you should find an example project made by someone else that’s closely similar and duplicate it. Master craftsmen start out by doing what everyone else does in exactly the same way – it’s how you learn technique and skill. This applies to any skill such as writing, painting, machining, sculpting, and architecture. Once the skills are available to you, you can take the discipline in new directions with your own projects.
And finally, the human brain is subject to something called “priming” (see the Wikipedia page). If you’re stuck on a problem, filling your head with lots of slightly similar objects will tend to activate the priming circuits and help your brain find a solution. Run through the craigslist “free” section and think of a project you could make with each object, go to the Salvation Army store and browse the kitchen section in terms of chemistry glassware, or the toys section and think about microcontrollers and LEDs, and so on.
Well said. I think a corollary might be that the more you do the easier it becomes to get started.
Also, I remember meeting new members at my old makerspace who would say they had no idea what to build. But over time, as they got some experience making things and saw what was possible, their list started to grow until they complained they had too many things they wanted to do.
> you should know everything you have to do and what the expected results are.
Which assumes that you already know exactly what you want out of it. Suppose for example that you want to make a new carrying case for your binoculars – there are a million ways to do it, so you get analysis paralysis just trying to imagine all the options. Instead, if you just pick up a piece of fabric or leather and start folding it around your binoculars, you get a better idea of what you can do with it rather than trying to arm-chair-philosophize yourself in advance.
And as many people show, we have distorted ideas about how things “should” work. We over-estimate our skills, or just have false information about materials and techniques, which are revealed once we actually try it. We may watch youtube videos that are fake or done using trickery, and then wonder why we can’t do it like that.
When you realize that you can’t weld 0.1 mm stainless steel sheet without a masterclass in welding and a whole bunch of expensive equipment, the plan goes out the window.
Or in my case, I tried to make a tiny pump impeller spin by induced magnetic drag through a 3mm sheet of plastic. Looked so easy in the youtube videos – didn’t work at all in practice.
>The rule is that you don’t make design choices while building.
Strongly disagree. Especially when you’re working with materials and methods that are unfamiliar, you just can’t plan ahead that far. Of course it means that you may have to scrap your project, but that’s the entire point of learning by doing – you also learn how to not do it.
weird. i don’t relate at all. i sometimes suffer from blank canvas paralysis. maybe it’s because i know when i’m starting that a very long way down the road i will be fixing and working around the decisions of today. i’ve done some big-ish projects that i was surprised to complete…i knew they were big when i started and the concept sketch in my diary was just a throw away pipedream. i wasn’t surprised the second and third steps were so hard, but rather surprised that i took them.
i was just talking to another guy who i guess is the opposite in some sense. i remarked to him that he seems to be able to very rapidly take off-the-shelf components to throw together a prototype, and i envied that. his web projects, for example, i’m gonna say (lovingly) that they tend to be bloated because he uses so much prepackaged javascript. he volunteered that he gets projects most of the way done and then loses interest in them, he has a hard time motivating to fix the last few nagging issues — bugs, performance, or features.
my projects, by comparison, are a lot less likely to make it to any usable state…but if i get them to the first functioning prototype then i almost can’t set them down until i’m to the end of my list. i think one of the reasons i have so much paralysis at the beginning is i know that after a bunch of hours of work, i’m going to have a big mess of code and face the maintainability problem. if i write it from scratch as the minimum of what i want, then that maintenance is easier…even if i forget where i started, i can read my brief code “cover to cover” in a reasonable amount of time. on the other hand, i’m terrified that if i use some off-the-shelf component, then that maintenance / fine-tuning part could be actually impossible. if i use a big library and at the end everything is great but it’s intolerably slow because of poor fundamental architecture decisions in the big library, i am sunk. or if i have to debug an interaction between mismatched dependencies within a stack of libraries, it is very hard to be sure i will ever get to the bottom of it. i don’t want to leave that landmine lurking for me at the end, so when i start out i am already thinking how to avoid it, how to be sure i have good control and visibility all the way to the bottom of the parts that i expect to be crucial.
so i don’t think i have ever underestimated the scope or difficulty of a project when starting. which is a crazy thing to say. i can’t blame you if you don’t believe me. :)
Talking with some software-developer coworkers about an Arduino in my car, one of them said something like “how did you know you’d succeed?”
The thing is, I knew when I started that I DID NOT know enough to succeed – but I knew where to find people who could answer questions and brainstorm with me when I got stuck.
That’s basically the same thing as knowing how to succeed.
And if you don’t have a more knowledgeable human to ask directly books and the internet are almost as good, assuming you have the determination to see the project through. So really the question with all projects is do you want it enough to put in the work, and is there any real danger to you or others if you get it wrong. Where if you are unsure do your research first!
Note I’m not saying you can’t do projects that have clearly dangerous elements (where is the fun in that), but do enough research or consult the experts before you dive in on a fun idea and ruin somebodies life. Failing along the way isn’t a bad thing as long as you can learn from it.
Its really a matter of expectation management, not stubbornness. When you start, if you aren’t absolutely confident that you know everything you need to know to succeed, (and even if you are) assume the project will take 8x as long as you estimate. You’ll be happy you did. It prevents the feeling of failure which creates burnout, which leads to unfinished projects.
Don’t let things like https://xkcd.com/1205/ stand in the way either. Chances are, you needed to learn because some component wasn’t premade/open source, and you had to dig deeper than you thought you would to complete your project. After all, a lot of projects these days feel like legos for engineers, where you’re just piecing together components written by other people. (This can be 3d printed components, circuit components, and/or software components. Often, all of the above!) The one catch is that to make this XKCD “invalid”, you have to make this missing component as a component rather than an integrated part or your project, which often takes even more time. However, just think how quickly you would have finished your project had this component been freely available! Releasing it as a compoent means someone else’s project will take that much less time. Of course, this leads to the discussion above about % done and release it….(which some users are parroting 1990’s tropes, but oh well)