what's the reason in your opinion?

Because in my opinion a programming tutorial that starts from installibg the IDE is like a recipe tutorial that starts from how to use a gas stove.

it should be two different tutorials, at least

It is clearly important to understand how an IDE works, but that's the kind of knowledge that should be implied when you watch a programming tutorial.

Otherwise you need to learn two things at the same time.

Besides, IDE are usually complex enough that the two sets of skill don't overlap, so if the tutorial focuses on the programming and skims over installing the IDE, it is assuming that you can "simply" or "trivially" install an IDE such as Jetbrains Idea and be immediately ready to use it proficiently enough to learn something else with it, instead of fighting it to get things done. Which is usually the case, when I teach programming at work I focus on the programming using slides or some basic live coding using a very basic editor (vanilla sublime for example), because if I start using IDE features, people start making a lot of questions on how to do the things that I am doing that I don't even realize that I am doing them without even thinking about them, to the point that it becomes an IDE focused training. Showing that you can't take for granted that installing an IDE is a good starting point. It raises more issues than it solves.

I'm quite sure it would have been much harder for me to study Italian literature while I was learning how to read.

For every document I write, there are always a couple people for whom my document fails. It's not because they're stupid, or because I am. It's because communication is hard, and different perspectives change how information is processed. In addition, in many cases, there's simply a different use case that my document didn't account for because I didn't think of it or run into it.

So much of the time, I need to amend documents after the fact. I may need to clarify a statement, or provide alternate instructions. Often it's a detail that I thought should be universal but wasn't. And often users will simply have done something different beforehand, or out of order, or in some way not in accordance with the intended instructions.

Therefore, if I want a user to be successful with my document, it has to be complete, and thorough, and be tested by different people. It needs to not make assumptions, and it needs to be clear and concise so it can be followed in one go.

If you start getting fancy and make 50 different documents for different steps, because "logically" that makes more sense, what you will find is the user will run into a problem that the two separate documents didn't consider when taken together. Then the user will stop and try to find someone to fix their issue.

If you don't want to be tied up in support calls your whole life, one complete document is the best solution. And if you're a user who just wants to try out some sample tutorial, one complete document is the most likely to work for you without taking up more of your time.

The YouTube video that shows you installing the IDE is superior to one that doesn't. And for pete's sake you can always skip through it.

I disagree.

That's assuming that your time is infinite, the user time is infinite and you are writing a tutorial about everything.

It's usually not the case, the best documentation I have found is the kind that focus on what it is about and only that.

It doesn't imply that an introduction is not necessary, it implies that you will talk about what's in the title of the document and only that. You have to assume a certain level of knowledge, you gotta stop somewhere and say "they must know this already or this is not for them" otherwise any documentation should include a chapter on how to download the software you are about to install and how to, why not?, connect to a WI-FI network. "A tutorial that talks about it is superior to one that doesn't" isn't it?

YouTube videos do that because the algorithm rewards longer videos, tech writers to that because it makes the final document larger and larger is always better than smaller, if you are paid for the words you write.

The laziest documentation I have found is the one that starts from the origin of the universe and it only resolves in the last 5 paragraphs, "drawing an howl" style, even though it should only be about drawing the damn howl.

One infamous example is Coursera coursers, each one of them presents the same exact intros, like if it's Java or Scala, they start on how to install Intellij Idea and the first assignment is compile a project and send it to show you understood how it is done. Except the course is called something like "Writing highly concurrent distributed systems in Scala", it is marked as an advanced specialization and it makes no sense to take it if you don't know how to install an IDE. But even assuming it happens, it could be easily solved by an FAQ. And BTW you have to complete the first assignment even if this is the nth course you're taking on the subject, you already installed Intellij, already compiled a project and already completed the assignment n minus 1 other times.

Do you also believe that teaching people how to drive a car should start from how to buy one?

> what you will find is the user will run into a problem that the two separate documents didn't consider when taken together.

the opposite is usually true in my experience.

You will find that most of the times the people that are actually interested in the documentation, will be much better off with a more succinct version of the same document.

> If you start getting fancy and make 50 different documents for different steps, because "logically" that makes more sense,

Nobody said 50 different documents. Just separated the "tools setup" from the rest of the documentation or put it in an appendices at the end.

The "setup" section in most Github repos are very welcome, if they are in the in the form

  * do this
  * do that
  * run `docker run ... -p ...`