When you're all alone, your entire mindset changes. It is either "do" or it doesn't ever get done. When writing the kernel for LensorOS, I didn't have anyone to talk to in real life about it (at least anyone that would understand what the hell a filesystem even is, haha). This meant that most of my work was done alone; chicken-scratched writings in countless notebooks, solving problems that have been solved a million times before. Obviously, I didn't just gain knowledge spontaneously; I still utilised the resources I had available (like the OSDev wiki, among other things). When I say alone, I'm referring to the fact that, within those first four months, the only time I asked anybody for help on how to solve an issue was through a Reddit post that got no responses. With no contributors, no one to bounce ideas off of … just me, within the eternal sunshine of my spotless mind, alone and unknowing of what I might find, I meandered onto a lesson that has stuck with me through time.

No one is there to save you.

For weeks I would battle a problem, flinging lines of code into file upon file, waiting for one—just one—solution to work. They often didn't. If I decided at this time, "I don't know how to do it, that means I can't do it without help", then I wouldn't have any programming projects. For every single one of these problems—these problems that caused me to yell in frustration, angrily write cuss words, and frantically etch my thoughts into disorganised page after disorganised page of my helpless notebook—I would go through a cycle. First, the idea would hit me; the excitement that came with it usually meant I got started right away on designing some sort of system to implement this idea. After an initial design that I thought might work, I'd jump right into implementing it. Usually, about half-way through implementing it, I would run into a road-block that made me realise my design could never work, it's inherently flawed, and I have to redesign it if I ever want this idea to come to fruition. This is where I often spent days/weeks, just desperately hoping for each attempt to be "the one".

In these weeks is when the frustration came: every time something didn't work as expected, the program crashed for seemingly no reason, or one piece of code being changed affected an entirely unrelated piece of code. In these moments, it wasn't only frustration that came, but also severe feelings of failure. My notebooks would be filled with phrases like "fucking loser", "idiot", "useless, pathetic fool", and every permutation of those you may possibly think of (and more). In those times, I heavily based my self-esteem on my accomplishments; if I didn't get what I wanted done that day, I'd be in an awful mood and wonder why I should even be alive. Needless to say, there were constant hardships throughout my journey, both mental and technical, but I never once gave up (or let my unhealthy thoughts make me do something I'd regret).

TL;DR: Oh, you have a question about how something works? Better just go ask your superior… WRONG! Chances are your superior doesn't know this specific, minute detail either, and will have to go through the same channels that you could have to get the information, and then relay it back to you. Companies don't appreciate you off-loading your work onto your coworkers, at all; they want forward thinkers, people who get the job done before it has even started. A problem is only a problem if you haven't solved it yet!

Read The Fucking Manual

I didn't have anyone to run to when I wanted to write an assembler for the Intercept compiler; I was the only one who implemented it. What I did have that I could run to when I got lost was the Intel Software Developer's Manual. That manual has everything you could possibly need to know about each and every possible instruction and encoding in x86_64. That manual was all I ever needed to write an assembler for x86_64.

Now, did I still take to Googling "how does modrm byte work x86_64"? Of course! There's no need to limit yourself to only one set of knowledge. HOWEVER! The Intel SDM does actually have everything that one may ever need to know about the ModRM byte. That is, this "rule" isn't meant to make you limit your sources of knowledge; it is to exercise the most likely avenue of getting that knowledge first, before you go crying to your peers/superiors about it.

Something is always better than nothing in the world of software engineering. GET STARTED. It doesn't matter if your whole idea of what is needed is wrong, your design is flawed, or anything like that; if you are dedicated, you will overcome all of these hurdles and get exactly where you want to go in the end (or somewhere near). For example, I had no idea how to serialise types for the Intercept compiler module description: that didn't stop me from starting up a stream and getting started on an implementation. About half-way through implementing my initial idea (Tag/Length/Value records), I realised that it wouldn't work at all for recursive types (i.e. a struct with a pointer to itself as a member). This didn't stop me; I continued implementing the flawed design, and then went back and thought about how I could change it to fix this new issue I've run into.

By continuing to work through the initial roadblock, I was able to reach a point where I made progress towards my goal of serialising types, even though I hadn't yet succeeded. With this progress, Siraide was able to come up with a fix in just a few minutes, and I implemented that in less than an hour. From my broken, shoddy design emerged a functional one.

I am not a genius or something because my terrible designs end up working in the end; it's a simple fact that if you begin building something, you will run into issues along the way. If you let these issues stop you, then you will never get anything done. However, if you are able to begin working on a solution to any problem, no matter how small, you will begin making progress on that problem. Keep doing that, and the problem will eventually be so small you don't even notice it.