5 ms·

I've never found anything that worked as well as: 1. Become aware that something I'm interested in learning exists 2. Watch and skim a bunch of videos at 2x s

• ozarkerD 5y ago
  Question driven development is a great name for it.
• Jarwain 5y ago
  Any advice for dealing with tool choice paralysis? I've been interested in getting into video editing and music production, among other things, but I tend to get stuck trying to decide between different tooling and it saps my drive. I get the idea that I should just pick one and run with it, but get stuck on trying to pick the "best". Which I guess I tend to define nebulously, since some tools might be easier to learn but others are more powerful/featureful, etc.
  • umvi 5y ago
    My rule of thumb is: if it's free choose the most popular one, if it's paid pick the perceived second best one (usually better value for your money). Version control system? Git (most popular) Linux Distro? Ubuntu (most popular) CPU? AMD (perceived second best) Rideshare? Lyft (perceived second best) DAW? FL Studio (perceived second best) This system has generally worked out well for me. Note that the popular choice is just to get me started because it usually has the best troubleshooting/community resources, years later when I'm more experienced sometimes I'll switch to something less popular (for example I no longer use Ubuntu in favor of openSUSE Tumbleweed).
    • copperx 5y ago
      So, React over Vue and Vim over Emacs?
      • kragen 5y ago
        Those might not be optimal choices—or they might be—but they are very unlikely to make the difference between project success and failure. Anything you can do with Vue you can do with React, and vice versa, with a modicum more or less effort, and similarly for Vim and Emacs. On the contrary, if you choose MooTools or YUI over React and Vue, or Notepad or Microsoft Word over Vim and Emacs, that might cause project failure. (I prefer Emacs over Vim for programming, but it's probably easier to get started with Vim nowadays as a new user. SO has 17208 #emacs questions and 26937 #vim questions.)
        • publicola1990 5y ago
          There are still things that Emacs can do that Vim can't do, I think.
          • kragen 5y ago
            Sure, like run Elisp.
      • ARandomerDude 5y ago
        > React over Vue Yes, because of market share. > Vim over Emacs Yes, because you won't need surgery.
    • vangelis 5y ago
      Why the second best?
      • simonw 5y ago
        "usually better value for your money"
    • 5y ago
  • asauce 5y ago
    It does depend on the situation, and how easily you are able to change tools down the road. However analysis paralysis can be a never ending cycle, so at a certain point you need to accept that you just need to pick one. If its a low cost, easy to switch tool then I'll force myself to stop over analyzing and just dive into the tool. Theres no better way to learn a tools shortcomings than actually using it. A high cost tool is a lot more difficult. Personally, I assign myself a deadline to pick the tool (eg this week I'll research, next Monday I'll purchase) and then I must follow through on that day. Otherwise I will just keep overanalyzing every single comparison until neither tool looks attractive. There are situations where you are going to pick the wrong tool. It happens. An example is I started music production in Logic Pro X, hated it, and ended up switching to Ableton. I spent a lot of time researching the two, but it was only once I started using them that I realized which tool suited me better.
  • nickjj 5y ago
    It's my biggest weakness, so it's definitely not like I have this fully under control. The problem I have around tool paralysis is mostly related to permanence, especially when each choice is technically really good but has their own individual known flaws. I'll fearlessly try a bunch of things out, implement the same project in each thing, compare my results and then pick one based on what feels best for me when the thing I'm implementing doesn't take a long time. Editing a specific video is a great example of something with little permanence. You can try out a few audio / video editing tools in a few days while you actively do your editing and then pick the one the best meshes with your brain and stick with it until it becomes a problem. Each video might take a few hours to edit from beginning to end, and is a self contained unit for the most part. That's what makes it feel pretty temporary to me. But for me, building a long living web app, or the idea of a SAAS app is one of the hardest things to pick a language or web framework for because you can easily talk yourself into thinking "well this is my potential life, it needs to be the right tech choice or I'm stuck with the wrong decision forever". But this is an illusion. I know it's an illusion, I've proven to myself multiple times it's an illusion and there's countless examples online showing this is an illusion but damn it, this permanence magician is really good so I often find myself going back and forth, implementing bits and pieces in 1 thing but never feeling motivated to finish because I always think there's something better just around the corner. With that said, the thing that pushes me over the edge to actually do it is usually the act of making a decision and running with it. Knowing full well this isn't a perfect solution but a perfect solution or tool or tech stack doesn't exist. It's just picking the thing that checks off the most boxes on what you like and prefer and then embracing it. In the end, nothing beats your own personal experience. If 7 people say a tool sucks and 3 people say the same tool is amazing that doesn't mean the tool sucks. It means 3 people found a tool they really like and it's working for them. Don't let reviews or others fully control your decision. Absolutely take their feedback into account but never follow the crowd for the sake of following the crowd.
  • notapenny 5y ago
    Just pick one. That's probably more simple than you'd want to hear, but there is no such thing as "best". If you search for the best in anything, you can find tons of posts/articles/whatever all suggesting different tools are the best. That's the beauty of the internet. You'll always find something to substantiate your assumptions, or in this case make you doubt them. I can only speak to your music production ambition, but I've spent way to much time looking for the best DAW, compressor/effect/synth plugin, best hardware. All those things are distractions. See which ones are popular and available for your platform and pick one. Learn to produce music first, it doesn't matter what tool you do that in, if a year from now you end up deciding you don't like your tool you can still change it. Its like worrying about which language to program in without even being able to write simple programs. Just pick one.
    • white-flame 5y ago
      Even if you like one, you should (_after_ you finished learning the first) also go through the other alternatives, for perspective. And even though you found one that worked for you, doesn't mean that others won't click even better. The only way you can truly evaluate the choice between tools is to be familiar with all of them, but yes just start with one arbitrary one that seems fine, instead of trying to learn them all before deciding. But at the end you should know something about all of them.
  • afarrell 5y ago
    Find a person (vlogger, friend, teacher) whom you feel inclined to trust and just pick what they use.
  • roamingdave 5y ago
    Very literally: just pick one, even if it's at random. People have this awesome ability to work around all kinds of inefficiencies and stumbling blocks. If you had nothing else but pen and paper which you then submit to another person who somehow feeds it to a machine you would still find ways to achieve what you want efficiently. Remember what people were able to do with punch cards! Once you have a better understanding of the thing you're learning you'll be able to make your own reasoned choices about tools.
  • kragen 5y ago
    So, there are two possible reasons it's hard to make a choice. One is that you're lacking crucial information that will make it clear that one choice is much better than the other. For example, if you've never programmed before, and you want to make some interactive web pages, it might not be obvious whether Python, C++, or JavaScript is a better language to learn. Picking Python would be disastrous, but you don't know enough to understand why yet. In this situation, you have several possible courses of action: 1. Ask someone who knows about the problem. Better, two or three people. Follow their advice. 2. Snoop on conversations between people who are doing what you want to do. Imitate what they're doing until you know enough to have opinions of your own. Nowadays with the internet this is usually pretty easy, although the web forums where leading-edge hardware designers chat mostly require not only knowledge of Chinese but also actual mainland Chinese friends to vouch for you in case you start posting stuff about Tiananmen Square and the Uighurs. This is not a new problem; my aunt had to learn German to get her chemistry degree. 3. Try several courses of action briefly, then abandon the ones that were least fruitful. The other possible reason is that, although you basically have most of the relevant information, the difference between the possible choices is very small, so it's hard to tell which one is really best. You have become Buridan's Ass; toss a coin before you starve to death in the midst of plenty.
• 63 5y ago
  The trouble I've found with JIT learning and project driven learning is that it doesn't cover things I don't know I don't know. Often, there's more than one way to solve a problem so I'll solve it with what I already know how to do, meanwhile there's actually a simpler and more efficient solution that I would know if I'd used traditional learning resources ahead of time.
  • nickjj 5y ago
    Yep, this topic is covered in the blog post, search the post for "Expectations of Question Driven Development". The TL;DR is until you write a lot of code you'll have no idea what you're doing so it's fully expected you'll be writing, refactoring and deleting code as you go. It's only after you've taken so much action that you discover the more simple and efficient solutions. Front loading all the reading and research isn't going to help you get there sooner. IMO the best time to read a book or take a course on a subject is months after you've built something real, because then you can apply and understand all of the efficient solutions and end up with a bunch of takeaways to improve what you've done. Things that might take you 1-2 days to apply after you've read the book. This is also covered near the end of the blog post btw.
    • deregulateMed 5y ago
      If you ever want to reconsider the topic of SWE not being Engineers, here's an example. It's typically not feasible to "wing it". Cost, time, and Effort make it so you need to be correct the first time. mistakes do happen, but when I switched from Design Engineering to SWE, I'm allowed significantly more mistakes. These can be inefficiencies, incorrect outcomes, bugs/errors, etc... No big deal because I can recompile. Can't do that with a half million dollar in steel molds with production on a set date. Additionally with engineering, I'll have 4 layers of management review and sign off. With programming it's subjective code reviews.
      • bigyikes 5y ago
        This seems like gatekeeping. You’re describing the awesome power of software: it can be updated and infinitely replicated and is therefore more tolerant of mistakes. Just because the field has this boon doesn’t mean that those working in it aren’t “real engineers” or whatever. Suppose technology was sufficiently advanced to make steel mold production nearly free and instant. Are the mold designers no longer engineers then? (Watch out for 3D printing, by the way...)
• netfortius 5y ago
  Foreign language learning doesn't work this way.
  • gjs278 5y ago
    thankfully basically everyone is forced to speak english
• com2kid 5y ago
  I did this to learn JS and React Native and it let me get started quickly, but wow was my code horrible. It was a good year before I stopped doing really stupid things in JS, because I only ever had learned enough JS to "Get Things Done". This was in stark contrast to how I learned Java and C#, I deep dived into the internals of the languages and their runtimes (and at one point even worked on a version of the .NET CLR!), and all the code I wrote was in a mindset where I was cognizant of exactly what the runtime was doing to my code, how memory layout looked, how the GC works, and so on and so forth. I would've spent a year being 100% more productive if I'd spent just another week or two learning JS properly.
  • MathYouF 5y ago
    This is what my intuition tells me about the idea that one should only do JIT learning and onboard to an idea only over a weekend. I'm guilty of it, but when I've taken the deeper dive, I feel it has paid dividends down the road.
• evnix 5y ago
  this works for programming, but I tried something similar to try learn some guitar and I had no luck.
• pjm331 5y ago
  I do this same loop but I’ve given up trying to learn anything quickly. When it comes to tech I don’t use for my day job I’ll do an iteration like this every 3-6 months and after 2 or 3 years I’ll have become comfortable with it. The nice thing is that while I won’t remember everything, each loop feels easier and I can go a bit deeper into the subject because the total number of brand new things I have to wrap my head around is on a downward trend.
• thefourthchime 5y ago
  ^ this, exactly what I do.