The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects.
That's an option, but not the only option.
For big shared mature projects, I treat each commit (to shared branches at least) as a presentation, where I try to describe exactly what changed, how, why, and to preemptively answer any questions I suspect will come up in the code review, clean up unnecessary or unrelated changes, cross linked to any task tracking items and bugs, the code review itself, any docs I might've updated in tandem, .... the description will often be longer than the actual code changes. With a quick summary to start, so you won't typically need to read the rest, of course. After the review and submit, I'll ping QA with some stuff I think might be worth testing once the build goes green. My commit messages, at least, tend to be better than any of my coworkers.
For solo seed projects, on the other hand, I take 5 seconds to try and describe what it was I did in the past X minutes. I try to remember to commit often enough that this doesn't devolve into "Changed stuff" because I forgot to commit for a day and touched 20 different things, but it happens - making those commits worse than any my coworkers generate, but still better than no VCS. They come in handy for tracking down bugs and such.
> The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects.
Most of these had drafts and earlier revisions (or versions.) I agree that VCS is not mandatory mandatory, but the entire reason I switched to git (from SVN) was that "git init" is super low friction for getting new projects under VCS. That it handles branches way better and enables distributed workflows are mere side benefits.
Code is different. There are many times that I have been developing and I do something to my code that causes mystery behavior, and I don't catch it until perhaps days later. Being able to walk backward in time and see when the problem first occurred is invaluable.
I used to really like using Visual Source Safe. It was so easy to set up and integrated directly with Visual Studio, there was no excuse not to have a VCS. Too bad it had a reputation for garbling itself (something I never had happen as a single dev).
Having to learn a VCS at the same time you are learning the difference between a parameter and an argument will cause more harm than good for a novice.
I wouldn't recommend it to someone at the hello world level, but would not long after. The industry is plagued by people that don't know how to use source control.
I don't even understand "treat everything as a series of patches" as that's not really a VCS workflow unless you are Linus.
Not true. These things usually go through many drafts and revisions, and the previous drafts are usually available to check out.