I’ve embarked on learning web development from scratch. Since I haven’t done this in a long time, it made me reflect on how I should approach learning in today’s world, starting with how I learned in the past. Hopefully, this will serve as a helpful retrospective…

¯\(ツ)/¯

As a Kid

My brother gave me a Pascal book that started with the basics: variables, conditional statements, loops, functions, and so on. For a 10-year-old just being introduced to programming, it was perfect. Those basics have stayed with me. It was a slow and simple introduction, very appropriate for a kid, though perhaps too slow for a novice adult.

As a Student

Earning a Bachelor’s in Computer Science was a lot of fun. Three years of learning and implementing various aspects of computer science theory and practice. From learning OOP, implementing TCP, and exploring a plethora of algorithms, to building a competitive bot in Unreal Tournament. There’s much to be said for a well-structured, extended educational curriculum. The fundamentals I gained there have served me well in my career. I truly believe it gave me the tools to build all the amazing things I’ve done since. But it was three years… I don’t think I have the patience for that today, not even for a full-semester course on a single subject.

As an Employee

Joining a team with a specific technology stack and plenty of existing code to learn from, along with a supportive team to help you get up to speed and accelerate from there^[1], is one of the most time- and cost-efficient ways to learn. But there can be a few challenges:

1. You usually can’t get hired without some baseline knowledge in the area. This is especially true for senior engineers, as they’re expected to contribute to the team’s direction, make decisions, and mentor junior engineers. As a result, it’s rare to learn something completely new on the job^[2].
2. You need a good team, mentor, manager, or tech lead. Lacking any of these can significantly limit your ability to learn, in addition to making the experience stressful. If the code is poor or the team is inexperienced, it’s hard to pick up good practices. And if the manager or tech lead isn’t supportive, you may not have the freedom to learn or write high-quality code.
3. Ultimately, it’s up to you to acquire deep knowledge of the technology or domain. As an employee, you’re being paid to deliver company value within budget and deadlines. Even in the best teams, you can’t take twice as long just to educate yourself. And this is where the next point comes in…

As a Lifetime Learner

As soon as I started my first job, I began reading documentation, books, and blogs to supplement my on-the-job training. It’s essential to stay up-to-date and continuously expand your technical knowledge. Otherwise, you risk falling behind, your skills become outdated, and your effectiveness diminishes. Personally, I found that without this ongoing learning, I felt less connected to the “art” of software engineering.

• Documentation: The obvious first step is to RTFM! We all do it, but we all skim too much. Going back after finishing the immediate task to read deeper into the library—why it made certain trade-offs, its best practices, etc.—is invaluable firsthand developer knowledge. Good documentation is gold!
• Books: A considerable time investment, but a good book can greatly supplement learning. For me, CLR via C# deepened my knowledge of .NET, C#, and modern runtimes. A good technical book is “skimmable”; you should be able to easily skip forward, reread, and choose the sections to focus on.
• Blogs: In some sense, they are the middle ground between books and documentation. Developer-written knowledge on a wide variety of subjects. Fabulous Adventures in Coding was a big one for me, with its deep dives into language design and C# internals. Unfortunately, with so many blogs out there today, finding well-written, knowledgeable content not generated by AI is challenging.

Open Source

Open source is like a job with better management, worse work-life balance, and absolutely terrible pay! 😀
Jokes aside, it’s a way for new engineers to gain practical work experience before being hired, for experienced engineers to explore areas their job doesn’t allow the space to, and for fun projects to turn into real-world work.

For me, open-sourcing two of my projects provided an opportunity to dive deeper into fringe technologies, learn new things, improve workflows, and simply enjoy coding!

As a bonus, during an interview with a team at Microsoft, they discovered I was the author of an open-source library they were using. And Facebook once used me in a hiring promo for having the “most starred Java open-source project” in Israel at the time.

Writing

You don’t fully understand something until you have to explain it to someone else—preferably a five-year-old. Writing down what you’ve learned forces you to slow down, go deeper, structure your thoughts, and better retain the material.

Additionally, improving my writing skills, technical or otherwise, is a nice bonus as a non-native speaker. Strong communication is a must-have skill for senior engineers.

Things That Didn’t Work for Me in the Past

A few times, I tried learning a language or framework using methods that absolutely didn’t work for me:

• YouTube: I find it very hard to concentrate and absorb technical knowledge via video. It’s also difficult to skim or skip content without losing context, or go back to review something. With the sheer number of “tech tutors/influencers” out there, it’s hard to invest time in a video/series without risking wasting time on low-quality content.
• Tutorials: A previous attempt at learning TypeScript through tutorials was a complete failure. It took forever to cover the basics, and the simple exercises didn’t leave an impression. Again, it’s hard to find quality tutorials with so much low-quality content out there.
• Books: Specifically, just reading a book without doing significant hands-on coding. Unlike reading a book that supplements current working technology, reading a book on different technology didn’t contribute enough to justify the effort.

What I’m Doing Today

With this reflection, I decided to combine reading a book or two, supplementing with smaller targeted tutorials, and sprinkling in some casual blog reading—all while working on a few open-source projects for hands-on experience. In my mind, the open-source projects will be like commissioned work, to force myself to produce at a professional level.

I’m going to approach this chronologically, staying true to my learning curve, and see how it goes…

• Started with a basic tutorial: TypeScript tutorial with VS Code.

• Skimmed TypeScript Lang as a good source for introductory info, with TypeScript for Java/C# Programmers, TypeScript Do’s and Don’ts, and TypeScript Play being helpful resources.

• Created demo apps in different frameworks to get a feel for the ecosystem—Express, React, Next.js, Electron, tsdx, Fastify, NestJS, and Epic Stack^[3].

• Read an online “book” for a deeper dive: TypeScript Deep Dive^[4]. I found it easy to read because it’s concise and to the point. The chapters on Promises/Async were especially well done; the modules, not so much. This broad but shallow coverage is okay for gaining critical mass, but I can’t say I was impressed. I wouldn’t recommend it.

• A few noteworthy posts/articles I read:

  • Visualizing memory management in V8 Engine
  • Trash talk: the Orinoco garbage collector
  • Text Buffer Re-implementation
  • Shrinking VS Code with name mangling
  • What we got wrong about HTTP imports
  • How to handle “experimental” status when adoption is significant?
  • JavaScript ECMA Versions

To be Continued…