For self-taught developers - How to build my own knowledge system during work?

Got it, really appreciate the context!

Q1 - For what it's worth, I literally have no idea what an "event sourcing pattern" is, and I have 8 years of experience, which includes multiple years TL-ing across Meta and Robinhood. 😅 I also got a traditional 4-year CS degree from UCLA, and I didn't learn this there (or maybe I forgot, I was a bad student). Tech is just full of these "lingo" terms; you're bound to encounter one (and probably a lot) that you don't know. I wouldn't see this as an inherent weakness, just you being a regular person who doesn't know everything (which is all of us!). In these situations, I just ask, "n00b question: What is "XYZ term you just mentioned"?". If you have a good team at Meta, people will totally understand these questions and be happy to answer them. Don't fear people dunking on you for not knowing, especially if you have that "n00b question" Meta cheat code, hehe.

Q2 - I totally get this one: Meta's tech stack is very custom to the point where it's almost weird. I actually didn't want to work on Big Blue/Messenger as their way of doing Android with Litho doesn't really match "real-world" Android. Here's my thoughts on how to build up more fundamental skills that are easily transferrable outside of Meta, which luckily happen as you're progressing from E4 to E5 in particular:

• Develop good high-level coding habits - This just translates to "strive to write good code". If your goal is to scramble to get stuff working as fast as possible, then yeah, you will only learn Meta's specific tech stack. But let's say you take the time to cover all edge cases, write diff reviews with great context and discussions, modularize your logic into clean abstractions and layers of separation, and think forward in terms of how your code can be extended and build flexible APIs accordingly. These are all instincts that you can take to any company and any tech stack. We have a lot of advice on how to write clean code here: [Taro Top 10] Becoming A Better Coder
• Build up strong non-coding skills - This is the stuff I love talking about and teaching within Taro! Skills like communication, mentorship, project management, timeline crafting, hiring, interviewing, running meetings, writing a great PRD - These can all be taken anywhere, especially to other large companies! Here's a couple resources on how to grow these:
  • [Course] Effective Communication For Engineers
  • [Course] Frontend System Design Masterclass - Building Playlists

All of the skills I just mentioned are all things you can become great at without a university or bootcamp degree. They're much more dependent on the team/company you work at, and Meta is one of the best software companies in the world!

Going back to the original question - Universities and bootcamps do some great work obviously, but I feel like you may be overrating their value and the more systematic knowledge they provide.

I got the traditional CS degree from UCLA, and yeah, I learned some more "foundational" software concepts like how operating systems work, networking concepts (UDP, TCP, etc), and cryptography. However:

1. I didn't find this helpful on my actual job - I just put code into Android Studio and see it on my phone. All those more lower-level, foundational things are abstracted away from me. It's not 1990 anymore - You don't need a deep knowledge of how computers work underneath to get anything done. It obviously helps, but I don't think you need it to be a great software engineer.
2. I pretty much forgot it all - Largely due to #1. I imagine a lot of folks coming from university are going to be like this as well. The vast majority of learning comes from real-world experience (i.e. doing your actual job).

On a side note, how we were taught Git and version control at UCLA was pretty bad, lol. Just "git add .", "git commit", and "git push" all the things.

I feel like bootcamps are even more tactical and less foundational as they're very time constrained, generally taking 4-12 months, way shorter than 4 years.

Lastly, if you're a stable E4 at Meta, don't worry about your previous background - You're definitely a great software engineer already! Meta is a hard company to perform at.

Interesting question - Would love to learn more! Here's some questions from me to get a better understanding around your definition of "systematic knowledge base" (I'll leave my thoughts regarding answers in a later comment):

1. Can you give an example of something an engineer coming from a degree/bootcamp background knew that you didn't know, which you felt like came from them having this knowledge base?
2. How do you feel like your lack of a systematic knowledge base holds you back? Are there any concrete problems, particularly to your work at Meta, that this is connected to?

Q1: Can you give an example of something an engineer coming from a degree/bootcamp background that you didn't know, which you felt like came from them having this knowledge base?

Recently I'm working with a group of xfn engineers closely, and they simply describe their part of the design as "using event sourcing pattern" without further detail, and our senior eng seems communicate with them well. It took me a while to google it and went through their design doc but still don't fully understand what they are trying to do. (also it's a whole new code base so I'm completely blind from that part of the context as well) For cases like this, I don't know whether it's my imposter syndrome or there's a piece missing in my technical skill.

Q2. How do you feel like your lack of a systematic knowledge base holds you back? Are there any concrete problems, particularly to your work at Meta, that this is connected to?

Over time when encounter complicated problems, I know about system design in Meta, but not any other options outside of Meta. This gives me identity crisis of who I am as an engineer and how can I live without the company and its infra. It's not holding me back at my current stage of career in Meta, but gives me the sense of uncertainty about my long term career growth.

Thank you for your detailed reply, Alex! This boils my original question to more actionable directions. Really appreciate it!