Just trial and error mostly, and digging through example code. And learning to google. I always thought everyone just knew how to look for solutions to their pr

Just trial and error mostly, and digging through example code. And learning to google. I always thought everyone just knew how to look for solutions to their problems online, but when observing others learning to code I realized this is not the case. It takes practice to know how to word what you're searching for. But to go on a bit of a tangential rant about doing it "on our own": I don't think many people do it on their own _really_. Most people eventually get to a point where their code is out in the world for feedback. Whether it is something they're getting reviews on at their job, or a personal GitHub account, or their blog. I learned enough to hack stuff together through trial and error in a little bubble to start with, but then I started blogging and getting involved in the community of a framework I'd been using. I would post questions and try to contribute answers, and all of that expanded my knowledge (even answering a question usually involves learning). Later, as a junior programmer, I was on a team that had a _very picky_ teammate. He'd point out every nitpick he could in code reviews. Things that might not necessarily "matter" in practice in _that_ particular scenario, but that were just not as efficient or well implemented as they could be. I put "matter" in quotes because my mindset is now: of course it matters. Knowing what tradeoffs I'm making and not getting complacent with quality always matters, as I learned from these reviews. And when reviewing my code he always asked "Why" questions. Why did I chose to use this data type vs that one? Would a hashset be better here? Why did I go with a LINQ method? What iterations are involved in this, and why do we need it? Why is there a null check here, why would this ever be null (a harder question than one might think considering we were working in a huge, old, proprietary codebase)? Every code review was a bunch of questions and improvements, and it was extremely useful. I learned to predict the kinds of questions he'd ask me and look for answers in advance, often finding better approaches in the process. And when he asked "Why" in the next review, I'd get to explain exactly why, and how other options were subpar in this case. I'd credit him with a very big chunk of my development as a programmer: mostly learning about the importance of why I'm doing something this way vs another way, digging into internals, deciding if the performance tradeoffs of my approach are worth it (and _knowing_ the performance tradeoffs), and paying attention to details. I'm technically what people refer to as "self taught", but I definitely didn't do it on my own.