I actually think that self-doubt is a sign that you're growing as a developer. If you had asked me how hard it would have been to write an OS kernel ten years ago, I probably would have said something like "Oh yeah, that's pretty hard, it would probably take me like four months to make Linux."
If you asked me to reinvent the Linux kernel now, I would probably first say "I don't know anything about that, I'm not your guy", and if you were really insistent I'd give a huge number, like 10-15 years, with several disclaimers of "seriously, I don't know what I'm doing here, I'm pulling these numbers out of my ass".
Did I become a worse engineer in the last decade? No, I was just inexperienced ten years ago, and as a result I wasn't really able to differentiate "easy" and "hard" problems, and since I was a goofball (with too big of an ego at the time) I just assumed most projects were easy. Nowadays I have a much better handle on what I know and what I don't know, and as a result I find myself in doubt about things all the time. It's easy to get into a spiral of "I don't know to do this and omg I'm going to fuck it all up."
A single-core single-tasking (or co-operative multitasking) OS kernel is fairly easy. You just need a memory allocator, syscalls, maybe some virtual memory or process isolation (as a treat), and a basic display driver.
Writing the USB stack would probably take longer than the whole rest of the OS combined. (Though you'd be hard-pressed to write a USB stack in less than four months.)
That might be true (I don't know, I've never done it), but my point is that I would have thought that I could implement something as large as Linux or macOS in a few months, when in reality that's certainly not true even with my ~decade of experience, let alone when I first dropped out of college in 2012.
There's no reason you shouldn't have been able to. Programming basic things like an operating system shouldn't be as hard as it is. (Honestly, programming an entire OS is easier than programming within existing systems, at this point, for many applications – but only if you can cope with bare-bones serial I/O.)
You're completely missing his point. He was simply using "programming operating systems" as an example. His point still stands regardless of how easy you think something is or should be.
If your goal is to produce Linux, you've picked the wrong goal; just use Linux! But back when computers were simpler, in the months April – August 1991, one absolutely could make an OS kernel where things “seem to work” in four months.
Ok, you're very clever. Replace "building an OS" with "proving the Goldbach hypothesis" or something. I was just giving an example of what I thought was a challenging project. Clearly for you it wouldn't be challenging.
If you asked me to reinvent the Linux kernel now, I would probably first say "I don't know anything about that, I'm not your guy", and if you were really insistent I'd give a huge number, like 10-15 years, with several disclaimers of "seriously, I don't know what I'm doing here, I'm pulling these numbers out of my ass".
Did I become a worse engineer in the last decade? No, I was just inexperienced ten years ago, and as a result I wasn't really able to differentiate "easy" and "hard" problems, and since I was a goofball (with too big of an ego at the time) I just assumed most projects were easy. Nowadays I have a much better handle on what I know and what I don't know, and as a result I find myself in doubt about things all the time. It's easy to get into a spiral of "I don't know to do this and omg I'm going to fuck it all up."