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.

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.

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.

Inexpensive/inconsequential mistakes simply enable bigger mistakes to be made. Systems grow more complicated as long as they're allowed to.

You can recompile a syntax error, but even in software, you can't back track on things like choice of language / tech stack / architectural design decisions without wasting millions of dollars.

For traditional industries, there's (presumably) some best practice or de-facto standard for many things, since most things have already been invented in the past.

For software, you have contradicting best practices with people arguing convincingly both ways. Everybody has their favorite tech stack and some end up being fads. New technologies come out every couple years, and if your project is successful enough and runs long enough, you either get stuck with old tech or spend millions of dollars figuring out an upgrade path. Sometimes the "upgrade" is actually another fad, but sometimes the upgrade is crucial to your future business.

Not sure whether these things fall under "engineering" but I don't think it's inherently less "hard" than what traditional engineers do. Sure your junior dev is not going to do this, but people who make these decisions are often called software engineers ("senior", "lead", whatever).

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

This is an interesting topic. "Engineer" is a word that people respect. "Developer" is a meh word. You'd rather want to be Software Engineer as opposed to Software Developer even though some companies call you former and the other latter despite your responsibilities and everything being exactly the same.

Common people would respect classical engineers more because they can see that they are building something tangible. And it seems many definitions for engineers everywhere seem to exclude "software", something like "a person who designs, builds, or maintains engines, machines, or structures.".

Fun story is, when I was doing medical checkup for my work the old lady saw I was marked as "software engineer", and she didn't like it and asked me for an alternative.

I believe this confusion arises between the valid definition of the act of "engineering" with another equally valid definition of the profession of engineering, which like most professions, require some sort of formal degree.

Yep at that point you can have technicians designing molds.

Stick your engineers on projects that require correct answers.

You could also be winging it when you are inventing something or building something experimental and given the thing is not large enough to last several years. E.g. when inventing a light bulb for the first time you would be iterating on it and "winging it".

I think this is more similar to science than engineering.

Learning fundamentals doesn't mean you don't code as you learn, it just means you code to learn rather than code to finish a project. Coding to learn is deliberate practice and is the best way to learn fundamentals. Just learning whatever you need to get a specific project done means you will always have a lot of holes, likely you'd get more things done in the medium to long run by practicing and learning things properly from the beginning instead.

The goal isn't to code to finish the project and ignore any questionable code you've written because "it works".

It's to write a lot of code which is practice in the end. It's expected you'll be doing an ongoing combination of writing code and looking things up as you go, but you're not looking for the first working solution that you copy / paste and move on. The topics you end up researching will lead you to write good code if you put in the effort.

There's been plenty of examples of doing this where I spent hours going over a few functions because I wanted to make sure I was doing things nicely and the journey to go from the original version to the end version lead to learning a lot. That might have been reading through 5 pages worth of search results, skimming as many videos as I could find and maybe even asking an open question somewhere which yielded code examples written by people who have been working with the language for years.

You can then use all of that as input to guide your code. Through out the process I may have written a few versions and ultimately landed on 1 based on what feels good when using it, isn't too clever, easy to test, easy to understand, runs quickly, etc. Basically all of the properties that make code good.

I use a combination of katas (repeating a task multiple times - though not necessarily with the exact same code - to polish my understanding of how to do the task) and diving into rabbit holes deliberately to stumble upon things I don't know I don't know.

I'd like to implement something like this. What sort of tasks do you define in your Kata's? I'm thinking of adding them into an Anki deck to repeat them regularly.

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.

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.

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.

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.

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.

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

Man, honestly, not too sure about this, picking the "second best" is very random and can probably affect your choices of stack/methods in the long run. Take for example the DAW part, i chose FL studio to start with for the same reason as the "best" one being pretty complicated. Unfortunately when I did switch to Ableton and saw what the industry standard was, my whole year long progress pretty much went to s*t because of how overly simplified FL is, Just an opinion.

I remember going through this and ended up learning Nuendo and Ableton. Then I realised I knew all this technical stuff without a grasp of the fundamentals. I reckon if I had, I’d have been extraordinarily more productive in FL Studio than I ever was with Ableton without it.

So, React over Vue and Vim over Emacs?

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

There are still things that Emacs can do that Vim can't do, I think.

Sure, like run Elisp.

> React over Vue

Yes, because of market share.

> Vim over Emacs

Yes, because you won't need surgery.

Why the second best?

"usually better value for your money"

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.

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.

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.

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.

Find a person (vlogger, friend, teacher) whom you feel inclined to trust and just pick what they use.

Foreign language learning doesn't work this way.

Question driven development is a great name for it.

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.

this works for programming, but I tried something similar to try learn some guitar and I had no luck.

^ this, exactly what I do.