Learning to Code and Finding Opportunities as a New Developer

A viewer asked how to learn as a new developer: should they take their time and nerd out, or follow another path? It is a great question and harder to answer than it used to be. The way people learn, get hired and build a career has changed since I started.

My earlier advice came from having gone through a similar hiring market myself. That is less true now. What follows is my outside perspective, not a guarantee that the route I took would work for someone graduating today. I might not have made it if I had to start over in the current market.

Experienced developers have a responsibility here too. We should not pull the ladder up behind us simply because we found a path at a different time. People who could become excellent engineers still need opportunities to learn and demonstrate potential.

I want to separate two questions: how do you learn, and how do you find work? They overlap, but they are not identical. A person can grow considerably without having an easy way to convince an employer of that growth, especially when a hiring process is noisy.

I draw an illustrative distribution of developers and argue that people often judge what is average from the people around them. That is a useful warning about biased reference groups, not a validated measurement of developer ability. The percentiles in my sketch are a mental model, not a ranking of actual people.

For illustration I invent 70,000 new tech jobs and 100,000 computer-science graduates per year. I explicitly made those figures up. They show a hypothetical mismatch between openings and candidates; they are not statistics about a country, a year or the current job market.

Even in that example, it would be wrong to assume an interview sorts every applicant perfectly and awards jobs in exact order of ability. Interviewers see limited evidence, make mistakes and disagree with one another. A hiring decision is an estimate under uncertainty.

At Amazon, I remember an interview process that asked panelists to score candidates from one to four. The even number avoided an easy neutral middle. I could strongly favor someone while other interviewers disagreed, or vice versa. The scoring system forced a judgment, but it did not make the judgment precise.

I use a person in chat as an example of why every assessment needs a range. I think they are talented based on the work I have seen, but I could be overestimating or underestimating them. A confident placement on a drawing is not a measurement of a person’s true potential.

A company’s own team can also distort its reference point for what an average hire looks like. My broader point is that hiring is not a clean ranking exercise: company needs, available candidates and imperfect evaluation all affect who gets an opportunity.

I was hired at Twitch before I knew how to deliver software reliably. I understood computers and servers, but in my interview I froze when asked which language I wanted to use. I chose C++ because I had recently used it, then struggled with the problems.

The team brought in a frontend-focused interviewer after my C++ round went badly, and I struggled there too. Two panelists still liked me and thought I might fit. Instead of a full-time offer, they gave me a three-month contract, then another, before I eventually joined full time.

That was a risk for the team. They needed people with an interest in media and had an urgent project, while I had enough technical background and rapport for them to give me a chance. I worked hard to keep the job. Other candidates in the same situation might not have had that opportunity.

Looking back, the shortage of available engineers mattered as much as anything about me. A team can hire someone promising but inexperienced, continue searching, or leave a role open. In my case, the urgency and the people involved made the first option possible.

I was effectively paid to learn on the job, and I do not want to pretend that everyone entering the field can count on the same conditions. My view is that competition for entry-level roles is tougher now, although experiences differ by location, employer and timing.

I think about hiring in terms of three factors: the employer’s urgency, the working relationship or likeability, and competence. The employer largely controls the first. Both sides shape the relationship; the candidate can develop and demonstrate skills, while the employer remains responsible for evaluating them fairly.

In a hiring rush, a company may take a chance on someone whose skills are not yet proven. With more experienced applicants competing for the same opening, a new graduate can find it harder to demonstrate comparable ability. This does not mean inexperienced people never get hired; there are still many paths in.

AI-generated work can make a portfolio easier to produce and harder to interpret. That does not make every portfolio meaningless: it increases the importance of discussing decisions, explaining tradeoffs and showing what you can understand, maintain and improve. Employers should test those skills rather than assume appearances are proof.

The original question was about learning, so let us focus on the parts a person can influence: developing competence and building relationships. I do not mean networking as a trick. I mean finding people who care about similar problems and learning how to work and exchange ideas with them.

I asked my audience whether they regularly spend time with developers they consider more capable than themselves. Many said they work remotely, live far from technology hubs or simply do not know other developers nearby. That can be lonely, and it changes how much feedback and inspiration is available day to day.

I was lucky: older students introduced me to Linux, and later my friends became interested in programming too. For much of my life I could talk about technical work with people around me. Being in that environment made learning a regular part of the day instead of an activity I had to arrange from scratch.

Not everyone can move to San Francisco or find a local group. Online communities can bridge some of the gap. Share ideas, ask questions, help other members and observe how they reason. Remote contact is different from meeting in person, but it can still provide meaningful peer learning.

I have seen community members turn a passing idea into a benchmark, contribute useful information in chat and find work through relationships built around shared interests. Those are individual stories, not a guaranteed hiring strategy. What they illustrate is that making your thinking visible can connect you with people who value it.

It is difficult to know exactly where you stand as a developer. I use a drawing to describe how different experience levels can affect a conversation, but there is no evidence in my sketch for a precise numerical distance at which people become uncomfortable. Treat it as a metaphor, not a psychological law.

I describe helping someone with a tangled application: redundant ways to fetch data, a complicated frontend flow and an outdated backend template. The lesson is not that beginners should already know everything. It is that feedback and willingness to revisit assumptions matter when a project accumulates complexity.

Sometimes the people around you are interested in a different level or aspect of programming. A student who wants to explore deeper may feel isolated if nobody nearby shares that curiosity. That does not make their classmates less valuable; it means they may need an additional community for that particular interest.

A community can provide a place to ask questions that feel too specialized for a classroom or local circle. People watching from different time zones may simply enjoy being around others who care about the same subject. The useful part is the shared interest, not loyalty to any one creator.

You do not have to participate in every discussion. Reading a thoughtful thread, following a link, trying a library and returning with a question can all be ways to join in. The aim is to make learning less isolated and more connected to actual work.

The qualities that make you interested in a community can also make others enjoy collaborating with you. Show up because you care, ask good questions, respond to what others are discussing and help when you can. That is more useful than repeatedly dropping a portfolio link into conversations.

If someone asks for a resource and you remember where to find it, sharing it is a small contribution. Notice what people need and participate without demanding attention. These habits can make you recognizable as a helpful collaborator while giving you opportunities to learn.

To improve a skill, you need some way to calibrate your self-assessment. It is easy to feel confident after an early success or discouraged after encountering a harder problem. Feedback from capable peers and concrete comparisons with work you admire can help you see both progress and gaps.

I use my early YouTube videos as an example. A couple of videos performed well, so I expected every new one to succeed. When a later video about SolidJS initially received far fewer views, it challenged my confidence. It took many attempts to learn what made a good video.

An early result can create a misleading sense of mastery; later knowledge can also reveal how much remains unknown. I use the names Dunning–Kruger and impostor syndrome conversationally for these experiences, not as a diagnosis or a claim that everyone follows a fixed confidence curve.

Rather than deciding your worth from a feeling, ask people whose work you respect for specific feedback. Compare particular skills, not your entire identity with someone else’s career. The community can help you discover what good work looks like and which next step is worth practicing.

Online peers count. A local technology hub can make accidental encounters easier, but geography and cost make that inaccessible to many people. Participate in a community that fits your interests and circumstances rather than assuming a particular city is the only route to growth.

My answer to the original question is to start with things you enjoy and find others who enjoy them too. That might be frontend libraries, coding agents, low-level memory management, hardware or a product you want to build. Interest can sustain the repetition and curiosity needed to get better.

When using AI to learn, ask for a small hint, an explanation of an approach, or a reason your current solution might fail. If the tool immediately generates the entire answer, you may miss the part where you develop your own understanding. Use it to unblock deeper investigation rather than replace it.

I also ask who made the things I find interesting. I often visit a creator’s profile, look at their earlier work and read why a project exists. Understanding the people and decisions behind a tool can reveal paths into the field that are invisible if you look only at its code.

A short, sincere message thanking a maintainer can matter. It does not have to contain a request or a long pitch. I once told Ryan Carniato that I liked his writing, later offered useful copy feedback, and a relationship grew from that shared interest.

Do not expect a reply from every person you contact, especially someone with a large audience. Smaller maintainers may appreciate encouragement too. The point is to acknowledge work that genuinely helped you, not to turn every message into a demand for a referral or free review.

While improving syntax highlighting in T3 Chat, I found react-shiki, a small library that was close to what I needed. It had very few stars. I contacted its creator, Basim, to ask whether he intended to maintain it and whether a fork would be welcome if he did not.

Basim replied that he did plan to maintain it. He was working in IT and learning to code in his spare time; the library showed ability that I thought deserved more opportunity. I did not have an engineering opening, but I knew someone building the open-source Assistant UI project.

I introduced him to that company, expecting the interview might at least provide practice and feedback. He was hired quickly. It is one anecdote with unusual circumstances, not a promise that a two-star repository produces a job. The important part is that useful work and a human connection made his skills visible.

Basim did not approach me asking for a job. I wanted to help after seeing his work. I encourage people to reach out to creators with appreciation because their work matters, not as a transaction with an expected reward. Relationships can create opportunities, but they are not an entitlement to someone else’s time.

Recognizing a small creator can also encourage them to keep building. People often remember the first person who notices something they made. Being present, curious and helpful is a way to become part of a community, and over time that can complement the technical skills you are developing.

Look at how people you admire reached their current work, and look for patterns you can adapt. Do not study only one narrow layer forever: a frontend developer can learn some design and API design, while a backend developer can explore databases and the interface between frontend and backend.

Depth and breadth support each other. Build strong knowledge in an area you care about, then explore adjacent areas so you understand how the pieces fit. Genuine gratitude and clear human communication can help you make those connections without turning learning into a performance.

For experienced developers, take opportunities to help people who are starting under different conditions from yours. For beginners, do not lose hope: follow an interest, practice, seek feedback and find people to learn alongside. It may take longer than you want, and no single path guarantees a job, but growth is possible.