Learn Code and Get a Developer Job: The Ultimate Guide

Are you looking to Learn Code and embark on a fulfilling career as a software developer? You’ve landed in the perfect spot. This comprehensive guide, brought to you by learns.edu.vn, your trusted source for quality education, will illuminate the path to mastering coding and securing your dream developer job.

Yes, you’re reading it right – this is the complete guide, available entirely for free right here. Consider this your definitive resource, meticulously crafted to provide you with the insights and strategies you need to succeed in the dynamic world of software development.

For those who prefer auditory learning, I’ve also created a FREE full-length audiobook version of this guide, featured as episode #100 of The freeCodeCamp Podcast. Find it on your favorite podcast platform and hit subscribe for more valuable content. You can also listen to it directly below for your convenience.

[Audiobook Embed Placeholder]

Interestingly, a few years ago, a major New York City book publisher approached me with a book deal. While I considered it, time constraints prevented me from taking on the project then.

Now, the time is finally right. And I decided to publish this book for free, directly on freeCodeCamp.

Because information should be accessible to everyone, right? 🙂

Reading through this guide will take a few hours of your time. But within these pages, you’ll find my distilled knowledge on learning to code and navigating the path to a developer career.

These insights are drawn from my own journey:

• Learning to code in my 30s, starting from scratch.
• Working as a software engineer in the industry.
• Leading freeCodeCamp.org for the past 8 years. Today, freeCodeCamp is a global community with over a million daily visitors learning about programming, computer science, and mathematics.

My background? I was an English teacher with zero programming experience. Yet, within a single year, I acquired the coding skills necessary to land my first software development job.

And I achieved this without spending money on expensive books or courses.

(I did invest in travel to attend tech events in nearby cities, a decision that, as you’ll discover later, proved invaluable.)

After several years as a software engineer, I felt a calling to guide others through this transformative career shift.

Initially, I developed several technology education tools that didn’t gain traction. However, one weekend, I created freeCodeCamp.org. A vibrant community quickly formed around it.

Through mutual support and collaboration, countless individuals worldwide have used freeCodeCamp to prepare for their first tech jobs.

You might be thinking, “Do I even have the time to read this entire guide?”

Don’t worry. Bookmark this page. Revisit it as needed, reading at your own pace.

Share it on social media. Sharing “Check out this guide I’m reading” with a link is a surprisingly effective way to motivate yourself to complete it.

My intention isn’t to sell you anything. By simply opening this page, you’ve already “purchased” this guide with your attention. My aim now is to assure you that investing your time in reading it will be worthwhile. 😉

I promise to be respectful of your time. There’s no hype or filler here – just direct, actionable advice.

I’m committed to packing as much valuable insight as possible into each chapter of this guide.

Which reminds me, where’s the table of contents?

Ah, here it is:

Table of Contents

Preface: Is This Book For You?

This guide is designed for anyone considering a career transition into software development.

If you seek a career that offers flexibility, high earning potential, and stimulating creative problem-solving challenges, software development might be your calling.

We each embark on our coding journey with unique resources: time, money, and opportunity.

Perhaps you’re further along in life, with family responsibilities like children or elderly parents. This might mean you have less time available to dedicate to learning.

Or maybe you’re younger and haven’t had as much time to accumulate savings or develop high-income skills, resulting in less money.

And you might live far from major tech hubs like San Francisco, Berlin, Tokyo, or Bengaluru.

Or you may face physical or mental disabilities. Ageism, racism, and sexism are undeniable realities. Immigration status and even a past criminal record can further complicate the job search.

These factors can limit your opportunity.

Learning to code and securing a developer job will present varying levels of difficulty for different individuals. We all start from different points, with unique sets of resources.

Regardless of your starting point – in terms of time, money, and opportunity – I’m committed to providing you with practical, actionable guidance.

In essence: rest assured – you’re in the right place.

A Quick Note on Terminology

Throughout this guide, I will define new terms as they appear.

However, there are a few core terms I’ll be using frequently.

I will use “programming” and “coding” interchangeably.

I’ll use “app” in its broader sense – as a general term for any application, whether it runs on a phone, computer, game console, or even a refrigerator. (Apologies, Steve Jobs. The iPhone doesn’t own the word “app.”)

I will also use “software engineer” and “software developer” interchangeably.

You might encounter individuals in the tech world who differentiate these terms, suggesting “software engineering” is a more prestigious field with a long history, like civil or mechanical engineering. Perhaps that will be true for future generations. But software development is still a relatively young and evolving field.

Consider this quote, especially if you feel self-conscious about 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 Truly Learn Code?

Yes. I firmly believe that anyone with sufficient motivation can learn code. Ultimately, mastering coding is a test of motivation, not inherent aptitude.

Think about early humans on the African savanna, millennia before computers existed. Programming skills were never a factor in natural selection. Computers as we know them – desktops, laptops, smartphones – only emerged in recent decades.

While aptitude does play a role, persistence is paramount. Anyone aspiring to become a professional developer must dedicate significant time to practice and hands-on coding.

Many people who attempt to learn code become discouraged and give up.

I myself experienced frustration and quit several times.

But like others who ultimately succeeded, I returned to it after breaks, determined to try again.

I share this to acknowledge that learning code and landing a developer job is challenging. And it’s undeniably harder for some due to their circumstances.

I’m not claiming to have faced immense adversity in my coding journey. Yes, I started in my 30s without a formal background in programming or computer science. But consider my advantages:

I grew up in a middle-class, English-speaking household in the United States. I attended university, as did my father and grandfather. (My ancestors before them were farmers from Sweden.)

I benefited from intergenerational privilege, a momentum built up over generations free from war, famine, or slavery.

So, my disclaimer to you: I’m not a motivational speaker here to pump you up to overcome extreme adversity.

If you need inspiration, the developer community is full of individuals who have overcome genuine hardship. Seek out their stories.

My aim isn’t to glorify software development or paint unrealistic utopian visions of a future where everyone codes.

Instead, I’m here to offer practical, step-by-step guidance on acquiring coding skills and securing a well-paying job to support yourself and your family.

There’s no shame in wanting to learn code for a stable, well-compensated career.

There’s no shame in wanting to learn code to launch a business.

You might encounter people who say you must be so passionate about coding that it consumes your every thought, that you should spend all your free time contributing to open-source projects.

I know people with that level of passion for coding. But I also know many successful developers who, after a demanding week, prefer to relax in nature or play board games.

People generally enjoy activities they excel at. Passion for coding can develop simply by becoming proficient at it.

So, who is this guide for? Anyone serious about improving their coding abilities and landing a developer job. That’s it.

You don’t need to fit any stereotypes – “geek,” introvert, or activist.

If you do, that’s perfectly fine. But it’s not a prerequisite.

If you’re serious about learning code well enough to get paid to code – this guide is for you.

Start with the executive summary below, then delve into the rest of the guide.

500 Word Executive Summary

Learning code is challenging. Getting a software developer job is even more so. But for many, the rewards are worth the effort.

Coding offers a high-paying, intellectually stimulating, and creatively fulfilling career path. Clear career progression awaits: senior developer, tech lead, engineering manager, CTO, and potentially even CEO.

Developer jobs are available across nearly every industry. Approximately two-thirds are outside the traditional “tech” sector – in agriculture, manufacturing, government, and service industries like banking and healthcare.

Worried about job automation? Coding is the act of automation itself, making it arguably the last career to be fully automated.

Automation will impact coding, and already has for decades.

Generative AI tools like GPT-4 and Copilot are shifting programming from Imperative Programming – detailed instructions for computers – towards Declarative Programming – giving computers higher-level objectives, akin to Star Trek-style programming.

Just as calculators haven’t eliminated the need for math, AI tools won’t replace the need to learn code.

Convinced that coding is a viable career for you?

Excellent. Here’s how to break into the field.

Build Your Skills.

Essential skills to learn code include:

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

These are all established, 20+ year-old technologies. You’ll likely use most of them regardless of your employer.

The most effective way to learn code is by building projects. Code daily, even if just a little. Following the freeCodeCamp curriculum from start to finish will teach you these technologies and guide you through building numerous projects.

Build Your Network.

Networking is crucial for job success.

Even if you’re introverted, step outside your comfort zone.

Create profiles on GitHub, Twitter, LinkedIn, and Discord.

Attend tech meetups and conferences. Travel if necessary. (Prioritize travel and event tickets over books and courses in your “learn to code” budget.)

Engage with people standing alone. Listen actively, letting others talk more. Remember names.

Connect on LinkedIn, follow on Twitter, and attend after-parties.

Build Your Reputation.

Share short video demos of your projects online.

Apply to speak at increasingly larger conferences.

Participate in hackerspaces and assist coding newcomers.

Contribute to open-source projects; this mirrors professional software development.

Simultaneously build your Skills, Network, and Reputation. Don’t procrastinate on challenging aspects.

Instead of applying for jobs through standard channels, leverage your network to secure interviews via “side doors.” Recruiters can also be valuable allies.

Continue interviewing until you receive job offers. Be patient; you don’t have to accept the first offer.

Your first developer job will be the toughest to get. Aim to stay for at least two years, using it as paid learning.

The real learning accelerates on the job, working within a team and with substantial legacy codebases.

Prioritize sleep and exercise.

Anyone sufficiently motivated can learn code well enough to become a developer.

It’s a matter of your determination and persistence in the job search.

Remember: you are capable of this.

This Guide is Dedicated to the Global freeCodeCamp Community.

Thank you to everyone who has supported our mission and charity over the past nine years.

Your volunteerism and philanthropy have enabled us to help countless individuals learn code and secure their first developer jobs.

The community has grown immensely from the humble open-source project I launched in 2014. I am now just a small part of this global movement.

It’s a privilege to continue working alongside you all, addressing fundamental challenges of our time: access to information, education, and the tools shaping the future.

We are still in the early stages. I don’t expect everyone to know how to code in my lifetime. But, like the Gutenberg Bible accelerated literacy in 1455, we can continue to accelerate technology literacy through free, open learning resources.

Thank you again.

Special thanks to Abbey Rennemeyer for her editorial feedback and Estefania Cassingena Navone for the book cover design.

And now, let’s begin the book.

Chapter 1: Mastering the Skills to Learn Code

“Every artist was first an amateur.” ― Ralph Waldo Emerson

The journey to coding proficiency is a long one.

For me, it was also circuitous.

But it doesn’t have to be that way for you.

In this chapter, I’ll share effective strategies to learn code as smoothly as possible.

First, I’ll recount my own coding journey back in 2011.

Then, I’ll extract key lessons from this experience.

Finally, I’ll show you how to learn code much more efficiently than I initially did.

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

I was running an English school for adult students from around the world seeking advanced English for graduate studies.

While our teachers loved teaching and engaging with students, paperwork was a major pain point: attendance, grades, immigration forms.

I wanted to free up teachers to spend more time with students and less time bogged down in paperwork.

But what did I know about computers?

Programming? Wasn’t that for geniuses? I struggled with WiFi routers and math.

One day, I decided to push past these doubts and thought, “I’m going to try. What do I have to lose?”

I started Googling questions like “how to automate website clicks” and “import website data into Excel.”

Unknowingly, I was learning code to automate workflows.

My learning began with Excel macros, then progressed to AutoHotKey, a tool to program mouse movements, clicks, text copying, and pasting across screen coordinates.

After weeks of trial and error, I automated some tasks. I could run a script, and ten minutes later, a spreadsheet would be automatically populated with data from a website.

Amateurish? Yes. A “dirty hack” in developer terms? Perhaps. But it worked.

I used these basic automation skills to streamline school operations.

Teachers barely had to touch computers. My rudimentary scripts were doing the work of several staff members.

This had a tangible impact. Freed from rote computer tasks, teachers spent more time with students.

Happier teachers, happier students. Students told friends, “Check out this school.”

Soon, we became one of the most successful schools in the system.

This success emboldened me. “Maybe I can learn code,” I thought.

I knew software engineers from my board game group, graduates of prestigious Computer Science programs.

Back then, it was less common for people in their 30s to learn code.

I shared my aspirations with these friends: to learn code professionally, to write software for schools. “I want to do what you do.”

Their responses were lukewarm:

“You could try, but you’ll need to absorb an ocean of knowledge.”

“It’s competitive. How will you compete with those who coded since childhood?”

“You’re doing well as a teacher. Why not stick with what you’re good at?”

These comments would momentarily deter me. I’d soul-search, wondering if they were right.

But each morning, I’d return to my desk, watch my scripts run, and see my computer automating tasks at incredible speeds.

It occurred to me: maybe they were trying to protect me from disappointment. Perhaps they hadn’t seen anyone learn code in their 30s and doubted it was possible.

Like doctors once believed running a mile in under four minutes was physically impossible.

Then, Roger Bannister, a 25-year-old student, broke that four-minute barrier. His heart didn’t explode.

Once that psychological barrier was broken, many others followed. Over 1,000 people have since run a sub-four-minute mile.

My goal wasn’t as audacious as a four-minute mile. Many famous developers have taught themselves coding.

Ada Lovelace taught herself programming in the 1840s without a working computer, just understanding its theoretical operation.

She wrote some of the first computer algorithms and is considered the world’s first programmer. She overcame any self-doubt.

I was no Ada Lovelace, just a teacher with a computer, internet, and Google.

I cracked my knuckles, narrowed my eyes. I was determined to learn code.

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 weeks Googling and doing random online tutorials.

“Oh, a Ruby tutorial.”

“Uh-oh, this is getting hard. Error messages not in the tutorial… what’s wrong?”

“Oh, a Python tutorial.”

Human psychology is funny. When something gets tough, we question our approach.

“Is this tutorial outdated? Is the author incompetent? Is this language even relevant?”

Faced with cryptic errors after hours of coding, other options look appealing.

It’s easy to fake progress. “Lunch break!”

“Coding going well?” a friend at the café would ask.

“Great! Coded four hours today.”

“Awesome! Show me what you’re building sometime.”

“Sure,” I’d say, knowing I’d built nothing. “Soon.”

Perhaps a new JavaScript book from the library.

Buying books feels good, like buying time to read them.

Weeks into learning code, I was stuck.

I’d read the first 100 pages of many programming books, finishing none.

I’d written the first 100 lines of code from many tutorials, completing none.

Unknowingly, I was in “tutorial hell.”

Tutorial hell is jumping between tutorials, relearning basics, never progressing.

Moving beyond basics requires real work.

It Takes a Village to Raise a Coder

Learning code consumed my free time, yet progress was minimal. I could type { and * without looking, but little else.

I needed help, a Yoda-like mentor. Surely, that would make all the difference.

I found a “hackerspace” nearby. The name sounded intimidating. Hackers do illegal things, right? I was a board game-loving teacher, not looking for trouble.

I called the number listed. Steve answered. Nervously, I asked, “You don’t do anything illegal, do you?” Steve laughed.

“Hack” is an overloaded term. Yes, it can mean malicious software intrusion. But it also means writing code.

“Hacky” can mean inelegant code. But “a clever hack” is an ingenious, efficient coding trick.

In short, don’t fear “hack.”

I rarely use “hack” due to its ambiguity. Many hackerspaces now call themselves “makerspaces.”

A hackerspace is about making things.

Steve invited me to visit Saturday afternoon, promising developers would be there.

The Santa Barbara Hackerspace blew me away.

It smelled faintly of burning electronics. Tables were covered in soldering irons, LED strips, Arduino boards, and disassembled Roomba robots.

Steve, glasses, slicked-back hair, goatee, greeted me with a smile. He thought before answering questions, a math and philosophy graduate passionate about Python.

Steve demoed an app recognizing QR codes in video and replacing them with images. Someone held up a QR code; Steve’s app replaced it with a pizza image.

“Can you make the pizza spin?” someone shouted.

Steve opened Emacs, his code editor, and started live-coding, effortlessly switching between editor, command line, and browser, “hot-loading” code updates.

Sorcery. Steve built that app in hours, adding features on the fly.

“This guy’s a genius,” I thought.

Afterward, we talked. “I could code my whole career and not be as good as you. I’d be thrilled to code half as well in ten years.”

Steve demurred. “I’m nothing special. Don’t limit yourself. You could surpass me.”

I didn’t believe him, but his belief gave me hope.

Here was a developer who believed in me, a random teacher, a “script kiddie,” seeing my potential.

We talked late. He showed me his $200 netbook, underpowered even in 2011.

“You don’t need a powerful computer to build software,” Steve said. “Hardware is powerful now. Software bloat slows computers. Get a cheap laptop, wipe it, install Linux, and code.”

I noted his laptop model and ordered it that night.

After days of debugging with Stack Overflow, I installed Ubuntu and started learning Emacs. By Saturday, I knew commands and eagerly showed them off.

Steve nodded. “Awesome. But what are you building?”

I didn’t understand. “I’m learning Emacs. Look…”

Steve was pensive. “Cool, but you need a project. Always have a project. Learn code to finish projects.”

Beyond school scripts, I’d finished nothing. I began to see his point.

Tutorial hell, going in circles, finishing nothing.

Steve said, “Build an HTML5 project. Present it next Saturday.”

Mortified, I said, “Sounds like a plan.”

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 Matrix

Next morning, I Googled “HTML5 tutorial.” Familiar from tutorial hell, but this time, I went slow, typing every command.

Usually, after a tutorial, I’d find another. This time, I played with the code. Project idea: an HTML5 documentation page, coded purely in HTML5.

HTML5 is a newer HTML version, the backbone of webpages since the 90s.

HTML is to a website as bones are to a body. (JavaScript: muscles, CSS: skin. But back to the story.)

HTML can link to page sections using IDs. I envisioned a sidebar table of contents. Clicking items would scroll the main content.

Within 30 minutes, a prototype was ready.

Work beckoned. All day, I thought about my project.

Raced home, opened my laptop, coded all evening.

I copied official (Creative Commons licensed) HTML documentation into my page, “hard-coding” it.

An hour on CSS, styling, absolute positioning for the sidebar.

Utilizing HTML5’s new “semantic” tags.

Project finished.

A wave of accomplishment. I ran laps around a football field, celebrating. I finished a project.

Decision made: everything would be project-based. Working towards a finished product.

Next evening, I presented my HTML5 page at the hackerspace. Answered HTML5 questions.

Sometimes, I was wrong, and someone would correct me, politely, supportively. It felt like collaborative learning.

Afterward, Steve said, “Not bad.”

I smiled, happy.

Steve squinted. “Start your next project tonight.”

Lessons from my Coding Journey

We’ll follow young Quincy’s coding journey in later chapters. Now, let’s break down lessons and address your questions.

Why is Learning Code so Hard?

Learning any new skill is hard, from soccer to car repair to new languages.

Learning code is hard for specific reasons, some unique to coding.

First, most people misunderstand what coding is. Let me clarify.

What is Coding?

Coding is telling a computer what to do, in a way it understands.

That’s it. Simple, but profound.

Communicating with computers is hard. They’re “dumb” by human standards, doing exactly what you say, but not always what you want without precise coding.

What about servers, databases, networks?

Ultimately, all controlled by software, code all the way down, to hardware moving electrons.

Early coding was “close to the metal,” directly manipulating hardware, bits from 0 to 1.

Modern software development uses “abstraction layers” – programs on programs – where JavaScript lines achieve powerful tasks.

In the 1960s, a “bug” was literally an insect short-circuiting room-sized computers.

Today, we code layers above hardware.

Coding is vastly easier now, getting easier yearly.

In decades, coding will be so easy and common, most young people will know how.

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

Three main reasons learning code remains hard:

1. Primitive tools.
2. Handling ambiguity is tough, and coding is ambiguous. People get lost.
3. Handling constant negative feedback is tough. Coding is error messages. People get frustrated.

Let’s explore these and strategies to overcome them.

The Tools are Still Primitive

“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

Future programming might be like Star Trek, just telling the computer what to do.

Everyone in Star Trek codes – doctors, officers, pilots. Even Wesley Crusher codes.

In their 24th-century post-scarcity society, with free education, coding is much easier. Just precise instructions, and the computer obeys.

Imagine programming in plain English.

We’ve made progress. Think of grandmothers with punchcard-driven mainframes.

Simple apps used to require meticulous instructions.

Consider the “Caesar Cipher” (ROT-13), a classic CS exercise.

Here’s x86 Assembly code for it:

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
  mov al, [buf]        ; load read char to eax

  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

Complex and hard to read, right?

Now, the same program 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))

Much simpler and readable.

This Python code was generated by GPT-4, prompted like Captain Picard would: “Computer. New program. ROT-13 the word ‘Banana’.”

GPT-4 produced Python code and said, “Onanan.”

This is Declarative Programming: “Computer, do this.” The computer understands and executes.

Most coding today is Imperative Programming: step-by-step instructions, because computers were historically “dumb.”

Software development is still immature.

But like early tools evolving from stone to iron, software tools are evolving faster.

We’re in the programming Bronze Age, possibly reaching the Iron Age soon. Generative AI tools like GPT are rapidly improving.

Developer community is split on GPT’s utility.

Some “become your own boss” influencers claim: “No need to learn code. ChatGPT codes for you. Just have an app idea.”

“Old guard” developers are skeptical of GPT for production-grade code.

Reality is likely in between.

YouTube videos show people prompting ChatGPT for app code, assembling working apps.

Large Language Models like GPT-4 are impressive, improving rapidly.

However, skepticism remains about their ultimate usefulness. Can AIs stop “hallucinating” false info?

“Interpretability” is a core problem. Understanding AI “black boxes” like GPT-4 might take decades. Until then, double-check AI code for bugs and security flaws.

There’s a difference between getting a computer to do something and understanding how it does it.

Many drive cars, few can repair or design them.

To develop powerful, secure software solving new problems, you still need to learn code properly.

Which means navigating ambiguity.

Learning Code is an Ambiguous Process

When you learn code, you constantly question: “Am I using my time well? Learning the right tools? Are these resources reliable?”

Ambiguity clouds every study session. “Did my test fail because the tutorial is outdated, or am I just wrong?”

Tutorial hell and “grass is greener” syndrome exacerbate this.

Some developers answer questions with unhelpful “RTFM” (Read The Freaking Manual). Which manual? Which section?

You don’t know what you don’t know. Often, you can’t even articulate the question.

Especially hard because your app might be unique, with unprecedented problems.

No one to turn to.

15% of daily Google queries are new. Bad news if yours is one.

Developers often solve problems and move on, undocumented. You might be reinventing solutions.

Then there are old forum threads and StackOverflow pages.

How Not to Get Lost When Learning Code

Good news: competence and confidence come with practice.

Soon, you’ll know what to Google, understand documentation structure, and know where to ask questions.

No simple solution for ambiguity. Accept it. Learning code is ambiguous, even for experts.

Coding is unique: you rarely reuse solutions exactly.

Developers always do something new.

Software development isn’t just typing code. It’s learning.

Much time spent thinking, experimenting, understanding systems.

Also, meetings with managers, clients, devs, learning the problem to solve.

Embrace ambiguity, and you’ll go far.

Learning Code is One Error Message After Another

Many learning code feel they hit a wall. Progress is slower than expected.

One reason: programming feedback is rapid.

In school, feedback is periodic – assignments graded over weeks.

“Bad exam, study harder for midterm.”

Teachers give feedback in red ink.

Bad grades ruin days.

That’s how we view feedback.

Computers are fast. Code executes in milliseconds.

Often, code crashes.

If lucky, error messages appear.

If very lucky, a “stack trace” – error details with line numbers.

This constant, immediate negative feedback can be overwhelming.

Imagine teachers instantly returning term papers with a big red “F.” Repeatedly.

That’s coding sometimes. You want to shout, “Why don’t you understand what I want?!”

How Not to Get Frustrated

Key is practice.

Tolerance for vague errors and stack traces develops over time.

Coding is never harder than at the start.

Not only do you not know what you’re doing, you’re not used to rapid, negative feedback.

Tips:

Tip #1: You’re not uniquely bad at this.

Everyone struggling to learn code feels frustration trying to “mind-meld” with computers.

Some started coding as kids, seeming naturally good. But they also struggled initially, forgetting early frustrations.

Think of computers as friends, clarifying instructions, not adversaries.

Tip #2: Breathe.

Natural reaction to errors is teeth-gnashing, blindly changing code, hoping for luck.

This doesn’t work. Universe and software are complex. You won’t Forest Gump your way to success.

Infinite Monkey Theorem: chimps typing randomly.

Chimps typing “to be or not to be” by chance would take 1 quintillion years (10^18).

Don’t be a chimp.

In that time, teach chimps English. They could type Hamlet.

Even if you get lucky, what did you learn?

Instead of thrashing, take time. Understand code, errors, and fix them.

Always understand failing code. Don’t be a quintillionarian chimp.

Instead of blindly trying, slow down.

Breathe. Stretch. Get a drink.

Future you will thank you for learning from this moment.

Tip #3: Rubber Duck Debugging

Get a rubber ducky. Explain your code to it when errors occur.

Silly? Yes, but effective.

Rubber Duck Debugging slows you down, makes you talk through the problem.

Explain your Python app to a cactus, SQL query to a cat.

Verbalizing your thinking helps process the situation.

How do Most People Learn Code?

Let’s discuss traditional paths to a developer job.

Why care what others do? You do you.

But self-doubt might creep in.

My goal: calm any anxieties.

The Importance of Computer Science Degrees

University degrees, especially Computer Science bachelor’s, are still the gold standard.

Don’t have a CS degree? No worries. Not required to become a developer.

But their value is undeniable.

Why study computer science?

“Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.” – Eric Raymond

CS departments were initially in math departments, then electrical engineering.

Now, universities recognize CS as a crucial field.

CS is now the highest-paying degree, even beating Finance and Economics.

Glassdoor reports US CS majors earn $70,000 starting salary, more than Nursing, Finance, Architecture.

CS degrees help land high-paying entry-level jobs. Why?

How Employers Think About Bachelor’s Degrees

Tech employers say, “Degrees not required.” Google, Apple, etc.

True, but degrees still matter.

freeCodeCamp alumni get jobs at these companies without degrees, but they are exceptional candidates.

Job criteria include:

1. Work experience
2. Education
3. Portfolio and projects
4. Recommendations
5. Reputation

For degree-optional employers, education is one of several factors. Strong in other areas? Interview possible.

But degrees ease getting interviews, even at degree-optional companies.

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

“Bachelor’s required” jobs often accept any major.

Military officer, work visa, many “bachelor’s required” jobs – any major works.

Why? Does major matter?

My theory: less about what you learn, more about finishing university.

Employers seek those who can complete this rite of passage.

Bottom of class, failed courses, probation – a degree is a degree.

Med school last in class? Still “Doctor.”

Many employers just check “degree” box. HR software filters out non-degree applicants.

Not all employers, but many, especially in the US and globally.

Unfair, but how the job market is. May change, may not.

Encourage teens/20s to consider bachelor’s degrees.

Not for:

• Education itself (free online courses).
• “College experience” (many don’t live on campus).
• “Well-rounded” education (Freshman 15 joke).

Real value: employers often require degrees.

Other benefits: military officer, work visas.

Doctor, lawyer, professor? Need bachelor’s for grad school.

OK, blunt answers:

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

No. Many employers hire without bachelor’s degrees.

But a degree eases interviews and may command higher salary.

What About Associate’s Degrees? Are Those Valuable?

Theoretically, yes. Some tech fields might require associates. Increases interview chances.

But, don’t aim just for an associate’s. Pursue a bachelor’s, vastly more valuable.

US Dept of Education: bachelor’s earners make 31% more than associate’s.

Wider gap likely for CS bachelor’s.

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

30s, maybe some college, maybe an associate’s?

Does “back to school” make sense?

Yes, potentially.

But don’t quit your job for full-time study.

Full-time student life is for 18-22 year olds, pre-career.

Traditional universities are expensive, assuming student loans, family funds, scholarships.

Working adults have less access to these, less time.

But don’t abandon the dream.

Instead of traditional universities, consider online nonprofit universities. Western Governor’s University, University of the People are reputable and affordable.

Also, local community colleges or state university extensions, often online, self-paced.

Research. If promising, find alumni on LinkedIn, ask about their experience and value.

Avoid debt to finance degrees. Cheaper school is better. A degree is a degree, accredited is key.

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 are rarely worth it.

Any bachelor’s, even non-STEM, provides most university value.

What About a Master’s of Computer Science Degree?

Helpful for career advancement. Pursue later, after developer job.

Many employers pay for continuing education.

Georgia Tech’s online, affordable Master’s in Computer Science is popular.

But focus on getting a job first. (Job search later in this guide).

Will Degrees Continue to Matter in the Future?

Yes. University degrees will likely matter for decades, maybe centuries.

Degrees are 1000+ years old.

Top US universities predate the USA itself (Harvard is 400+ years old).

University degree “death” is exaggerated.

Bashing universities is popular, claiming degrees are useless.

Statistics show this is untrue. Degrees impact lifetime earnings.

And open safer, more stable, fulfilling careers.

High pay offshore deckhand work servicing oil rigs.

Similar pay as developer in climate-controlled office, servicing servers.

One dangerous, backbreaking, one comfortable 40-year career.

Many “thought leaders” bashing universities benefited from university education.

Why “useless” perception? Hard to separate learning from status boost.

Is university class signaling for wealthy to maintain advantage? Rich kids 3x more likely at Harvard than poor.

Life is unfair. But labor market works as it does.

Choose easy mode: degree for more options.

Or hard mode: save time/money, be selective about employers.

Both paths lead to success for many.

What Alternatives are There to a University Degree?

Two decades in adult education, no convincing substitute for university degree seen yet.

Certifications, bootcamps exist, but lack employer weight, rigor.

Side note: “Certification programs” (course + certification) are less valuable. Exam-based certifications (Amazon, Microsoft) are valuable (more later).

Degree or no degree? That’s the question.

Auto mechanics, electricians, tradespeople without bachelor’s can learn code, apply skills, get jobs.

Bookkeepers, paralegals, knowledge workers without bachelor’s can too.

Many can self-teach coding using free resources, communities.

Some aim to finish bachelor’s later, a good goal.

Not for everyone.

Formal education? Bachelor’s degree. No formal education? Self-teach.

Bootcamps, certifications offer structure, peer pressure. Worth thousands? Maybe not.

How to Teach Yourself to Code

Most developers are self-taught, even CS degree holders often self-identify as such in surveys.

Learning code is lifelong. New tools, legacy codebases, problems to solve.

Formal education or not, self-teaching is essential.

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

Self-taught means self-directed learning, outside formal education.

Few are truly “self-taught.” Isaac Newton self-taught Calculus because no books existed, he invented it.

Ada Lovelace self-taught programming, inventing it before computers.

Someone might say, “Not self-taught, you used books/courses, you had teachers.” Technically correct, narrowly.

If someone argues about “self-taught”, say, “By your standards, only wolf-raised people are self-taught.”

Point them to this section, say “Quincy anticipated your snobbery.” Move on.

Life’s too short. You are self-taught.

What is Self-Directed Learning?

Self-learners curate resources, choose what and where to learn code. Essence of self-directed learning.

How to know you’re learning right skills, using right resources?

Community.

Learn code with communities, helping each other expand skills.

Community definition is broad: Tech Twitter, freeCodeCamp forum, Discord groups, subreddits.

Online, in-person events too: Ruby meetups, startup meetups, Linux user groups.

Communities are online, in-person, or mixed.

Build Your Network chapter discusses communities more. Takeaway: community friends help narrow learning, choose resources.

What Programming Language Should I Learn First?

Short answer: it doesn’t really matter. Second language is much easier after the first.

Different language types, but most modern dev uses “high-level scripting languages” like JavaScript and Python. Less efficient than “low-level” like C, but easier to use.

Today’s computers are billions of times faster than 70s/80s computers when C was dominant. Scripting language inefficiency is negligible.

JavaScript and Python are written in C and getting faster via open-source communities.

Python is powerful for scientific computing (Data Science, Machine Learning).

JavaScript is the ultimate Swiss Army Knife language, doing almost everything. Web’s duct tape.

“Any application that can be written in JavaScript, will eventually be written in JavaScript.” – Atwood’s Law

Code your entire career in JavaScript, no need for another language. (Python useful later, maybe others).

Start with JavaScript. Easier than Java, C++, easier to learn code. More JavaScript jobs.

Other key skills: HTML and CSS. Website body: HTML bones, CSS skin. (JavaScript: muscles, interactivity).

HTML and CSS can be learned code in an afternoon. Easy to learn, hard to master.

Linux is essential. Powers most servers. Command line skills crucial.

Mac? MacOS terminal is similar to Linux (Unix ancestor).

Windows? Install WSL (Windows Subsystem for Linux) for Linux commands. Dual-boot Windows/Linux possible.

Linux is harder than Windows/MacOS, but fast, secure, customizable.

No OS licenses needed. Red Hat, a billion-dollar company with open-source software, sells support.

Git is essential. Version Control for team code collaboration.

GitHub extends Git, aiding open-source collaboration (more in Reputation chapter).

SQL and relational databases are vital. Information economy workhorses.

NoSQL databases (graph, document, key-value) exist, learn later. Focus on SQL first.

Web servers understanding is crucial. Start with Node.js and Express.js.

“Full stack development” is front-end (HTML, CSS, JavaScript) and back-end (Linux, SQL, Node + Express) combined.

Other tools like React, NGINX, Docker, testing libraries can be learned later.

Key skills for 90% of pre-job learning time:

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

These tools enable building most web/mobile apps, qualify you for most entry-level jobs. (Job descriptions list more, discussed later.)

Great, how to learn code these?

Where do I learn how to code?

Funny you ask. There’s a curriculum by experienced software engineers and teachers, designed for busy adults, free and self-paced.

freeCodeCamp core curriculum. It helps you learn code:

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

Thousands have used it to get developer jobs, without quitting jobs, loans, or major risks.

freeCodeCamp is the default path for many self-learners.

It’s your “home base,” branching out from there. Learn core job skills, explore technologies you’re interested in.

Decades of books, courses exist, libraries, subscription services offer access (some free via libraries).

freeCodeCamp has ~1,000 free full-length courses: AWS certification, mobile app development, Kali Linux, etc.

Never been easier to self-teach programming.

Building Your Skills is a Life-Long Endeavor

We discussed self-teaching, alternatives like degrees, and essential tools to learn code first.

Now, let’s shift to the second leg of your stool: your network.

Chapter 2: How to Build Your Network to Learn Code and Advance Your Career

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

“Networking.” The word might make you cringe.

Awkward job fairs in stuffy suits, résumés desperately pushed into hands.

Alcohol-fueled parties, feigning interest in unfamiliar sports.

LinkedIn birthday wishes to near-strangers, status updates hoping for notice.

Networking doesn’t have to be that way.

In this chapter, I’ll share networking insights, building trust, and staying top-of-mind for opportunities.

Because it’s about helping people, being useful.

I’ll show you how to build a strong, lasting personal network.

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

Last time: Quincy learned coding, joined the hackerspace, built a project, and gave a tech talk…

I had basic coding skills, could code my way out of a paper bag.

Next step? Tech outsider status.

Despite being new to tech, I understood work dynamics from teaching.

“It’s who you know.” Networks are powerful. Opportunity goes through gatekeepers.

A hiring manager’s “Yes, Quincy seems worthy” was the key to a developer job.

Being a tech outsider, I didn’t grasp the culture immediately.

Academic culture is formal: suits, jargon, university name-dropping, journal publications.

Tech culture is different. Conferences, career progression, power structures are unique.

Initially, I wore a suit to tech events, pocketed résumés, carried business cards – laser-etched aluminum with a John Dewey quote. Heavy-handed.

“Hi, I’m Quincy. Aluminum card. Metal detector warning.”

Trying too hard. Obvious to everyone.

Meetup.com, RSVP’d to all developer events, even driving to LA from Santa Barbara.

Quickly, I traded suits for jeans and hoodies, ditched business cards, following hackerspace devs’ cues: passionate, understated.

I read books to understand developer culture.

The Coders at Work (80s).

Hackers: Heroes of the Revolution (90s).

Mr. Robot (contemporary TV series).

I began to speak less like a teacher, more like a developer. Less awkward.

Attended tech events weekly. Favorite: Santa Barbara Startup Night, developer prototypes pitched, some securing angel funding.

Mike ran the event, knew every Santa Barbara developer and entrepreneur, an ultra-marathoner, perfectly groomed, respected by all.

I observed Mike’s interactions. I, too, was recently “non-technical.”

Old habits crept in. Showing off skills and projects.

Developers are modest. “I dabble in Python.” Insecure me: “Python in my sleep!”

Later, Googling them, realizing they were core Python library contributors. Kicking myself.

Learned not to boast. Someone you talk to is likely better than you, but won’t say so.

Nothing worse than showing code, then facing questions you can’t answer.

Humbling experience, but events energized my skill-building.

People recognized me. “I keep seeing you. Name again?”

A dev said, “Let’s Twitter follow.” Twitter, gimmicky website to me, but I had an account. She followed.

Inspired me to refine online presence. LinkedIn less formal, more friendly. Mimicked other devs’ online presentation.

Within months, I knew:

• Experienced developers
• Semi/non-technical tech company people
• Hiring managers, recruiters
• Peers breaking into tech

Peers were most crucial. Least able to help get jobs? Wrong.

Hiring manager hires good dev, asks: “Where to find more like you?”

Peers are vital network piece. Freelance and job interviews came from coding peers.

We grew together, bonds tightest.

Networking paid off one night at a fancy hotel bar for a developer event.

More on that next chapter. Let’s discuss network building.

Is it Really Who You Know?

Success is “less what you know, more who you know?”

Actually, it’s both.

Connections help, but skills are essential. Without skills, you won’t succeed in a role.

Assume you’re building skills. When to network?

Best time to network? Yesterday.

But you already have a network, likely smaller than desired, but you know people.

Friends, parents’ colleagues, anyone from your past might help.

Step one: inventory people you know. Not reaching out yet, just strategy.

First, inventory people you know.

How to Build a Personal Network Board

Start by listing people you know.

Spreadsheet or CRM tools are overkill.

Use a Kanban board tool like free Trello.

5 columns: “to evaluate”, “to contact”, “waiting for reply”, “recently in contact”, “don’t contact yet”.

Labels to classify people: “Childhood friend”, “Family friend”, “Former colleague”, “Classmate”, “Tech Event Friends”.

Create cards. Name, photo if available.

Trello board example: characters from Teenage Mutant Ninja Turtles.

Go through social media, yearbooks, add people.

Many won’t help, but be comprehensive. “So-and-so at XYZ Corp, reach out?”

Process might take days. Investment. Use board throughout career.

“LinkedIn enough?” LinkedIn is blunt. Maximize signal, minimize noise with dedicated network board.

As you add people, label them. Research each person. What are they doing? Job? Company?

Add notes to cards. Recent 5K run? Grandma’s 90th? Seemingly extraneous, but important to them if shared publicly.

Be interested in people’s lives, aspirations. Understand motivations, goals, to help them.

Helping people forges alliances. More on this soon.

For each person, assess if worth contacting. “To contact” or “Don’t contact yet.”

“Don’t contact yet” column? Never write anyone off. Friendships and acquaintanceships are valuable.

Once board is filled, labeled, sorted, start reaching out.

How to Prepare for Network Outreach

Key for outreach: keep it simple.

People are busy, remember limited facts about you. Boil down who you are. Write a personal bio.

How to Write a Personal Bio for Social Media

Consistent presence across social media.

My bio:

“I’m Quincy. Teacher at freeCodeCamp. Dallas, Texas. I help you learn code.”

Write yours. Under 100 characters. Avoid jargon.

Distilling identity is hard, but important.

People are busy, don’t need your life story. As you connect, fill in details as they ask.

And you need a good smiling headshot.

How to Make a Social Media Headshot

If budget allows, hire a photographer for professional headshots.

Photography friends might help for free.

Self-taken headshot using PhotoBooth (MacOS), friend Photoshopped background, shading, teeth whitening.

Smile with your eyes, look genuine. Think of something funny for a natural smile.

Take many shots, different angles, use the best one.

Use a headshot resembling your everyday look, not heavily photoshopped. Approachable, friendly. Acid test: would you ask this person for directions if lost?

No sunglasses, avoid trying too hard to look cool. Friendly, approachable is key.

Choose a headshot, use it everywhere. Social media, personal website, email profile photo.

Keep a high-def version for conference promotions, podcast appearances (future possibilities).

Use the same photo for years. Changes risk people not recognizing you. Subtle lighting/angle changes can confuse familiarity.

How to Reach Out to People from your Past

Bio and photos ready, time to connect.

15 years ago, phone calls over messages. Culture shifted with smartphones. People prefer messages, not calls.

Avoid coffee/lunch requests initially, too awkward, people are busy.

Get to the point, quickly.

Point:

1. I know you
2. I like you
3. I respect your work

That’s it.

People like to be known, liked, and have their work recognized.

Birthdays offer recognition. But what about the other 364 days?

Here’s a simple way to recognize people.

Step 1: Research the person. Google, social media, LinkedIn, family photos.

Step 2: Think of something to brighten their day.

Step 3: Choose a platform they’re active on. Direct message them.

Template (don’t use verbatim, personalize it):

“Hey [name], hope your [new year/spring/week] is fun. Congrats on [new job/promotion/baby/project]. Inspiring to see you getting things done.”

Short, to the point. Greeting + congratulations + compliment. Basic formula.

Be sincere. Brighten their day. Encourage their progress.

Humans detect insincerity. Don’t oversell, avoid “this person wants something.”

Keep it brief, respect time. No long letters needing lengthy responses.

People are busy.

How to Build Even Deeper Connections

Busy people prioritize what strangers can do for them:

• Bus driver to work
• Barista making coffee
• HR answering time-off questions
• Playlist curator
• Email newsletter with coding resources

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

Not for close friends/family, but for casual acquaintances, that’s likely their perspective.

Give people a reason to care. Inspire them to learn more.

Before close friendship, be helpful.

We’ll build deeper relationships by offering help.

Long process, start before job search. Avoid “reaching out because you need something.”

Offer value.

You have a powerful skillset: coding.

Or on the path to becoming one.

Good pretext to reach out.

“Cold call” – selling to strangers. Hard, most end quickly.

More info you know, “warmer” the call, better the chance.

You’re not selling anything, sending a direct message.

Platform: Twitter, LinkedIn, Discord, Reddit, etc. Short text paragraph.

Strongest opening: offer help casually.

Template (personalize, don’t use verbatim):

“Hey [name], congrats on [new job/promotion/baby]. I’m learning code, building my portfolio. You came to mind as someone who gets things done. Any tool/app that would make your life easier? I might code it for practice.”

Personalized, not automated. People hate automated messages.

Manual messages are better than mail-merges.

Fastest way to get blocked: “Hi , how’s it going?” – missing name, template alert.

“Hey Larson.” Military school?

LinkedIn emojis at name start signal automated messages. “Hi 🍜Sarah, job hunting?” Bulk message.

My template avoids “school together” unless recent contact. Don’t remind people how you know them, might make them think, “I barely know this person.”

How to Keep the Conversation Going

Goal: get a response, start a back-and-forth.

Messaging platforms are casual. Keep it casual.

Short, snappy messages. Don’t make replying a chore.

Once they reply, note facts on Personal Network Board.

Maybe they have an app idea. Ask questions. Offer to build it.

Sketch a UI mockup, use graph paper for sophistication, photo it, send it. “Something like this?”

Shows you’re serious. Likely a new experience for them.

“You’re helping me? Creating this app for me?” Flattering, memorable, even if app doesn’t materialize.

Go with conversation flow. Fizzles out? No worries. Re-engage later.

Direct message logs are great. Next message, they see, “Oh, that’s the app offer person.” No “who are you again?” awkwardness like in person.

Keep it casual, upbeat. Slow conversation pace is fine. You’ll have many conversations going. Busy bee networking.

How to Meet New People and Expand Your Personal Network

Outreach to existing contacts discussed.

How to make new connections?

Hard, but tips to ease the process.

In-person meetings are more powerful than online.

In-person memory cues:

• Appearance, posture, movement
• Voice, speech
• Venue lights, sounds, smells, temperature

10-minute in-person talk > dozens of online messages over weeks.

Get out and meet people at local events.

How to Meet People at Local Events Around Town

Which events? City density impacts options. Tech events several nights a week in big cities.

Small towns: local gatherings, book fairs, ice cream socials, sports events.

Church, mosque, temple? Connect there too.

“Soccer bleachers person help me get a dev job?” Maybe. Maybe not. Don’t write people off.

They might run a business, know a VP of Engineering, or be a software engineer too. Millions of us, not all in Silicon Valley. 😉

Meeting someone new, don’t immediately LinkedIn request.

Play it cool. Introduce yourself.

Remember their name. Names build relationships. Practice name memory. Remember minor character names in TV/movies.

Forget name? “What’s your name again?” Remember it second time.

Handshake or fist bump. Natural conversation. Conversation dies? Let it go.

Relationships build over time. Not total time, but frequency over time.

Likely to see them again. Same location, weeks later. Then make your move:

“Hi [name], how’s [previous conversation topic] going?”

Resume conversation. If they seem helpful, “What are you doing next [day]? Want to join me at [upcoming event]?”

Always have upcoming events in mind, invite people.

Great way to hang out in a safe, public space. Value offered: event awareness.

Interested? “Best way to message you event details?”

Email, social media, phone number acquired, relationship unfolds.

Slow burn approach. Why cautious?

People are busy. Smart people guard time, personal info.

Too many “vampires” trying to exploit people – selling, scamming, MLM schemes, proselytizing.

Best way to bypass defensiveness: be on their radar as reasonable person from previous encounters.

How to Leverage Your Network

Leveraging network discussed in Chapter 4. For now, see it as time/energy investment.

Network as an orchard. Planting, tending relationships.

Relationships grow into trees, bear fruit eventually. Keep planting trees, they’ll sustain you later.

Send positive energy. Offer help using skills, network. (Polite introductions are rarely bad).

Be kind, thoughtful, helpful.

Don’t be impatient with job search pace.

Don’t feel slighted or snubbed.

Don’t be jealous of others’ success.

What goes around, comes around. Reap what you sow. Sowing positivity leads to bountiful harvest.

Chapter 3: How to Build Your Reputation to Learn Code and Advance Your Career

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

Skills and network built, time to build reputation.

Starting from scratch, tech newcomer? Or bringing credibility from past career?

This chapter: practical tips for building a strong reputation, key for freelance, jobs, career advancement.

First, my reputation story.

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

Last time: Quincy networked, frequented events, but hadn’t tested his skills in competition…

Months into coding, I finally dared to go to a hackathon.

Dealing with a nasty bug, procrastinating online, I found Startup Weekend EDU.

54-hour competition, app building, pitching to judges. Rewards coding, design, entrepreneurship.

This Silicon Valley event had educators and education entrepreneurs as judges. Ideal for my adult education background.

Told Steve about it. “I’ll drive,” I said (Steve had no license).

With Steve, we added two devs from the hackerspace to our team.

Weeks preparing: judge research, sponsor research, coding practice like a monk.

After a month, big weekend arrived. 2003 Toyota Corolla, peeling clear coat, high-energy music, 5-hour drive to Silicon Valley.

Driving, we discussed app ideas. Education-focused, ideally high school, judges’ companies focused on that.

App function? Make life easier?

High school memories… dropped out after a year (GED story another time).

Pain point from high school: English papers.

Loved writing, hated MLA format, citation rules. Dreaded Works Cited pages, always losing points for formatting.

After OK ideas from others, I piped up. “Citation app.”

Someone laughed, “Out of sight.”

Steve: “Hey, good name. Out of Cite, with a ‘C’.”

Laughing, feeling clever, we discussed implementation.

Venue: 100+ devs in open-plan office, cubicles, whiteboards.

Whispers about a dev: “He won last year.” Cocky-looking dev, surrounded by fans. “Maybe he’ll let me join his team.”

Event started with pitches. 60-second pitches for app ideas.

Nervous, alien-bursting chest feeling. First in line. Rip band-aid, right?

Sweating, gesturing wildly, rushed pitch. “Citations suck. Necessary, but preparing them sucks. App to auto-generate Works Cited page. Who’s with me?”

Quiet room, then obligatory applause. MC took mic, next person, I pranced back to my seat.

After pitches, team forming. Santa Barbara group looked at each other, “Guess we’re a team.”

Wifi password, best workspace: corner office with a door.

Whiteboard UI mockups. “Always a click away, browser menu bar.”

“Browser plugin,” Steve said.

“Yeah, browser plugin.”

Showed MLA, APA, Chicago formats.

“Generate all three at once, copy-paste?” I asked.

“Better,” Steve said. “Buttons for each, direct clipboard copy.”

Worked fast, MVP (Minimum Viable Product) by Friday night. Grabbed website metadata, structured citation. It worked.

First hackathon, no hostel stress, hotel room. Twin beds, bed-floor rotation.

Saturday morning, ambitions grew. “Website citations good, but students cite books and papers too. Need citations for those.”

Found API for ISBN (book serial number) citation info. Hacked script to search academic papers by DOI (paper serial number), scrape data from results.

Saturday night, plugin code coming together. I started presentation slides, final coding to teammates, rehearsing pitch for hours.

Sleepless night due to jitters, even in a bed. Silicon Valley.

Teacher giving talks to peers was different. This was a room of ambitious devs, judges with PhDs, tech company founders, evaluating our work. Terrified of blowing it.

Sleepless, opened email. Startup Weekend sent a PDF book, unofficial mash-up of startup classics 4 Steps to the Epiphany and The Lean Startup.

Read those books, startup book slurry in my mind.

4 a.m., couldn’t sleep, started reading. Books emphasized building something people pay for, customer validation.

Realized: presentation needs proof of product-market fit, proof app solves real problem, people pay for it.

Idea: take app on the road, sell it.

Sunday morning. Where to find customers? Hotel near Stanford University.

Drove team to venue, “I’ll be back with customer cash.”

Teammates chuckled. “Don’t be late for pitch.”

Serious. Prototype on laptop. Stanford in GPS, mission started.

State university in Oklahoma background, felt out of depth at Stanford.

$50,000/year tuition, $5,000 car.

Campus deserted on Sunday. Palatial ghost town, bronze statues, iconic arches.

Where are high-achieving, hardcore students now? No time for manual citations.

Walked into main library, “no soliciting” sign ignored.

Found few studying in stacks. Kid taking notes from thick textbook. Bingo.

Slid into seat next to him. “Psst. Hey. Citations?”

“What?”

“Citations, Works Cited pages.”

“Um…”

“Last page, list of sources…”

“I know what a Works Cited page is.”

“OK. Check this out.” Drug dealer jacket move, $200 netbook reveal. Sales pitch.

“Browser plugin. Website, click button, voilà, citation.”

Kid raised eyebrows. “MLA?”

Excited, I said, “MLA, APA, Chicago. Watch.” Clicked button, three citations appeared, copy-to-clipboard buttons.

Kid nodded, impressed. Sales close attempt.

“Launching app with yearly subscription. Sign up now, lifetime unlimited access.”

Kid thought.

Heard silence is salesperson’s friend. Uncomfortable silence, staring him down.

Finally, “Cool, I’m in.”

“Awesome. Twenty bucks.”

Kid recoiled. “Expensive.”

Venture capital-subsidized startups era, Uber/Lyft losing money for market share. Kid’s reaction unsurprising.

“How much cash you got?” I asked.

Wallet fumble, “five bucks.”

Crumpled bill shrug. “Sold.”

He smiled, email instructions sent. “One more thing. Picture together.”

Selfie mode phone. “Hold up five dollars.”

Hour pitching in library, another paying customer. Raced back to venue, finalize prototype.

Afternoon, best presentation ever. Live demo, app worked perfectly.

Presentation ended with Stanford student customer photos, holding up cash earned. Audience applause.

Exhilarating. Second place, API credit prize.

After-party, pizza chipmunking, networking, LinkedIn connections, Twitter follows, selfies, event hashtag use.

Watershed moment. Proved I could design, code, sell an app. More importantly, proved it to myself.

Riding the Hackathon Circuit

Hooked on hackathons. Dozens that year, road warrior, coastal competitions.

Harder now, no team. Solo.

Arrived, met people, pitched ideas, hoping judges liked them.

Sometimes teams formed, sometimes joined others.

Not just design, wanted to code too. Reach exceeding grasp.

Hackathons with last-minute bug fixes, apps crashing during demos.

Vegas hackathon, code disaster, slideshow demo, head in hands, judges unimpressed.

Kept grinding, new towns, hostels, venues, free pizza.

Second/third place many times, lost count. Never outright won.

Breaking Through

Until San Diego event. Winning felt inevitable.

Winner announcement, snuck out back door, called grandparents. Told them I finally won.

Grandparents maybe didn’t grasp software development or hackathons, but they were proud.

Grandparents gone now, cherish that conversation, their belief in 30-something teacher grandson becoming a developer.

Kept hackathoning. New teams, new tools. API success, Git command understanding, unforgettable. Hustling teammates, app barely holding together for demos, unforgettable too.

TechCrunch Disrupt, DeveloperWeek, ProgrammableWeb, $1 Million Salesforce Hackathon. Big hackathons, huge learning. Crucible forging developer skills.

Skills, network, reputation built. Reputation as “hackathon winner.”

Could ship.

Known quantity.

Reputation crucial for freelance clients, first job, and self-trust as a dev.

Why Your Reputation is So Important

Reputation’s role in society is ancient. Tribes, settlements tracked debts.

Pre-cash, credit existed. Ledgers or elders’ memories.

Beyond accounting, intangible vibes.

“John shoes horses well.”

“Jane, best storyteller.”

“Jay’s courage saved us from invaders.”

Examples involve skill, not just being likable.

Being chill helps, but charm alone isn’t enough.

Easy for a dev to say, “I know JavaScript. Can build anything.”

Or, “I ship code under budget, on time, always.”

How to know they aren’t exaggerating?

“If you can only be good at one thing, be good at lying.

Then you’re good at everything.”

(Quote origin unknown, 1920s con man image in mind).

Anyone can lie, some do.

Teacher lied about master’s degree, got away with it for years, until caught.

Spoils of lying are tempting. Some yield to temptation.

Employers know this. Can’t trust every “full-stack JavaScript” claim. Cautious about company badges, emails, database access.

Behavioral interview questions try to catch dishonest people.

Most people are good, play by rules if fair.

But even one bad hire is disastrous, increasing scrutiny for all.

Worst case: not just lying for pay, but selling secrets, ruining customer relations, breaking laws.

History rife with employees causing catastrophic damage for personal gain.

Developer hiring is paranoid. Makes it harder for everyone, even honest candidates.

Developers need proof of skills, work ethic.

Reputation provides this proof. Reduces ambiguity, risk. Easier for employers to offer jobs.

Strong reputation means “side door” access, bypassing front door lines.

Recruiters fast-track interviews. Reputation boosts salary negotiation power.

Let’s discuss building a strong reputation, becoming sought-after.

How to Build Your Reputation as a Developer

Six time-tested ways to build developer reputation:

1. Hackathons
2. Open source contributions
3. Developer-focused content
4. Rising ranks at “household name” companies
5. Freelance client portfolio
6. Starting open source project, company, charity

How to Find Hackathons and Other Developer Competitions

Hackathons are immediate way to build reputation, network, coding skills.

Most are free, open to public. Just time and travel budget needed.

Big cities like San Francisco, New York, Bengaluru, Beijing have many hackathons, commute possible.

Santa Barbara hackathons rare, but old classmate in San Francisco let me crash on his couch for more events.

Hackathons were hardcore, energy drinks, floor sleeping, project finish by pitch time.

Now, organizers are mindful of health, sustainability. Many participants have kids, jobs, can’t code all weekend.

Best way to find events: Google “hackathon [your city name]” and browse event calendars. Universities, employers, charities often host.

Playing to win? Research sponsors beforehand.

Sponsors are often B2D (Business-to-Developer) companies with APIs, database tools, SaaS.

Sponsors often have booths at events, talk to developer advocates, key employees, founders for networking.

Hackathons often have sponsor-specific prizes. “Best Use of [sponsor’s] API.” Easier to focus on sponsor tools than grand prize. Wins are wins.

High-profile hackathons, substantial prizes, worth aiming for outright win.

During hackathons, I won rent money, coworking space years, UN building tour.

Hackathon regulars sometimes found VC-backed companies or launch open-source projects.

Hackathon ambition level is higher than average developer. Work week + work weekend people, unafraid of leaping from frying pan into fire.

How to Contribute to Open Source

Open-source contribution is immediate reputation builder. GitHub profile displays Git commit history.

Open-source projects like Linux Foundation, Mozilla, freeCodeCamp have high code quality standards.

Find GitHub issues, bugs, feature requests. Make code changes, open pull request. Merged pull requests are a major win.

Best way to job at tech company: prolific open-source contributor to their repos.

Open-source contribution builds reputation publicly. Social proof of code review and acceptance.

Getting started with open source? Read Hillary Nyakundi’s guide: getting started with open source.

How to Create Developer-Focused Content

Developers are people, needing entertainment outside work, sleep, family.

Books, video essays, interactive experiences, like visual novels. “Content.”

Software development is broad, many content topics. Developer lifestyle vlogs, coding interview prep, Twitch live streams, freeCodeCamp Podcast.

Untapped developer content categories exist, future trends will emerge.

Film, journalism, creative writing background? Developer content builds reputation.

Pick a topic, become the expert.

Developer tutorial specialists exist.

Andrew Brown, ex-CTO, AWS/Azure/Google Cloud certified, creates free certification prep courses, exam prep service.

30+ million developers globally. Large content audience, building recognition.

How to Rise in the Ranks by Working at Big Companies

“Ex-Googler,” “Ex-Netflix engineer” introductions.

Some companies’ hiring is rigorous, getting a job there is an accomplishment.

Employer reputation matters, reduces bad hire risk.

Build reputation by climbing prestige hierarchy. Local to Fortune 500 to tech giants.

Corporate giant work not for everyone (Chapter 4). But reputation building option.

How to Build your Reputation by Building a Portfolio of Freelance Clients

Build reputation via freelance work.

Freelancers often work on smaller, one-person projects. Local reputation building strategy.

Good work for local bank? Local law firm might hire you too.

“Hometown hero” advantage. Local presence, in-person meetings, local connections matter.

How to Build a Developer Portfolio of Your Work

Show off projects. Short videos are best.

People are busy, no time to run your code.

Websites might not convey project value.

Use screen capture for 2-minute video demos.

Two minutes to show project, then explain implementation, design.

Demo first, always. Visuals engage viewers.

Once hooked by demo, explain details. Audience has context, more interest.

2 minutes is Twitter video autoplay length. Autoplay videos get more views, less friction than clicks.

Put project demos on YouTube, Twitter, GitHub, portfolio website.

Capture video using QuickTime (MacOS) or Game Recorder (Windows 10). OBS (free, open-source, powerful, customizable).

Recording tips: large font size, external mic. Any mic > laptop mic.

Invest time in recording, re-recording until perfect.

Project demo and code presentation are valuable career skills. Pitch practice is never wasted.

How to Start Your Own Open Source Project, Company, or Charity

Founder status builds reputation fastest, but riskiest.

Risky due to time, money, relationship wagering, unknown outcomes.

Open-source contribution and hackathons will build reputation.

Entrepreneurial projects can fail for decades, wasting time, money, connections.

Entrepreneurship is complex, beyond this guide’s scope. Quick advice:

Most entrepreneurs fail. Some due to circumstances, many due to risk misunderstanding.

Don’t rush into founding. Work for organizations in your field of interest first.

Get paid to learn, gain experience, build savings for eventual 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

Reputation building is marathon, not sprint.

Years to build strong reputation.

Like marathon stumble, reputation stumble costs time, injury can end the race.

Don’t Say Dumb Things on the Internet

Used to be, dumb things said dissipated.

Now, dumb things online are indelible, permanent record.

Assume everything online is saved, backed up globally, permanent.

Data existence is provable, absence isn’t.

Assume cat’s out of bag. No getting it back in. Permanent record.

Deletion, account deletion, Google scrubbing – someone has likely backed it up. Database hacks resurface old data.

Scary time to be loudmouth. Don’t be. Think before speaking.

Cowardly advice: avoid online arguments.

Playground rule: “If you don’t have something nice to say, don’t say anything at all.”

“Praise in public, criticize in private.”

Publicly recognize good work.

Refrain from tearing people down, even deserved ones.

In a fight, everyone looks dirty.

Avoid wrathful, argument-tearing, dog-piling.

Caustic wit wins internet points short-term, but makes people fear, not love, you.

Refrain from complaining. Better customer service with tweet threat? Maybe.

But people are busy, don’t want social media groaning about minor inconveniences.

Social media advice: stay positive.

If it’s a cause you believe in, speak your mind, but think before typing, sending.

Don’t Over-promise and Under-deliver

Common developer reputation torpedo: over-promising, under-delivering. Not fatal, but bad.

Vegas hackathon failure, using slides instead of working app.

Lowest point. Teammates polite, but disappointed. Overconfident, over-promised, under-delivered.

Better to be modest about abilities.

Icarus parable, wax wings too close to sun. Measured approach, slower ascent, wings wouldn’t melt, no sea plunge, no guilt-stricken father.

Get Addictions Under Control Before They Damage Your Reputation

Drug, alcohol, gambling addiction? Seek help first. Job search is grueling, needs full attention.

Even video game addiction distracts, soaks up time. Get it under control.

Not a doctor, no “drugs are bad” speech. Silicon Valley fads of drug abuse for coding improvement exist (micro-dosing LSD, amphetamines).

Gut reaction: short-term edge, unsustainable, net negative long-term.

Don’t feel peer pressure for drugs. Don’t feel pressure to drink at happy hours. (Sober since daughter’s birth, no regrets).

If in recovery, coding job search is stressful. Pace yourself, avoid relapse.

Don’t achieve so much, only to relapse and undo your hard work.

Try and Separate Your Professional Life From Your Personal Life

“Don’t mix business with pleasure.”

As developer, you’ll be powerful, respected.

Not doctor or astronaut level, but still. People will look up to you.

Talk to people who want to be in your shoes.

Don’t flaunt wealth.

Don’t act smarter than everyone.

Don’t abuse power in relationships.

Unlikable, online capture, career haunting.

Never lose sight of what you have and what you can lose.

Use the Narrator Trick

Pump-up trick: Narrator Trick.

Hero in your coding journey. Theater of mind, everyone watching, rooting for you.

Narrate actions in your head.

“Quincy strides across hackerspace, laptop under arm. Tea mug under dispenser, tea bag in, lever pulled. Steaming mug in hand, British accent: ‘Tea. Earl Grey. Hot.’

Energizing beverage, booth slide-in, laptop squared. Fellow developer glance. Eye contact, slight nod acknowledgment, dev nods back, telepathic sentiment: ‘I see you friend. Showing up. Getting things done.'”

Ridiculous? Yes. But it works.

Mundane moments narrated energize you, crystallize moment, purpose clarity.

Works better thinking in eras (“Taco Bell years”), inflection points (“GED exam”).

Reputation is summary of who you are, what you mean to people.

Taking yourself more seriously, life as movie, working through who you are, who you want to be.

Narrating actions shines light on them. Why did I do that? Better move?

Many sabotage reputation unknowingly, settled into bad habits.

Humor reflex, class clown grade school days, decades later, reflex isn’t serving me well.

“When you repeat a mistake, it’s not a mistake anymore. It’s a decision.” – Paulo Coelho

Narrator Trick exposed awkwardness.

More suboptimal thinking/doing ways likely exist, Narrator Trick helps identify and refine them, before wrong impressions.

Your Reputation Will Become Your Legacy.

Who do you want to be at story’s end? How do you want to be remembered? Work backward.

Future movie hero you want people to admire. Carry yourself like that now?

Imagine successful developer you. Built software people rely on.

Future you – how would they think, approach situations, solve problems, talk about accomplishments, setbacks?

Future self thought clarifies thinking, priorities.

“Old Man Quincy,” bad back, toilet runs, still working, moving despite pain, pondering despite fog, getting things done, proud of accomplishments, but looking forward, not back, daily goals.

Think of Old Man Quincy, work backward to today.

Today’s decisions setting you up for admiration tomorrow? Wait decades? Or borrow respect from future?

Thinking like future self, can you make moves earning positive reputation now?

Leverage future reputation now. Think future self, use as waypoint.

Narrator Trick and future self visualization – tools to think about reputation and take concrete steps to improve it.

Building reputation is sure path to sustainable developer success.

Success is many things. For most, food on the table for self and family is key.

Next chapter: getting paid to code.

Chapter 4: How to Get Paid to Code – Freelance Clients and the Job Search to Learn Code

Skills, network, reputation built, getting a developer job isn’t complicated.

Not complicated, but still work, still a grind.

First, how I got my first job.

Story Time: How Did a Teacher in His 30s Get His First Developer Job?

Last time: Quincy hackathon circuit, won events, reputation as “dangerous” JavaScript dev…

Long day learning at library, tea sipping, project building.

California weather perk. Exorbitant rent for the outside, joked we’d pay for the outdoors.

Cramped 100-year-old apartment avoidance, walking around town instead.

Beautiful Wednesday evening. Two more days to hackathon prep. Brain fried from coding. Wife working late, checked calendar for events.

First Monday event mapping, monthly tech events around SoCal, always an event if energy allowed.

Ah, Santa Barbara Ruby on Rails meetup tonight, RSVP’d already.

Limited Ruby on Rails knowledge, few projects, JavaScript and Python focus.

But, what the heck. Network building momentum needed. Venue few blocks away.

Walked in, few devs chatting. Worked together at local startup, maintaining Ruby on Rails codebase. Years working there.

Year of skill, network, reputation building. Held my own in conversation.

Felt limits of abilities, stayed modest, understated, like other devs at events.

One dev was Director of Engineering, reported to CTO.

They were hiring Ruby on Rails developers.

Candid about background, abilities. “Adult education, teaching English, running schools. Learned code about a year ago.”

Surprisingly unfazed. “Interview if you want, see if you fit.”

Walked home electric. Dread, not excitement.

Nowhere near ready. Not even job hunting. Savings, wife’s health insurance.

Compulsive saver. Frugal habits, oil changes, haircuts, home-cooked rice with takeout.

Decade of teaching, saved quarter of after-tax earnings, flipped old video games on eBay. Substantial income source.

Saving for what? California house maybe? No job hustle needed. Privileged, learning full-time.

Didn’t think I was ready, job mistake, fired, failure explanation in future interviews.

Looking at opportunity wrong. Story continues.

Scheduled interview, résumé requested. Professional experience only, schools taught at. (Taco Bell drive-thru omitted).

No coding experience, but portfolio of projects, hackathon wins/placings included.

Hours before interview, revisited Ruby on Rails tutorials. Hoody, jeans, backpack, walked to office.

Office manager, nice lady, developer bullpen intro, small team of devs, dozen, jeans/hoodies, 20s to 40s, two women.

Navigated desks, cables, handshakes, introductions. Teacher experience memorizing names helped. Remembered all names, follow-up later: “Great meeting you, [name]. Excited to work with you.”

Met Director of Engineering first, small office, closed door.

Whiteboard UML diagrams, server/service relationships.

Glanced at whiteboard, feared coding problem, fizzbuzz, binary tree inversion?

Whiteboard never mentioned. Intense look whole time.

50-employee company, VC funded, paying customers, small businesses. Pragmatic. No school or past work questions. Cared about…

“Look. I know you can code,” he said. “Hackathons, portfolio projects. Code quality OK for newbie. Real question: can you learn our way? Teamwork? Get things done?”

Gulped, leaned in, mustered confidence. “Yes,” I said. “I believe I can.”

“Good. Good. OK. Pho restaurant downstairs, CTO will be there.”

CTO meeting over noodles, mostly listening. Quiet people project intelligence. Listening intently makes you smarter, look smarter.

Meeting hour long, tasty noodles, company history, near-term goals learned. CTO: “Go back up, talk to Director of Engineering.”

Did, job offered.

Emphasize: not typical first developer job story.

“Quincy Forest Gumping into job he wasn’t seeking.” Lucky?

Felt lucky, but employer-developer relationship, job less about interview skills, more about year of coding, networking, reputation building beforehand.

Not cushy big tech job, no perks, bowling alleys. Contractor role, pay same as teaching.

But a developer job. Paid to code.

Professional developer now.

What Employers Want

Decade later, both sides of table. Interviewed by hiring managers, interviewed developers as manager.

Calls with job-seeking developers, hundreds of applications, few call-backs.

Calls with managers/recruiters, hiring process, needs understanding.

Developer job frustration is misunderstanding.

Employers value predictability above all else.

Which candidate preferred?

X: “Rockstar” 10x coder, genius flashes, bursts of productivity, grumpy, misses deadlines/meetings.

Y: OK coder, consistent output, good colleague, rarely misses deadlines/meetings.

Z: Like Y, consistent, good colleague, meets deadlines, but changed jobs 3 times in 3 years.

Guess who’s preferred? Y. Predictability trumps all.

X is a trap, some new managers hire by mistake. We fired our top talent. Best decision we ever made.

Z added to highlight: avoid frequent job changes.

Rolling stone gathers no moss. In and out of codebases before understanding them.

New developer onboarding takes 6+ months to be net positive for team.

Before that, new hire drains resources, onboarding time from peers, codebase navigation, bug fixing help.

Most Employers are Risk Averse

Wrong hire impact is huge.

Developer position fill time ~3 months. Employers:

• Budget approval
• Job description creation
• Job posting, recruiter communication
• Résumé sifting (many low-effort, mass applications)
• Interview process, flights, hotels
• Multi-round interviews
• Final candidate selection, offer negotiation…
• Many offers rejected
• Contract signing, onboarding
• System access, introductions, team integration
• Months of informal training, codebase understanding
• Team workflow immersion

In short, a lot of work.

Then, new hire says, “Higher offer elsewhere, peace out.”

Or unreliable, late arrivals.

Or addiction issues, anger, passive-aggression.

Start process over, search again.

Hiring is hard.

Employers are risk-averse, pass on qualified candidates until 99% sure.

Because Employers are So Risk Averse, Job Seekers Suffer

Hiring is hard, job application process is worse.

• Résumé/CV prep, constant second-guessing.
• Job search online, employer research, good fit assessment.
• Job openings lead to webforms, retyping résumés, server errors, JavaScript validation errors.
• Job application submission, waiting game, employer processing. Google gets 9,000 applications daily. Software filters applications. Recruiters spend 6 seconds per résumé. Many applications unseen by humans.
• No feedback, “We chose other candidates” email if lucky.
• Hours spent applying, unpaid, mentally exhausting.

Nightmare hiring for employers and job seekers.

But persistence lands offers. And when it rains, it pours.

freeCodeCamp contributor’s 12-week job search data:

Offers increased, starting salary rose. San Francisco job market data.

Good interview rate, strong negotiation. Read more about his process.

Easier to get in through side door.

This book’s purpose: avoid front door lines.

If you Build Your Skills, Your Network, and Your Reputation You Can Bypass a Lot of the Job Application Process.

This book teaches techniques to increase “luck” of job offers.

“Luck is preparation meeting opportunity. If you hadn’t been prepared when the opportunity came along, you wouldn’t have been ‘lucky.'” – Oprah Winfrey

Develop skills, network, reputation simultaneously, early on, before job search.

My job story, “lucking” into a job, happens more than you think.

Reality: learning code is hard.

Knowing how to code is important.

Every industry, company, managers automate via software layer.

Developers needed.

Tech layoffs happen, often non-developer roles affected. Developer layoffs too.

Why layoff developers after hiring/training investment? Bankruptcy aside, no clear answer.

Layoffs destroy long-term company value. But CEOs feel investor pressure, follow suit when others layoff.

Even with layoffs, developer job growth expected. US Dept of Labor Statistics projects 15% developer increase in decade.

Job market tight now, downturn likely temporary.

Strong skills, network, reputation help land jobs in challenging market.

Hopefully, easier employer-employee matching, less brutal job application process in future.

What to Expect from the Developer Job Interview Process

Job interviews landed, developer interview process, coding interview dreaded.

Typical interview flow:

1. Online coding assessment/Phone Screen.
2. Phone/video technical interview.
3. “Onsite” interview, company office visit, HR, managers, team member interviews.

Questions test problem-solving, algorithms, data structures, debugging.

Coding problems solved on computer in editor or whiteboard by hand.

Interviewer seeks thought process, not just correct answer.

Fundamentals understanding or memorized solutions?

Algorithm/data structure practice helps, but think aloud, explain thought process while solving.

Practice by talking aloud while coding, live stream coding, “learn in public” on Twitch. Builds reputation too.

Interviewer is watching, evaluating consciously and unconsciously.

Interactive interview. Smile, eye contact. Judge body language. Relaxed? Nodding?

Interviewer likely knows what they want in code. Tease hints out. Open-ended questions aloud, interviewer might step in, feel involved.

Interviewer liking you matters. They might overlook coding shortcomings, errors.

Selling yourself as candidate. Make interviewer feel they’re getting a good deal.

Behavioral Interviews assess “culture fit.” Vague, manager-dependent definition.

Convince interviewer of strong communication skills in Behavioral Interviews.

Fluency, jargon helpful. Tech podcasts like freeCodeCamp Podcast help.

Key interviewer assessment: cool-headed, team player? Polite, no profanity, focused conversation.

Avoid unrelated debates, sports rivalries. Avoid correcting interviewers, even if wrong.

Bad vibes from company? No need to accept offer. Candidates and employers can pass. Interview not time for conflict.

Should I Negotiate My Salary at My First Developer Job?

Negotiating salary upward usually doesn’t hurt, if polite.

How to negotiate developer job offer salary.

Salary negotiation leverage depends on:

Employer needs you to work for them? Other options?

You need income? Other options? Backup plan?

Job offer from another company? Leverage in negotiation.

Backup plan grad school? Not strong leverage, but mentionable.

Employer lengthy hiring process. Expects negotiation, won’t be surprised.

“Out of the blue” job offer like my story, awkward negotiation?

Admit it, didn’t negotiate in my story.

Should I have negotiated? Probably.

Leverage? Probably not much. Backup plan: hackathons, tea, library coding.

Few more bucks an hour possible? Maybe. Ecstatic about being developer, compensation last thought.

After year or so, ask for raise. How to ask for raise as developer. Leverage again.

Should You Use a Recruiter for Your Developer Job Search?

Yes. If recruiter helps land first developer job, use them.

Why recruiters underrated tool.

Employers pay recruiters finder’s fee for good candidates.

Recruiter incentives align with job seeker goals:

1. Paid based on starting salary, helps you negotiate higher salary.
2. More candidates placed, faster placements, more recruiter income. Helps you get job fast.
3. Paid only if you succeed (90-day stay), they ensure competence, good company culture fit.

Red flag: recruiter asking you for payment.

Not all recruiters equal. Research before working with one. Even if employer-paid, your time invested.

Speaking of time, get paid to code sooner – freelance clients.

How to Get Freelance Clients

New developers, get freelance clients before job search. Three reasons:

1. Easier to get freelance client than full-time job.
2. Less risky, freelance without quitting day job.
3. Get paid to code sooner, build professional portfolio sooner.

Freelance clients easier to get than developer jobs. Why?

Small local businesses. Restaurant, shop, plumbing, law firm.

Many need interactive websites, back office systems, workflow automation. Most do.

Many can’t afford full-time developer for systems. Not as many.

Freelancers solve this. Economical, case-by-case work. Freelancer for project or short period.

Active networking can lead to clients.

Accountant needing website update, scheduling, credit card payments. Common small business needs you can implement.

Small business managers needing ERP, CRM, inventory, other systems.

Often, open-source tools can be deployed and configured. Teach them to use system, monthly service fee for on-call support.

Should I Use a Contract for Freelance Work?

Find standard contract template, customize, lawyer approve.

Awkward to contract bakery for website/social media update? No, it makes it professional.

Small businesses unlikely to sue over few thousand dollars. But contract protects you if it happens.

How Much Should I Charge for Freelance Work?

Your day job hourly rate, doubled. Sounds high, but freelance work is harder, lots to learn.

Or bill per project. “System deployment and configuration for $1,000.”

Specify maintenance timeframe. Avoid calls 3 years later for unfixed system.

How Do I Make Sure Freelance Clients Pay Me?

Freelancer approach: half compensation upfront, before work. Half when halfway done.

Full payment before project finish ensures client can’t dangle money for extra work.

Full payment, post-completion help conveys, “Going above and beyond.”

Different vibe than, “Are you even going to pay me?”

Should I Use a Freelance Website like Upwork or Fiverr?

Rural area, no local clients, maybe freelance websites. Otherwise, avoid.

Freelance websites, compete with global freelancers. Lower cost of living cities, some may offer subpar work.

“Race to the bottom” phenomenon, cheapest often gets job.

Local network clients avoid global freelancer competition.

Same for hiring freelancers. In-person meetings, community ties important.

Local, long-term resident, same social circles, less likely to exploit you. Reputation investment for both sides.

Mutual success stories in portfolios.

Freelancing is like running a one-person company. And that means a lot of hidden work.

Freelance “hidden work” underestimated.

Legal entity creation recommended.

US: Limited Liability Company (LLC) for freelance business, even solo.

Tax simplification, personal liability protection from lawsuits. LLC bankruptcy, not personal.

Liability insurance further protects you.

Freelance, pay taxes end of year, save for taxes.

LLC creation, boilerplate online, DIY filing. But lawyer/accountant consultation recommended for setup.

When Should I Stop Freelancing and Start Looking for a Job?

If freelancing pays bills, keep doing it. Build software development agency, hire developers.

If job stability desired, freelance clients might convert to full-time jobs. Client might offer full-time at lower hourly rate for stability.

Keep freelance clients with job. Income supplement. But first developer job is all-consuming, initially.

How wild is first year? Next chapter.

Chapter 5: How to Succeed in Your First Developer Job and Continue to Learn Code

“A ship in port is safe. But that’s not what ships are built for.” – Grace Hopper

First developer job, real learning begins.

Productive teamwork, large legacy codebases navigation.

Version Control Systems, CI/CD, project management tools.

Working under engineering manager. Shipping by deadlines. Ambiguity on job.

Self-management.

Imposter syndrome breakthrough. Knowing limits, pushing slightly beyond them.

Story Time: How did a Teacher in his 30s Succeed in his First Developer Job?

Last time: Quincy got first developer job at startup, one of dozen devs maintaining codebase, clueless…

Woke at 4 a.m., couldn’t sleep, anxiety, panic.

Decade in education, now starting from bottom, developer.

Past learning, success, matter in new career?

Anxiety run. Beach run at sunrise.

Wife leaving for work, “I’ll still love you if you get fired.”

Office empty. Teacher habit, 7:30 sharp arrival. Devs arrive later.

Cross-legged in hallway, coding tutorials on netbook.

Employee nervous, squatter suspicion. Reassured her, convinced her to let me in.

Surreal walk across empty office, dev bullpen, exit sign light.

Set up netbook at standing desk, finished tutorial.

Lights flickered on, boss arrived. No greeting initially, keyboard burst.

“Larson,” he finally said. “Ready for first day?”

Unready, but signal confidence. “I was born ready.”

“Great,” boss said. “Let’s get you a machine.”

“Oh, got one,” netbook tap. “Linux Mint, customized .emacs file…”

“We’re a Mac shop.” Storage closet rustling, emerged with 3-year-old Mac. “Factory default wiped.”

Started to say familiar setup, faster work, but he cut me off.

“Same tools for collaboration. Convention over configuration.”

First time heard “convention over configuration,” but it would be common.

Hours configuring new work Mac as devs arrived.

10 a.m., team standup. Circle by whiteboard. Status updates.

Quick, precise updates.

My turn, introduction, anxiety spiked as Mike, startup event runner, ultrarunner, walked in, baby carrots crunching.

Mike welcomed me, recognized me from events. 15-second status update.

10-minute meeting, everyone back to desks.

Company codebase running on new laptop. Ruby on Rails app, 5 years old. rake stats, millions of lines. Shuddered. Comprehending it impossible.

Neighbor, gruff, bearded dev, “Most packages. Actual codebase ~100,000 lines. You’ll get it.”

“Name’s Nick,” introduced himself. “Need help, ask. Stumbling in this codebase years, can help.”

Days, peppered Nick with questions about internal systems.

Nick started “code mode” chat status, noise-canceling headphones, back swivel, “leave me alone” body language.

Team dynamic lesson. Don’t over-question, learn independently.

Massive codebase, undocumented, sparse wiki, inline comments.

Closed-source, no Stack Overflow help. Feeling in the dark.

Started rotating neighbors for questions, but felt like wearing out welcome.

Over-corrected, shy about asking even simple questions. 2-hour rule before asking for help.

Stuck for hours, asked for help. Manager asked, “Why didn’t you ask sooner?”

Codebase understanding struggle too – “monolith” and microservices.

Thousands of unit and integration tests. New code needed tests to avoid breaking things.

Frequent “build breaks,” code breaking other parts I hadn’t considered. Team frustrated, unable to merge code until fixed.

Build breaks weekly, felt like it was always me.

Days felt like I wasn’t cut out to be a developer. “Who am I kidding? Wake up one day, developer now?”

Echoes of developer friends’ doubts from year prior.

“How compete with childhood coders?”

“Ocean of knowledge.”

“Stick to teaching.”

Longer breaks, snack kitchen trips, delaying crushing feeling of cluelessness.

First months rough. Standups, everyone fast, closing bugs, shipping features. Nothing to say. Still on same feature.

Every morning, dread. “Firing day.”

But everyone kind, patient. Help offered when stuck. Some progress, bug fixes.

Codebase navigation faster, stack trace reading faster. Shipping features faster.

Boss office calls, “Firing time” thought. Just more bugs, features assigned. Phew.

Surreal terror of firing, boss clueless.

Heard “imposter syndrome” before, didn’t realize that’s what it was. “Sucks at coding” syndrome?

Sitting next to Nick, frazzled Nick. Soda offer.

Back with soda, Nick cracked it open, sip, leaned back, code monitor gaze. “This bug, man. Three weeks. Debugging in sleep.”

“Three weeks, same bug?” I asked, never heard of that.

“Some bugs are tougher. This one’s devious.”

Salmon slap across face feeling. Viewed job as chunks of work. Half-day bug fix, longer = failure.

Nick, CS degree, years of experience, stumped for three weeks on one bug.

Maybe too hard on myself. Bugs not “half-day bugs,” but “two- or three-day bugs.” Inexperienced, slow, but maybe unrealistic standards.

Feature time budgets: “5-day features,” “2-week features.” Bug budgets similar, varied.

Went home, read about Imposter Syndrome. Explained anxiety.

Months passed, feature building, team collaboration. Still hard, brain-busting, but easier.

Team bonding at lunch, board games, company chess tournament.

CEO match, unorthodox opening, early lead.

CEO ground back control, won.

Asked CEO chess skills with company running. “Oh, I don’t. Play once or twice a year.”

Pause, hand frozen, lecture starting. “Uncle was competitive chess player. Advice: every opponent move, slow down, understand their perspective – why that move?“

Bow, excused himself for meeting.

Thought about that advice over years. Not just chess. Any adversarial situation.

If You Keep Having to Do a Task, You Should Automate it

Another software development lesson: junior person, grunt work assigned. “Build nanny” task.

Build break, pull main branch, git bisect, identify breaking commit.

Open commit, run tests, figure out issue. Message breaker, fix instructions.

Got fast at this. Day of confusing bugs, feature requests, build breaks welcome. Chance to feel useful quickly.

Soon, teammate said, “Build breaks often, we should automate.”

Defensive feeling. Bad idea, script as good as human build nanny?

Days later, teammate whipped up script. No more build nanny.

Build fail message, then commit breaker and fix instructions message.

Strange, script took my job.

Indignant, “That’s my work. Script took my job.”

Now, looking back, laugh. 40s me, still build nanny?

If task automatable, break down into computer steps, automate it.

More interesting work to do.

Lessons from the Village Elders

Learned much from team. Product design from Mike, beach runs, forefoot running.

Agile software engineering from Nick, book recommendations, house-warming party, kids met.

Year working, time to strike out, online learning projects. CTO resignation.

“Grateful you hired me, weakest dev.”

CEO laugh, “Sure, worst dev when started. Still worst dev.”

Awkward smile, blinking, angry resignation?

“But that’s smart. You’re smart. Always want to be worst musician in the band. Surrounded by better people. That’s how you grow.”

Two weeks later, code changes checked in, tickets handed off, Mac factory reset, manager handoff.

Handshakes, California evening air.

Hit ground running, freelance contracts, Bay Area apartment scouted, across bridge from tech heart, South of Market San Francisco.

Professional developer now, year experience.

New dreams, new moves.

Startup land bound.

Lessons From my First Year as a Developer

Did many things right, B- grade self-assessment.

If redo, some changes.

Tips to maximize learning, minimize heartache.

Leave Your Ego at the Door

Many starting dev career at bottom, “Junior Developer” title.

Awkward middle-aged “junior” title, but patience, hard work gets you past it.

Problem: 10 years professional experience. Not entry-level employee. Teaching, managing people experience.

But, entry-level developer. Novice. Neophyte. Newbie.

Wanted to scream, “Used to be boss, no babysitting needed.” But babysitting needed.

Production break? Security vulnerability? Database wipe? Key loss?

Disasters happen.

New developer, bull in china shop, careful walk, smashing everything.

Don’t be impatient with teammates. Resist past achievement talk.

Not just for teamwork. Distracts from task at hand.

First months, past achievements as pacifier. “Yeah, coding sucks, but English grammar phenomenal. School director, did I mention?”

Fingers on keyboard, eyes on code editor, let past self go. Revel in yesterday’s success tonight.

Now, focus on task, get job done.

It’s Probably Just the Imposter Syndrome Talking

Almost everyone experiences Imposter Syndrome. Feeling out of place, teammates seeing through you.

Feeling never fully goes away. Always in back of mind, ready to surface when doing new things.

“Help with error?” “Not best person to ask.”

“Pair program on feature?” “If no one more qualified.”

“Give conference talk?” “Um… me?”

Senior engineers still experience imposter syndrome, decade+ into career.

Feeling inadequate, unprepared, might be imposter syndrome.

Scalpel in hand, heart surgery ask, imposter feeling justified. Depth out of depth.

Problem: if you’ve practiced coding, you might be capable, yet still anxious.

Not a doctor, but instinct: imposter syndrome diminishes with practice, confidence.

Randomly pops up. Admit it, imposter syndrome pangs in new or infrequent tasks.

Key is to accept it: “Probably imposter syndrome talking.”

And keep going.

Find Your Tribe. But Don’t Fall for Tribalism

First developer job, work with other developers. Tribe found.

Tight unit feeling.

Don’t ignore non-developer people around you.

Mike, Product Manager, startup event runner, “non-technical.” Learned as much from him as anyone.

Designers, product managers, project managers, IT, QA, marketing, finance, accounting. Learn from them too.

Build dev team connections, but stay curious. Lunch room, company events, other department people. Next help source might be unexpected.

Don’t Get Too Comfortable and Specialize too Early

“Learn general coding skills, specialize on job.”

Once common tool understanding, learn less common equivalents.

PostgreSQL, learn MySQL easily. Node.js, learn Ruby on Rails, Java Spring Boot easily.

Some specialize too early at work. “Own” API or feature. Good job, similar projects assigned.

Boss manages many, nuanced understanding of abilities/interests might be lacking. Seen as “XYZ person,” assigned XYZ tasks.

You know your strengths, interests. Volunteer for out-of-comfort-zone projects. Get boss to assign them, expand skills, new teams.

Boss responsible for job performance, you responsible for career performance.

Take projects fulfilling employer and long-term career goals.

Epilogue: You Can Do This

One message to leave you with: you can do this.

You can learn code concepts.

You can learn code tools.

You can become a developer.

Moment someone pays you to code, you graduate to professional developer.

Learning code, first job is daunting. Don’t be daunted.

Persistence leads to success. Practice is key.

Build projects. Show friends. Build for friends.

Build network. Help people you meet. What goes around comes around.

Not too late. Life is long.

Years from now, look back, glad you made the move.

Plan for long time, uncertainty.

Keep returning to keyboard. Keep going to events. Share wins with friends.

Lao Tsu:

“A journey of a thousand miles begins with a single step.”

Finishing this guide, you’ve already taken a step. Many steps already taken.

Momentum is everything. Keep forward momentum built in these hours.

Start next coding project today.

And always remember:

You can do this.