Although, I should point out that reading code is not the same as reading tutorials. Reading code occurs with a kind of intent and focus that is missing when you don’t know much, and thus you may end up falling into the trap of studying multiple tutorials without really trying out much yourself.

Tutorials include some code which is intended to be exemplary and simple enough for a new programmer to make sense of, so I wouldn't discount it as a part of reading code. Practical code does not always have those properties, although you'd certainly be missing a lot if you only read code from tutorials.

I completely agree with the claim "There is no substitute for doing", and I might even say that code you read without running and tweaking it doesn't count.

Trying to learn to become a developer from tutorials is like trying to become a carpenter by reading instruction manuals for saws, nail guns, &c.

To learn how to implement computer programs, read books about it.

We might have different ideas about what constitutes a tutorial. Online tutorials vary massively in quality, but something like the official Python tutorial https://docs.python.org/3/tutorial/ is a fine resource. I would even say that the categories are not mutually exclusive - I would call "Structure and Interpretation of Computer Programs" both a book and a tutorial. Different people probably find different resources most helpful.

Also, "To learn how to implement computer programs, read books about it." contradicts the original comment's "There is no substitute for doing" more than I'm happy with.

I wouldn't call it a tutorial. It's the reference manual, but with more words and some stuff about pip and so on to make it more palatable to someone who isn't already initiated.

You need to start by reading somewhere, or you'll probably not get anywhere, as evidenced by pretty much zero office grunts using web browsers every day having figured out the JS console and application development on their own without reading about it. I recommend books over tutorial texts.

But yeah, as I alluded to, you need to build stuff and learn from other builders.

Indeed it's not general advice, it's to me specifically, who used to procrastinate a lot under the guise of learning.

Same. I would fall into the same trap. One more article, another tutorial, another chapter of a book… juuust to make sure I understood the concepts; and what actually helped? Just coding, getting it wrong, fixing it, getting it wrong, fixing it, etc.

But you're not going to realize which way it's better unless you've written the bad code before.

Tangential, but I think that's the problem with trying to learn from design patterns.

I read about them and tried to apply them.

That's backward and didn't produce anything good.

I started to understand them by doing it the other way around:

- Coding, solving problems.

- Reading other people's sources.

- Then reinventing half a terrible design pattern.

- Later on, looking at a book: "ohhh, that's what I tried to do" or "ohhh, hence the snippet in that source".

- Now I can discuss with people about the pattern and name my code entities according to that.

Design patterns are a communication tool.

I think reading code to understand because you forked a project and want to continue it is very different to following tutorials.

I'd definitely agree that reading others' code can be a good way of learning, especially if you take the time to disassemble it line by line and look up things like what language features and functions they're using, how it's structured, etc.