Rethink the self-learning journey for a junior engineer

How most people think of programming

Most people associate programming with generating lots of codes.

And many current AI solutions emphasize alleviating the burden on humans to write code. However, the actual process of programming is heavily tied to various skill sets, including solving engineering problems, project management, and the ability to self-learn — especially when building projects as a way to progress. Here, I want to explore how we might rethink the self-learning journey for junior engineers as they attempt to learn through building projects.

What programming actually is in a project

When a junior engineer attempts to solve a problem or implement new ideas, they need to begin with technical planning, research various technologies to address the issue, compare different solutions, formulate hypotheses, and validate these hypotheses through testing. However, each step requires different abilities:

1. Planning: Ability to plan out solutions within the desired difficulty level.
2. Research: Ability to differentiate between good and useful resources (evaluation) and those that are not, and identify important learning spots.
3. Hypothesis Formulation: Ability to detect incorrect assumptions they may have when setting up hypotheses.
4. Hypothesis Validation: Ability to proof of concepts that can be transferred to the actual project.
5. Implementation: Ability to implement the solutions and unblock when encountering problems.

They might need multiple iterations. For instance, to host a full-stack image gallery app, they might consider different technologies including Node.js, Vercel, and Next.js. If they want to decide which technology will be best to quickly load the images, they will need to test different solutions through research and hypothesis testing for each technology.

3 Problems in self-learning for a junior engineer

Research: The superficial learning problem

If you are familiar with Bayesian inference, you probably know that our minds constantly update when new information comes in. However, the difference between a junior and senior engineer lies in experience, indicating the ability to assign correct weight to prioritize important concepts or problems for deeper exploration. Since junior engineers don’t have much prior experience, they are more likely to treat all information with equal weight, feeling puzzled by potential directions, and unable to delve deep into essential concepts.

For instance, even in React, one might simply see `props.name` and believe they understand `props` without comprehending the relationships between child and parent components, the concept of single-direction data flow, and the idea of lifting state — concepts strongly connected to the initial design of props.

More often than not, important concepts are overlooked by simply copying and pasting without a deep understanding of the underlying principles. This results in an inability to grasp more complicated concepts in the future.

Hypothesis testing: The wrong assumption problem

Whenever we try to implement an idea or resolve a problem, we will have a “bug hypothesis.” These hypotheses are formed based on evidence and assumptions. If we set our assumptions incorrectly, we can never formulate a good hypothesis to address our problems at hand.

For instance, I spent the entire afternoon working on the integration from text to speech, wondering why the generated speech couldn’t be played. It was only later that I discovered the issue — the QuickTime Player on Mac doesn’t support MP3 as a file format!

However, operating under my implicit assumption that my QuickTime Player could definitely play my MP3 file, I spent time working on the wrong hypothesis until a senior engineer friend pointed it out.

Validate hypothesis & Implementation: The give-up problem

The process of validating hypotheses can consume a significant amount of time and energy, often representing a common period when individuals abandon their projects.

When building projects, I constantly face decision-making challenges. Questions such as “Which technology is best suited to solve this problem?” and “How much time should I invest in a particular testing?” consistently arise. At times, the need to learn a new technology to test a hypothesis adds complexity. This process can be both painful and time-consuming, ultimately proving fruitless for the current project due to underestimation of difficulty or limitations in available learning resources.

For example, my roommate rebuilt her entire language learning app without using Unity because she hypothesized that she could achieve her desired features without it. This hypothesis was based on extensive online research and initial proof-of-concept building. However, she ended up resetting her entire GitHub repository painfully and relearning Unity when she realized her hypothesis was falsified.

While the initial hypothesis may seem promising, unexpected complexities or limitations can emerge during the testing and implementation phases, and the flood of overwhelming negative emotions becomes a reason for learners to give up on their projects.

How might we ease the pain?

I want to temporarily disregard online coding boot camps and paid classes as solutions due to the monetary constraints that most junior engineers face, being either poor students or recent graduates.

Current personal solutions

The simplest way to observe what learners do is by working on safe projects (e.g. working on projects with existing working code on YouTube or replicating code from others’ GitHub repositories)

However, this strategy introduces a conflict between creativity and safety when undertaking new projects. Some of my friends build numerous projects but only by following the successful and existing work of others because they lack confidence in their ability to gauge the scope and difficulty of constructing their own. In fact, they simply don’t know how to start.

This safety-first approach not only diminishes the enjoyment of building but also lacks an assessment of applying the concepts learned. How can we de-risk the building process and provide learners with more freedom to imagine what they want to realize?

Community Solutions: Buildspace

I’ve come across another existing solution that is well-known in Silicon Valley: Buildspace. This event invites learners to submit their weekly projects and share comments on Twitter as part of an accountability system. However, it primarily addresses motivation issues and does not alleviate the other challenges associated with learning engineering through building passion projects.

How can I pick up full-stack development in a few months?

Reflecting on my personal learning experience, I realize that the reason I was able to grasp full-stack development in a short time is not solely due to my hard work. Many learners also put in a lot of effort to learn engineering. However, the key factor contributing to my success was the abundance of resources in San Francisco. In this environment, I am constantly exposed to best practices in coding and easy-to-use, up-to-date technology. Participating in hackathons exposes me to what’s possible, and I frequently encounter people who are happy to teach me the entire mental models for new technology, eliminating the need to slowly piece together various bits of information.

For example, in an effort to reduce my give-up rate and address my poor intuition in problem-solving, I force myself to use a well-structured template when building side projects. I break down projects into multiple versions of MVP, build proof of concepts before adopting new technology, time-box my exploration of new solutions, and iteratively reflect and improve during my learning process. Yet, I found that these practices were still not quite enough, and I wonder how we can do better than this.

Our idea: The development of a painkiller

We aim to address the three problems in self-learning for juniors:

• Detecting hidden assumptions by asking guided questions.
• Encouraging in-depth learning through following up on new concepts.
• Auto-generating code for proof of concepts to validate hypotheses.

What we are essentially imagining is having a senior engineer sitting next to you, with intelligence-guided questions to uncover your assumptions and lead you to the right problems with confident evidence of proof of concepts.

This is the procedure that my friend and I have built for this first-generation tool:

1. Track the problems you are attempting to work on during research.
2. Provide suggested questions to address hidden assumptions and problems.
3. Generate explanations for you.
4. Offer follow-up questions to encourage learning beyond the superficial, guiding you down the rabbit hole.
5. Provide sample code so you can “see” the concept and easily test hypotheses.

For instance, when I attempted to learn about information theory, the AI gave me Huffman code to understand how information is compressed. Similarly, when exploring the difference between runtime and build time, the tool generated a timer with simulation for runtime and build time so I can see the difference.

Based on our interviews with learners, most people find the most value in the sample code generation. The “Ah-ha” moment from seeing sample codes allows people to learn through an immediate connection between their hypotheses and the real output. While the guided questions are useful to re-center learners on better questions, we haven’t been able to observe the in-depth dive of learnings from more follow-up questions.

If von Neumann’s First Draft has already transformed our understanding of machines from a fancier specialized adding machine to a general-purpose tool, I cannot see why the self-learning journey of a junior engineer cannot imagine whatever ideas they want to build in their minds. If hardware is our instrument, software should be the music that allows us complete freedom to play and experiment with different notes Hence, the self-learning journey should allow as much creativity and fun as possible, steering away from the grinding and emotionally traumatizing process learners usually describe and fear. The purpose of self-learning software should be to play, not to cause pain.

All in all, I love this entire building process because I can observe different learners and see how they solve their problems in their heads, all while rethinking how to improve my own learning process. This idea is very preliminary, but the point is to throw out bricks to attract jade ideas from people (拋磚引玉).