How to Learn to Code and Get a Developer Job [Full Book]

If you want to learn to code and get a job as a developer, you're in the right place. This book will show you how.

And yes this is the full book – for free – right here on this page of freeCodeCamp.

Also, I've recorded a FREE full-length audiobook version of this book, which I published as episode #100 of The freeCodeCamp Podcast. You can search for it in your favorite podcast player. Be sure to subscribe. I've also embedded it below for your convenience.

A few years back, one of the Big 5 book publishers from New York City reached out to me about a book deal. I met with them, but didn't have time to write a book.

Well, I finally had time. And I decided to just publish this book for free, right here on freeCodeCamp.

Information wants to be free, right? 🙂

It will take you a few hours to read all this. But this is it. My insights into learning to code and getting a developer job.

I learned all of this while:

• learning to code in my 30s
• then working as a software engineer
• then running freeCodeCamp.org for the past 8 years. Today, more than a million people visit this website each day to learn about math, programming, and computer science.

I was an English teacher who had never programmed before. And I was able to learn enough coding to get my first software development job in just one year.

All without spending money on books or courses.

(I did spend money to travel to nearby cities and participate in tech events. And as you'll see later in the book, this was money well spent.)

After working as a software engineer for a few years, I felt ready. I wanted to teach other people how to make this career transition, too.

I built several technology education tools that nobody was interested in using. But then one weekend, I built freeCodeCamp.org. A vibrant community quickly gathered around it.

Along the way, we all helped each other. And today, people all around the world have used freeCodeCamp to prepare for their first job in tech.

You may be thinking: I don't know if I have time to read this entire book.

No worries. You can bookmark it. You can come back to it and read it across as many sittings as you need to.

And you can share it on social media. Sharing: "check out this book I'm reading" and linking to it is a surprisingly effective way to convince yourself to finish reading a book.

I say this because I'm not trying to sell you this book. You already "bought" this book when you opened this webpage. Now my goal is to reassure you that it will be worth investing your time to finish reading this book. 😉

I promise to be respectful of your time. There's no hype or fluff here – just blunt, actionable tips.

I'm going to jam as much insight as I can into every chapter of this book.

Which reminds me: where's the table of contents?

Ah. Here it is:

Table of Contents

1. Preface: Who is this book for?
2. 500 Word Executive Summary
3. Chapter 1: How to Build Your Skills
4. Chapter 2: How to Build Your Network
5. Chapter 3: How to Build Your Reputation
6. Chapter 4: How to Get Paid to Code – Freelance Clients and the Job Search
7. Chapter 5: How to Succeed in Your First Developer Job
8. Epilogue: You Can Do This

Preface: Who is This Book For?

This book is for anyone who is considering a career in software development.

If you're looking for a career that's flexible, high-paying, and involves a lot of creative problem solving, software development may be for you.

Of course, each of us approaches our own coding journey with certain resources: time, money, and opportunity.

You may be older, and may have kids or elderly relatives you're taking care of. So you may have less time.

Or you may be younger, and may have had less time to build up any savings, or acquire skills that boost your income. So you may have less money.

And you may live far away from the major tech cities like San Francisco, Berlin, Tokyo, or Bengaluru.

Or you may live with disabilities, physical or mental. Agism, racism, and sexism are real. Immigration status can complicate the job search. So can a criminal record.

So you may have less opportunity.

Learning to code and getting a developer job is going to be harder for some people than it will be for others. Everyone approaches this challenge from their own starting point, with whatever resources they happen to have on hand.

But wherever you may be starting out from – in terms of time, money, and opportunity – I'll do my best to give you actionable advice.

In other words: don't worry – you are in the right place.

A Quick Note on Terminology

Whenever I use new terms, I'll do my best to define them.

But there are a few terms I'll be saying all the time.

I'll use the words "programming" and "coding" interchangeably.

I'll use the word "app" as it was intended – as shorthand for any sort of application, regardless of whether it runs on a phone, laptop, game console, or refrigerator. (Sorry, Steve Jobs. iPhone does not have a monopoly on the word app.)

I will also use the words "software engineer" and "software developer" interchangeably.

You may encounter people in tech who take issue with this. As though software engineering is some fancy-pants field with a multi-century legacy, like mechanical engineering or civil engineering are. Who knows – maybe that will be true for your grandkids. But we are still very much in the early days of software development as a field.

I'll just drop this quote here for you, in case you feel awkward calling yourself a software engineer:

"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." – Gerald Weinberg, Programmer, Author, and University Professor

Can Anyone Learn to Code?

Yes. I believe that any sufficiently motivated person can learn to code. At the end of the day, learning to code is a motivational challenge – not a question of aptitude.

On the savannas of Africa – where early humans lived for thousands of years before spreading to Europe, Asia, and the Americas – were there computers?

Programming skills were never something that was selected for over the millennia. Computers as we know them (desktops, laptops, smartphones) emerged in the 80s, 90s, and 00s.

Yes – I do believe that aptitude plays a part. But at the end of the day, anyone who wants to become a professional developer will need to put in time at the keyboard.

A vast majority of people who try to learn to code will get frustrated and give up.

I sure did. I got frustrated and gave up. Several times.

But like other people who eventually succeeded, I kept coming back after a few days, and tried again.

I say all this because I want to acknowledge: learning to code and getting a developer job is hard. And it's even harder for some people than others, due to circumstance.

I'm not going to pretend to have faced true adversity in learning to code. Yes, I was in my 30s, and I had no formal background in programming or computers science. But consider this:

I grew up middle class in the United States – a 4th-generation American from an English-speaking home. I went to university. My father went to university. And his father went to university. (His parents before him were farmers from Sweden.)

I benefitted from a sort of intergenerational privilege. A momentum that some families are able to pick up over time when they are not torn apart by war, famine, or slavery.

So that is my giant caveat to you: I am not some motivational figure to pump you up to overcome adversity.

If you need inspiration, there are a ton of people in the developer community who have overcome real adversity. You can seek them out.

I'm not trying to elevate the field of software development. I'm not going to paint pictures of science fiction utopias that can come about if everyone learns to code.

Instead, I'm just going to give you practical tips for how you can acquire these skills. And how you can go get a good job, so you can provide for your family.

There's nothing wrong with learning to code because you want a good, stable job.

There's nothing wrong with learning to code so you can start a business.

You may encounter people who say that you must be so passionate about coding that you dream about it. That you clock out of your full-time job, then spend all weekend contributing to open source projects.

I do know people who are that passionate about coding. But I also know plenty of people who, after finishing a hard week's work, just want to go spend time in nature, or play board games with friends.

People generally enjoy doing things they're good at doing. And you can develop a reasonable level of passion for coding just by getting better at coding.

So in short: who is this book for? Anyone who wants to get better at coding, and get a job as a developer. That's it.

You don't need to be a self-proclaimed "geek", an introvert, or an ideologically-driven activist. Or any of those stereotypes.

It's fine if you are. But you don't need to be.

So if that's you – if you're serious about learning to code well enough to get paid to code – this book is for you.

And you should start by reading this quick summary of the book. And then reading the rest of it.

500 Word Executive Summary

Learning to code is hard. Getting a job as a software developer is even harder. But for many people, it's worth the effort.

Coding is a high-paying, intellectually challenging, creatively rewarding field. There is a clear career progression ahead of you: senior developer, tech lead, engineering manager, CTO, and perhaps even CEO.

You can find work in just about any industry. About two thirds of developer jobs are outside of what we traditionally call "tech" – in agriculture, manufacturing, government, and service industries like banking and healthcare.

If you're worried your job might be automated before you reach retirement, consider this: coding is the act of automating things. Thus it is by definition the last career that will be completely automated.

Automation will impact coding. It already has. For decades.

Generative AI tools like GPT-4 and Copilot can help us move from Imperative Programming – where you tell computers exactly what to do – closer to Declarative Programming – where you give computers higher-level objectives. In other words: Star Trek-style programming.

You should still learn math even though we now have calculators. And you should still learn programming even though we now have AI tools that can write code.

Have I sold you on coding as a career for you?

Good. Here's how to break into the field.

Build your skills.

You need to learn:

• Front End Development: HTML, CSS, JavaScript
• Back End Development: SQL, Git, Linux, and Web Servers
• Scientific Computing: Python and its many libraries

These are all mature, 20+ year old technologies. Whichever company you work for, you will almost certainly use most of these tools.

The best way to learn these tools is to build projects. Try to code at least some every day. If you do the freeCodeCamp curriculum from top to bottom, you'll learn all of this and build dozens of projects.

Some of the certifications in the freeCodeCamp core curriculum.

Build your network.

So much of getting a job is who you know.

It's OK to be an introvert, but you do need to push your boundaries.

Create GitHub, Twitter, LinkedIn, and Discord accounts.

Go to tech meetups and conferences. Travel if you have to. (Most of your "learn to code" budget should go toward travel and event tickets – not books and courses.)

Greet people who are standing by themselves. Let others do most of the talking, and really listen. Remember people's names.

Add people on LinkedIn, follow them on Twitter, and go to after-parties.

Build your reputation.

Share short video demos of your projects.

Keep applying to speak at bigger and bigger conferences.

Hang out at hackerspaces and help people who are even newer to coding than you.

Contribute to open source. The work is similar to professional software development.

Build your Skills, Network, and Reputation at the same time. Don't let yourself procrastinate the scariest parts.

Instead of applying for jobs through the "front door" use your network to land job interviews through the "side door." Recruiters can help, too.

Keep interviewing until you start getting job offers. You don't need to accept the first offer you get, though. Be patient.

Your first developer job will be the hardest. Try to stay there for at least 2 years, and essentially get paid to learn.

The real learning begins once you're on-the-job, working alongside a team, and with large legacy codebases.

Most importantly, sleep and exercise.

Any sufficiently-motivated person can learn to code well enough to get a job as a developer.

It's just a question of how badly you want it, and how persistent you can be in the job search.

Remember: you can do this.

This Book is Dedicated to the Global freeCodeCamp Community.

Thank you to all of you who have supported our charity and our mission over the past 9 years.

It is through your volunteerism and through your philanthropy that we've been able to help so many people learn to code and get their first developer job.

The community has grown so much from the humble open source project I first deployed in 2014. I am now just a small part of this global community.

It is a privilege to still be here, working alongside you all. Together, we face the fundamental problems of our time. Access to information. Access to education. And access to the tools that are shaping the future.

These are still early days. I have no illusion that everyone will know how to code within my lifetime. But just like the Gutenberg Bible accelerated literacy in 1455, we can continue to accelerate technology literacy through free, open learning resources.

Again, thank you all.

And special thanks to Abbey Rennemeyer for her editorial feedback, and to Estefania Cassingena Navone for designing the book cover.

And now, the book.

Chapter 1: How to Build Your Skills

"Every artist was first an amateur." ― Ralph Waldo Emerson

The road to knowing how to code is a long one.

For me, it was an ambiguous one.

But it doesn't have to be like that for you.

In this chapter, I'm going to share some strategies for learning to code as smoothly as possible.

First, allow me to walk you through how I learned to code back in 2011.

Then I'll share what I learned from this process.

I'll show you how to learn much more efficiently than I did.

Story Time: How Did a Teacher in His 30s Teach Himself to Code?

I was a teacher running an English school. We had about 100 adult-aged students who had traveled to California from all around the world. They were learning advanced English so they could get into grad school.

Most of our school's teachers loved teaching. They loved hanging out with students around town, and helping them improve their conversational English.

What these teachers didn't love was paperwork: Attendance reports. Grade reports. Immigration paperwork.

I wanted our teachers to be able to spend more time with students. And less time chained to their desks doing paperwork.

But what did I know about computers?

Programming? Didn't you have to be smart to do that? I could barely configure a WiFi router. And I sucked at math.

Well one day I just pushed all that aside and thought "You know what: I'm going to give it a try. What do I have to lose?"

I started googling questions like "how to automatically click through websites." And "how to import data from websites into Excel."

I didn't realize it at the time, but I was learning how to automate workflows.

And the learning began. First with Excel macros. Then with a tool called AutoHotKey where you can program your mouse to move to certain coordinates of a screen, click around, copy text, then move to different coordinates and paste it.

After a few weeks of grasping in the dark, I figured out how to automate a few tasks. I could open an Excel spreadsheet and a website, run my script, then come back 10 minutes later and the spreadsheet would be fully populated.

It was the work of an amateur. What developers might call a "dirty hack". But it got the job done.

I used my newfound automation skills to continue streamlining the school.

Soon teachers barely had to touch a computer. I was doing the work of several teachers, just with my rudimentary skills.

This had a visible impact on the school. So much of our time had been tied up with rote work on the computer. And now we were free.

The teachers were happier. They spent more time with students.

The students were happier. They told all their friends back in their home country "you've got to check out this school."

Soon we were one of the most successful schools in the entire school system.

This further emboldened me. I remember thinking to myself: "Maybe I can learn to code."

I knew some software engineers from my board game night. They had traditional backgrounds, with degrees from Cal Tech, Harvey Mudd, and other famous Computer Science programs.

At the time, it was far less common for people in their 30s to learn to code.

I worked up the courage to share my dreams with some of these friends.

I wanted to learn to how program properly. I wanted to be able to write code for a living like they did. And to maybe even write software that could power schools.

I would share these dreams up with my developer friends. "I want to do what you do."

But they would sort of shrug. Then they'd say something like:

"I mean, you could try. But you're going to have to drink an entire ocean of knowledge."

And: "It's a pretty competitive field. How are you going to hang with people who grew up coding from an early age?"

And: "You're already doing fine as a teacher. Why don't you just stick with what you're good at?"

And that would knock me off course for a few weeks. I would go on long, soul-searching walks at night. I would ponder my future under the stars. Were these people right? I mean – they would know, right?

But every morning I'd be back at my desk. Watching my scripts run. Watching my reports compile themselves at superhuman speeds. Watching as my computer did my bidding.

A thought did occur to me: maybe these friends were just trying to save me from heartache. Maybe they just don't know anyone who learned to code in their 30s. So they don't think it's possible.

It's like... for years doctors thought that it would be impossible for someone to run a mile in 4 minutes. They thought your heart would explode from running so fast.

But then somebody managed to do it. And his heart did not explode.

Once Roger Bannister – a 25-year old Oxford student – broke that psychological barrier – a ton of other people did it, too. To date, more than 1,000 people have run a sub-4 minute mile.

Roger Bannister running like a a champ. (Image: Britannica)

And it's not like I was doing something as bold and unprecedented as running a 4 minute mile here. Plenty of famous developers have managed to teach themselves coding over the years.

Heck, Ada Lovelace taught herself programming in the 1840s. And she didn't even have a working computer. She just had an understanding of how her friend Charles Babbage's computer would work in theory.

She wrote several of the first computer algorithms. And she's widely regarded as the world's first computer programmer. Nobody taught her. Because there was nobody to teach her. Whatever self doubt she may have had, she clearly overcame it.

Now, I was no Ada Lovelace. I was just some teacher who already had a working computer, a decent internet connection, and the ability to search through billions of webpages with Google.

I cracked my knuckles and narrowed my gaze. I was going to do this.

Stuck in Tutorial Hell

"If you work for 10 years, do you get 10 years of experience or do you get 1 year of experience 10 times? You have to reflect on your activities to get true experience. If you make learning a continuous commitment, you’ll get experience. If you don’t, you won’t, no matter how many years you have under your belt." – Steve McConnell, Software Engineer

I spent the next few weeks googling around, and doing random tutorials that I encountered online.

Oh look, a Ruby tutorial.

Uh-oh, it's starting to get hard. I'm getting error messages not mentioned in the tutorial. Hm... what's going on here...

Oh look, a Python tutorial.

Human psychology is a funny thing. The moment something starts to get hard, we ask: am I doing this right?

Maybe this tutorial is out of date. Maybe its author didn't know what they were talking about. Does anybody even still use this programming language?

When you're facing ambiguous error messages hours into a coding session, the grass on the other side starts to look a lot greener.

It was easy to pretend I'd made progress. Time to go grab lunch.

I'd see a friend at the café. "How's your coding going?" they'd ask.

"It's going great. I already coded 4 hours today."

"Awesome. I'd love to see what you're building sometime."

"Sure thing," I'd say, knowing that I'd built nothing. "Soon."

Maybe I'd go to the library and check out a new JavaScript book.

There's that old saying that buying books gives you the best feeling in the world. Because it also feels like you're buying the time to read them.

And this is precisely where I found myself a few weeks into learning to code.

I had read the first 100 pages of several programming books, but finished none.

I had written the first 100 lines of code from several programming tutorials, but finished none.

I didn't know it, but I was trapped in place that developers lovingly call "tutorial hell."

Tutorial hell is where you jump from one tutorial to the next, learning and then relearning the same basic things. But never really going beyond the fundamentals.

Because going beyond the fundamentals? Well, that requires some real work.

It Takes a Village to Raise a Coder

Learning to code was absorbing all of my free time. But I wasn't making much progress. I could now type the { and * characters without looking at the keyboard. But that was about it.

I knew I needed help. Perhaps some Yoda-like mentor, who could teach me the ways. Yes – if such a person existed, surely that would make all the difference.

I found out about a nearby place called a "hackerspace." When I first heard the name, I was a bit apprehensive. Don't hackers do illegal things? I was an English teacher who liked playing board games. I was not looking for trouble.

Well I called the number listed and talked with a guy named Steve. I nervously asked: "You all don't do anything illegal, do you?" And Steve laughed.

It turns out the word "hack" is what he called an overloaded term. Yes – "to hack" can mean to maliciously break into a software system. But "to hack" can also mean something more mundane: to write computer code.

Something can be "hacky" meaning it's not an elegant solution. And yet you can have "a clever hack" – an ingenious trick to make your code work more efficiently.

In short: don't be scared of the term "hack."

Facebook's corporate campus has the word "hack" written in giant letter on the concrete. (Image: Bloomberg)

I, for one, scarcely use the term because it's so confusing. And I think recently a lot of hackerspaces have picked up on the ambiguity. Many of them now call themselves "makerspaces" instead.

Because that's what a hackerspace is all about – making things.

Steve invited me to visit the hackerspace on Saturday afternoon. He said several developers from the area would be there.

The first time I walked through the doors of the Santa Barbara Hackerspace, I was blown away.

The place smelled like an electric fire. Its makeshift tables were lined with soldering irons, strips of LED lights, hobbyist Arduino circuit boards, and piles of Roomba vacuum robots.

The same Steve I'd spoken to on the phone was there, and he greeted me. He had glasses, slicked back hair, and a goatee beard. He was always smiling. And when you asked him a question, instead of responding quickly, he would nod and think for a few seconds first.

Steve was a passionate programmer who had studied math and philosophy at the University of California – Santa Barbara. He was still passionate about those subjects. But his real passion was Python.

Steve turned on the projector and gave an informal "lightning talk." He was demoing an app he'd written that would recognize QR codes in a video and replace them with images.

Someone in the audience pulled up a QR code on their laptop and held it in front of the camera. Steve's app then replaced the QR code with a picture of a pizza.

Somebody in the audience shouted, "Can you make the pizza spin?"

Steve opened up his code in a code editor, called Emacs, and started making changes to it in real time. He effortlessly tabbed between his code editor, his command line, and the browser the app was running in, "hot loading" updates to the code.

For me, this was sorcery. I couldn't believe Steve had just busted out that app over the course of few hours. And now he was adding new features on the fly, as the audience requested them.

I thought: "This guy is a genius."

And that evening, after the event ended, he and I stayed after and I told him so.

We ate sandwiches together. And I said to him: "I could code for my entire career and not be as good as you. I would be thrilled if after 10 years I could code even half as well as you."

But Steve pushed back. He said, "I'm nothing special. Don't limit yourself. If you stick with coding, you could easily surpass me."

Now, I didn't for a second believe the words he said to me. But just the fact that he said it gave me butterflies.

Here he was: a developer who believed in me. He saw me – some random teacher – the very definition of a "script kiddie" – and thought I could make it.

Steve and I talked late into the night. He showed me his $200 netbook computer, which even by 2011 standards was woefully underpowered.

"You don't need a powerful computer to build software," Steve told me. "Today's hardware is incredibly powerful. Computers are only slow because the bloated software they run makes them slow. Get an off-the-shelf laptop, wipe the hard drive, install Linux on it, and start coding."

I took note of the model of laptop he had and ordered the exact same one when I got home that night.

After a few days of debugging my new computer with Stack Overflow, I successfully installed Ubuntu. I started learning how to use the Emacs code editor. By the following Saturday, I knew a few commands, and was quick to show them off.

Steve nodded in approval. He said, "Awesome. But what are you building?"

I didn't understand what he meant. "I'm learning how to use Emacs. Check it out. I memorized..."

But Steve looked pensive. "That's cool and all. But you need a project. Always have a project. Then learn what you need to learn en route to finishing that project."

Other than a few scripts I'd written for to help the teachers at my school, I had never finished anything. But I started to see what he was saying.

And it started to dawn on me. All this time I had been trapped in tutorial hell, going in circles, finishing nothing.

Steve said, "I want you to build a project using HTML5. And next Saturday, I want you to present it at the hackerspace."

I was mortified at his words. But I stood up straight and said. "Sounds like a plan. I'm on it."

Nobody Can Make You a Developer But You

"I'm trying to free your mind, Neo. But I can only show you the door. You're the one that has to walk through it." – Morpheus in the 1999 film The Matrix

The next morning, I woke up extra early before work and googled something like "HTML5 tutorial." I already knew a lot of this from my previous time in tutorial hell. But instead of skipping ahead, I just slowed my roll and followed along exactly, typing every single command.

Usually once I finished a tutorial I would just go find another tutorial. But instead, I started playing with the tutorial's code. I had a simple idea for a project. I was going to make an HTML5 documentation page. And I was going to code it purely in HTML5.

Let me explain HTML5 real quick. It's just a newer version of HTML, which has existed since the first webpages back in the 1990s.

If a website was a body, HTML would be the bones. Everything else rests on top of those bones. (You can think of JavaScript as the muscles and CSS as the skin. But let's get back to the story.)

I knew that in HTML, you could link to different parts of the same webpage by using ID properties. So I thought: what if I put a table of contents along the left hand side? Then clicking the different items on the left would scroll down the page on the right to show those items.

Within half an hour, I had coded a rough prototype.

But it was time to report for work at the school. The entire day, all I could think about was my project, and how I should best go about finishing it.

I raced home, opened up my laptop, and spent the entire evening coding.

I copied the official (and creative commons-licensed) HTML documentation directly into my page, "hard coding" it into the HTML.

Then I spent about an hour on the CSS, getting everything to look right, and using absolute positioning to keep the sidebar in place.

I made a point to make use of as many of HTML5's new "semantic" tags as I could.

And boom – project finished.

A wave of accomplishment washed over me. I jogged to a nearby football field and ran laps around the field, celebrating. I did it. I finished a project.

And I decided right then and there: from here on out, everything I do is going to be a project. I'm going to be working toward some finished product.

The next evening I walked up to the podium, plugged in my laptop, and presented my HTML5 webpage. I answered questions from the developers there about HTML5.

Sometimes I'd get something wrong, and someone in the audience would say, "that doesn't sound right – let me check the documentation."

People weren't afraid to correct me. But they were polite and supportive. It didn't even feel like they were correcting me – it felt like they were correcting the public record – lest someone walk away with incorrect information.

I didn't feel any of the anxiety that I might have felt giving a talk at a teacher in-service meeting.

Instead I almost felt like I was part of the audience, learning alongside them.

After all, these tools were new and emerging. We were all trying to understand how to use them together.

After my talk, Steve came up to me and said, "Not bad."

I smiled for an awkwardly long time, not saying anything, just happy with myself.

Then Steve squinted and pursed his lips. He said: "Start your next project tonight."

Lessons from my Coding Journey

We'll check in on younger Quincy's coding journey in each of the following chapters. But now I want to break down some of the lessons here. And I want to answer some of the questions you may have.

Why is Learning to Code so Hard?

Learning any new skill is hard. Whether it's dribbling a soccer ball, changing the oil on a car, or speaking a new language.

Learning to code is hard for a few particular reasons. And some of these are unique to coding.

The first one is that most people don't understand exactly what coding is. Well, I'm going to tell you.

What is coding?

Coding is telling a computer what to do, in a way the computer can understand.

That's it. That's all coding really is.

Now, make no mistake. Communicating with computers is hard. They are "dumb" by human standards. They will do exactly what you tell them to do. But unless you're good at coding, they are probably not going to do what you want them to do.

You may be thinking: what about servers? What about databases? What about networks?

At the end of the day, these are all controlled by layers of software. Code. It's code all the way down. Eventually you reach the physical hardware, which is moving electrons around circuit boards.

For the first few decades of computing, developers wrote code that was "close to the metal" – often operating on the hardware directly, flipping bits from 0 to 1 and back.

But contemporary software development involves so many "layers of abstraction" – programs running on top of programs – that just a few lines of JavaScript code can do some really powerful things.

In the 1960s, a "bug" could be an insect crawling around inside a room-sized computer, and getting fried in one of the circuits.

The first computer bug, discovered in 1945, was a moth that got trapped in the panels of a room-sized calculator computer at Harvard. (Image: Public Domain)

Today, we're writing code so many layers of abstraction above the physical hardware.

That is coding. It's vastly easier than it has ever been in the past. And it is getting easier to do every year.

I am not exaggerating when I say that in a few decades, coding will be so easy and so common that most younger people will know how to do it.

Why is learning to code still so hard after all these years?

There are three big reasons why learning to code is so hard, even today:

1. The tools are still primitive.
2. Most people aren't good at handling ambiguity, and learning to code is ambiguous. People get lost.
3. Most people aren't good at handling constant negative feedback. And learning to code is one brutal error message after another. People get frustrated.

Now I'll discuss each of these difficulties in more detail. And I'll give you some practical strategies for overcoming each of them.

The Tools are Still Primitive

A Possessed Barclay from Star Trek: The Next Generation, programming on the Holodeck.

"Computer. Begin new program. Create as follows. Work station chair. Now create a standard alphanumeric console positioned to the left hand. Now an iconic display console for the right hand. Tie both consoles into the Enterprise main computer core, utilizing neuralscan interface." - Barclay from Star Trek: The Next Generation, Season 4 Episode 19: "The Nth Degree"

This is how people might program in the future. It's an example from my favorite science fiction TV show, Star Trek: The Next Generation.

Every character in Star Trek can code. Doctors, security officers, pilots. Even little Wesley Crusher (played by child actor Wil Wheaton) can get the ship's computer to do his bidding.

Sure – one of the reasons everyone can code is that they live in a post-scarcity 24th-century society, with access to free high quality education.

Another reason is that in the future, coding will be much, much easier. You just tell a computer precisely what to do, and – if you're precise enough – the computer does it.

What if programming was as easy as just saying instructions to a computer in plain English?

Well, we've already made significant progress toward this goal. Think of our grandmothers, running between room-sized mainframe computers with stacks of punchcards.

Working with a punchcard-based computer in the 1950s (Image: NASA)

It used to be that programming even a simple application would require meticulous instructions.

Here are two examples of a "Cesar Cypher", the classic computer science homework project.

This is also known as "ROT-13" because you ROTate the letters by 13 positions. For example, A becomes N (13 letters after A), and B becomes O (13 letters after B).

I'm going to show you two examples of this program.

First, here's the program in x86 Assembly:

format     ELF     executable 3
entry     start

segment    readable writeable
buf    rb    1

segment    readable executable
start:    mov    eax, 3        ; syscall "read"
    mov    ebx, 0        ; stdin
    mov    ecx, buf    ; buffer for read byte
    mov    edx, 1        ; len (read one byte)
    int    80h

    cmp    eax, 0        ; EOF?
    jz    exit

    xor     eax, eax    ; load read char to eax
    mov    al, [buf]
    cmp    eax, "A"    ; see if it is in ascii a-z or A-Z
    jl    print
    cmp    eax, "z"
    jg    print
    cmp    eax, "Z"
    jle    rotup
    cmp    eax, "a"
    jge    rotlow
    jmp    print

rotup:    sub    eax, "A"-13    ; do rot 13 for A-Z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "A"
    jmp    rotend

rotlow:    sub    eax, "a"-13    ; do rot 13 for a-z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "a"

rotend:    mov    [buf], dl

print:     mov    eax, 4        ; syscall write
    mov    ebx, 1        ; stdout
    mov    ecx, buf    ; *char
    mov    edx, 1        ; string length
    int    80h

    jmp    start

exit:     mov     eax,1        ; syscall exit
    xor     ebx,ebx        ; exit code
    int     80h

This x86 Assembly example comes from the Creative Commons-licensed Rosetta Code project.

And here's the same program, written in Python:

def rot13(text):
    result = []

    for char in text:
        ascii_value = ord(char)

        if 'A' <= char <= 'Z':
            result.append(chr((ascii_value - ord('A') + 13) % 26 + ord('A')))
        elif 'a' <= char <= 'z':
            result.append(chr((ascii_value - ord('a') + 13) % 26 + ord('a')))
        else:
            result.append(char)

    return ''.join(result)

if __name__ == "__main__":
    input_text = input("Enter text to be encoded/decoded with ROT-13: ")
    print("Encoded/Decoded text:", rot13(input_text))

This is quite a bit simpler and easier to read, right?

This Python example comes straight from GPT-4. I prompted it the same way Captain Picard would prompt the ship's computer in Star Trek.

Here's exactly what I said to it: "Computer. New program. Take each letter of the word I say and replace it with the letter that appears 13 positions later in the English alphabet. Then read the result back to me. The word is Banana."

GPT-4 produced this Python code, and then read the result back to me: "Onanan."

What we're doing here is called Declarative Programming. We're declaring "computer, you should do this." And the computer is smart enough to understand our instructions and execute them.

Now, the style of coding most developers use today is Imperative Programming. We're telling the computer exactly what to do, step-by-step. Because historically, computers have been pretty dumb. So we've had to help them put one foot in front of the other.

The field of software development just isn't mature yet.

But just like early human tools advanced – from stone to bronze to iron – the same is happening with software tools. And much faster.

We're probably still in the programming equivalent of the Bronze Age right now. But we may reach the Iron Age in our lifetime. Generative AI tools like GPT are quickly becoming more powerful and more reliable.

The developer community is still divided on how useful tools like GPT will be for software development.

On one side, you have the "become your own boss" entrepreneur influencers who say things like: "You don't need to learn to code anymore. ChatGPT can write all your code for you. You just need an app idea."

And on the other side of the spectrum, you have "old guard" developers with decades of programming experience – many of whom are skeptical that tools like GPT are really all that useful for producing production-grade code.

As with most things, the real answer is probably somewhere in between.

You don't have to look hard to find YouTube videos of people who start with an app idea, then prompt ChatGPT for the code they need. Some people can even take that code and wire it together into an app that works.

Large Language Models like GPT-4 are impressive, and the speed at which they're improving is even more impressive.

Still, many developers are skeptical about how useful these tools will ultimately become. They question whether we'll be able to get AIs to stop "hallucinating" false information.

This is the fundamental problem of "Interpretability." It could be decades before we truly understand what's going on inside of a black box AI like GPT-4. And until we do, we should double check everything it says, and assume there will be lots of bugs and security flaws in the code that it gives us.

There's a big difference from being able to get a computer to do something for you, and actually understanding how the computer is doing it.

Many people can operate a car. But far fewer can repair a car – let alone design a new car from the ground up.

If you want to be able to develop powerful software systems that solve new problems – and you want those systems to be fast and secure – you're still going to need to learn how to code properly.

And that means feeling your way through a lot of ambiguity.

Learning to Code is an Ambiguous Process

When you're learning to code, you constantly ask yourself: "Am I spending my time wisely? Am I learning the right tools? Do these book authors / course creators even know what they're talking about?"

Ambiguity fogs your every study session. "Did my test case fail because the tutorial is out of date, and there have been breaking changes to the framework I'm using? Or am I just doing it wrong?"

As I mentioned earlier with Tutorial Hell, you also have to cope with "grass is greener on the other side" disease.

This is compounded by the fact that some developers think it's clever to answer questions with "RTFM" which means "Read the Freaking Manual." Not super helpful. Which manual? Which section?

Another problem is: you don't know what you don't know. Often you can't even articulate the question you're trying to ask.

And if you can't even ask the right question, you're going to thrash.

This is extra hard with coding because it's possible no one has attempted to build quite the same app that you're building.

And thus some of the problems you encounter may be unprecedented. There may be no one to turn to.

15% of the queries people type into Google every day have never ever been searched before. That's bad news if you're the person typing one of those.

My theory is that most developers will figure out how to solve a problem and simply move on, without ever documenting it anywhere. So you may be one of dozens of developers who has had to invent their own solution to the same exact problem.

And then, of course, there are the old forum threads and StackOverflow pages.

Comic by XKCD

How Not to Get Lost When Learning to Code

The good news is: both competence and confidence come with practice.

Soon you'll know exactly what to google. You'll get a second sense for how documentation is usually structured, and where to look for what. And you'll know where to ask which questions.

I wish there were a simpler solution to the ambiguity problem. But you just need to accept it. Learning to code is an ambiguous process. And even experienced developers grapple with ambiguity.

After all, coding is the rare profession where you can just infinitely reuse solutions to problems you've previously encountered.

Thus as a developer, you are always doing something you've never done before.

People think software development is about typing code into a computer. But it's really about learning.

You're going to spend a huge portion of your career just thinking really hard. Or blindly inputting commands into a prompt trying to understand how a system works.

And you're going to spend a lot of time in meetings with other people: managers, customers, fellow devs. Learning about the problem that needs to be solved, so you can build a solution to it.

Get comfortable with ambiguity and you will go far.

Learning to Code is One Error Message After Another

A lot of people who are learning to code feel like they hit a wall. Progress does not come as fast as they expect.

One huge reason for this: in programming, the feedback loop is much tighter than in other fields.

In most schools, your teacher will give you assignments, then grade those assignments and give them back to you. Over the course of a semester, you may only have a dozen instances where you get feedback.

"Oh no, I really bombed that exam," you might say to yourself. "I need to study harder for the midterm."

Maybe your teacher will leave notes in red ink on your paper to help you improve your work.

Getting a bad grade on an exam or paper can really ruin your day.

And that's how we generally think about feedback as humans.

If you've spent much time coding, you know that computers are quite fast. They can execute your code within a few milliseconds.

Most of the time your code will crash.

If you're lucky, you'll get an error message.

And if you're really lucky, you'll get a "stack trace" – everything the computer was trying to do when it encountered the error – along with a line number for the piece of code that caused the program to crash.

Now this in-your-face negative feedback from a computer. Not everyone can handle it seeing this over and over all day long.

Imagine if every time you handed your teacher your term paper, they handed it back with big red "F" written on it. And imagine they did this before you could even blink. Over and over.

That's what coding can feel like sometimes. You want to grab the computer and shout at it, "why don't you just understand what I'm trying to do?"

How Not to Get Frustrated

The key, again, is practice.

Over time, you will develop a tolerance for vague error messages and screen-length stack traces.

Coding will never be harder than it is when you're just starting out.

Not only do you not know what you're doing, but you're not used to receiving such impersonal, rapid-fire, negative feedback.

So here are some tips:

Tip #1: Know that you are not uniquely bad at this.

Everyone who learns to code struggles with the frustration of trying to Vulcan Mind Meld with a computer, and get it to understand you. (That's another Star Trek reference.)

Of course, some people started programming when they were just kids. They may act like they've always been good at programming. But they most likely struggled just like we adults do, and over time have simply forgotten the hours of frustration.

Think of the computer as your friend, not your adversary. It's just asking you to clarify your instructions.

Tip #2: Breathe.

Many people's natural reaction when they get an error message is to gnash their teeth. Then go back into their code editor and start blindly changing code, hoping to somehow luck into getting past it.

This does not work. And I'll tell you why.

The universe is complex. Software is complex. You are unlikely to just Forest Gump your way into anything good.

Forest Gump doing what he does and getting improbably lucky catching shrimp.

You may have heard of the Infinite Monkey Theorem. It's a thought experiment where you imagine chimpanzees typing on typewriters.

If you had a newsroom full of chimpanzees doing this, how long would it take before one of them typed out the phrase "to be or not to be" by random chance?

Let's say each chimp types one random character per second. It would likely take 1 quintillion years for one of them to type "to be or not to be." That's 10 to the 18th power. A billion billion.

Even assuming the chimps remain in good health and the typewriters are regularly serviced – the galaxy would be a cold, dark void by the time one of them managed to type "to be or not to be."

Why do I tell you all of this? Because you don't want to be one of those chimps.

In that time, you could almost certainly figure out a way to teach those chimps how to type English words. They could probably manage to type out all of Hamlet – not just its most famous line.

Even if you somehow do get lucky, and get past the bug, what will you have learned?

So instead of thrashing, you want to take some time. Understand the code. Understand what's happening. And then fix the error.

Always take time to understand the failing code. Don't be a quintillionarian chimp. (I think that means someone who is 1 quintillion years old, though according to Google, nobody has ever typed that word before.)

Instead of blindly trying things, hoping to get past the error message, slow down.

Take a deep breath. Stretch. Get up to grab a hot beverage.

Your future self will be grateful that you took this as a teachable moment.

Tip #3: Use Rubber Duck Debugging

Get a rubber ducky and set it next to your computer. Every time you hit an error message, try to explain what you think is happening to your rubber duck.

Of course, this is silly. How could this possibly be helpful?

Except it is.

Rubber Duck Debugging is a great tool for slowing down and talking through the problem at hand.

You don't have to use a rubber duck, of course. You could explain your Python app to your pet cactus. Your SQL query to the cat that keeps jumping onto your keyboard.

The very act of explaining your thinking out loud seems to help you process the situation better.

How do Most People Learn to Code?

Now let's talk about traditional pathways to a first developer job.

Why should you care what everyone else does? Spoiler alert: you don't really need to.

You do you.

This said, you may doubt yourself and the decisions you've made about your learning. You may yearn for the path not taken.

My goal with this section is to calm any anxieties you may have.

The Importance of Computer Science Degrees

University degrees are still the gold standard for preparing for a career in software development. Especially bachelor's degrees in Computer Science.

Before you start saying "But I don't have a computer science degree" – no worries. You don't need a Computer Science degree to become a developer.

But their usefulness is undeniable. And I'll explain why.

First, you may wonder: why should developers study computer science? After all, one of the most prominent developers of all time had this to say about the field:

"Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter." – Eric Raymond, Developer, Computer Scientist, and Author

Computer Science departments were traditionally part of the math department. Universities back in the 1960s and 1970s didn't know quite where to put this whole computer thing.

At other universities, Computer Science was considered an extension of Electrical Engineering. And until recently, even University of California – Berkeley – one of the greatest public universities in the world – only provided Computer Science degrees as sort of a double-major with Electrical Engineering.

But most universities have now come to understand the importance of Computer Science as a field of study.

As of writing this, Computer Science is the highest paying degree you can get. Higher even than fields focused on money, such as Finance and Economics.

According to Glassdoor, the average US-based Computer Science major makes more money at their first job than any other major. US $70,000. That's a lot of money for someone who just graduated from college.

More than Nursing majors ($59,000), Finance majors ($55,000) and Architecture majors ($50,000).

OK – so getting a Computer Science degree can help you land a high-paying entry-level job. That is probably news to no one. But why is that?

How Employers Think About Bachelor's Degrees

You may have heard some big employers in tech say things like, "we no longer require job candidates to have a bachelor's degree."

Google said this. Apple said this.

And I believe them. That they no longer require bachelor's degrees.

We've had lots of freeCodeCamp alumni get jobs at these companies, some of whom did not have a bachelor's degrees.

But those freeCodeCamp alumni who landed those jobs probably had to be extra strong candidates to overcome the fact that they didn't have bachelor's degrees.

You can look at these job openings as having a variety of criteria they judge candidates on:

1. Work experience
2. Education
3. Portfolio and projects
4. Do they have a recommendation from someone who already works at the company? (We'll discuss building your network in depth in Chapter 2)
5. Other reputation considerations (we'll discuss building your reputation in Chapter 3)

For these employers who do not require a bachelor's degree, education is just one of several considerations. If you are stronger in other areas, they may opt to interview you – regardless of whether you've ever even set foot inside a university classroom.

Just note that having a bachelor's degree will make it easier for you to get an interview, even at these "degree-optional" employers.

Why do so Many Developer Jobs Require a Computer Science Degree Specifically?

A bachelor's is a bachelor's, I often tell people. Because for most intents and purposes, it is.

Want to enter the US military as an officer, rather than an enlisted service member? You'll need a bachelor's degree, but any major will do.

Want to get a work visa to work abroad? You'll probably need a bachelor's degree, but any major will do.

And for so many job openings that say "bachelor's degree required" – any major will do.

Why is this? Doesn't the subject you study in university matter at all?

Well, here's my theory on this: what you learn in university is less important than whether you finished university.

Employers are trying to select for people who can figure out a way to get through this rite of passage.

It is certainly true that you can be at the bottom of your class, repeating courses you failed, and being on academic probation for half the time. But a degree is a degree.

You know what they call the student who finished last in their class at medical school? "Doctor."

And for most employers, the same holds true.

In many cases, HR folks are just checking a box on their job application filtering software. They're filtering out applicants who don't have a degree. In those cases, they may never even look at job applications from people without degrees.

Again, not every employer is like this. But many of them are. Here in the US, and perhaps even more so in other countries.

It sucks, but it's how the labor market works right now. It may change over the next few decades. It may not.

This is why I always encourage people who are in their teens and 20s to seriously considering getting a bachelor's degree.

Not because of any of the things universities market themselves as:

• The education itself. (You can take courses from some of the best universities online for free, so this alone does not justify the high cost of tuition.)
• The "college experience" of living in a dorm, making new friends, and self discovery. (Most US University students never live on campus so they don't really get this anyway.)
• General education courses that help you become a "well rounded individual" (Ever hear of the Freshman 15? This is a joke of course. But a lot of university freshman do gain weight due to the stress of the experience.)

Again, the real value of getting a bachelor's degree – the real reason Americans pay $100,000 or more for 4 years of university – is because many employers require degrees.

Of course, there are other benefits of having a bachelor's degree, such as the ones I mentioned: expanded military career options, and greater ease getting work visas.

One of these is: if you want to become a doctor, dentist, lawyer, or professor, you will first need a bachelor's degree. You can then use that to get into grad school.

OK – this is a lot of background information. So allow me to answer your questions bluntly.

Do You Need a University Degree to Work as a Software Developer?

No. There are plenty of employers who will hire you without a bachelor's degree.

A bachelor's degree will make it much easier to get an interview at a lot of employers. And it may also help you command a higher salary.

What About Associate's Degrees? Are Those Valuable?

In theory, yes. There are some fields in tech where having an associates may be required. And I think it always does increase your chances of getting an interview.

This said, I would not recommend going to university with the specific goal of getting an associate's degree. I would 100% encourage you to stay in school until you get a bachelor's degree, which is vastly more useful.

According to the US Department of Education, over the course of your career, having a bachelor's degree will earn you 31% more than merely having an associate's degree.

And I'm confident that difference is much wider with a bachelor's in Computer Science.

Is it Worth Going to University to Get a Bachelor's Degree Later in Life, if You Don't Already Have One?

Let's say you're in your 30s. Maybe you attended some college or university courses. Maybe you completed the first two years and were able to get an associate's degree.

Does it make sense to go "back to school" in the formal sense?

Yes, it may make sense to do so.

But I don't think it ever makes sense to quit your job to go back to school full time.

The full-time student lifestyle is really designed with "traditional" students in mind. That is, people age 18 to 22 (or a bit older if they served in the military), who have not yet entered the workforce beyond high school / summer jobs.

Traditional universities cost a lot of money to attend, and the assumption is that students will pay through some combination of scholarships, family funds, and student loans.

As a working adult, you'll have less access to these funding sources. And just as importantly, you'll have less time on your hands than a recent high school graduate would.

But that doesn't mean you have to give up on the dream of getting a bachelor's degree.

Instead of attending a traditional university, I recommend that folks over 30 attend one of the online nonprofit universities. Two that have good reputations, and whose fees are quite reasonable, are Western Governor's University and University of the People.

You may also find a local community college or state university extension program that offers degrees. Many of these programs are online. And some of them are even self-paced, so that you can complete courses as your work schedule permits.

Do your research. If a school looks promising, I recommend finding one of its alumni on LinkedIn and reaching out to them. Ask them questions about their experience, and whether they think it was worth it.

I recommend not taking on any debt to finance your degree. It is much better to attend a cheaper school. After all, a degree is a degree. As long as it's from an accredited institution, it should be fine for most intents and purposes.

If You Already Have a Bachelor's Degree, Does it Make Sense to Go Back and Earn a Second Bachelor's in Computer Science?

No. Second bachelor's degrees are almost never worth the time and money.

If you have any bachelor's degree – even if it's in a non-STEM field – you have already gotten most of the value you will get out of university.

What About a Master's of Computer Science Degree?

These can be helpful for career advancement. But you should pursue them later, after you're already working as a developer.

Many employers will pay for their employee's continuing education.

One program a lot of my friends in tech have attended is Georgia Tech's Master's in Computer Science degree.

Georgia Tech's Computer Science department is among the best in the US. And this degree program is not only fully online – it's also quite affordable.

But I wouldn't recommend doing it now. First focus on getting a developer job. (We'll cover that in-depth later in this book).

Will Degrees Continue to Matter in the Future?

Yes, I believe that university degrees will continue to matter for decades – and possibly centuries – to come.

University degrees have existed for more than 1,000 years.

Many of the top universities in the US are older than the USA itself is. (Harvard is more than 400 years old.)

The death of the university degree is greatly exaggerated.

It has become popular in some circles to bash universities, and say that degrees don't matter anymore.

But if you look at the statistics, this is clearly not true. They do have an impact on lifetime earnings.

And just as importantly, they can open up careers that are safer, more stable, and ultimately more fulfilling.

Sure, you can make excellent money working as a deckhand offshore, servicing oil rigs.

But you can make similarly excellent money working as a developer in a climate-controlled office, servicing servers and patching codebases.

One of these jobs is dangerous, back-breaking work. The other is a job you could comfortably do for 40 years.

Many of the "thought leaders" out there who are bashing universities have themselves benefitted from a university education.

One reason why I think so many people think degrees are "useless" is: it's hard to untangle the learning from the status boost you get.

Is university just a form of class signaling – a way for the wealthy to continue to pass advantage on to their children? After all, you're 3 times as likely to find a rich kid at Harvard as you are a poor kid.

The fact is: life is fundamentally unfair. But that does not change how the labor market works.

You can choose easy mode, and finish a degree that will give you more options down the road.

Or you can go hard mode, potentially save time and money, and just be more selective about which employers you apply to.

I have plenty of friends who've used both approaches to great success.

What Alternatives are There to a University Degree?

I've worked in adult education for nearly two decades, and I have yet to see a convincing substitute for a university degree.

Sure – there are certification programs and bootcamps.

But these do not carry the same weight with employers. And they are rarely as rigorous.

Side note: when I say "certification programs" I mean a program where you attend a course, then earn a certification at the end. These are of limited value. But exam-based certifications from companies like Amazon and Microsoft are quite valuable. We'll discuss these in more depth later.

What I tell people is: to degree or not to degree – that is the question.

I meet lots of people who are auto mechanics, electricians, or who do some other sort of trade, who don't have a bachelor's. They can clearly learn a skillset, apply it, and hold down a job.

I meet lots of people who are bookkeepers, paralegals, and other "knowledge workers" who don't have a bachelor's. They can clearly learn a skillset, apply it, and hold down a job.

In many cases, these people can just learn to code on their own, using free learning resources and hanging out with likeminded people.

Some of these people have always had the personal goal of going back and finishing their bachelor's. That's a good reason to do it.

But it's not for everyone.

If you want formal education, go for the bachelor's degree. If you don't want formal education, don't do any program. Just self-teach.

The main thing bootcamps and other certification programs are going to give you is structure and a little bit of peer pressure. That's not a bad thing. But is it worth paying thousands of dollars for it?

How to Teach Yourself to Code

Most developers are self-taught. Even the developers who earned a Bachelor's of computer science still often report themselves as "self-taught" on industry surveys like Stack Overflow's annual survey.

Most working developers consider themselves to be "self-taught" (Image: Stack Overflow 2016 Survey)

This is because learning to code is a life-long process. There are constantly new tools to learn, new legacy codebases to map out, and new problems to solve.

So whether you pursue formal education or not, know this: you will need to get good at self-teaching.

What Does it Mean to be a "Self-Taught" Developer?

Not to be pedantic, but when I refer to self-teaching, I mean self-directed learning – learning outside of formal education.

Very few people are truly "self-taught" at anything. For example, Isaac Newton taught himself Calculus because there were no Calculus books. He had to figure it out and invent it as he went along.

Similarly, Ada Lovelace taught herself programming. Because before her there was no programming. She invented it.

Someone might tell you: "You're not really self taught because you learned from books or online courses. So you had teachers." And they are correct, but only in the most narrow sense.

If someone takes issue with you calling yourself self-taught, just say: "By your standards, no one who wasn't raised by wolves can claim to be self-taught at anything."

Point them to this section of this book and tell them: "Quincy anticipated your snobbery." And then move on with your life.

Because come on, life's too short, right?

You're self taught.

What is Self-Directed Learning?

As a self-learner, you are going to curate your own learning resources. You're going to choose what to learn, from where. That is the essence of "Self-Directed Learning."

But how do you know you're learning the right skills, and leveraging the right resources?

Well, that's where community comes in.

There are lots of communities of learners around the world, all helping one another expand their skills.

Community is a hard word to define. Is Tech Twitter a community? What about the freeCodeCamp forum? Or the many Discord groups and subreddits dedicated to specific coding skillsets?

I consider all of these communities. If there are people who regularly hang out there and help one another, I consider it a community.

What about in-person events? The monthly meetup of Ruby developers in Oakland? The New York City Startup community meetup? The Central Texas Linux User Group?

These communities can be online, in-person, or some mix of both.

We'll talk more about communities in the Build Your Network chapter. But the big takeaway is: the new friends you meet in these communities can help you narrow your options for what to learn, and which resources to learn from.

What Programming Language Should I Learn First?

The short answer is: it doesn't really matter. Once you've learned one programming language well, it is much easier to learn your second language.

There are different types of programming languages, but today most development is done using "high-level scripting languages" like JavaScript and Python. These languages trade away the raw efficiency you get from "low-level programming languages" like C. What they get in return: the benefit of being much easier to use.

Today's computers are billions of times faster than they were in the 1970s and 1980s, when people were writing most of their programs in languages like C. That power more than makes up for the relative inefficiency of scripting languages.

It's worth noting that both JavaScript and Python themselves are written in C, and they are both getting faster every year – thanks to their large communities of open source code contributors.

Python is a powerful language for scientific computing (Data Science and Machine Learning).

And JavaScript... well, JavaScript can do everything. It is the ultimate Swiss Army Knife programming language. JavaScript is the duct tape that holds the World Wide Web together.

"Any application that can be written in JavaScript, will eventually be written in JavaScript." – Atwood's Law (Jeff Atwood, founder of Stack Overflow and Discourse)

You could code your entire career in JavaScript and would never need to learn a second language. (This said, you'll want to learn Python later on, and maybe some other languages as well.)

So I recommend starting with JavaScript. Not only is it much easier to use than languages like Java and C++ – it's easier to learn, too. And there are far, far more job openings for people who know JavaScript.

A screenshot from job search engine Indeed. My search for "javascript" for the US yielded 68,838 job listings.

The other skills you'll want to focus on are HTML and CSS. If a webpage were a body, HTML would be the bones, and CSS would be the skin. (JavaScript would be the muscles, making it possible for the website to move around and be interactive.)

You can learn some HTML and CSS in a single afternoon. Like most of the tools I mention here, they are easy to learn, but difficult to master.

You'll also want to learn how to use Linux. Linux powers a vast majority of the world's servers, and you will spend much of your career running commands in the Linux command line.

If you have a Mac, MacOS has a terminal that accepts almost all the same commands as Linux. (MacOS and Linux have a common ancestor in Unix.)

But if you're on a Windows PC, you'll want to install WSL, which stands for Windows Subsystem for Linux. You will then be able to run Linux commands on your PC. And if you're feeling adventurous, you can even dual boot both the Windows and Linux operating systems on the same computer.

If you're going to install Linux on a computer, I recommend starting with Ubuntu. It is the most widely used (and widely documented) Linux distribution. So it should be the most forgiving.

Make no mistake – Linux is quite a bit harder to use than Windows and MacOS. But what you get in return for your efforts is an extremely fast, secure, and highly customizable operating system.

Also, you will never have to pay for an operating system license again. Unless you want to. Red Hat is a billion dollar company even though its software is open source, because companies pay for their help servicing and supporting Linux servers.

You'll also want to learn Git. This Version Control System is how teams of developers coordinate their changes to a codebase.

You may have heard of GitHub. It's a website that makes it easier for developers to collaborate on open source projects. And it further extends some of the features of Git. You'll learn more about GitHub in the How to Build Your Reputation chapter later.

You'll want to learn SQL and how relational databases work. These are the workhorses of the information economy.

You'll also hear a lot about NoSQL databases (Non-relational databases such as graph databases, document databases, and key-value stores.) You can learn more about these later. But focus on SQL first.

Finally, you'll want to learn how web servers work. You'll want to start with Node.js and Express.js.

When you hear the term "full stack development" it refers to tying together the front end (HTML, CSS, JavaScript) with the back end (Linux, SQL databases, and Node + Express).

There are lots of other tools you'll want to learn, like React, NGINX, Docker, and testing libraries. You can pick these up as you go.

But the key skills you should spend 90% of your pre-job learning time on are:

1. HTML
2. CSS
3. JavaScript
4. Linux
5. Git
6. SQL
7. Node.js
8. Express.js

If you learn these tools, you can build most major web and mobile apps. And you will be qualified for most entry-level developer jobs. (Of course, many job descriptions will include other tools, but we'll discuss these later in the book.)

So you may be thinking: great. How do I learn these?

Where do I learn how to code?

Funny you should ask. There's a full curriculum designed by experienced software engineers and teachers. It's designed with busy adults in mind. And it's completely free and self-paced.

That's right. I'm talking about the freeCodeCamp core curriculum. It will help you learn:

• Front End Development
• Back End Development
• Engineering Mathematics
• and Scientific Computing (with Python for Data Science and Machine Learning)

To date, thousands of people have gone through this core curriculum and gotten a developer job. They didn't need to quit their day job, take out loans, or really risk anything other than some of their nights and weekends.

In practice, freeCodeCamp has become the default path for most people who are learning to code on their own.

If nothing else, the freeCodeCamp core curriculum can be your "home base" for learning, and you can branch out from there. You can learn the core skills that most jobs require, and also dabble in technologies you're interested in.

There are decades worth of books and courses to learn from. Some are available at your public library, or through monthly subscription services. (And you may be able to access some of these subscription services for free through your library as well.)

Also, freeCodeCamp now has nearly 1,000 free full-length courses on everything from AWS certification prep to mobile app development to Kali Linux.

There has never been an easier time to teach yourself programming.

Building Your Skills is a Life-Long Endeavor

We've talked about why self-teaching is probably the best way to go, and how to go about it.

We've talked about the alternatives to self-teaching, such as getting a bachelor's degree in Computer Science, or getting a Master's degree.

And we've talked about which specific tools you should focus on learning first.

Now, let's shift gears and talk about how to build the second leg of your stool: your network.

Chapter 2: How to Build Your Network

"If you want to go fast, go alone. If you want to go far, go together." – African Proverb

"Networking." You may wince at the sound of that word.

Networking may bring to mind awkward job fairs in stuffy suits, desperately pushing your résumé into the hands of anyone who will accept it.

Networking may bring to mind alcohol-drenched watch parties – where you pretend to be interested in a sport you don't even follow.

Networking may bring to mind wishing "happy birthday" to people you barely know on LinkedIn, or liking their status updates hoping they'll notice you.

But networking does not have to be that way.

In this chapter, I'll tell you everything I've learned about meeting people. I'll show you how to earn their trust and be top of their mind when they're looking for help.

Because at the end of the day, that's what it's all about. Helping people solve their problems. Being of use to people.

I'll show you how to build a robust personal network that will support you for decades to come.

Story Time: How did a Teacher in his 30s Build a Network in Tech?

Last time on Story Time: Quincy learned some coding by reading books, watching free online courses, and hanging out with developers at the local Hackerspace. He had just finished building his first project and given his first tech talk...

OK – so I now had some rudimentary coding skills. I could now code my way out of the proverbial paper bag.

What was next? After all, I was a total tech outsider.

Well, even though I was new to tech, I wasn't new to working. I'd put food on the table for nearly a decade by working at schools and teaching English.

As a teacher, I got paid to sling knowledge. And as a developer, I'd get paid to sling code.

I already knew one very important truth about the nature of work: it's who you know.

I knew the power of networks. I knew that the path to opportunity goes right through the gatekeepers.

All that stood between me and a lucrative developer job was a hiring manager who could say: "Yes. This Quincy guy seems like someone worthy of joining our team."

Of course, being a tech outsider, I didn't know the culture.

Academic culture is much more formal.

You wear a suit.

You use fancy academic terminology to demonstrate you're part of the "in group."

You find ways to work into every conversation that you went to X university, or that you TA'd under Dr. Y, or that you got published in The Journal of Z.

Career progressions are different. Conferences are different. Power structures are different.

And I didn't immediately appreciate this fact.

The first few tech events I went to, I wore a suit.

I kept neatly-folded copies of my résumé in my pocket at all times.

I even carried business cards. I had ordered sheets of anodized aluminum, and used a laser cutter to etch in my name, email address, and even a quote from legendary educator John Dewey:

"Anyone who has begun to think places some portion of the world in jeopardy." – John Dewey

It's still my favorite quote to this day.

But talk about heavy-handed.

"Hi, I'm Quincy. Here's my red aluminum business card. Sorry in advance – it might set off the metal detector on your flight home."

I was trying too hard. And it was probably painfully apparent to everyone I talked to.

I went on Meetup.com and RSVP'd for every developer event I could find. Santa Barbara is a small town, but it's near Los Angeles. So I made the drive for events there, too.

I quickly wised up, and traded my suit for jeans and a hoody. And I noticed that no one else gave out business cards. So I stopped carrying them.

I took cues from the devs I met at the hackerspace: Be passionate, but understated. Keep some of your enthusiasm in reserve.

And I read lots of books to better understand developer culture.

The Coders at Work is a good book from the 1980s.

Hackers: Heroes of the Revolution is a good book from the 1990s.

For a more contemporary cultural resource, check out the TV series Mr. Robot. Its characters are a bit extreme, but they do a good job of capturing the mindset and mannerisms of many developers.

Soon, I was talking less like a teacher and more like a developer. I didn't stick out quite as awkwardly.

Several times a week I attended local tech-related events. My favorite event wasn't even a developer event. It was the Santa Barbara Startup Night. Once every few weeks, they'd have an event where developers would pitch their prototypes. Some of the devs demoing their code were even able to secure funding from angels – rich people who invest in early-stage companies.

The guy who ran the event was named Mike. He must have known every developer and entrepreneur in Santa Barbara.

When I finally got the nerve to introduce myself to Mike, I was star-struck. He was an ultra-marathoner with a resting heartbeat in the low 40s. Perfectly cropped hair and beard. To me he was the coolest guy on the planet. Always polished. Always respectful.

Mike was "non-technical". He worked as a product manager. And though he knew a lot about technology and user experience design, he didn't know how to code.

Sometimes devs would write non-technical people off. "He's just a business guy," they'd say. Or: "She's a suit." But I never heard anyone say that about Mike. He had the respect of everyone.

I made a point to watch the way Mike interacted with developers. After all, I wasn't that far removed from "non-technical" myself. I'd only been coding for a few months.

Often my old habits would creep in. During conversations I'd have the temptation to show off what I'd learned or what I'd built.

Many developers are modest about their skills or accomplishments. They might say: "I dabble in Python." And little 'ol insecure me would open his big mouth and say something like, "Oh yeah. I've coded so many algorithms in Python. I write Python in my sleep."

And then I'd go home and google that developer's name, and realize they were a core contributor to a major Python library. And I'd kick myself.

I quickly learned not to boast of my accomplishments or my skills. There's a good chance a person you're talking to can code circles around you. But most of them would never volunteer this fact.

There's nothing worse than confidently pulling out your laptop, showing off your code, and then having someone ask you a bunch of questions that you're wholly unprepared to answer.

My first few months of attending events was a humbling experience. But these events energized me to keep pushing forward with my skills.

Soon people around southern California would start to recognize me. They'd say: "I keep running to you at these events. What's your name again?"

One night a dev said, "Let's follow each other on Twitter." I had grudgingly set up a Twitter account a few days earlier, thinking it was a gimmicky website. How much could you really convey with just 140 characters? I had barely tweeted anything. But I did have a Twitter account ready, and she did follow me.

That inspired me to spend more time refining my online presence. I made my LinkedIn less formal and more friendly. I looked at how other devs in the community presented themselves online.

Within a few months, I knew people from so many fields:

• experienced developers
• non-technical or semi-technical people who worked at tech companies
• hiring managers and recruiters
• and most importantly, my peers who were also mid-career and trying to break into tech

Why were peers the most important? Surely they would be the least able to help me get a job, right?

Well, let me tell you a secret: let's say a hiring manager brings on a new dev, trains them, and they turn out to be really good at their job. That hiring manager is going to ask: where can I find more people like you?

Your peers are one of the most important pieces of your network. So many of my freelance opportunities and job interview opportunities came from people who started learning to code around the same time as I did.

We came up together. We were brothers and sisters in arms. Those bonds are the tightest.

Anyway, all this networking over the months would ultimately come to fruition one night when I walked into the bar of a fancy downtown hotel for a developer event.

But more on that in the next chapter. Now let's talk more about the art and science of building your network.

Is it Really Who You Know?

You may have heard the expression that success is "less about what you know, and more about who you know."

In practice, it's about both.

Yes – your connections may help you land your dream job. But if you're out of your depth, and lack the skills to succeed, you will not fare well in that role.

But let's assume that you are proactively building your skills. You've followed my advice from Chapter 1. When is the right time to start building your network?

The best time to start building your network is yesterday.

But you don't need a time machine to do this. Because you already have a network. It's probably much smaller than you'd like it to be, but you do know people.

They may be friends from your home town, or the colleagues of your parents. Any person you know from your past – however marginally – may be of help.

So step one is to take full inventory of the people you know. Don't worry – I am not asking you to reach out to anyone yet, or tax your personal relationships.

Think before you move. Formulate a strategy.

First, let's inventory all the people you know.

How to Build a Personal Network Board

You want to start by creating a list of people you know.

You could do this with a spreadsheet, or a Customer Relationship Management tool (CRM) like sales people use. But that's probably overkill for what we're doing here.

I recommend using a Kanban board tool like Trello, which is free.

You're going to create 5 columns: "to evaluate", "to contact", "waiting for reply", "recently in contact", and "don't contact yet".

Then you're going to want to create labels, so you can classify people by how you know them. Here are some label ideas for you: "Childhood friend", "Friend of the family", "Former colleague", "Classmate", "Friends from Tech Events".

Now you can start creating cards. Each card can just be their name, and if you have time you can add a photo to the card.

Here is the Trello board I created to give you an idea of what this Personal Network Board might look like. I used characters from my favorite childhood movie, the 1989 classic Teenage Mutant Ninja Turtles.

My Personal Network Board with my friends from my side job fighting crime.

You can go through your social media accounts – even your old school year books if you have them – and start adding people.

Many of these people are not going to be of any help. But I recommend adding them for the sake of being comprehensive. You never know when you'll remember: "oh – so and so got a job at XYZ corp. I should reach out to them."

This process may take a day or two. But know that this is an investment. You'll be able to use this board for the rest of your career.

You may think "I don't need to do this – I already have a LinkedIn account." That might work OK, but LinkedIn is a blunt instrument. You want to maximize signal and minimize noise here. That's why I'm encouraging you to create this dedicated personal network board.

As you add people to your board, you can label them. Take a moment to research each of these people. What are they up to these days? Do they have a job? Run a company?

You can add notes to each card, as you discover new facts about them. Did they recently run a fundraiser 5K run? Did their grandma recently celebrate her 90th birthday? These facts may seem extraneous. But if the person is sharing them on social media, it means these facts are important to them.

Make an effort to be interested in people. Their daily lives. Their aspirations. By understanding their motivations and goals, you will have deeper insight into how you can help them.

And as I said earlier, the best way to forge alliances is to help people. We'll talk about this at length in a little bit.

For each of the people you add to your Personal Network Board, consider whether they might be worth reaching out to. Then either put them into the "to contact" or "don't contact yet" column.

You may be wondering: why is the column called "don't contact yet"? Because you never know when it might be helpful to know someone. Never take any friendship or acquaintanceship for granted.

Once you've filled up your board, labeled everyone, and sorted them into columns, you're ready to start reaching out.

How to Prepare for Network Outreach

The main thing to keep in mind when reaching out and trying to make an impression: keep yourself simple.

People are busy, and they can only remember so many facts about you. You want to boil down who you are to the fundamentals. And the best way to do this is to write a personal bio.

How to Write a Personal Bio for Social Media

You want your presence to be consistent across all of your social media accounts.

Here's how I introduce myself:

"I'm Quincy. I'm a teacher at freeCodeCamp. I live in Dallas, Texas. I can help you learn to code."

Go ahead and write yours. See if you can get it down to 100 characters or less. Try to avoid using fancy words or jargon.

It may be hard to distill your identity down to a few words. But this is an important process.

Remember: people are busy. They don't need to know your life story. As you get to know these people better, you can gradually fill in the details of who you are as a person. As they ask questions, they can get to know you better over time.

And on that note, you need a good photo of your smiling face.

How to Make a Social Media Headshot

If you have the money, just find a local photographer and pay them to take some professional headshots.

You may even have a friend who's into photography, who can take them for free.

I took my headshot myself, using Photobooth, which comes pre-installed on MacOS. My friend spent about 10 minutes fixing some background and shading in Photoshop. He may have made my teeth slightly whiter. Here's what it looks like:

My headshot. I use this same photo everywhere.

Be sure to smile with your eyes, so you don't look robotic. Or better yet, think of something really funny, like I did here. Then the smile will be genuine.

Take a lot of shots from different angles, and just use whichever one looks best on you.

I recommend using a headshot that looks like how you look on any given day. Not a heavily photoshopped photo that tries to maximize your attractiveness. You want people at events to recognize you from your photo. And you don't want to intimidate people with your beauty. You want to put them at ease.

Speaking of putting people at ease: do not wear sunglasses, or try too hard to look cool. You want to look friendly and approachable. A good acid test for this is: look at your photo. If you were lost, and saw this person on the street, would you be brave enough to ask them for directions?

Once you have chosen your headshot photo, use that same photo everywhere. Put it on all of your social media accounts.

Use it on your personal website. Even add the profile photo to your email account.

I recommend using that same photo for years. Every time you change it, you run the risk that some people won't immediately recognize you. Even subtle changes in lighting, angle, or background can throw off people's familiarity.

Be sure to keep a high-definition version of the photo. That way people can use it to promote your talk at their conference, or your guest appearance on their podcast. (Don't worry – in time, you will get there.)

How to Reach Out to People from your Past

Now that you've got your bio and photos sorted out, you're ready to start talking with people.

15 years ago, I would say you should call people on the phone instead of messaging them. But culture has changed a lot with the introduction of smart phones. Most people will not respond well to a phone call.

Similarly, I don't recommend asking people out to coffee or lunch until much later in the conversation. People are busy, and may view the request as awkward.

You need to get to the point, and do so quickly.

So what is that point you need to get to?

Essentially:

1. I know you
2. I like you
3. and I respect the work you're doing.

That's it.

People like to be known. They like to be liked. They like for the work they do and the lives they live to be noticed.

Most of us get recognition on our birthdays. People from our past might send "happy birthday" text messages, social media posts, or even call us.

But what about the other 364 days of the year? People like to be recognized on those other days, too.

Well, here's a simple way you can recognize people.

Step 1: Research the person. Google them. Read through their most recent social media posts. Read through their LinkedIn. If they post family photos, actually take time to look at them.

Step 2: Think about something you could say that might make their day a bit brighter.

Step 3: Choose a social media platform they've been recently active on. Send them a direct message.

I'm going to share a template, but never use any templates verbatim, because if the recipient plugs your message into Google, they'll discover it's a template, and all your goodwill will be squandered.

If I were messaging someone I hadn't talked to in a few months or years out of the blue, I would say something like this:

"Hey [name], I hope your [new year / spring / week] is off to a fun start. Congrats on [new job / promotion / new baby / completed project]. It's inspiring to see you out there getting things done."

Something short and to the point like that. Greeting + congratulations + compliment. That is the basic formula.

Don't just say it. Mean it.

Really want this person to feel recognized. Really want to brighten their day. Really want to encourage them to keep progressing toward their goals.

Humans are very good at detecting insincerity. Don't try to over-sell it. Don't give them any reason to think "this person wants something from me."

That's why the most important thing about this is: be brief. Be respectful of people's time. Nobody wants a long letter that they'll feel obligated to respond to at length.

Because – say it with me again – people are busy.

How to Build Even Deeper Connections

Because people are so busy, they're often tempted to see strangers more for what those strangers can do for them:

• This person drives the bus that gets me to work.
• This person makes my beverage just the way I like it.
• This person in HR answers my questions about time off.
• This person put together a bangin' acid jazz playlist for me to listen to while I code.
• This person sends me helpful emails each week with free coding resources.

To some extent, you are what you do for people.

I know, I know. That might sound overly reductive. Cynical even. And that is 100% not true for the close friends and family in your life.

But for people who barely know you – who just encounter you while going about their day – this is likely how they see you.

You have to give people a reason to care about you. You have to inspire them to learn more about you.

Before you can become somebody's close friend – someone they truly care about, and think about when you're not around – you need to start off as someone who is helpful to them.

And that's what we're going to do here. We're going to build even deeper relationships by offering to help people.

This will be a long process. And you should start it well in advance of your job search. The last thing you want is for someone to think "Oh – you're just reaching out because you need something from me."

On the contrary – you're reaching out because you have something to offer them.

You are, after all, in possession of one of the most powerful skillsets a person can acquire. The ability to bend machines to your will. You are a programmer.

This is what being good at coding feels like.

Or, at least, you're on the road to becoming one.

So you already have a good pretext to reach out to people.

You may have heard the term "cold call". This is where you call someone knowing almost nothing about them, and trying to sell them something. This is not easy, and a vast majority of cold calls end with the other party hanging up.

But the more information you know about the other person, the warmer the call gets, and the more likely you are to succeed.

Now, you're not selling anything here. And as I mentioned earlier, you're not calling them either. You're sending them a direct message.

Maybe this is through Twitter, LinkedIn, Discord, Reddit – wherever. But you are reaching out to them with a single paragraph of text.

As I said, the strongest opening move – the approach that's most likely to get a response – is to casually offer help.

If I were doing this, here's a simple template I'd use. Remember not to use this template verbatim. Rewrite it in your own voice, how you would say it to a friend:

"Hey [name], congrats on the [new job / promotion / new baby]. I've been learning some programming, and am building my portfolio. You immediately came to mind as someone who gets a lot of things done. Is there any sort of tool or app that would make your life easier? I may be able to code it up for you, for practice."

This is a strong approach, because it is personalized and doesn't come across as automated. People get so many automated messages these days that they are quick to disregard anything that even resembles an automated message.

This is why I send all my messages manually, and don't rely on automation. It's better to slowly compose messages one-by-one than it is try and save time with a script or a mail-merge.

The fastest way to get blocked is to message someone with "Hi , how's it going?" where there's clearly a first name missing – evidence that the message is a template.

Sometimes I get a message using my last name instead of my first name. "Hey Larson." What, am I in military school now?

And a lot of people on LinkedIn have started putting an emoji at the beginning of their name. This makes it easy to detect automated messages, because nobody would include that emoji in their direct message.

When a message starts with: "Hi 🍜Sarah, are you looking for a new job?" Then you know it's a bulk message.

Also note that my above template does not say "we went to school together" or something like that. Unless you just met someone a few days ago, you shouldn't specify how you two know one another.

Why? Because the very act of reminding people how you know one another will prompt some people to step back and think: "Gee, I barely know this person."

How to Keep the Conversation Going

Again, your goal is to get a response from them, so you can start a back-and-forth conversation.

These messaging platforms have a casual feel to them. Keep it casual.

Don't send a single, multi-paragraph message. Keep your messages short and snappy. You don't want for it to feel like a chore to reply to you.

Once you've got them replying to you, start making notes on your Personal Network Board so you can remember these facts later.

Maybe they do have some app idea or tool idea. Great. Ask them questions about it. See if you can build it for them.

Start by sketching out a simple mockup of the user interface. Use graphing paper if you want to look extra sophisticated. Snap a photo of it and send it to them. "Something like this?"

This will establish that you're serious about helping them. And I'd be willing to bet for most people, this would be a new experience.

"You're helping me? You're creating this app for me?" It will be flattering, and they will be likely to remember it. Even if the app itself doesn't go anywhere.

From there, you can just go with the flow of conversation. Maybe it fizzles out. No worries. Let it. You can find a reason to pick the conversation back up a few weeks later.

The great thing about these social media direct messages is the entire message log is there. The next time you message them, they can just scroll up and see "oh – this is that person who offered to build that app for me." There are no more "who are you again?" head tilts that you might get during in-person conversations.

Again, keep everything casual and upbeat. If it feels like the conversation is going slow, that's no problem. Because you're going to have dozens of other conversations going. Other irons in the fire. You're going to be a busy bee building your network.

How to Meet New People and Expand Your Personal Network

We've talked about how to reach out to people you already know. Those connections are still there, even if they've atrophied a bit over the years.

But how do you make brand new connections?

This is no easy task. But I have some tips that will make this process a bit less daunting.

First of all, meeting people for the first time in person is so much more powerful than meeting them online.

When you meet someone in person, your memory has so much more information to latch onto:

• How the person looks, their posture, and how they move through the space
• The sound of their voice and the way they speak
• The lights, sounds, aromas, temperature, and the general feel of the venue
• And so many other little details that get baked into your memory

Spending 10 minutes talking with someone in person can build a deeper connection than dozens of messages back and forth, across weeks of correspondence.

This is why I strongly recommend: get out there and meet people at local events.

How to Meet People at Local Events Around Town

Which events? If you live in a densely-populated city, you may have a ton of options at your disposal. You may be able to go to tech events several nights each week, with minimal commuting.

If you live in a small town, you may have to stick with meeting people at local gatherings. Book fairs, ice cream socials, sporting events.

If you go to church, mosque, or temple, get to know people there, too.

And yes, I realize this may sound ridiculous. "That person standing in the bleachers next to me at the soccer game? They're somehow going to help me get a developer job?"

Maybe. Maybe not. But don't write people off.

That person may run a small business.

They may have gone to school with a friend who's a VP of Engineering at a Fortune 500 company.

And maybe – just maybe – they're a software engineer, too. After all, there are millions of us software engineers out there. And we don't all live in Silicon Valley. 😉

When you do meet a new person, you don't want to immediately pull out your phone and say "Can I add you to my LinkedIn professional network?"

Instead, you want to play it cool. Introduce yourself.

Remember their name. Names are integral to building a relationship. If you are bad with names, practice remembering them. You can practice by just trying to remember the name of every character – no matter how minor they are – when you're watching TV shows or movies.

If you forget someone's name, don't guess. Just say "what's your name again" and be sure to remember it the second time.

Shake their hand or fist bump. Talk with them about whatever feels natural. If the conversation peters out, no worries. Let it.

You build relationships over time. It's not about total time spent with someone – it's about the number of times you meet that person over a longer span of time.

There's a good chance you will see the person again in the future. Maybe at that same exact location a few weeks later. And that is when you make your move:

"Hi [name] how's the [thing you talked about the previous time] going?"

Pick the conversation up where it left off. If they seem like someone who would be a helpful addition to your Personal Network Board, ask them "hey what are you doing next [day of week]? Do you want to come with me to [other upcoming local event]?"

Always have your upcoming week of events in mind, so you can invite people to join you.

This is a great way to get people to hang out with you in a safe, public space. And you're providing something of value – giving them awareness of an upcoming event.

If they seem interested, you can say "Awesome. What's the best way for me to message with you, and get you the event details?"

Boom – you now have their email or social media or phone number, and your relationship can unfold from there.

This may sound like a slow burn approach. Why be so cautious?

Again, people are busy. Smart people are defensive of their time, and of their personal information.

There are too many vampires out there who want to take advantage of people – trying to sell them something, scam them, get them into their multi-level marketing scheme, or in some other way proselytize them.

The best way to help other people get past this reflexive defensiveness is to already be on their radar from previous encounters as a reasonable person.

How to Leverage Your Network

We'll talk more about how to leverage your network in Chapter 4. For now, look at your network purely as an investment of time and energy.

I like to think of my network as an orchard. I am planting relationships. Tending to them, and making sure they're healthy.

Who knows when those relationships will grow into trees and bear fruit. The goal is to keep planting trees, and at some point in the future, those trees will help sustain you.

Keep sending out positive energy. Keep offering to help people using your skills, and even your own network. (It is rarely a bad move to make a polite introduction between two people you know.)

Be a kind, thoughtful, helpful person.

Don't ever feel impatient with how slow a job search may be going.

Don't ever let yourself feel slighted or snubbed.

Don't ever let yourself feel jealous of someone else's success.

What goes around comes around. You will one day reap what you sow. And if you're sowing positive energy, you're setting yourself up for one bountiful harvest.

Chapter 3: How to Build Your Reputation

"The way to gain a good reputation is to endeavor to be what you desire to appear." – Socrates

Now that you've started building your skills and your network, you're ready to start building your reputation.

You may be starting from scratch – a total newcomer to tech. Or you may already have some credibility you can bring with you from your other job.

In this chapter, I'll share practical tips for how you can build a sterling reputation among your peers. This will be the key to getting freelance clients, a first job, and advancing in your career.

But first, here's how I built my reputation.

Story Time: How Did a Teacher in His 30s Build a Reputation as a Developer?

Last time on Story Time: Quincy started building his network of developers, entrepreneurs, and hiring managers in tech. He was frequenting hackerspaces and tech events around the city. But he had yet to climb into the arena and test his might...

I was already several months into my coding journey when I finally worked up the courage to go to my first hackathon.

One day I encountered a particularly nasty bug, and I wasn't sure how to fix it. So I did what a lot of people would do in that situation: I procrastinated by browsing the web. And that's when I saw it. Startup Weekend EDU.

Startup Weekend is a 54-hour competition that involves building an app, then pitching it to a panel of judges. These events reward your knowledge of coding, design, and entrepreneurship as well.

This particular event – held in the heart of Silicon Valley – had a panel of educators and education entrepreneurs as its judges. With my background in adult education, this seemed like an ideal first hackathon for me.

I told Steve about the event. And then I said the magic words: "I'll do the driving." Which was good, because Steve didn't have a driver's license.

With Steve onboard, we rounded out our team with a couple of devs from the Santa Barbara Hackerspace.

I spent weeks preparing for the event by researching the judges and the companies they worked for. I researched the sponsors. And of course, I practiced coding like a Shaolin monk.

Finally, after a month of preparation, it was the big weekend. We piled into my 2003 Toyota Corolla with the peeling clear coat, put on some high energy music, and started our 5-hour drive.

On the way up, we discussed what we should build. It would be education-focused, of course. Preferably catering to high school students, since those were the grade levels the judge's companies focused on.

But what should the app do? How was it going to make people's lives easier?

I thought back to my own time in high school. I didn't have much to go on, since I'd dropped out after just one year. (I did manage to study for and pass the GED – Good Enough Degree as we called it – while working at Taco Bell, before eventually going to college. But that's another story.)

But one pain point I did remember from high school, which still rang out after all these years: English papers.

Now I loved writing. But I didn't love writing in MLA format, with its rigid citation rules. I used to dread preparing a Work Cited page. My teacher would always dock me points for not formatting my citations correctly.

After listening to a lot of OK ideas from the other passengers in the car, I piped up. I said: "I have an idea. We should code an app that creates citations for you."

And someone laughed and said: "Out of sight."

And Steve said, "Hey that's a good name. We could call it Out of Cite with a 'C'."

We all laughed and felt clever. Then we started discussing the implementation details.

When we arrived at the venue, there were about 100 other devs there. It was an open-plan office space, with low-rise cubicles flanked by whiteboards.

I heard whispers about one of those developers. "Hey, it's that guy who won the event last year," I heard people say. They gestured in the direction of a cocky-looking dev surrounded by fans. "Maybe he'll let me be on his team."

The event started with pitches. Anyone could go up to the front of the room, grab the mic, and deliver a 60 second pitch for the app they wanted to build.

I was so nervous it felt like an alien was about to burst out of my chest. So naturally, I was first in line. Rip the band-aid off, right?

I was sweating and gesticulating wildly as I raced through my pitch. I said something like this: "Citations suck. I mean, they don't suck. They're necessary. And you need to add them to your papers. But preparing citations sucks. Let's build an app that will fill out your Work Cited page for you. Who's with me?"

The room was quiet. Then people realized I was finished talking, and they gave me an obligatory round of applause. The MC took the mic out of my hand and gave it to the next person, and I pranced back to my seat.

After pitches, it was time to form teams. Our Santa Barbara contingent looked at each other and said "I guess we're a team."

We figured out the wifi password and grabbed the choicest of workspaces: a corner office that had a door you could actually close.

I started scrawling UI mockups on whiteboard. I said, "We want something that's always a click away. Right in your browser's menu bar."

"Like a browser plugin," Steve said.

"Yeah. Let's build a browser plugin."

I showed them examples of the three formats that essays might require: MLA, APA, and Chicago.

"Could we generate all three of these at once, so they can just copy-paste them?" I asked.

"We can do better than that," Steve said. "We can have a button for each of them that puts the citation directly into their clipboard."

We worked fast, creating a simple MVP (Minimum Viable Product) by the end of Friday night. All it did was grab the current website's metadata and structure it as a citation. But it worked.

Since it was my first hackathon, I didn't want the stress of staying in a hostel. So I'd splurged to get a hotel room. We had two twin beds, so each night we'd rotate which of us had to sleep on the floor.

Saturday morning, our ambitions grew. I walked to the whiteboard and said to the team: "Citing websites is great and all. But a lot of the things students cite are in books or academic papers. We need to be able to generate citations for those, too."

We found an API that we could use to get citation information based on ISBN (a serial number used for books). And we hacked together a script that could search for academic papers based on their DOI (a serial number used for academic papers), then scrape data from the result page.

By Saturday night, the code for our browser plugin was really coming together. So I sat down and started preparing the presentation slides. I left a lot of the final coding to my teammates while I rehearsed my pitch over and over again for hours.

Even though it was my turn to sleep in a bed, I could barely get any shut-eye due to the jitters. Here I was, right in the heart of the tech ecosystem. Silicon Valley.

As a teacher, I would routinely give talks in front of my peers – sometimes dozens of them. But this was different.

In a few hours, I'd be presenting to a room full of ambitious developers. And judges. People with Ph.D.s, some of whom had founded their own tech companies. They were going to be evaluating our work. I was terrified I'd somehow blow it.

Unable to sleep, I opened my email. The Startup Weekend staff had sent out an email, which included a PDF of a book. It was an unofficial mash-up of the tech startup classics 4 Steps to the Epiphany and The Lean Startup.

Now, I had already read these books, because they were required reading for anyone who wanted to build software products in the early 2010s. But I had also read dozens of other startup books. And a lot of their insights sort of ran together into a slurry of advice.

It was 4 a.m., and I couldn't sleep. So I just started reading. One thing these books really hit on is building something that people will pay for. The ultimate form of customer validation.

That's when I realized: you know what would really push my presentation over the finish line? Proof of product-market fit. Proof that the app we were building solved a real problem people had. So much so that they'd open up their wallets.

This gave me an idea. I should take our app on the road and sell it to people.

But it was Sunday morning. Where was I going to find potential customers? Well, our hotel just happened to be located near the main campus of Stanford University.

I drove my team to the event venue, waved goodbye and said: "I'll come back when I have cold, hard cash from customers."

My teammates chuckled. I'm not sure if they thought I was serious. They said, "Just don't be late for the pitch."

But I was serious. I had a prototype of the app running on my laptop. I punched Stanford into my GPS and embarked on my mission.

Now, I studied at a really inexpensive state university in Oklahoma. So I felt really out of my depth when I rolled up to one of the premier universities in the world.

Stanford costs $50,000 per year to attend. And I pulled into their parking lot driving a car worth 1/10th of that.

The campus was a ghost town this time of the week. But a palatial ghost town, nonetheless. Bronze statues. Iconic arches everywhere.

I asked myself: where are the most high-achieving, hard-core students this time of day? The ones who don't have time to waste on manually creating their Work Cited pages?

I walked into the main library, right past the security desk and a sign that said "no soliciting."

I strode around the stacks, finding a small handful of people studying. This one kid was studiously taking notes as he read through a thick textbook. Bingo.

I slid into the seat next to him. "Psst. Hey. Do you like citations?"

"What?"

"Citations. You know, like, work cited pages."

"Um..."

"You know, the last page of your paper, where you have to list all the..."

"I know what a work cited page is."

"OK. Well check this out." I pulled my jacket to the side like a drug dealer, and whipped out my $200 netbook. He humored me for a moment while I delivered my awkward sales pitch.

I said: "Here. I've got this browser plugin. I go to any website, click the button, and voilà. It will create a citation for me."

The kid raised his eyebrows. "Can it do MLA?"

I bit back my excitement and said, "MLA, APA, and even Chicago. Watch." I clicked the button and three citations appeared – each with its own copy-to-clipboard button.

The kid nodded, seeming somewhat impressed. So I attempted to close the sale.

"What if I told you that I was about to launch this app with a yearly subscription. But if you sign up now, I'll get unlimited access not for a year, but for a lifetime."

The kid thought for a moment.

I had heard that silence was the salesperson's best friend. So I sat there for an uncomfortably long time in total silence, staring him down.

Finally he said: "Cool I'm in."

"Awesome. That'll be twenty bucks."

The kid recoiled. "What? That's expensive."

This was of course the era of venture capital-subsidized startups, where Uber and Lyft were losing money on every ride in a race for market share. So the kid's reaction was not totally surprising.

But I thought fast. "Well, how much cash do you have on you?"

He fumbled with his wallet, then said, "five bucks."

I looked at the crumpled bill and shrugged. "Sold."

He smiled, and I sent him an email with instructions for how to install it. Then I said, "One more thing. Let's take a picture together."

I put my phone on selfie mode. He started to smile, and I said, "Here. Hold up the five dollar bill."

I spent another hour pitching people in the library, and managed to get another paying customer as well. Then I raced back to the event venue to finalize our prototype with the team.

That afternoon, I gave what I still think is the best presentation of my life. We live-demoed the working app – which worked perfectly.

We ended the presentation with the photos I'd taken, posing with Stanford students who were now our paying customers. When I held up the cash we earned, the audience burst into applause.

Overall, it was one of the most exhilarating experiences of my life. We came in second place, and won some API credit from one of the companies who sponsored the event.

At the after party, I chipmunked some pizza, so I'd have more time to network with everyone I could. I connected on LinkedIn. I followed on Twitter. I snapped selfies together with people and used the heck out of the event's hashtag.

This was a watershed moment in my coding journey. I had proven to the people in that room that I could help design, code, and even sell an app. And more importantly, I'd proven it to myself.

Riding the Hackathon Circuit

From that moment on, I was hooked on hackathons. That year, I participated in dozens of them. I became a road warrior, railing up and down the coast, attending every competition I could.

It would be much harder from here on out. I didn't have a team anymore. I was on my own.

I'd arrive, meet as many people as I could, then go up and pitch an idea I thought might win over the judges.

Sometimes people joined my team. Sometimes I joined other people's teams.

I didn't merely want to design apps – I wanted to code them, too. And my reach often exceeded my grasp.

There were many hackathons where I would still be trying to fix bugs down to the final minutes before going on stage. Sometimes my apps would crash during live demos.

One hackathon in Las Vegas, I managed to screw up the codebase so badly that we just had to use a slideshow. I sat in the audience with my head in my hands, watching helplessly as my team member demonstrated how our app would hypothetically work – if I could have gotten it to work. We didn't fare well with the judges.

But I kept grinding. Kept arriving in new towns, checking into the hostel, and hitting the venue, and eating as much free pizza as I could.

My teams had come in second or third so many times I could barely keep count. But we'd never managed to outright win a hackathon.

Breaking Through

That was until an event in San Diego. I'll never forget the feeling of building something that won over the audience and judges to the extent that our victory felt like a foregone conclusion.

After they announced us as the winner, I remember sneaking out the back door to a parking lot and calling my grandparents. I told them that I'd finally done it. I'd helped build an app and craft a pitch that had won a hackathon.

I don't know how much my grandparents understood about software development, or about hackathons. But they said they were proud of me.

With them gone now, I often think back to this conversation. I cherish their encouragement. Their faith in a 30-something teacher grandson could try like crazy and become a developer.

I kept going to hackathons after that. I kept forming new teams and learning new tools along the way. You never forget the first time you get an API to work. Or when you finally grok how some Git command works. And you never forget the people hustling alongside you, trying to get the app to hold together through the demo.

The TechCrunch Disrupt hackathon. The DeveloperWeek hackathon. The ProgrammableWeb hackathon. The $1 Million Prize Salesforce Hackathon. So many big hackathons and so much learning. This was the crucible where my developer chops were forged.

Not only did I manage to build my skills and my network along the way – I now had a reputation as someone who could actually win a hackathon.

I could ship.

This made me a known quantity.

And that reputation was crucial to getting my first freelance clients, my first developer job, and most importantly – trusting my own instincts as a dev.

Why Your Reputation is So Important

The role of reputation in society goes way, way back to human prehistory. In most tribes and settlements, there was some system to keep track of who owed what to whom.

Before there was cash, there was credit.

This may have been a written ledger. Or it may have been an elder who simply kept all these records in their head.

Beyond raw accounting, there was also a less tangible, but equally important vibe that people carried with them.

"John sure knows how to shoe a horse."

Or "Jane is the best story teller in the land."

Or "Jay's courage in battle saved us against the invaders three winters ago."

You'll note that these examples all involve someone being good at something. Not merely being a good, likable person.

It certainly helps to be a chill, down-to-earth human being. But this isn't The Big Lebowski, and we aren't going to survive on our charm alone.

The Big Lebowski (left). He had no job, he had no skills, he had no energy. But he had chill, out the wazoo.

It's easy for a developer to say: "Oh yeah. I know JavaScript like the back of my hand. I can build you any kind of JavaScript application you need, running on any device you can think of."

Or to say: "I ship code under budget and ahead of time – all the time."

But how do you know they're not exaggerating their claims?

After all, a devious man once said:

"If you can only be good at one thing, be good at lying.

Then you're good at everything."

(The true provenance of this quote is unknown. But I like to imagine it was said by a 1920s con man wearing a top hat and a monocle.)

Anyone can lie. And some people do.

Earlier in my career, I had the unpleasant task of firing a teacher who had lied about earning a master's degree. The years went by and nobody caught it.

Every year, he would lie on his annual paperwork, so that he could get a higher pay raise than the other teachers. And every year, he would get away with it.

But one day a small discrepancy tipped me off. I reviewed his file, called up some university record departments, and discovered that he had never bothered finishing his degree.

When I caught him it was a real Scooby Doo moment. "And I would have gotten away with it, if not for you darn kids."

It sucked to know that this person was teaching at the school for years and getting paid more than many of the other teachers – just because he was willing to lie.

The spoils of lying are always there, glistening. Some people are willing to give in to that temptation.

Employers know this. They know you can't trust just any person who claims to know full-stack JavaScript development. You have to be cautious about who gets a company badge, a company email address, and the keys to your production databases.

This is why employers use behavioral interview questions – to try and catch people who are more capable of dishonesty.

Call me naive, but I believe that most people are inherently good. That most people are willing to play by the rules as long as those rules are reasonably fair.

But if even one person out of ten would be a disaster hire, it means that all of us are subjected to higher scrutiny.

The worst-case scenario is not merely someone who lies to make more money. It's someone who sells company secrets, destroys relationships with customers, or breaks laws in the name of inflating their numbers.

History is rife with employees who unleashed catastrophic damage upon their employers, all for their own personal gain.

Thus, the developer hiring process at most big companies is paranoid as heck. Maybe it should be. But unfortunately, this makes it harder for everyone to get a developer job – even the most honest of candidates.

As developers, we need proof that our skills are as strong as we say they are. We need proof that our work ethic is as steadfast as our employers need it to be.

That's where reputation comes in. It reduces ambiguity. It reduces counter-party risk. It makes it safer for employers to make a job offer, and to sign an employment contract with you.

This means that – if you have a strong enough reputation – you may be able to get into the company through a side door – rather than the front door that other applicants line up for.

Some companies even have in-house recruiters who can fast track your interview process. A strong reputation can also help you command more bargaining power during salary negotiations.

So let's talk about how you can build a strong reputation, and become sought-after by managers.

How to Build Your Reputation as a Developer

There are at least six time-tested ways you can build your reputation as a developer. These are:

1. Hackathons
2. Contributing to open source
3. Creating Developer-focused content
4. Rising in the ranks working at companies who have a "household name"
5. Building a portfolio of freelance clients
6. Starting your own open source project, company, or charity

How to Find Hackathons and Other Developer Competitions

Hackathons represent the most immediate way to build your reputation, your network, and your coding skills at the same time.

Most hackathons are free, and open to the public. You just need to have the time and the budget to travel.

If you live in a city with lots of hackathons – like San Francisco, New York, Bengaluru, or Beijing – you may be able to commute to the event, then go home and sleep in your own bed.

Even though I lived in Santa Barbara, which only had hackathons once every few months, I did have an old classmate in San Francisco who let me crash on his couch. This gave me access to many more events.

Hackathons used to be hard core events. People would knock back energy drinks and sleep on floors, all to finish their project by pitch time.

But hackathon organizers are gradually becoming more mindful about the health and sustainability of these events. After all, a lot of participants have kids, or demanding full-time jobs, and can't just all-out code for an entire weekend.

The best way to find upcoming events is to just google "hackathon [your city name]" and browse the various event calendars that come up in the search results. Many of these will be run by universities, local employers, or even education-focused charities.

If you're playing to win, I recommend doing your research ahead of time.

Who are the event sponsors? Usually it will be Business-to-Developer type companies, with APIs, database tools, or various Software-as-a-Service offerings.

These sponsors will probably have a booth at the event where you can talk with their developer advocates. These are people who get paid to teach people how to use the company's tools. Sometimes you'll even meet key employees or founders at these booths, which can be a great networking opportunity, too.

Often the hackathon will offer sponsor-specific prizes. "Best Use of [sponsor's] API." It may be easier to focus your time on incorporating specific sponsor tools into your project, rather than trying to win the grand prize. You can still put these down as wins on your LinkedIn or your résumé. A win is a win.

Sometimes the hackathon is just so high profile – or the prize is so substantial – that is just makes sense to try and win the competition outright.

During my time going to hackathons, I was able to win several months' rent worth of cash prizes, several years' worth of free co-working space, and even a private tour of the United Nations building in New York City.

On the hackathon circuit, I met people whose main source of income was cash prizes from winning hackathons. One dev I knew managed to win nine sponsor prizes at the same hackathon. He managed to integrate all of those sponsor tools into his project – and also win second place overall.

Don't be surprised if some of the people you run into frequently at hackathons go on to found venture-backed companies, or launch prominent open source projects.

The level of ambition you'll see among hackathon regulars is way, way higher than that of the average developer. These are, after all, people who finish a work week, then go straight into a work weekend. These people are not afraid to leap out of the frying pan and into the fire.

How to Contribute to Open Source

Contributing to open source is one of the most immediate ways you can build your reputation. Most employers are going to look at your GitHub profile, which will prominently display your Git commit history.

The GitHub profile of Mrugesh Mohapatra, who does a ton of platform development and DevOps for freeCodeCamp.org. Note how green his activity bar is. 2,208 contributions in the past year alone.

Many open source project maintainers, such as Linux Foundation, Mozilla (Firefox), and of course freeCodeCamp ourselves, have high standards for code quality.

You can read through open GitHub issues to find known bugs or feature requests. Then you can make the code changes and open a pull request. If the maintainers merge your pull request, this will be a major feather in your cap.

One of the best ways to get a job at a tech company is to become a prolific open source contributor to their repositories.

Open source contribution is a great way to build your reputation because everything you do is right out in public. And you get the social proof of having other developers review and accept your work.

If you're interested in building your reputation through open source, here's how to get started.

Read Hillary Nyakundi's comprehensive guide to getting started with open source.

How to Create Developer-Focused Content

Developers are people. And like other people, they want something to do with their time when they're not working, sleeping, or hanging with friends and family.

For many people – including myself – that means spending time in other people's thoughts. Books. Video essays. Interactive experiences like visual novels.

You can broadly refer to these as "content." I'm not a huge fan of the word, because it makes these works feel disposable. But that's what people call it.

Software development is an incredibly broad field, with so many different topics you could approach. There are developer lifestyle vlogs, coding interview prep tutorials, coding live streams on Twitch, and developer interview podcasts like the freeCodeCamp Podcast.

There are probably entire categories of developer content that we haven't even thought of yet, which will break over the next decade.

If you're interested in film, journalism, or creative writing, developer content may be a good way to build your reputation.

You can pick a specific topic and gradually come to be seen as the expert.

There are developers who specialize in tutorials for specific technology stacks, for example.

My friend Andrew Brown is a former CTO from Toronto who has passed all the major DevOps exams. He creates free courses to prepare you for all the AWS, Azure, and Google Cloud certifications, and also runs an exam prep service.

There are more than 30 million software developers around the world. That's a lot of people who will potentially consume your content, and who will come to know who you are.

How to Rise in the Ranks by Working at Big Companies

You may have seen a developer introduced as an "Ex-Googler" or an "Ex-Netflix engineer."

Some tech companies have such rigorous hiring processes – and such high standards – that even getting a job at the company is a big accomplishment.

There are some practical reasons why employers look at where candidates have previously worked. It reduces the risk of a bad hire.

You can build up your reputation by working your way up the prestige hierarchy. You can ladder from a local employer to a Fortune 500 company, and ultimately to one of the big tech giants.

Of course, working at a giant corporation is not for everyone. I'll talk about this more in Chapter 4. But know that it is one option you have for building up your reputation.

How to Build your Reputation by Building a Portfolio of Freelance Clients

You can build your reputation by working with companies as a freelancer.

Freelance developers usually work on smaller one-person projects. So this may be a better strategy for building your reputation locally.

For example, if you did good work for a locally-based bank, that may be enough to convince a local law firm to contract you as well.

There is something to be said for being a "hometown hero." I know many developers who can effectively compete with online competition just by being physically present in meetings, and knowing people locally.

How to Build a Developer Portfolio of Your Work

Once you've built some projects, you'll want to show them off. And the best way to do this is with short videos.

People are busy. They don't have time to pull down your code and run it on their own computer.

And if you send people to a website, they may not fully grasp what they're looking at, and why it's so special.

That's why I recommend you use a screen capture tool to record 2 minute video demos.

Two minutes should be long enough to show how the project works. And once you've done that, you can explain some of the implementation details, and design decisions you made.

But always, always start with the demo. People want to see something work. They want to see something visual.

Once you've lured people in with your compelling demo of your app running, you can explain all the details you want. Your audience will now have more context, and be more interested.

Two minutes is also a magic length, because you can upload that video to a tweet, and it will auto-play on Twitter as people scroll past it. Auto-play videos are much, much more likely to be watched on Twitter. They remove the friction of having to click a play button, or navigate to another website.

You can put these project demo videos on websites like YouTube, Twitter, your GitHub profile, and of course your own portfolio website.

For capturing this video, I recommend using QuickTime, which comes built-in with MacOS. And if you're on Windows, you can use Game Recorder, which comes free in Windows 10.

And if you want a more powerful tool, OBS is free and open source. It's harder to learn, but infinitely customizable.

As far as recording tips: keep your font size as large as possible, and use an external mic. Any mic you can find – even from cheap headphones – will be better than speaking into your laptop's built in mic.

Invest as much time as you need to in recording and re-recording takes until you nail it.

Being able to demo your projects and present your code is a valuable skill you'll use throughout your career. Time spent practicing pitching is never wasted.

How to Start Your Own Open Source Project, Company, or Charity

Being a founder is the fastest – but also riskiest – way to build a reputation as a developer.

It's riskiest because you're wagering your time, your money, and possibly even your personal relationships – all for an unknown outcome.

If you contribute to open source for long enough, you will build a reputation as a developer.

If you grind the hackathon circuit for long enough, you will build a reputation as a developer.

But you could attempt to start entrepreneurial projects for decades without getting traction. And squander your time, money, and connections along the way.

Entrepreneurship is beyond the scope of this book. But if you're interested in it, I will give you this quick advice:

Most entrepreneurs fail. Some fail due to circumstances outside their control. But a lot fail due to not understanding the nature of the risks they're taking on.

Don't rush into founding a project, company, or charity. Try to work for other organizations who are already doing work in your field of interest.

By working for someone else, you get paid to learn. You get exposure to the work, and the risks surrounding it. And you can build savings for an eventual entrepreneurial venture.

How Not to Destroy Your Reputation

"It takes a lifetime to build a good reputation, but you can lose it in a minute." – Will Rogers, Actor, Cowboy, and one of my heroes growing up in Oklahoma City

Building your reputation is a marathon, not a sprint.

It may take years to build up a reputation strong enough to open the right doors.

But just like in a competitive marathon, a stumble can cost you valuable time. A stumble that results in injury may put you out of the race completely.

Don't Say Dumb Things on the Internet

People used to say dumb things all the time. The words might hang in the air for a few minutes while everyone winced. But the words did eventually dissipate.

Now when people say dumb things, they often do so online. And in indelible ink.

Always assume that the moment you type something into a website and press enter, it's going to be saved to a database. That database is going to be backed up across several data centers around the world.

You can prove the existence of data, but there is no way to prove the absence of data.

You should assume, for all intents and purposes, that the cat is out of the bag. There's no getting the cat back in the bag. Whatever you just said: that's on your permanent record.

You can delete the remark. You can delete your account. You can even try to scrub it from Google search results. But someone has probably already backed it up on the Wayback Machine. And when one of those databases inevitably gets hacked years from now, those data will probably still be in there somewhere, ready for someone to resurface them.

It is a scary time to be a loud mouth. So don't be. Think before you speak.

My advice, which may sound cowardly: get out of the habit of arguing with people online.

Some people abide by the playground rule of "if you don't have something nice to say, don't say anything at all."

I prefer the "praise in public, criticize in private."

I will publicly recognize good work someone is doing in the developer community. If I see a project that impresses me, I will say so.

But I generally refrain from tearing people down. Even people who deserve it.

In a fight, everyone looks dirty.

You don't want to look wrathful, tearing apart someone's argument, or dog piling in on someone who just said something dumb.

Sure – caustic wit can win you internet points in the short term. But it can also make people love you a little bit less and fear you a little bit more.

I also try to refrain from complaining. Yes, I could probably get better customer service if I threatened to tweet about a cancelled flight.

But people are busy. Most of them don't want to use their scarce time, scrolling through social media, only to see me groaning about what is in the grand scheme of things a mild inconvenience.

So that is my advice on using social media. Try to keep it positive.

If it's a matter that you believe strongly about, I won't stop you from speaking your mind. Just think before you type, and think before you hit send.

Don't Over-promise and Under-deliver

One of the most common ways I see developers torpedo their own reputations is to over-promise and under-deliver. This is not necessarily a fatal error. But it is bad.

Remember when I talked about the Las Vegas hackathon where I utterly failed to finish the project in time for the pitch, and we had to use slides instead of a working app?

Yeah, that was one of the lowest points in my learn to code journey. My teammates were polite, but I'm sure they were disappointed in me. After all, I had been overconfident. I had over-promised what I'd be able to achieve in that time frame, and I had under-delivered.

It is much better to be modest in your estimations of your abilities.

Remember the parable of Icarus, who on wax wings flew too close to the sun. If only he'd taken a more measured approach. Ascended a bit slower. Then his wings wouldn't have melted, and he wouldn't have plunged into the sea, leaving a guilt-stricken father.

Landscape with the Fall of Icarus by Pieter Bruegel the Elder, circa 1560. Icarus coulda been a contender. He coulda been somebody. But instead, he's just legs disappearing into the sea. And the farmers and the shepherds can't be bothered to look up from their work to take in his insignificance.

Get Addictions Under Control Before They Damage Your Reputation

If you have an untreated drug, alcohol, or gambling addiction, seek help first. The developer job search can be a long, grueling one. You want to go into it with your full attention.

Even something as seemingly harmless as video game addiction can distract you, and soak up too much of your time. It's worth getting it under control first.

I am not a doctor. And I'm not going to give you a "drugs are bad" speech. But I will say: you may hear of Silicon Valley fads, where developers abuse drugs thinking they can somehow improve their coding or problem solving abilities.

For a while there was a "micro-dosing LSD" trend. There was a pharmaceutical amphetamines trend.

My gut reaction to that is: any edge these may give you is probably unsustainable, and a net negative over a longer time period.

Don't feel peer pressure to take psychoactive drugs. Don't feel peer pressure to drink at happy hours. (I haven't drank so much as a beer since my daughter was born 8 years ago, and I don't feel like I've missed out on anything at all.)

If you are in recovery from addiction, be mindful that learning to code and getting a developer job will be a stressful process. Pace yourself, so you don't risk a relapse.

You do not want to reach the end of the career transition process – and achieve so much – only to have old habits resurface and undo your hard work.

Try and Separate Your Professional Life From Your Personal Life

You may have heard the expression, "Don't mix business with pleasure."

As a developer, you are going to become a powerful person. You are going to command a certain degree of respect from other people in your city.

Maybe not as much as a doctor or an astronaut. But still. People are going to look up to you.

You're going to talk with people who would love to be in your shoes.

Do not flaunt your wealth.

Do not act as though you're smarter than everybody else.

Do not abuse the power dynamic to get what you want in relationships.

This will make you unlikable to the people around you. And if it's somehow captured and posted online, it may go on to haunt you for the rest of your career.

Never lose sight of how much you have. And how much you have to lose.

Use the Narrator Trick

I'll close this chapter with a little trick I use to pump myself up.

First, remember that you are the hero in your own coding journey. In the theater of your mind, you are the person everyone's watching – the one they are rooting for.

The Narrator Trick is to narrate your actions in your head as you do them.

Quincy strides across the hackerspace, his laptop tucked under his arm. He sets his mug under the hot water dispenser and drops in a fresh tea bag. He pulls back the lever. And as the steaming water fills his mug, he says aloud in his best British accent: "Tea. Earl Grey. Hot."

His energizing beverage in hand, he slides into a booth, squares his laptop on the surface, and catches the glance of a fellow developer. They lock eyes for a second. Quincy bows his head ever-so-slightly, acknowledging the dev's presence. The dev bows back, almost telepathically sharing this sentiment: "I see you friend. I see you showing up. I see you getting things done."

This may sound ridiculous. Why yes, it is ridiculous. But I do it all the time. And it works.

Narrating even the most mundane moments of your life in your head can help energize you. Crystalize the moment laid out before you, and give you clarity of purpose.

And this works even better when you think of your life in terms of eras ("the Taco Bell years"). Or inflection points ("passing the GED exam").

What does this have to do with building your reputation? Your reputation is essentially the summary of who you are. What you mean to people around you.

By taking yourself more seriously, by thinking about your life as a movie, you're gradually working through who you are. And who you want to one day become.

By narrating your actions, you shine a brighter light on them in your own mind. Why did I just do that? What was I thinking? Was there a better move there?

So many people sabotage their reputations without even realizing it, just because they've settled into bad habits.

For years I thought I had to be "funny" all the time. I would find any opportunity to inject some self-deprecating humor. A lot of people realized what I was doing and found it amusing. But a lot of them didn't understand, and just got the impression I was a jerk.

Why did I do that? I think it went back to grade school, when I was always trying to be the class clown and make people laugh.

But decades later, this reflex to fill silence with laughter was not serving me well.

"When you repeat a mistake, it's not a mistake anymore. It's a decision." – Paulo Coelho

I might have gone on much longer without noticing this bad habit. But with the Narrator Trick, the awkwardness of my behavior was laid bare.

I'm sure I've got lots of other ways of thinking and ways of doing things that are suboptimal. And with the help of the Narrator Trick, I'm hoping to identify them in the future and refine them, before they give people the wrong impression.

Your Reputation Will Become Your Legacy.

Think about who you want to be at the end of your story. How you want people to think of your time on Earth. Then work backward from there.

The person you want to be at the end of the movie. That hero you want people to admire. Why not start carrying yourself like that now?

Can you imagine what it would be like to be a successful developer? To have built software systems that people rely upon?

That future you – how would they think? How would they approach situations and solve problems? How would they talk about their accomplishments? Their setbacks?

Merely thinking about your future self can help you clarify your thinking. Your priorities.

I often think of "Old Man Quincy", with his bad back. He has to excuse himself to run to the toilet every 30 minutes.

But Old Man Quincy still tries his best to work with what he has. He moves in spite of sore joints. He ponders in spite of a foggy mind.

Old Man Quincy still wants to get things done. He's proud of what he's accomplished, but he doesn't spend much time looking back. He looks forward at what he's going to do that day, and what goals he's going to accomplish.

I often think about Old Man Quincy, and work backward to where I am today.

What decisions can I make today that will set me up for being someone worthy of admiration tomorrow? Do I have to wait decades to earn that reputation? Or can I borrow some of that respect from the future?

By thinking like my future self might think, can I make moves that earn me a positive reputation in the present?

I believe that you can leverage your future reputation – your legacy – right now. Just think in terms of your future self and what you'll accomplish. And use that as a waypoint to guide you forward.

I hope that these tools – the Narrator Trick and the visualizing your future self trick – help you not only think about the nature of reputation. I hope they also help you take concrete steps toward improving your reputation.

Because building a reputation – making a name for yourself – is the surest path to sustainable success as a developer.

Success can mean many things to many people. But most people – from most cultures – would agree: one big aspect of success is putting food on the table for yourself and your family.

And that's what we're going to talk about next.

Chapter 4: How to Get Paid to Code – Freelance Clients and the Job Search

If you've been building your skills, your network, and your reputation, then getting a developer job is not all that complicated.

Note that I said it's not complicated – it's still a lot of work. And it can be a grind.

First, let me tell you how I got my first job.

Story Time: How Did a Teacher in His 30s Get His First Developer Job?

Last time on Story Time: Quincy hit the hackathon circuit hard, even winning a few of the events. He was building his reputation as a developer who was "dangerous" with JavaScript. Not super skilled. Just dangerous...

I had just finished a long day of learning at the Santa Barbara downtown library, sipping tea and building projects.

The best thing about living in California is the weather. We'd joke that when you rented an exorbitantly-priced one-bedroom apartment in the suburbs, you were not paying for the inside – you were paying for the outside.

My goal was to spend as little time in that cramped 100-year old rat trap as necessary, and to spend the rest out walking around town.

It was a beautiful Wednesday evening. I still had two more days to prepare for that weekend's hackathon. And my brain was completely fried from the day of coding. My wife was working late, so I checked my calendar to find something to do.

On the first Monday of each month, I would map out all that month's upcoming tech events around southern California, so I'd always have a tech event I could attend if I had the energy.

Ah – tonight is the Santa Barbara Ruby on Rails meetup, and I had already RSVP'd.

I didn't know a lot about Ruby on Rails, but I had completed a few small projects with it. I was much more of a JavaScript and Python developer.

But I figured, what the heck. I need to keep up my momentum with building my network. And the venue was just a few blocks away.

I walked in and it was just a few devs sitting around a table chatting. It quickly became clear that they all worked together at a local startup, maintaining a large Ruby on Rails codebase. Most of them had been working there for several years.

Now at this point, I'd spent the past year building my skills, my network, and my reputation. So I was able to hold my own during the conversation.

But I also had a feel for the limits of my abilities. So I stayed modest. Understated. The way I'd seen so many other successful developers maneuver a conversation at tech events.

It became clear that one of the developers at the table was the Director of Engineering. He reported directly to the CTO.

And then it became clear that they were looking to hire Ruby on Rails developers.

I was candid about my background and my abilities. "My background is in adult education. Teaching English and running schools. I just started learning to code about a year ago."

But the man was surprisingly unfazed. "Well if you want to come in for an interview, we can see whether you'd be a good fit for the team."

That night I walked home feeling an electricity. It was much more dread than excitement.

I felt nowhere near ready. And I wasn't even looking for a job. I was just living off my savings, learning to code full-time, with health insurance through my wife's job.

I was a compulsive saver. People would give me a hard time about it. I would change my own oil, cut my own hair, and even cook my own rice at home when we ordered takeout – just to save a few bucks.

Over the decade that I'd worked as a teacher, I'd managed to save nearly a quarter of my after-tax earnings. And I would buy old video games on Craigslist, then flip them on eBay. That may sound silly, but it was a substantial source of income for me.

What were we saving all this for? We weren't sure. Maybe to buy a house in California at some point in the future? But it meant that I did not have to hustle to get a job. I knew I was in a privileged position, and I tried to make the most of it by learning more every day.

So in short, I didn't think I was ready for my first developer job. And I was worried that if they hired me, it would be a big mistake. They would realize how inexperienced I was, fire me, and then I'd have to explain that failure during future job interviews.

Of course, I now know I was looking at this opportunity the wrong way. But let me finish the story.

When I scheduled my job interview, they asked me for a résumé. I wasn't sure what to do, so I left all my professional experience there. All the schools I'd worked for over the years. (I left off my time running the drive-thru at Taco Bell.)

Of course, none of my work experience had anything to do with coding. But what was I supposed to do, hand them a blank sheet of paper?

Well, I did have an online portfolio of projects I'd built. And most importantly, I had a list of all the hackathons I'd won or placed at. So I included those.

I spent the final hours before the interview revisiting all the Ruby on Rails tutorials I'd used over the past year, to refresh my memory. And then I put on my hoody, jeans, and backpack, and walked over to their office.

The office manager was a nice lady who took me back to the developer bullpen and introduced me to their small team of devs. There were maybe a dozen of them, most of them dressed in jeans and hoodies, aged from early 20s to late 40s. Two of them were women.

I took turns navigating the tangle of desks and cables, shaking hands with each of them and introducing myself. This is where all my experience as a classroom teacher memorizing student names came in handy. I was able to remember all their names, so that later in the day when I left I could follow up with each of them: "Great meeting you [name]. I'd be excited to work alongside you."

First I met with the director of engineering. We went into a small office and closed the door.

A whiteboard on the wall was covered in sketches of Unified Modeling Language (UML) diagrams. A rainbow of dry-erase marker laid out the relationships between various servers and services.

I kept glancing at that whiteboard, fearing that he'd send me over to it to solve some coding problems and demonstrate my skills. Maybe the famous fizzbuzz problem? Maybe he'd want me to invert a binary tree?

But he never even mentioned the whiteboard. He just sat there looking intensely at me the whole time.

They were a company of about 50 employees, with lots of venture capital funding, and thousands of paying customers – mostly small businesses. They prided themselves on being pragmatic. At no point did they inquire about what I studied in school, or what kind of work I did in the past. All they really cared about was...

"Look. I know you can code," he said. "You've been coding this whole time, winning hackathons. I checked out some of your portfolio projects. The code quality was OK for someone who's new to coding. So for me, the real question is – can you learn how we do things here? Can you work with the other devs on the team? And most critically: can you get things done?"

I gulped, leaned forward, and mustered all the confidence I could. "Yes," I said. "I believe I can."

And he said, "Good. Good. OK. Go wait in the Pho restaurant downstairs. [The CTO] should be down there in a minute."

So I talked with the CTO over noodles. Mostly listened. I'd learned that people project intelligence onto quiet people. Listening intently not only helps you get smarter – it even makes you look smarter.

And the approach worked. The meeting lasted about an hour. The noodles were tasty. I learned a lot about the company history, and the near-term goals. The CTO said, "OK go back up and talk with [the director of engineering]."

And I did. And he offered me a job.

Now, I want to emphasize. This is not how most people get their first developer job.

You're probably thinking, "Gee, here Quincy is Forest Gumping his way into a developer job that he wasn't even looking for. If only we could all be so lucky."

And that's certainly what it felt like for me at the time. But in the next section, I'm going to explore the relationship between employers and developers. And how me landing that job was less about my skills as an interviewee, and more about the year of coding, networking, and reputation building that preceded it.

This wasn't a cushy job at a big tech company, with all the compensation, benefits, and company bowling alleys. It was a contractor role that paid about the same as I was making as a teacher.

But it was a developer job. A company was paying me to write code.

I was now a professional developer.

What Employers Want

Flash forward a decade. I have now been on both sides of the table. I've been interviewed by hiring managers as a developer. I've interviewed developers as a hiring manager.

I've spent many hours on calls with developers who are in the middle of the job search. Some of them have applied to hundreds of jobs and gotten only a few "call-backs" for job interviews.

I've also spent many hours on calls with managers and recruiters, trying to better understand how they hire and what they look for.

I think much of the frustration developers feel about the hiring process comes down to a misunderstanding.

Employers value one thing above all else: predictability.

Which of these candidates do you think an employer would prefer?

X is a "rockstar" 10x coder who often has flashes of genius. X also has bursts of incredible productivity. But X is often grumpy with colleagues, and often misses deadlines or meetings.

Y is an OK coder, and has slower but more consistent output. Y gets along fine with colleagues, and rarely misses meetings or deadlines.

Z is similar to Y in output, and able to get along well with colleagues and meet deadlines. But Z has changed jobs 3 times in the past 3 years.

OK, you can probably guess from everything I've said up to this point: Y is the preferred candidate. And that is because employers value predictability above all else.

X is a trap candidate that some first-time managers may make the mistake of hiring. If you are curious why hiring X would be such a bad idea, read We fired our top talent. Best decision we ever made.

I only added Z to this list to make a point: try not to change jobs too often.

You can increase your income pretty quickly by laddering from employer to employer. You can start applying for new jobs the moment you accept an offer letter. But this will repel many hiring managers.

After all, the rolling stone gathers no moss. You will be in and out of codebases before you have the time to understand how they work.

Consider this: it can take 6 months or longer for a manager to bring a new developer up to speed, to the point where they can be a net positive for the team.

Until that point, the new hire is essentially a drain on company resources, absorbing time and energy from their peers who have to onboard them, help them find their way around a codebase, and fix their bugs.

Most Employers are Risk Averse

Let's say a manager hires the wrong developer. Take a moment to think about how bad that can be for the team.

On average, it takes about 3 months to fill a developer position at a company. Employers have to first:

• get the budget to hire a developer approved by their bosses
• create the job description
• post the job on job sites and communicate with recruiters
• sift through résumés – many of which will be low-effort from candidates who are blindly applying to as many jobs as possible
• start the interviewing process, which may involve flying the candidates out to the city and lodging them in a hotel
• rounds of interviews involving lots of team members. For some employers, this is a multi-day affair
• selecting a final candidate, and negotiating an offer...
• which many candidates will not accept anyway
• signing contracts and onboarding the employee
• giving them access to sensitive internal systems
• introducing them to their teammates, and making sure everyone gets along OK
• and then months of informal training, when the employee needs to understand a service or a part of a legacy codebase
• and finally, steeping them in the team's way of doing things

In short – a lot of work.

Now imagine that after doing all that, the new employee says "Hey, I just got a higher offer from this other company. Peace out, yo."

Or imagine that the employee is unreliable, and often shows up hours after the workday has started.

Or imagine that the employee struggles with untreated drug, alcohol, or gambling addiction, anger issues – or just turns out to be a passive aggressive person who undermines the team.

Now you have to start this entire process over again, and search for a new candidate for the position.

Hiring is hard.

So you can see why employers are risk averse. Many of them will pass over seemingly qualified candidates until they find someone whom they feel 99% sure about.

Because Employers are So Risk Averse, Job Seekers Suffer

Now if you think hiring is hard, wait until you hear about the job application process. You may already be all-too-familiar with it. But here goes...

• You have to prepare your résumé or CV. Along the way, you will make decisions which you'll constantly second-guess throughout your job search.
• You have to look around for job openings online, research the employers, and assess whether they're likely to be a good fit for you.
• Most job openings will lead to webforms where you will have to retype your résumé over and over again, hoping the form doesn't crash due to server errors or JavaScript validation errors.
• Once you submit these job applications, you have to wait while employer process them. Some employers receive so many applications that they can't manually review them all. (Google alone receives 9,000 applications per day.) Employers will use software to filter through applications. In-house recruiters spend an average of 6 seconds looking at each résumé. Often your application will never even be reviewed by a human.
• You will likely never hear anything back from the company. They have little incentive to tell you why they rejected you (they don't want you to file a discrimination lawsuit). If you're lucky, you'll get one of those "We've chosen to pursue other candidates" emails.
• And all the time you spend applying for these jobs – potentially hours per week – is mentally exhausting and, of course, unpaid.

Wow. So you can see what a nightmare the hiring process is for employers, and especially for job candidates.

But if you stick with it, you can eventually land offers. And when it rains, it pours.

Here's data from one freeCodeCamp contributor's job search over the span of 12 weeks:

Out of 291 applications, he ultimately received 8 offers.

And as the offers came in, the starting salary got higher and higher. Note, of course, that this is for a job in San Francisco, one of the most expensive cities in the world.

By week 12 his starting salary offers were nearly double what they were in week 2.

This developer's rate of getting interviews is quite strong. And his negotiation ability was also strong. You can read more about his process if you're curious.

But as I've said before, it is much easier to get into a company through the side door.

And that's one of the reasons I wrote this book. I don't want you to keep lining up for the front door at these employers.

If you Build Your Skills, Your Network, and Your Reputation You Can Bypass a Lot of the Job Application Process.

Throughout this book, I've been teaching you techniques to increase your likelihood of "lucking" into a job offer.

"Luck is preparation meeting opportunity. If you hadn't been prepared when the opportunity came along, you wouldn't have been 'lucky.'" – Oprah Winfrey

This is why throughout this book I've encouraged you to develop all three of these areas at once, and to start thinking about them from day one – well in advance of your job search.

My story of not even looking for a job and landing a job may seem silly. But this happens more often than you might think.

The reality is: learning to code is hard.

But knowing how to code is important.

In every industry – in virtually every company in the world – managers are trying to figure out ways to push their processes to the software layer.

That means developers.

You may hear about big layoffs in tech from time to time. Many of these layoffs affect employees who are not developers. But often a lot of developers do lose their jobs.

Why would companies lay off developers, after spending so much time and money recruiting and training them? Aside from a bankruptcy situation, I don't know the answer to that question. I'm not sure that anyone does.

There's growing evidence that layoffs destroy long-term value within a company. But in practice, many CEOs feel pressure from their investors to do layoffs. And when a several companies do layoffs at around the same time, other CEOs may follow suit.

Still, even with the layoffs, most economists expect the number of developer jobs and other software-related jobs to continue to grow. For example, the US Department of Labor Statistics expects an increase of 15% in developers over the next decade.

The job market may be tight right now, but few people expect this downturn to last.

My hope is that with strong skills, a strong network, and a strong reputation, you'll be able to land a good job despite a challenging job market.

Hopefully one day, it will be easier for employers and skilled employees to find one another – without the long, brutal job application and interviewing process.

What to Expect from the Developer Job Interview Process

Once you start landing job interviews, you'll get a taste of the dreaded developer job interview process and the notorious coding interview.

A typical interview flow might involve:

1. Taking an online coding assessment of your skills or a "Phone Screen."
2. And then if you pass that, a second phone- or video call-based technical interview
3. And then if you pass that, an "onsite" interview where you travel to a company office. These usually involve several interviews with HR, hiring managers, and rank-and-file developers you might work with.

Along the way, you'll face questions that test your knowledge of problem solving, algorithms & data structures, debugging, and other skills.

Your interviewers may let you solve these coding problems on a computer in a code editor. But often you'll have to solve them by hand while standing at a whiteboard.

The key thing to remember is that the person interviewing you is not just looking for a correct answer from you. They're also trying to understand how you think.

They want to know: do you understand fundamentals of programming and computer science? Or are you just regurgitating a bunch of solutions you memorized?

Now, practicing algorithms and data structures will go a long way. But you also need to be able to think out loud, and explain your thought process as you write your solutions.

The best way to practice this is to talk out loud to yourself while you code. Or – if you're feeling adventurous – live stream yourself coding.

There are lots of "live coding" streams on Twitch where people "learn in public" by building projects in front of an audience. As a bonus, if you're willing to put yourself out there like this, it will also help you build your reputation as a developer.

Another thing to remember during white board interviews: your interviewer. They're not just sitting there waiting for you to finish. They're with you the entire time, watching you and evaluating you both consciously and unconsciously.

Try to make the interview process as interactive as possible for your interviewer. Smile and make occasional eye contact. Try to judge their body language. Are they relaxed? Are they nodding along as you explain points?

Your interviewer probably knows what they're looking for in your code. So see if you can tease some hints out of them. By making observations or asking open-ended questions out loud to yourself, you may be able to get your interviewer to step in, and feel involved in the process.

You want your interviewer to like you. You want them to be rooting for you, so that they may dismiss some of the shortcomings in your programming skills, or overlook some of the errors you may make in your code.

You are selling yourself as a job candidate. Make sure your interviewer feels like they're getting a good deal.

And this goes the same for any Behavioral Interviews you may have to clear. These interviews are less about your coding ability than your "culture fit." (I wish I could tell you what this means, but every manager will define it in a slightly different way.)

In these Behavioral Interviews, you'll have to convince your interviewer that you have strong communication skills.

It definitely helps to be fluent in the language you're interviewing in, and to know the right jargon. You can pick a lot of this up from regularly listening to tech podcasts, like the freeCodeCamp Podcast.

One big thing your interviewers are trying to establish: are you a cool-headed person who will play well with others? The best way to show this is to be polite, and refrain from using profanity or drifting too far off from the subject at hand.

You do not want to get into a debate over something unrelated, like a sports rivalry. I also recommend not trying to correct your interviewers, even if they say things that you believe to be silly or false.

If you get bad vibes from the company, you don't have to accept their job offer. Employers pass on candidates all the time. And you as a candidate also have the right to pass on an employer. The interview itself is probably not the best time for conflict.

Should I Negotiate My Salary at My First Developer Job?

Trying to negotiate your salary upward generally does not hurt as long as you do so politely.

I've written at length on how to negotiate your developer job offer salary.

Essentially, negotiating a higher starting salary comes down to how much leverage you have.

Your employer has work to be done. How badly does your employer need you to work for them? What other options do they have?

And you need income to survive. What other options do you have? What is your backup plan?

If you have a job offer from another employer offering to pay you a certain amount, you can use that as leverage in your salary negation.

If your best backup plan is to go back to school and get a graduate degree... that's not particularly strong leverage, but it's better than nothing. And you could mention it during the salary negotiation process.

Think back to the lengthy hiring process I described earlier. Employers have to go through at least a dozen steps before they can reach the job offer step with candidates. They are probably already planning for you to negotiate, and won't be surprised by it.

Now, if you're in a situation like I was where a company just offers you a job out of the blue, you may feel awkward trying to negotiate.

Smithers from the Simpsons

I will admit – in my story time above, when my manager offered me the job, I did not negotiate.

In retrospect, should I have negotiated my compensation? Probably.

Did I have leverage? Probably not much. My backup plan was to just keep competing in hackathons and keep sipping tea and coding at the public library.

I may have been able to negotiate and get a few more bucks an hour. But in the moment they offered me the job, compensation was the last thing on my mind. I was just ecstatic that I was going to be a professional developer.

By the way, once you've worked as a developer at a company for a year or so, you may want to ask for a raise. I've written at length about how to ask for a raise as a developer. But it comes down to the same thing: leverage.

Should You Use a Recruiter for Your Developer Job Search?

Yes. If you can find a recruiter who will help you land your first developer job, I think you should.

I've written at length about why recruiters are an underrated tool in your toolbox.

Many employers will pay recruiters a finder's fee for sending them high quality job candidates.

Recruiters’ incentives are well-aligned with your own goals as a job seeker:

1. Since they get paid based on your starting salary, they are inclined to help you negotiate as high a starting salary as possible.
2. The more candidates they place — and the faster they place them — the more money recruiters make. So they’ll want to help you get a job as fast as possible so they can move on to other job seekers.
3. Since they only get paid if you succeed as an employee (and stay for at least 90 days), they'll try and make sure you’re competent, and a good fit for the company’s culture.

This said, if a recruiter asks you to pay them money for anything, that is a red flag.

And not all recruiters are created equal. Do your research before working with a recruiter. Even if they're ultimately getting paid by the employer, you are still investing your time in helping them place you. And time is valuable.

Speaking of time, one way you can start getting paid to code sooner – even while you're preparing for the job search – is to get some freelance clients.

How to Get Freelance Clients

I encourage new developers to try and get some freelance clients before they start their job search. There are three good reasons for this:

1. It's much easier to get a freelance client than it is to get a full time job.
2. Freelance work is less risky since you can do it without quitting your day job.
3. You can start getting paid to code sooner, and start building your portfolio of professional work sooner.

Getting freelance clients can be much easier than getting a developer job. Why is this?

Think about small local businesses. It may just be a family that runs a restaurant. Or a shop. Or a plumbing company. Or a law firm.

How many of those businesses could benefit from having an interactive website, back office management systems, and tools to automate their common workflows? Most of them.

Now how many of those companies can afford to have a full-time software developer to build and maintain those systems? Not as many.

That's where freelancers come in. They can do work in a more economical, case-by-case basis. A small business can bring on a freelancer for a single project, or for a shorter period of time.

If you are actively building your network, some of the people you meet may become your clients.

For example, you may meet a local accountant who wants to update their website. And maybe add the ability to schedule a consultation, or accept a credit card payment for a bill. These are common features that small businesses may request, and you may get pretty good at implementing them.

You may also meet the managers of small businesses who need an ERP system, or a CRM system, or an inventory system, or one of countless other tools.

In many cases, there is an open source tool that you can deploy and configure for them. Then you can just teach them how to use that system. And you can bill them a monthly service fee to have you "on call" and ready to fix problems that may arise.

Should I Use a Contract for Freelance Work?

You will want to find a standard contract template, customize it, and get a lawyer to approve it.

It may feel awkward to make the local bakery sign a contract with you just to help update their website or social media presence. But doing so will make the entire transaction feel more professional than a mere handshake agreement.

It's unlikely that a small business will take you to court over a few thousand dollars. But in the event that this happens, you'll be glad you signed a contract.

How Much Should I Charge for Freelance Work?

I would take whatever you make at your day job, figure out your hourly rate, and double it. This may sound like a lot of money, but freelance work is much harder than regular work. You have to learn a lot.

Alternatively, you could just bill for a project. "I will deploy and configure this system for you for $1,000."

Just be sure to specify a time frame that you are willing to maintain the project. You don't want people calling you 3 years later expecting you to come back and fix a system that nobody has been maintaining.

How Do I Make Sure Freelance Clients Pay Me?

A lot of other freelancers – myself included – use this simple approach: ask for half of your compensation up-front, before you start the work. And when you can demonstrate that you're half way finished, ask for the other half.

Always try to get all the money before you actually finish the project. That way, the client will not be able to dangle the money over your head and try to get extra work out of you.

If you're already paid in full, the work you do to help your client after the fact will convey: "I'm going above and beyond for you."

Which is a totally different vibe from: "Uh oh – are you even going to pay me for all this work I'm doing?"

Should I Use a Freelance Website like Upwork or Fiverr?

If you are in a rural part of the world and can't find any clients locally, you could try some of these freelance websites. But otherwise I would not focus on them. Here's why:

When you try to land contracts on a freelance website, you are competing with all the freelancers around the world. Many of them will live in cities that have a much lower cost of living than yours. Some of them will not even really care about their reputations like you do, and may be willing to deliver sub-par work.

To some extent, these websites promote a "race to the bottom" phenomenon where the person who offers to do the work the cheapest usually gets the job.

If you instead focus on finding clients through your own local network, you will not have to compete with these freelancers abroad.

And the same goes for people who are looking for help from freelance developers. If you ever want to hire a freelancer, I strongly recommend working with someone you can meet with in-person, who has ties to your community.

Someone who has lived in your city for several years, and attends a lot of the same social gatherings as you – they're going to be much less likely to try to take advantage of you. If both you and your counterparty care about their reputation, you are both invested in a partnership that works.

You can each be a success story in one another's portfolios.

Freelancing is like running a one-person company. And that means a lot of hidden work.

Don't underestimate the amount of "hidden work" involved in running your freelance development practice.

For one, you may want to create your own legal entity.

In the US, the most common approach is to create a Limited Liability Company (LLC) and conduct business as that company – even if you're the only person working there.

This can simplify your taxes. And heaven forbid you make a mistake and get sued by a client, your legal entity can help insulate you from personal liability, so that it's your LLC going into bankruptcy – not you personally.

You may also consider getting liability insurance to further protect against this.

Remember that when you are working freelance, you usually have to pay tax at the end of the year, so be sure to save for this.

To create your LLC, you can of course just find boilerplate paperwork online, and file it yourself. But if you're serious about freelancing, I recommend talking with a small business lawyer and/or accountant to make sure you set everything up correctly.

When Should I Stop Freelancing and Start Looking for a Job?

If you are able to pay your bills freelancing, you may just want to keep doing it. Over time, you may even be able to build up your own software development agency, and hire other developers to help you.

This said, if you are yearning for the stability of a developer job, you may be in luck. Freelance clients may convert into full-time jobs if you stick with them long enough. At some point, it may make economic sense for a client to just offer you a full-time job at a lower hourly rate. You get the stability of a 40-hour work week, and they get your skills full-time.

You may also be able to hang onto a few freelance clients when you get a job. This can be a nice supplement to your income. But keep in mind that, as we'll learn in the next chapter, your first developer job can be an all-consuming responsibility. At least at first.

How wild is that first year of working as a professional developer going to be? Well, let's talk about that.

Chapter 5: How to Succeed in Your First Developer Job

"A ship in port is safe. But that's not what ships are built for." – Grace Hopper, Mathematician, US Navy Rear Admiral, and Computer Science Pioneer

Once you get your first developer job, that's when the real learning begins.

You'll learn how to work productively alongside other developers.

You'll learn how to navigate large legacy codebases.

You'll learn Version Control Systems, Continuous Integration and Continuous Delivery tools (CI/CD), project management tools, and more.

You'll learn how to work under an engineering manager. How to ship ahead of a deadline. And how to work through a great deal of ambiguity on the job.

Most importantly, you'll learn how to manage yourself.

You'll learn how to break through psychological barriers that affect all of us, such as imposter syndrome. You'll learn your limits, and how to push ever so slightly beyond them.

Story Time: How did a Teacher in his 30s Succeed in his First Developer Job?

Last time on Story Time: Quincy landed his first developer job at a local tech startup. He was going to work as one of a dozen developers maintaining a large, sophisticated codebase. And he had no idea what he was doing...

I woke up at 4 a.m. and I couldn't go back to sleep. I tried. But I had this burning in my chest. This anxiety. Panic.

I had worked for a decade in education. First as a tutor. Then as a teacher. And then as a school director.

In a few hours, I would be starting over from the very bottom, working as a developer.

Would any of my past learnings – past success – even matter in this new career?

I did what I always do when I feel anxiety – I went for a run. I bounded down the hills, my headlamp bobbing in the darkness. When I reached the beach, I ran alongside the ocean as the sun crept up over the treetops.

By the time I got home, my wife was already leaving for work. She told me not to worry. She said, "I'll still love you even if you get fired for not knowing what you're doing."

When I reached my new office, nobody was there. As a teacher, I was used to getting to school at 7:30 sharp. But I quickly realized that most software developers don't start work that early.

So I sat crosslegged in the entry hallway, coding along to tutorials on my netbook.

An employee walked up to me with a nervous look on her face. She probably thought I was a squatter. But I reassured her that I did indeed now work at her company, and convinced her to let me in.

It felt surreal walking across the empty open-plan office toward the developer bullpen, with only the light of the exit sign to guide my way.

I set up my netbook on an empty standing desk and finished my coding tutorial.

A little while later, the lights flickered on around me. My boss had arrived. At first he didn't acknowledge my presence. He just sat down at his desk and started firing off bursts of keystrokes onto his mechanical keyboard.

"Larson," he finally said. "You ready for your big first day?"

I wasn't. But I wanted to signal confidence. So I said the words first uttered in Big Trouble in Little China, one of my favorite 80s movies: "I was born ready."

You've probably heard "I was born ready" a million times. But it was first uttered in 1986 by Jack Burton to his friend Wang Chi, when they were getting ready to confront a thousand year old wizard in his death warehouse. I can't believe my parents let me watch this back then, but I'm glad they did.

"Great," my boss said. "Let's get you a machine."

"Oh, I've already got one," I said, tapping my $200 netbook. "This baby is running Linux Mint, and I've already customized my .emacs file to be able to..."

"We're a Mac shop," he said walking to a storage closet. He rustled around for a moment and emerged. "Here. It's a 3 year old model, but it should do. We wiped it to factory default."

I started to say that I was already familiar with my setup, and that I could work much faster with it, but he would have none of it.

"We're all using the same tools. It makes collaborating a lot easier. Convention over configuration, you know."

That was the first time I'd heard the phrase "convention over configuration" but it would come up a lot over the next few days.

I spent the next few hours configuring my new work computer as other developers gradually filed in.

It was nearly 10 a.m. when we started our team "standup meeting." We all stood in a circle by the whiteboard. We took turns reporting what we were working on that day.

Everyone gave quick, precise status updates.

When it was my turn, I started to introduce myself. I was already anxious enough, when in walked none other than Mike, that ultramarathoner guy who ran the Santa Barbara Startup events. He was crunching on some baby carrots, having already run about 30 miles that morning.

After I finished, Mike spoke, welcoming me and saying he'd seen me at some of his events. He then gave a 15 second status update about some feature he was working on.

The entire meeting only took about 10 minutes, and everyone scattered back to their desks.

I eventually got the company's codebase to run on my new laptop. It was a Ruby on Rails app that had grown over 5 years. I ran the rake stats command and saw that it was millions of lines of code. I shuddered. How could I ever comprehend all that?

My neighbor, a gruff, bearded dev said, "Eh, most of that is just packages. The actual codebase you'll be working on is only maybe 100,000 lines. Don't worry. You'll get the hang of it."

I gulped, but thought to myself: "That's less than millions of lines. So that is good."

"Name's Nick by the way," he said, introducing himself. "If you need any help just let me know. I've been stumbling around this codebase for quite a few years now, so I should be able to help you out."

Over the next few days, I peppered Nick with questions about every internal system I encountered.

Eventually Nick started setting his chat status to "code mode" and putting on his noise cancelling headphones. He swiveled his back toward me a bit, with the body language of: "leave me alone so I can get some of my own work done, too."

This was one of my earliest lessons about team dynamics. You don't want to wear out your welcome with too many questions. You need to get better at learning things for yourself.

But this was a massive codebase, and it was largely undocumented, aside from inline comments and a pretty sparse team wiki.

Since it was a closed-source codebase that only the devs around me were working in, I couldn't use Stack Overflow to figure out where particular logic was located. I just had to feel around in the dark.

I started rotating through which neighbor I'd bug about a particular question. But it felt like I was quickly ringing out any enthusiasm they may have had left for me as a teammate.

I over-corrected. I became shy about asking even simple questions. I made a rule for myself that I would try for 2 hours to get unstuck before I would ask for help.

At some point, after thrashing for several hours, I did ask for help. When my manager discovered I'd been stuck all morning, he asked, "Why didn't you ask for help earlier?"

Another struggle was with understanding the codebase itself – the "monolith" and its many microservices.

The codebase had thousands of unit tests and integration tests. Whenever you wrote a new code contribution, you were also supposed to write tests. These tests helped ensure that your code did what it was supposed to – and didn't break any existing functionality.

I would frequently "break the build" by committing code that I thought was sufficiently tested – only to have my code break some other part of the app I hadn't thought about. This frustrated the entire team, who were unable to merge their own code until the root problem had been fixed.

The build would break several times a week. And I was not the only person who made these sorts of mistakes. But it felt like I was.

There were days where I felt like I was not cut out to be a developer. I'd say to myself: "Who am I kidding? I just wake up one day and decide I'm going to be a developer?"

I kept hearing echoes of all those things my developer friends had said to me a year earlier, when I was first starting my coding journey.

"How are you going to hang with people who grew up coding from an early age?"

"You're going to have to drink an entire ocean of knowledge."

"Why don't you just stick with what you're good at?"

I would take progressively longer breaks to get away from my computer. The office had a kitchen filled with snacks. I would find more excuses to get up to grab a snack. Anything to delay the crushing sense that I had no idea what I was doing.

The first few months were rough. During morning standup meetings, it felt like everyone was moving fast. Closing open bugs and shipping features. It felt like I had nothing to say. I was still working on the same feature as the day before.

Every day when I woke up and got ready for work, I felt dread. "This is going to be the day they fire me."

But then I'd go to work and everyone would be pretty kind, pretty patient. I would ask for help if I was really stuck. I would make some progress, and maybe fix a bug or two.

I was getting faster at navigating the codebase. I was getting faster at reading stack traces when my code errored out. I was shipping features at a faster clip than before.

Whenever my boss called me into his office, I would think to myself: "Oh no, I was right. I'm going to get fired today." But he would just assign me some more bugs to fix, or features to develop. Phew.

It was the most surreal thing – me terrified out of my mind that I'm about to get the axe, and him having no idea anything's wrong.

Of course, I had heard the term "imposter syndrome" before. But I didn't realize that was what I was experiencing. Surely I was just suffering from "sucks at coding" syndrome, right?

One day I was sitting next to Nick, and he was looking pretty frazzled. I offered to grab him a soda from the kitchen.

When I got back, he cracked the can open, took a sip, and leaned back in his chair, gazing at his monitor full of code. "This bug, man. Three weeks trying to fix this one bug. At this point I'm debugging it in my sleep."

"Three weeks trying to fix the same bug?" I asked. I had never heard of such a thing.

"Some bugs are tougher to crack than others. This is one of those really devious ones."

It felt like someone had slapped me across the face with a salmon. I had viewed my job as chunks of work. As though it should take half a day to fix a bug, and if it took longer than that, I was doing something wrong.

But here Nick was – with his computer science degree from University of California and his years of experience working on this same codebase – and he was stumped for three weeks on a single bug.

Maybe I had been too hard on myself. Maybe some of these bugs I'd been fixing were not necessarily "half-day bugs", but were "two- or three-day bugs." Yes, I was inexperienced and slow. But even so, maybe I was holding myself to unrealistic standards.

After all, when we budgeted time for features, sometimes we would have "5-day features" or even "2-week features." We didn't do this for bugs, but they probably varied similarly.

I went home and read more about Imposter Syndrome. And what I read explained away a lot of my anxiety.

Over the coming months, I kept building out features for the codebase. I kept collaborating with my team. It was still hard, brain-busting work. But it was starting to get a little bit easier.

I bonded with my teammates each day at lunch over board games. One week, we had a company-wide chess tournament.

A couple rounds in, I played against the CEO.

The CEO has an unorthodox chess play style. He used a silly opening that few serious chess players would opt for. And I was able to take any early lead in the game.

But over the next few moves, he was able to slowly grind back control over the game. He eventually gained the upper hand and beat me.

When I asked him how he found time to keep his chess skills sharp while running a company, he said, "Oh, I don't. I only play once or twice a year."

Then he paused for a moment, his hand frozen in front of him, as if preparing to launch into a lecture. He said: "My uncle was a competitive chess player. And he just gave me a single piece of advice to follow: every time your opponent moves, slow down and try to understand the game from their perspective – why did they make that move?"

He bowed then excused himself to run to a meeting.

I've thought a lot about what he said over the years. And I've realized this advice doesn't just apply to chess. You can apply it to any adversarial situation.

If You Keep Having to Do a Task, You Should Automate it

Another lesson I learned about software development: since I was the most junior person on the team, I often got assigned the "grunt work" that nobody else wanted to do. One of these tasks was to be the "build nanny."

Whenever someone broke the build, I would pull down the latest version of our main branch and use git bisect to try and identify the commit that broke it.

I'd open up that commit, run the tests, and figure out what went wrong. Then I'd send a message to the person who broke the build, telling them what they needed to fix.

I got really fast at doing this. In a day full of confusing bug reports and ambiguous feature requests, I looked forward to the build breaking. It would give me a chance to feel useful real quick.

It wasn't long before someone on the team said, "With how often the build breaks, we should just automate this."

I didn't say anything, but I felt defensive. This was a bad idea. How could a script do as good a job at finding the guilty commit as I – a flesh and blood developer – could?

It took a few days. But sure enough, one of my teammates whipped up a script. And I didn't have to be the build nanny anymore.

It felt strange to see a message that the build failed, and then a moment later see a message saying which commit broke the build and who needed to go fix it.

I felt indignant. I didn't say anything, but in my mind I was thinking: "That's supposed to be my work. That script took my job."

But of course, I now look back at my reaction and laugh. I imagine myself, now in my 40s, still dropping everything several times each week so I could be the build nanny.

Because in practice, if a task can be automated – if you can break it down into discrete steps that a computer can reliably do for you – then you should probably automate it.

There's plenty of more interesting work you can do with your time.

This chart from XKCD can help you figure out whether a task is worth the time investment to automate.

Lessons from the Village Elders

I learned a lot from other people on the team. I learned product design concepts from Mike. He took me running on the beach, and taught me how to run on my forefoot, where the balls of my feet hit the ground before my heels. This is a bit easier on your joints.

And I learned about agile software engineering concepts from Nick. He helped me pick out some good software development books from the company library. And he even invited me over for a house-warming party, and I got to meet his kids.

After about a year of working for the company, I felt it was time to try to strike out on my own, and build some projects around online learning. I sat down with the CTO to break the news to him that I was leaving.

I said, "I'm grateful that you all hired me, even though I was clearly the weakest developer at the company."

He just let out a laugh and said, "Sure, when you started, you were the worst developer on the team. I'd say you're still the worst developer on the team."

I sat there smiling awkwardly, blinking at him, not sure whether he was just angry I was leaving.

And then he said, "But that's smart. You're smart. Because you always want to be the worst musician in the band. You always want to be surrounded by people who are better than you. That's how you grow."

Two weeks later, I checked in my code changes for the day and handed off my open tickets. I reset my Mac to factory settings and handed it to my manager.

I shook hands with my teammates and headed out the door into the California evening air.

I hit the ground running, lining up freelance contracts to keep the lights on. And I scouted out an apartment in the Bay Area, just across the bridge from the beating heart of tech in South of Market San Francisco.

I was now a professional developer with a year of experience already under my belt.

I was ready to dream new dreams and make new moves.

I was off to the land of startups.

Lessons From my First Year as a Developer

I did a lot of things right during my first year as a professional developer. I give myself a B-.

But if I had the chance to do it all again, there are some things I'd do differently.

Here are some tips. May these maximize your learning and minimize your heartache.

Leave Your Ego at the Door

Many people entering the software development field will start at the very bottom. One title you might have is "Junior Developer."

It can feel a bit awkward to be middle aged and have the word "junior" in your title. But with some patience and some hard work, you can move past it.

One problem I faced every day was – I had 10 years of professional experience. I was not an entry-level employee. Yes, I was new to development, but I was quite experienced at teaching and even managing people. (I'd managed 30 employees at my most recent teaching job.)

And yet – in spite of all my past work experience – I was still an entry-level developer. I was still a novice. A neophyte. A newbie.

As much as I wanted to scream "I used to be the boss – I don't need you to babysit me" – the truth was I did need babysitters.

What if I accidentally broke production? What if I introduced a security vulnerability into the app? What if I wiped the entire database? Or encrypted something important and lost the key?

These sorts of disasters happen all the time.

The reality is as a new developer, you are like a bull in a China shop, trying to walk carefully, but smashing everything in your path.

Don't let yourself get impatient with your teammates. Resist the temptation to talk about your advanced degrees, awards your work has won, or that time the mayor gave you the key to the city. (OK, maybe that last one never happened to me.)

Not just because it will make you hard to work with. Because it will distract you from the task at hand.

For the first few months of my developer career, I used my past accomplishments as a sort of pacifier. "Yeah I suck at coding, but I'm phenomenal at teaching English grammar. Did I mention I used to run a school?"

When your fingers are on the keyboard, and your eyes are on the code editor, you have to let that past self go. You can revel in yesterday's accomplishment tonight, after today's work is done.

But for now, you need to accept all the emotions that come with being a beginner again. You need to focus on the task at hand and get the job done.

It's Probably Just the Imposter Syndrome Talking

Almost everyone I know has experienced Imposter Syndrome. That feeling that you do not belong. That feeling that at any moment your teammates are going to see how terrible your code is and expose you as not a "real developer."

To some extent, the feeling does not go away. It's always there in the back of your mind, ready to rear its head when you try to do something new.

"Could you help me get past this error message?" "Um... I'm not sure if I'm the best person to ask."

"Could you pair program with me on implementing this feature?" "Um... I guess if you can't find someone more qualified."

"Could you give a talk at our upcoming conference?" "Um... me?"

I've met senior engineers who still suffer from occasional imposter syndrome, more than a decade into their career.

When you feel inadequate or unprepared, it may just be imposter syndrome.

Sure – if you handed me a scalpel and said, "help me perform heart surgery" I would feel like an imposter. To some extent, feeling out of your depth is totally reasonable if you are indeed out of your depth.

The problem is that if you've been practicing software development, you may be able to do something but still inexplicably suffer from anxiety.

I am not a doctor. But my instinct is that – for most people – imposter syndrome will gradually diminish with time, as you get more practice and build more confidence.

But it can randomly pop up. I'm not afraid to admit that I sometimes feel pangs of imposter syndrome when doing a new task, or one I haven't done in a while.

The key is to just accept it: "It's probably just the imposter syndrome talking."

And to keep going.

Find Your Tribe. But Don't Fall for Tribalism

When you get your first developer job, you'll work alongside other developers. Yipee – you found your tribe.

You'll spend a lot of time with them, and you all may start to feel like a tight unit.

But don't ignore the non-developer people around you.

In my story above, I talked about Mike, the Product Manager who also ran startup events. He was "non-technical". His knowledge of coding was limited at best. But I'd venture to say I learned as much from him as anyone else at the company.

You may work with other people from other departments – designers, product managers, project managers, IT people, QA people, marketers, even finance and accounting folks. You can learn a lot from these people, too.

Yes, you should focus on building strong connective tissue between you and the other devs on the team. But stay curious. Hang out with other people in the lunch room or at company events. You never know who's going to be the next person to help you build your skills, your network, or your reputation.

Don't Get Too Comfortable and Specialize too Early

I often give this advice to folks who are first starting their coding journey: "learn general coding skills (JavaScript, SQL, Linux, and so on) and then specialize on the job."

The idea is, once you understand how the most common tools work, you can the go and learn those tools' less common equivalents.

For example, once you've learned PostgreSQL, you can easily learn MySQL. Once you've learned Node.js, you can easily learn Ruby on Rails or Java Spring Boot.

But some people specialize too early at work. Their boss might ask them to "own" a certain API or feature. And if they do a good job with that, their boss may keep giving them similar projects.

You are only managing yourself, but your boss is managing many people. They may be too busy to develop a nuanced understanding of your abilities and interests. They may come to see you as "the XYZ person" and just give you tasks related to that.

But you know what you're good at, and what you're interested in. You can try and volunteer for projects outside of your comfort zone. If you can get your boss to assign these to you, you'll be able to continue to expand your skills, and potentially work with new teams.

Remember: your boss may be responsible for your performance at your job, but you are responsible for your performance across your career.

Take on projects that both fulfill your obligation to your employer, and also position you well for your long-term career goals.

Epilogue: You Can Do This

If there's one message I want to leave you with here, it is this: you can do this.

You can learn these concepts.

You can learn these tools.

You can become a developer.

Then, the moment someone hands you money for you to help them code something, you will graduate to being a professional developer.

Learning to code and getting a first developer job is a daunting process. But do not be daunted.

If you stick with it, you will eventually succeed. It is just a matter of practice.

Build your projects. Show them to your friends. Build projects for your friends.

Build your network. Help the people you meet along the way. What goes around comes around. You'll get what's coming to you.

It is not too late. Life is long.

You will look back on this moment years from now and be glad you made a move.

Plan for it to take a long time. Plan for uncertainty.

But above all, keep coming back to the keyboard. Keep making it out to events. Keep sharing your wins with friends.

As Lao Tsu, the Old Master, once said:

"A journey of a thousand miles begins with a single step."

By finishing this book, you've already taken a step. Heck, you may have already taken many steps toward your goals.

Momentum is everything. So keep up that forward momentum you've already built up over these past few hours with this book.

Start coding your next project today.

And always remember:

You can do this.