I think the point is not to get paralysed by the desire to know everything at once.

Each question tends to just give rise to ten more. Which is fine for someone who has a conceptual understanding of programming-in-general (whether from studying it academically or just being more experienced/talented), enabling them to contextualise all that information. But for the beginner who is trying to self-tech (self-learn?), even if they understand the words, they don't really mean anything.

>Django is a application framework, written in Python, which follows the model–view–controller (MVC) architectural pattern

I may know what all those words mean and thus understand that sentence. I may know what MVC is (in that, again, I understand the words used to describe it). But until I've done a bit of Python and implemented something following the MVC pattern (and compared it to the alternatives) I don't really get it. The knowledge has to become practical to be useful.

It's better to only ask questions that go one level deep at a time, practise what you learned until you actually understand it, then ask the next level of questions.

For self-taught coders who are never going to be amazing at it but just want to make stuff (like me), I think this is very good advice.

To elaborate, the goal should be to move forward by cycling between asking questions and doing something:

Ask question <-------> Do something (ie bang out code)

The "do something" will never be perfect, so don't waste hours trying to understand the theory perfectly. Use the coding time as a way to both test your knowledge and drive further questions.

This is why it's helpful to pick a motivating project while learning to code. It keeps you moving ahead and makes sure the "question time" is truly filling in the knowledge gaps you need to fill in.

>This is why it's helpful to pick a motivating project while learning to code.

Very much the case for me, yeah. I've tried learning from tutorials and books and I just get bored. But if I come up with an idea and try to make it, I love it, learning the bits I need as I need them.

Should note that I think that if one is capable of learning the academic way, that's probably a better approach. Understanding programming in the general and thus being able to apply it to the specific. You'll certainly make better code that way.

But for me, for whom learning that way is never going to work, the ad-hoc way is fine. It doesn't really matter if my code is scrappy so long as it works and doesn't do harm.

I generally agree. For me it just pissed off the people who were trying to help me. Seems like most practitioners (and this is in any industry, I think), know what to do and how to do it, but the logical "why" behind it has long since been archived. They learned it and accepted it, but don't think about it regularly. I would ask a lot of questions about language design, programming paradigms, and stylistic decisions. I read about theoretical and conceptual lessons that were difficult to directly apply to writing my own code.

The part where I disagree is that beginners should stop because it's advised. Some foundation in theory can really help to frame the lessons you learn as you hack your first projects together. The understanding also helps you recognize patterns and learn some vocabulary. When you're naturally ready to say "screw the theory, let's just do it" -- that's when you'll make measurable progress.

There's a line where you have to stop asking questions (lest you end up at the big bang). Experience will guide you in narrowing down where that line exactly is - over time, you better know what you don't know and don't need to know.

I'm also a proponent of constantly asking "why? how?", but at the beginning, you have to at least pause between your questions to process what's happening, and sometimes trust that you have enough to work with, or trust others to tell you what you don't need right away.

I agree with this, there is a line at which you have to stop. I need to know 'why' when I'm learning in order to put what I'm learning in context. This can often lead to chasing rabbits down innumerable holes.

Learning to stop asking why and at what point to just accept a certain level of understanding and move on has been tough for me.

Stopping asking right now doesn't preclude coming back later to flesh out your knowledge or course, which I've also found myself doing and it works well enough.

I think the point is to stop asking broad question like "Why doesn't this work?" before trying to figure it out yourself. In the process you will learn much more than just have the question answered in an equally broad form of "Oh there's a semicolon missing here". You still don't know why that semicolon was required in the first place afterwards.

#4 is phrased badly. Don't stop asking questions. But do identify which questions are relevant to getting your stuff done and which are sidetracking into irrelevant stuff. You don't need to know how a webserver works as a newbie. You should know how it works when you're starting to tune for performance.

both works: asking questions or not asking questions.

it mainly depends on the person

some ppl will learn by doing, they just want to go out there, break stuff, break it, break it, break it again and then they understand it

other ppl will want to know the subject even before writing the first line of code, so they ask questions and questions till they feel they have the thing figured out and they can start

yet other ppl will make an honour point to never ever ask a single question, they would rather spend hours reading doc, specifications, RFC, and whatnot

Who is to say there is a best way? I don't think there is

as a dev what I don't like is beginners asking a bit too obvious questions when all the answers are in the documentation if they took few minutes to read it, and what I really don't like is ppl asking questions feeling entitled to an answer like you owe them

but again it's my personal view on the thing, it's different for everyone

for example, I'm mentoring a friend and he often comes "I will bother you again with a question" (he is learning JavaScript) and it does not bother me at all, whatever the question is: 1. already agreed to help him and 2. it's easy to answer

I would be more worried about someone who want to learn programming and who doesn't care if he/she understand stuff, or is not curious; eg. the "asking questions" part is more about being curious and/or motivated enough to understand things than the act of asking a question, there many ways to understand "asking questions" is just another tool among "reading documentation", "reading previous answers to other ppl questions", etc.

my point: the pace you learn things is totally personal, if you think asking question is faster and you are concerned about the speed then ask a question; but then I could argue in some case you can ask a question and never get an answer (stack overflow) and maybe it is faster to read the doc.

I disagree. Keep asking questions, but do it only when you don't have an answer. If you deconstruct the question at it's simpler form, chances are that you'll find the answer yourself.