How to Learn to Code and Get a Developer Job: A Practical Guide

If you’re looking to learn coding and land a job as a developer, you’ve come to the right place. This comprehensive guide will show you exactly how to achieve your goals.

Yes, this is the complete guide, available for free right here on learns.edu.vn.

You can also listen to the FREE audiobook version of this guide, available on major podcast platforms. Just search for “learns.edu.vn Podcast” in your favorite podcast app and subscribe for more insightful content.

A few years ago, a major publishing house in New York City contacted me about writing a book. While flattered, I simply didn’t have the time to dedicate to such a project back then.

Now, I finally do. And I’ve decided to publish this book for free, directly on learns.edu.vn.

Because information should be accessible to everyone, right? 🙂

Reading this guide will take a few hours of your time, but it contains everything you need to know about learning to code and securing a developer job.

The insights shared here are based on my experiences:

• Learning to code in my 30s
• Working as a software engineer
• Founding and running learns.edu.vn for the past 8 years. Today, our website serves millions of visitors monthly, offering resources to learn about technology, programming, and computer science.

As a former English teacher with no prior programming experience, I successfully transitioned into software development within a year, without spending money on expensive books or courses.

(I did invest in traveling to tech events, which, as you’ll discover, was a worthwhile investment.)

After several years as a software engineer, I felt compelled to help others make a similar career change.

Initially, I built several educational tools that didn’t gain traction. However, one weekend, I created learns.edu.vn. A thriving community quickly formed around it.

Together, we supported each other, and today, countless individuals worldwide have used learns.edu.vn to prepare for their first tech jobs.

You might be thinking, “I’m not sure I have time to read this entire guide right now.”

No problem at all. Bookmark this page and return to it whenever you have time. You can read it at your own pace, across multiple sessions.

Feel free to 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 finish reading.

I’m not trying to sell you anything here. You’ve already “purchased” this guide by simply opening this page. My goal now is to assure you that investing your time in reading it will be genuinely worthwhile. 😉

I promise to be respectful of your time. You won’t find any hype or fluff here – just straightforward, actionable advice.

I’ve packed as much valuable insight as possible into each section of this guide.

Which leads me to the table of contents:

Table of Contents

Preface: Is This Guide For You?

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

If you seek a career that offers flexibility, high earning potential, and intellectually stimulating problem-solving, software development could be an excellent fit for you.

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

You might be older with family responsibilities, limiting your time.

Or younger with fewer savings or income-boosting skills, limiting your money.

You might live far from major tech hubs or face challenges related to disabilities, age, race, gender, immigration status, or past criminal records, limiting your opportunity.

Learning to code and getting a developer job will present varying levels of difficulty depending on individual circumstances and available resources.

Regardless of your starting point – in terms of time, money, and opportunity – I aim to provide you with practical, actionable guidance.

In short: don’t worry – you’re in the right place.

A Quick Note on Terminology

Throughout this guide, I’ll define any new terms as they appear.

However, a few terms will be used frequently.

I’ll use “programming” and “coding” interchangeably.

“App” will refer to any application, whether it runs on a phone, computer, gaming console, or even a smart appliance.

I’ll also use “software engineer” and “software developer” interchangeably.

While some in the tech world differentiate these terms, in practice, they are often used to describe the same role, especially in the current landscape of software development.

To illustrate this point, consider this quote:

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

Can Anyone Learn to Code?

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

Consider our ancestors on the African savanna – they thrived for millennia without computers. Programming skills are not innate or evolutionarily selected traits. Modern computers emerged only recently in the 1980s, 90s, and 2000s.

While aptitude plays a role, dedication and consistent effort are paramount. Aspiring developers must spend considerable time practicing at the keyboard.

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

I myself experienced frustration and quit multiple times.

However, like others who eventually succeeded, I returned after breaks and tried again.

Learning to code and securing a developer job is challenging, and circumstances can make it even harder for some.

While I acknowledge the challenges of learning to code in my 30s without a formal tech background, I also recognize my privileges:

Growing up middle class in the United States, a fourth-generation American from an English-speaking family, with access to university education, I benefited from intergenerational privilege – a momentum built over generations free from war, famine, or slavery.

Therefore, I’m not here to offer a purely motivational narrative of overcoming extreme adversity.

If you seek inspiration from those who have overcome significant obstacles in their coding journeys, there are many such stories within the developer community.

My aim is not to romanticize software development or paint utopian visions of the future.

Instead, I want to provide practical, actionable advice on acquiring coding skills and landing a well-paying job to support yourself and your family.

There’s no shame in learning to code for job security and financial stability.

Nor is there anything wrong with learning to code to launch a business.

You may encounter people who insist that true coders must be obsessively passionate, dreaming about code and spending weekends contributing to open-source projects.

While such passionate individuals exist, many developers simply want to enjoy their free time after a week’s work, pursuing hobbies or spending time with loved ones.

Passion for coding often develops as you become more proficient.

In short, this guide is for anyone serious about learning to code and securing a developer job.

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

If you are committed to learning to code well enough to get paid for it, this guide is for you.

Start by reading the executive summary below, and then dive into the rest of the guide.

500-Word Executive Summary

Learning to code is difficult. Getting a software developer job is even harder. But for many, the rewards are worth the effort.

Coding is a high-paying, intellectually stimulating, and creatively fulfilling field. It offers a clear career path: Senior Developer, Tech Lead, Engineering Manager, CTO, and even CEO.

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

If you worry about job automation, consider this: coding is the very act of automation. It’s inherently one of the last careers to be fully automated.

Automation will impact coding, and it already has for decades.

Generative AI tools like GPT-4 and Copilot are shifting programming from Imperative Programming – giving computers step-by-step instructions – towards Declarative Programming – defining high-level objectives, closer to Star Trek-style programming.

Just as calculators didn’t eliminate the need to learn math, AI coding tools won’t replace the need to learn programming.

Convinced about coding as a career path?

Great. Here’s how to break into the field:

Build Your Skills

Focus on learning these core technologies:

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

These are mature technologies, all over 20 years old. You’ll likely use most of them regardless of your employer.

The best way to learn is by building projects. Code daily, even if just for a short time. Following the freeCodeCamp curriculum from start to finish will teach you these technologies and guide you through building dozens of projects.

Build Your Network

Networking is crucial for job success.

Even if you’re an introvert, 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.

Approach people standing alone. Listen more than you talk. Remember names.

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

Build Your Reputation

Share short video demos of your projects online.

Seek opportunities to speak at conferences, starting small and aiming for larger events.

Spend time at hackerspaces and help those newer to coding than yourself.

Contribute to open source projects – the work is similar to professional software development.

Build Skills, Network, and Reputation simultaneously. Don’t postpone the challenging aspects.

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

Keep interviewing until you receive job offers. Be patient and don’t feel pressured to accept the first offer.

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

The real learning begins on the job, working with a team and navigating large, existing codebases.

Prioritize sleep and exercise.

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

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

Remember: you can do this.

This Guide is Dedicated to the Global learns.edu.vn Community.

Thank you to everyone who has supported our mission over the past 9 years through volunteerism and philanthropy.

Your contributions have enabled us to help countless individuals learn to code and begin their developer careers.

The community has grown immensely since I launched the open-source project in 2014. I am now just one part of this global movement.

It is 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. While universal coding literacy may not be achieved in my lifetime, we can continue to democratize technology literacy through free, open learning resources, much like the Gutenberg Bible accelerated general literacy in 1455.

Thank you again.

Special thanks to reviewers and editors who helped refine this guide.

And now, let’s begin.

Chapter 1: How to Build Your Skills

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

The journey to mastering code is a long one.

For me, it was filled with uncertainty.

But your path can be smoother.

In this chapter, I’ll share strategies to make your coding education as efficient as possible.

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

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

Finally, I’ll show you How To Learn To Code more effectively than I did.

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

I was managing an English language school with around 100 adult students from across the globe, all preparing for graduate studies in California.

Our teachers were passionate about teaching, loved interacting with students, and enjoyed helping them improve their English conversation skills.

However, they disliked paperwork: attendance reports, grade submissions, immigration forms.

I wanted to free up our teachers to spend more time with students and less time on administrative tasks.

But what did I know about computers?

Programming? Wasn’t that for geniuses? I struggled to set up a Wi-Fi router and was terrible at math.

One day, I decided to put aside these doubts and try. “What do I have to lose?” I thought.

I started Googling questions like “how to automatically click through websites” and “how to import data from websites into Excel.”

Unknowingly, I was beginning to learn workflow automation.

My learning journey began with Excel macros. Then, I discovered AutoHotKey, a tool that allowed me to program mouse movements to specific screen coordinates, automate clicks, copy text, and paste it elsewhere.

After weeks of fumbling in the dark, I managed to automate a few tasks. I could run a script to open an Excel spreadsheet and a website, and 10 minutes later, the spreadsheet would be populated with data.

It was amateurish, a “dirty hack” as developers might say, but it worked.

I used my newfound automation skills to further streamline school operations.

Soon, teachers barely had to touch computers. My basic scripts were doing the work of several staff members.

This had a significant positive impact on the school. We freed up countless hours previously spent on repetitive computer tasks.

Teachers were happier, spending more time with students.

Students were happier and recommended our school to friends back home.

We quickly became one of the most successful schools in the system.

This success fueled my confidence. “Maybe I can learn to code,” I thought.

I knew software engineers from my board game nights, who had traditional computer science backgrounds from prestigious universities.

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

I gathered the courage to share my aspirations with these friends.

I wanted to learn proper programming, to write code professionally, and perhaps even create software for schools.

I shared my dreams: “I want to do what you do.”

Their responses were often discouraging:

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

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

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

These comments often derailed me for weeks. I’d take long, contemplative walks, wondering about my future. Were they right? They must know better, right?

But each morning, I’d return to my desk, watch my scripts run, and see my computer perform tasks at superhuman speed.

A thought occurred to me: perhaps they were trying to protect me from disappointment. Maybe they simply didn’t know anyone who learned to code in their 30s and believed it was impossible.

It’s like how doctors once thought running a mile in under four minutes was physically impossible, fearing heart explosion.

Then Roger Bannister, a 25-year-old Oxford student, broke that barrier, and suddenly many others followed. Over 1,000 people have since run a sub-4-minute mile.

My goal wasn’t as audacious as a 4-minute mile. Many famous developers had taught themselves coding over the years.

Ada Lovelace taught herself programming in the 1840s, without even a working computer, understanding only the theoretical concept of Charles Babbage’s machine.

She wrote some of the first computer algorithms and is considered the world’s first programmer. No one taught her; there was no one to teach her. Whatever self-doubt she faced, she overcame it.

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

I cracked my knuckles and decided: I was going to do this.

Stuck in Tutorial Hell

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

I spent weeks Googling and following random online tutorials.

“Oh, a Ruby tutorial.”

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

“Oh look, a Python tutorial.”

Human psychology is funny. When things get tough, we question our approach.

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

Facing cryptic error messages hours into coding, the grass always looks greener elsewhere.

It was easy to feel productive. “Lunch time!”

Meeting a friend at a cafe: “How’s coding going?”

“Great! Coded 4 hours today.”

“Awesome, show me what you’re building sometime.”

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

Maybe I’d get a new JavaScript book from the library.

Buying books feels good – it feels like buying the time to read them.

Weeks into learning, I was in this cycle.

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

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

Unknowingly, I was trapped in “tutorial hell.”

Tutorial hell is jumping from tutorial to tutorial, relearning basics, never progressing beyond fundamentals.

Moving beyond fundamentals requires real work.

It Takes a Village to Raise a Coder

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

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

I discovered a “hackerspace” nearby. The name sounded intimidating. Hackers do illegal things, right? I was an English teacher, not a troublemaker.

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

“Hack” has multiple meanings. Yes, it can mean malicious system intrusion. But it also means writing code.

“Hacky” can describe an inelegant solution. Yet, a “clever hack” is an ingenious trick for efficient code.

“Don’t fear ‘hack’,” Steve said.

I rarely use the term due to its confusion. Many hackerspaces now call themselves “makerspaces.”

A hackerspace is about making things.

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

The Santa Barbara Hackerspace was mind-blowing.

It smelled faintly of burnt electronics. Tables were cluttered with soldering irons, LED strips, Arduino boards, and disassembled Roomba robots.

Steve, with glasses, slicked-back hair, and a goatee, greeted me warmly. He always smiled and paused thoughtfully before answering questions.

A passionate Python programmer with a math and philosophy background from UCSB, Steve gave a “lightning talk,” demoing an app recognizing QR codes in videos and replacing them with images.

Someone held a QR code to the camera; Steve’s app replaced it with a pizza.

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

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

It was sorcery to me. He’d built that app in hours and was now adding features on the fly.

“This guy is a genius,” I thought.

Afterward, Steve and I stayed late, eating sandwiches. I confessed, “I could code my whole career and not be as good as you. I’d be thrilled to code half as well in 10 years.”

Steve pushed back, “I’m nothing special. Don’t limit yourself. With dedication, you could surpass me.”

I didn’t believe him, but his belief in me gave me a thrill.

A developer believed in me, a random teacher, a “script kiddie.” He thought I could make it.

We talked late into the night. He showed me his $200 netbook, underpowered even for 2011.

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

I noted his laptop model and ordered the same that night.

After days debugging with Stack Overflow, I installed Ubuntu and Emacs. The next Saturday, I showed off my basic commands.

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

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

Steve looked thoughtful. “Cool, but you need a project. Always have a project. Learn what you need to finish it.”

I’d never finished anything beyond school scripts. But I started to understand.

Tutorial hell, going in circles, finishing nothing.

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

Terrified, I straightened up and said, “Sounds like a plan. I’m on it.”

Nobody Can Make You a Developer But You

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

Next morning, I woke up early and Googled “HTML5 tutorial.” I knew some of it from tutorial hell, but slowed down, typed every command.

Usually, I’d jump to another tutorial after finishing one. This time, I played with the code, envisioning a project: an HTML5 documentation page, purely in HTML5.

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

HTML is the bones of a website; JavaScript is the muscles, CSS the skin.

I knew HTML IDs could link to page sections. I envisioned a sidebar table of contents; clicking items would scroll to those sections.

Within 30 minutes, I had a rough prototype.

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

Racing home, I coded all evening.

I copied official, Creative Commons-licensed HTML documentation into my page, “hardcoding” it into HTML.

I spent an hour on CSS, perfecting the look, using absolute positioning for the sidebar.

I deliberately used as many new HTML5 semantic tags as possible.

Project finished.

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

I decided then and there: everything I do will be project-based, working towards a finished product.

Next evening, I presented my HTML5 webpage. I answered questions about HTML5.

Sometimes I was wrong; someone would correct me, “That doesn’t sound right, let’s check the docs.”

Corrections felt supportive, like refining public knowledge, not personal criticism.

I felt like part of the audience, learning together.

These were new tools; we were all figuring them out.

After my talk, Steve said, “Not bad.”

I smiled, wordless, happy.

Steve squinted, “Start your next project tonight.”

Lessons from my Coding Journey

We’ll revisit young Quincy’s journey in later chapters. Now, let’s analyze the lessons and address your potential questions.

Why is Learning to Code so Hard?

Learning any new skill is hard – soccer, car maintenance, new languages.

Coding is particularly hard for specific reasons, some unique to it.

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

What is coding?

Coding is instructing a computer in a language it understands.

That’s it. Simple, yet complex.

Communicating with computers is hard. They are “dumb” by human standards, doing exactly what you tell them, but often not what you want them to do unless you code precisely.

What about servers, databases, networks?

All controlled by software – code all the way down to hardware moving electrons.

Early coding was “close to the metal,” manipulating hardware directly.

Modern software uses “layers of abstraction” – programs on top of programs – enabling powerful actions with few JavaScript lines.

1960s “bugs” were insects frying circuits in room-sized computers.

Today, we code layers above hardware.

Coding is easier than ever and getting easier yearly.

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

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

Three main reasons coding remains difficult:

1. Primitive Tools: Coding tools are still evolving.
2. Ambiguity Intolerance: Coding is ambiguous; most struggle with this uncertainty and get lost.
3. Negative Feedback Aversion: Constant error messages are brutal; most get frustrated.

Let’s explore each difficulty 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

This is future programming from Star Trek.

Everyone in Star Trek can code – doctors, security, pilots, even Wesley Crusher.

Partly due to a 24th-century post-scarcity society with free education.

Mostly because future coding is much easier – just precisely tell the computer what to do, and it does it.

Imagine programming as easy as speaking instructions in plain English.

We’ve made progress. Consider our grandmothers with punchcard-based mainframes.

Early programming, even simple apps required meticulous instructions.

Example: Caesar Cipher (ROT-13), a classic CS homework project.

First, x86 Assembly:

format ELF executable 3
entry start

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

  cmp   eax, 0          ; EOF?
  jz    exit

  xor   eax, eax        ; load read char to eax
  mov   al, [buf]

  cmp   eax, "A"        ; see if it is in ascii a-z or A-Z
  jl    print
  cmp   eax, "z"
  jg    print

  cmp   eax, "Z"
  jle   rotup
  cmp   eax, "a"
  jge   rotlow
  jmp   print

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

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

rotend:
  mov   [buf], dl

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

  jmp   start

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

From Rosetta Code (Creative Commons).

Now, Python version:

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, easier to read, right?

Python from GPT-4, prompted like Captain Picard to the ship’s computer: “Computer. New program. Take each letter of the word I say and replace it with the letter that appears 13 positions later in the English alphabet. Then read the result back to me. The word is Banana.”

GPT-4 produced Python code, and output: “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, like early human tools evolving from stone to bronze to iron, but faster.

We’re in the programming Bronze Age, perhaps reaching the Iron Age soon. Generative AI like GPT is rapidly improving.

Developer community is divided on GPT’s usefulness.

Some “entrepreneur influencers” claim: “ChatGPT writes code, no need to learn coding. Just have an app idea!”

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

Reality is likely in between.

YouTube shows people using ChatGPT to generate app code. Some even wire it into working apps.

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

Yet, many developers doubt their ultimate utility, questioning AI “hallucinations” and interpretability.

“Interpretability” is key – understanding AI black boxes like GPT-4 may take decades. Until then, double-check AI code, expect bugs and security flaws.

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

Many drive cars, fewer repair them, and fewer design them from scratch.

For powerful, secure software systems solving new problems, you still need to code properly.

Meaning navigating ambiguity.

Learning to Code is an Ambiguous Process

Learning to code brings constant self-doubt: “Am I learning effectively? Right tools? Are these resources credible?”

Ambiguity clouds every session. “Is my test failing because the tutorial is outdated, framework changes, or my mistake?”

Tutorial hell and “grass is greener” syndrome worsen 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.

Coding is unique; your app might be unprecedented.

Problems may be unique, no help available.

15% of daily Google queries are new. Bad news if you’re one of those.

Developers often solve problems and move on, undocumented. You might reinvent solutions others already created, undocumented.

Then there are old forums and StackOverflow pages.

How Not to Get Lost When Learning to Code

Good news: both competence and confidence grow with practice.

Soon, you’ll google effectively, understand documentation structures, and know where to ask questions.

No simple ambiguity solution, just acceptance. Coding is ambiguous, even for experts.

Coding is rare: you rarely reuse exact solutions infinitely.

As a developer, you’re always doing something new.

Software development isn’t just typing code, it’s continuous learning.

You’ll spend much time thinking, experimenting, and in meetings – understanding problems to create solutions.

Embrace ambiguity, and you’ll go far.

Learning to Code is One Error Message After Another

Many learners hit a wall, progress slower than expected.

Reason: programming feedback is much tighter than in other fields.

In schools, feedback comes sparsely – assignments graded over semesters.

“Bombed that exam, need to study harder.”

Bad grades ruin days. That’s typical feedback.

Coding feedback is rapid. Computers execute code in milliseconds.

Most code crashes.

If lucky, you get an error message.

If really lucky, a “stack trace” – error details and line number.

This constant, direct negative feedback is tough.

Imagine teachers returning every paper instantly with a big red “F.” Over and over.

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

How Not to Get Frustrated

Key is practice.

You’ll develop tolerance for vague errors and stack traces.

Coding is never harder than at the start.

You’re inexperienced and unaccustomed to impersonal, rapid, negative feedback.

Here are tips:

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

Everyone learning to code struggles with computer communication frustration.

Some started coding young, acting like they’ve always been good. But they also struggled, forgetting early frustrations.

Think of the computer as a friend, not an adversary, asking for clarity.

Tip #2: Breathe.

Natural reaction to errors is frustration, then blindly changing code, hoping for luck.

This doesn’t work, the universe and software are complex. You can’t “Forest Gump” your way to success.

Infinite Monkey Theorem: Chimps typing randomly, how long to type “to be or not to be”?

Likely 1 quintillion years.

Don’t be a chimp. Blindly trying things won’t work.

In that time, you could teach chimps English and have them type Hamlet, not just one line.

Even if lucky and you bypass the bug, what did you learn?

Understand the code, what’s happening, then fix the error.

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

Slow down, breathe, stretch, get a drink.

Your future self will thank you for making it a learning moment.

Tip #3: Use Rubber Duck Debugging

Get a rubber duck, place it by your computer. When errors occur, explain the problem to the duck.

Silly? Yes. Helpful? Yes.

Rubber Duck Debugging slows you down, forces you to articulate the problem.

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

Verbalizing your thinking aids processing.

How do Most People Learn to Code?

Let’s discuss traditional paths to a first developer job.

Why care what others do? You do you.

However, self-doubt and the “path not taken” might cause anxiety.

This section aims to ease those anxieties.

The Importance of Computer Science Degrees

University degrees, especially CS bachelor’s, remain the gold standard for developer careers.

“But I don’t have a CS degree.” No worries. You don’t need one to be a developer.

However, their usefulness is undeniable. Why?

“Why study CS for development?” you might ask. After all:

“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 traditionally in math departments, or extensions of electrical engineering.

Most universities now recognize CS as a crucial field.

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

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

CS degrees can lead to high-paying entry-level jobs. Why?

How Employers Think About Bachelor’s Degrees

Some tech employers say “bachelor’s degree not required.” Google, Apple, etc.

True. freeCodeCamp alumni get jobs there without degrees.

But those alumni are exceptional to overcome not having a degree.

Job openings have criteria:

1. Work experience
2. Education
3. Portfolio and projects
4. Recommendations from company insiders (network, Chapter 2)
5. Reputation (Chapter 3)

For “degree-optional” employers, education is one of several factors. Stronger in other areas? You might get interviewed without a degree.

But a bachelor’s still makes getting interviews easier, even at “degree-optional” companies.

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

“A bachelor’s is a bachelor’s,” I often say. For most purposes, it is.

Officer in US military? Bachelor’s needed, any major.

Work visa abroad? Likely bachelor’s needed, any major.

Many “bachelor’s required” jobs accept any major.

Why? Subject less important than finishing university.

Employers seek those who can complete this rite of passage.

Bottom of the class, repeating courses, on probation? Degree is still a degree.

Last in medical school? Still “Doctor.”

Same for many employers. HR checks the “degree” box. Filters out non-degree applicants. They might never see non-degree applications.

Not all employers, but many, especially in the US and more so elsewhere.

Labor market reality. May change, may not.

Why I encourage teens and 20s to consider bachelor’s degrees.

Not for:

• Education itself (online courses from top universities are free).
• “College experience” (most US students don’t live on campus).
• “Well-rounded individual” (Freshman 15 is a joke, but stress causes weight gain).

Real value of a bachelor’s – why Americans pay $100k+ – is employer requirement.

Other benefits: military officer options, work visas.

And for doctor, dentist, lawyer, professor – bachelor’s is needed for grad school.

OK, lots of background. Let’s answer bluntly.

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

No. Many employers hire without bachelor’s degrees.

A bachelor’s makes interviews easier and may lead to higher salary.

What About Associate’s Degrees? Are Those Valuable?

In theory, yes. Some tech fields may require associates. It always increases interview chances.

But I don’t recommend aiming for just an associate’s. Pursue a bachelor’s – vastly more valuable.

US Department of Education: bachelor’s earners make 31% more than associate’s earners over their career.

Difference is likely wider with a 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?

In your 30s, maybe some college, maybe an associate’s.

Does “going back to school” make sense?

Yes, possibly.

But quitting your job for full-time school? No.

Full-time student lifestyle is for “traditional” students – 18-22, no prior workforce beyond summer jobs.

Traditional universities are costly, assuming students pay via scholarships, family funds, and loans.

Working adults have less access to these, and less time than recent high school grads.

But don’t give up on a bachelor’s.

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

Local community colleges or state university extensions also offer degrees, often online and self-paced.

Research. If promising, find alumni on LinkedIn, ask about their experience, and if it was worthwhile.

Avoid debt for your degree. Cheaper schools are better. Degree is a degree. Accredited institution is usually sufficient.

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

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

Any bachelor’s – even non-STEM – already provides most of the value of university.

What About a Master’s of Computer Science Degree?

Helpful for career advancement, but pursue later, after working as a developer.

Many employers fund continuing education.

Georgia Tech’s online Master’s in CS is popular and affordable.

But focus on getting a developer job first. (Job search in later chapters).

Will Degrees Continue to Matter in the Future?

Yes, university degrees will likely matter for decades, possibly centuries.

Universities have existed for over 1,000 years.

Top US universities are older than the USA itself (Harvard is 400+ years old).

University degree’s death is exaggerated.

Bashing universities is popular, claiming degrees are useless.

Statistics show otherwise. They impact lifetime earnings and open safer, more stable, fulfilling careers.

Sure, offshore deckhand work pays well, but so does climate-controlled office developer work.

One dangerous, backbreaking; the other, a 40-year career.

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

“Useless” degree idea stems from untangling learning from status boost.

Is university just class signaling? Wealthy passing advantage to kids? Harvard has 3x more rich kids than poor kids.

Life is unfair. But labor market rules exist.

Choose easy mode – degree, more options.

Or hard mode – save time, money, be selective in employers.

Both approaches lead to success for many.

What Alternatives are There to a University Degree?

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

Certification programs and bootcamps exist, but lack employer weight and rigor.

Note: “Certification programs” are courses with certifications. Limited value. Exam-based certifications from Amazon, Microsoft are valuable (later discussion).

“Degree or not to degree – that is the question.”

Mechanics, electricians, tradespeople without bachelor’s learn skills, work jobs.

Bookkeepers, paralegals, “knowledge workers” without bachelor’s learn skills, work jobs.

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

Some always wanted a bachelor’s. Good reason to pursue.

Not for everyone.

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

Bootcamps/certifications offer structure, peer pressure. Useful, but worth thousands?

How to Teach Yourself to Code

Most developers are self-taught. Even CS degree holders self-identify as “self-taught” in surveys.

Learning to code is lifelong – new tools, legacy codebases, problems constantly emerge.

Formal education or not, self-teaching is crucial.

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

“Self-taught” means self-directed learning – outside formal education.

Few are truly “self-taught” in anything. Newton “self-taught” calculus because no books existed – he invented it.

Lovelace “self-taught” programming because it didn’t exist – she invented it.

Someone might argue, “Not self-taught if you use books/courses. You had teachers.” Technically true, narrowly.

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

Point them to this section, “Quincy anticipated your snobbery,” and move on.

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

What is Self-Directed Learning?

Self-learners curate their resources, choose what and where to learn. That’s self-directed learning.

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

Community.

Learner communities worldwide help each other expand skills.

Community is broad – Tech Twitter? freeCodeCamp forum? Discord groups? Subreddits?

Yes, all are communities if people help each other.

In-person events too? Ruby meetups? Startup events? Linux User Groups?

Online, in-person, or hybrid communities.

Community in “Build Your Network” chapter. Key takeaway: community friends help narrow learning options and resources.

What Programming Language Should I Learn First?

Short answer: doesn’t matter much. Second language is easier after learning one.

Different language types exist, but most development uses “high-level scripting languages” like JavaScript and Python. They trade efficiency of “low-level languages” like C for ease of use.

Modern computers are billions of times faster than in 70s/80s (C era). Scripting language inefficiency is negligible.

JavaScript and Python are written in C and improving yearly due to open-source communities.

Python excels in scientific computing (Data Science, Machine Learning).

JavaScript is the ultimate Swiss Army Knife language, powering the web.

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

You could code your entire career in JavaScript, no second language needed. (Though Python and others are beneficial later).

Start with JavaScript. Easier than Java, C++, easier to learn, more job openings.

Also learn HTML and CSS. Webpage as a body: HTML bones, CSS skin, JavaScript muscles (interactivity).

HTML/CSS basics in an afternoon. Easy to learn, hard to master.

Learn Linux. Powers most servers. Career spent in Linux command line.

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

Windows users: install WSL (Windows Subsystem for Linux) to run Linux commands. Dual booting Windows and Linux is also an option.

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

No OS license fees ever again. Red Hat, a billion-dollar company, supports Linux servers for companies.

Learn Git. Version Control System for team code coordination.

GitHub: website for open-source collaboration, extends Git features (“Build Your Reputation” chapter).

Learn SQL and relational databases – information economy workhorses.

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

Learn web servers, starting with Node.js and Express.js.

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

Other tools: React, NGINX, Docker, testing libraries – learn later.

90% of pre-job learning time on:

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

These skills build most web/mobile apps, qualify you for most entry-level jobs. (Job descriptions list other tools, we’ll discuss later).

Great, how to learn these?

Where do I learn how to code?

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

freeCodeCamp core curriculum. Learn:

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

Thousands got jobs via this curriculum, without quitting jobs, loans, or much risk beyond time on nights and weekends.

freeCodeCamp is the default path for many self-learners.

Your “home base” for learning, branching out as needed. Learn core job skills, dabble in interests.

Decades of books and courses available at libraries or subscription services (library access may be free).

freeCodeCamp has ~1,000 free full-length courses – AWS certs, mobile apps, Kali Linux.

Never been easier to self-teach programming.

Building Your Skills is a Life-Long Endeavor

We discussed self-teaching, alternatives (degrees), and starting tools.

Now, shift gears to the second leg: building your network.

Chapter 2: How to Build Your Network

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

“Networking.” Might cringe at the word.

Networking might evoke awkward job fairs, stuffy suits, resume pushing.

Alcohol-fueled parties, pretending to care about sports.

LinkedIn birthday wishes to strangers, liking updates for attention.

Networking doesn’t have to be like that.

I’ll share my networking lessons, building trust, and staying top-of-mind.

It’s about helping people, being useful.

I’ll show you how to build a robust, long-term personal network.

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

Last time: Quincy learned coding, built projects, and networked at the hackerspace. He just finished his first tech talk…

OK, basic coding skills, paper bag escape capable.

What’s next? Total tech outsider still.

But not new to work. Decade teaching, slinging knowledge. Now, slinging code.

I knew work truth: it’s who you know.

Power of networks. Opportunity path goes through gatekeepers.

Hiring manager approval was all that stood between me and a developer job.

Tech culture was new to me.

Academic culture is formal.

Suits, academic jargon, university name-dropping, TA mentions, journal publications.

Different career paths, conferences, power structures.

I didn’t immediately appreciate this.

First tech events, I wore a suit.

Resumes in pocket, business cards ready. Anodized aluminum, laser-etched with name, email, and John Dewey quote:

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

Still my favorite quote.

But too much. Red aluminum business card? Metal detector warning?

Trying too hard, obvious to everyone.

Meetup.com, RSVP’d to every developer event. Santa Barbara small, but LA nearby. Drove to events there too.

Quickly wised up, suit to jeans and hoodie. No business cards.

Took cues from hackerspace devs: passionate, understated, reserved enthusiasm.

Read books on developer culture.

Coders at Work (1980s).

Hackers: Heroes of the Revolution (1990s).

Mr. Robot TV series (contemporary). Extreme characters, but captures developer mindset.

Soon, talked less teacher-like, more developer-like. Less awkward.

Weekly tech events. Favorite: Santa Barbara Startup Night. Devs pitched prototypes, some got angel funding.

Mike ran it, knew every Santa Barbara dev and entrepreneur.

Finally introduced myself to Mike, star-struck. Ultramarathoner, low 40s heartbeat, perfect hair/beard. Coolest guy. Product manager, non-technical but respected by everyone.

Watched Mike interact with devs. I was almost “non-technical” myself, coding only months.

Old habits crept in. Show off temptation.

Developers modest about skills. “I dabble in Python.” Insecure me: “Python expert here, code in my sleep.”

Then google them, core Python library contributor. Kick myself.

Learned: no boasting. Person you’re talking to is likely better than you. Most won’t say it.

Nothing worse than showing off code and getting peppered with unanswerable questions.

First months of events, humbling. But energizing.

People recognized me. “Keep seeing you. Name again?”

Dev: “Let’s Twitter follow.” Twitter account set up reluctantly. 140 characters? Gimmicky. Barely tweeted. But followed back.

Refined online presence. LinkedIn less formal, more friendly. Looked at other devs’ online presence.

Months later, knew people in many fields:

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

Peers most important? Least helpful for jobs, right?

Secret: hiring manager hires good dev, asks: “Where find more like you?”

Peers are crucial network. Freelance/job interview opportunities came from coding peers.

Came up together, brothers/sisters in arms. Tightest bonds.

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

More on that in next chapter. Now, building your network.

Is it Really Who You Know?

Expression: success “less what you know, more who you know.”

Reality: both.

Connections help land jobs, but skills needed to succeed.

Assume you’re building skills (Chapter 1 advice). When to network?

Best time: yesterday.

You already have a network, smaller than desired, but you do know people.

Hometown friends, parents’ colleagues – anyone from your past might help.

Step one: inventory people you know. No outreach yet, strategize first.

First, inventory everyone you know.

How to Build a Personal Network Board

Create a person list. Spreadsheet or CRM overkill.

Kanban board (Trello, free) recommended.

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

Labels to classify: “Childhood friend,” “Family friend,” “Former colleague,” “Classmate,” “Tech Events.”

Create cards. Name, photo optional.

Trello board example: Teenage Mutant Ninja Turtles characters.

Social media, yearbooks – add people.

Many won’t be helpful, but be comprehensive. “Oh, so-and-so at XYZ Corp, reach out.”

Days to complete. Investment. Use board career-long.

“LinkedIn enough?” LinkedIn is blunt. Maximize signal, minimize noise. Dedicated board better.

Label people, research each. What are they doing? Jobs? Companies?

Add notes. Fundraiser run? Grandma’s 90th? Seemingly extraneous, but important to them if shared on social media.

Be interested in people, their lives, aspirations. Understand motivations, goals, how you can help.

Best way to build alliances: help people. More on this soon.

For each person, worth reaching out? “To contact” or “don’t contact yet.”

“Don’t contact yet“? Never know when knowing someone helps. Never take friendships/acquaintances for granted.

Board filled, labeled, sorted? Outreach ready.

How to Prepare for Network Outreach

Keep it simple.

People are busy, remember only so much about you. Boil down who you are. Personal bio.

How to Write a Personal Bio for Social Media

Consistent presence across social media.

My bio:

“I’m Quincy. Teacher at learns.edu.vn. Dallas, Texas. I help you learn to code.”

Write yours, under 100 characters, avoid jargon.

Hard to distill identity? Important process.

People busy. No life story needed. As you know them better, reveal more. As they ask, they learn more.

Good photo of smiling face needed.

How to Make a Social Media Headshot

If you can, hire a photographer. Or a photographer friend.

I took mine with MacOS Photobooth, friend fixed background/shading in Photoshop, whitened teeth slightly.

Smile with eyes, genuine, not robotic. Think funny thoughts.

Many shots, different angles, choose best.

Use photo resembling daily look, not heavily photoshopped. Recognize you at events. Approachable, not intimidatingly beautiful.

No sunglasses, trying too hard to be cool. Friendly, approachable. Acid test: lost, would you ask this person for directions?

Chosen headshot? Use everywhere. Social media, personal website, email profile.

Use same photo for years. Changing it risks people not recognizing you. Subtle changes throw off familiarity.

Keep high-def version. For conference promos, podcast guest spots. (You’ll get there).

How to Reach Out to People from your Past

Bio and photos ready? Start talking.

15 years ago, phone calls over messages. Culture changed. Most dislike phone calls.

No coffee/lunch invites initially. 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 being known, liked, recognized for their work and lives.

Birthdays bring recognition. “Happy birthday” texts, posts, calls.

What about other 364 days? Recognition appreciated then too.

Simple way to recognize people.

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

Step 2: Think of something to brighten their day.

Step 3: Choose recent social media platform. Direct message.

Template, never verbatim, recipient will Google it, goodwill lost.

Out-of-blue message template:

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

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

Mean it.

Really want them recognized, brighten their day, encourage their goals.

Humans detect insincerity. Don’t oversell, no “this person wants something from me” vibe.

Be brief. Respect time. No long letters requiring lengthy responses.

People are busy.

How to Build Even Deeper Connections

People are busy, see strangers as what they do for them:

• Bus driver
• Barista
• HR person
• Playlist creator
• Helpful email sender

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

Not true for close friends/family.

But for casual encounters, that’s likely how they see you.

Give people reason to care about you, inspire them to learn more.

Before close friend status, be helpful.

Build deeper relationships by offering help.

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

Reach out because you offer something.

You have powerful skills, bending machines to your will. You’re a programmer.

Or becoming one.

Good pretext for outreach.

“Cold call” – calling strangers to sell something. Hard, most calls end quickly.

More info you know, warmer the call, higher success chance.

You’re not selling, not calling, direct messaging.

Platform: Twitter, LinkedIn, Discord, Reddit – wherever. Single paragraph message.

Strongest opening move – offering help.

Template, rewrite in your voice:

“Hey [name], congrats on [new job/promotion/new baby]. Learning programming, building 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. Automated messages disregarded quickly.

Manual messages, no automation. Better slow, personalized messages than mail-merges.

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

“Hey Larson.” Military school vibe?

LinkedIn emoji names – automated message indicator.

“Hi 🍜Sarah, new job?” Bulk message.

Template doesn’t say “school together,” unless recent meeting.

Why? Reminding people how you know each other prompts: “Barely know this person.”

How to Keep the Conversation Going

Goal: response, start back-and-forth.

Messaging platforms casual. Keep it casual.

Short, snappy messages. No chore to reply.

Once they reply, note facts on Personal Network Board.

Maybe they have app/tool idea. Ask questions. Build it for them.

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

Shows you’re serious. New experience for most.

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

Go with conversation flow. Fizzles out? No problem. Resume later.

Social media DMs, message log is there. Next message, they scroll up, “Oh, app offer person.” No “who are you again?” awkwardness.

Keep casual, upbeat. Conversation slow? No problem. Dozens of conversations going. Busy bee networking.

How to Meet New People and Expand Your Personal Network

Reaching out to existing connections discussed.

How to make new connections?

Hard, but tips to ease process.

In-person meetings are more powerful than online.

In-person memory cues:

• Appearance, posture, movement
• Voice, speech
• Venue’s lights, sounds, smells, temperature
• Details baked into memory

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

Get out to local events.

How to Meet People at Local Events Around Town

Which events? Densely populated city, many options. Tech events weekly, minimal commute.

Small town, local gatherings. Book fairs, ice cream socials, sports.

Church, mosque, temple? Get to know people there too.

“Soccer game bleachers person? Help with developer job?”

Maybe. Maybe not. Don’t write people off.

Small business owner?

School friend VP of Engineering at Fortune 500?

Maybe a software engineer too. Millions of us out there, not all in Silicon Valley. 😉

First meeting, don’t immediately “LinkedIn connect.”

Play it cool. Introduce yourself.

Remember name. Names build relationships. Practice if bad at names. Remember minor TV/movie characters’ names.

Forget name? Don’t guess. “Name again?” Remember it second time.

Shake hands or fist bump. Natural conversation. Conversation ends? No worries.

Relationships build over time. Not total time spent, but number of encounters over time.

Likely see them again. Same place weeks later. That’s when you move:

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

Pick up conversation. If helpful network addition, ask: “Doing anything next [day]? Join me at [upcoming event]?”

Always have upcoming week’s events in mind for invites.

Safe, public hangouts. Value provided – event awareness.

Interested? “Awesome. Best way to message event details?”

Boom – email, social media, phone number, relationship unfolds.

Slow burn approach? Cautious?

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

Too many vampires, sellers, scammers, MLM schemes, proselytizers.

Help people past defensiveness by being reasonable person from previous encounters.

How to Leverage Your Network

Chapter 4 on leveraging network. Now, see network as time/energy investment.

Network as orchard. Planting relationships, tending, keeping them healthy.

Who knows when relationships bear fruit? Keep planting trees, future sustenance.

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

Be kind, thoughtful, helpful.

Never be impatient about job search pace.

Never feel slighted or snubbed.

Never be jealous of others’ success.

What goes around comes around. Reap what you sow. Sowing positivity yields bountiful harvest.

Chapter 3: How to Build Your Reputation

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

Skills and network built, now build reputation.

Starting from scratch tech newcomer? Or existing credibility from other jobs?

Practical tips for sterling reputation among peers. Key to freelance clients, first job, career advancement.

First, how I built my reputation.

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

Last time: Quincy built developer network, frequented hackerspaces, events. But hadn’t tested his mettle in the arena…

Months into coding, worked up courage for first hackathon.

Bug frustration led to web browsing, saw Startup Weekend EDU.

54-hour hackathon – app building, pitching to judges. Coding, design, entrepreneurship rewarded.

Silicon Valley event, education entrepreneurs as judges. My adult education background seemed ideal.

Told Steve, “I’ll drive.” Steve no driver’s license.

Steve and hackerspace devs joined our team.

Weeks preparing, researched judges, sponsors, practiced coding like Shaolin monk.

Month later, big weekend. 2003 Toyota Corolla, peeling clear coat, high-energy music, 5-hour drive.

On the way, app idea discussion. Education-focused, high school students target, judges’ companies focused on that.

App purpose? Make life easier?

High school memories, dropped out after a year, GED at Taco Bell, college later. English papers pain point, MLA format, citation rules. Dreaded Works Cited page, teachers docked points for formatting.

After OK ideas, I piped up: “Citation app idea.”

Someone laughed, “Out of sight.”

Steve: “Good name. Out of Cite with a ‘C’.”

Clever laughs, implementation details discussed.

Venue: Silicon Valley, 100 devs. Open-plan office, cubicles, whiteboards.

Whispers about returning winner. Cocky-looking dev, fans around him. “Maybe he’ll let me on his team.”

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

Terrified, alien chest-bursting feeling. First in line. Rip the band-aid.

Sweating, gesturing wildly, rushed pitch: “Citations suck. Necessary, but preparing them sucks. Let’s build an app to fill out Works Cited pages. Who’s with me?”

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

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

Wi-fi password, best workspace – corner office, 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, copy-paste?”

“Better,” Steve said. “Button for each, citation to clipboard.”

Worked fast, MVP Friday night. Grabbed website metadata, structured citation. It worked.

First hackathon, hostel stress avoided. Hotel splurged. Twin beds, nightly floor rotation.

Saturday morning, ambitions grew. Whiteboard: “Websites are great, but students cite books, papers too. Citations for those also needed.”

API for book citation info via ISBN. Script for academic papers via DOI, scraping data from result pages.

Saturday night, plugin code coming together. Presentation slides started. Final coding to teammates, I rehearsed pitch for hours.

Sleepless night before presentation jitters. Silicon Valley, tech ecosystem heart.

Teacher talks in front of peers, but this was different.

Presenting to ambitious devs, judges. PhDs, tech company founders. Evaluating our work. Terrified of blowing it.

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

Read these books, startup book slurry of advice.

4 a.m., couldn’t sleep, started reading. Books emphasized paying customers, ultimate validation.

Realized: proof of product-market fit would seal the presentation. Proof app solved real problem, people would pay.

Idea: take app on the road, sell it.

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

Drove team to venue, waved goodbye, “Back with cash from customers.”

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

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

State university grad, felt out of place at Stanford, $50k/year tuition. Car worth 1/10th of that.

Campus ghost town. Palatial ghost town. Bronze statues, iconic arches.

Where are high-achieving, hardcore students this time of day? No time for manual citations.

Main library, past security, “no soliciting” sign.

Stacks, few studying. Kid taking notes from thick textbook. Bingo.

Slid next to him. “Psst. Hey. Like citations?”

“What?”

“Citations. Works Cited pages.”

“Um…”

“Last page of paper, list of…”

“I know what a Works Cited page is.”

“OK. Check this out.” Drug dealer jacket flash, $200 netbook. Awkward pitch.

“Browser plugin. Website, button click, voilà. Citation created.”

Kid raised eyebrows. “MLA?”

Biting back excitement, “MLA, APA, Chicago. Watch.” Button click, three citations, copy-to-clipboard buttons.

Kid nodded, impressed. Close the sale.

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

Kid thought.

Silence, salesperson’s best friend. Uncomfortable silence, staring him down.

Finally, “Cool, I’m in.”

“Awesome. Twenty bucks.”

Kid recoiled. “What? Expensive.”

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

Thought fast. “How much cash you got?”

Wallet fumble, “five bucks.”

Crumpled bill shrug. “Sold.”

Kid smiled, email with install instructions. “One more thing. Picture together.”

Selfie mode phone. Smile, “Hold up the five dollar bill.”

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

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

Presentation ended with customer photos, cash earned. Audience applause.

Most exhilarating experience. Second place, API credit prize.

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

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, coast to coast, every competition possible.

Harder now, no team. Solo.

Arrived, met people, pitched ideas, hoped to win over judges.

Teams formed sometimes, sometimes joined others’ teams.

Not just design, coding too. Reach exceeded grasp often.

Many hackathons, still bug fixing minutes before stage. Apps crashed during demos.

Las Vegas hackathon, codebase disaster, slideshow only. Head in hands audience, team member demoed hypothetical app. Judges unimpressed.

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

Second/third place countless times, never won outright.

Breaking Through

Until San Diego event. Never forget winning feeling, audience and judges convinced victory was inevitable.

Winner announcement, snuck out back parking lot, called grandparents. Told them I won.

Grandparents, unsure about software/hackathons, said they were proud.

Cherish their encouragement, faith in 30-something teacher grandson becoming developer.

Kept going to hackathons. New teams, new tools. Never forget first API success, Git command understanding, hustling teammates.

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

Built skills, network, reputation as hackathon winner.

I could ship.

Known quantity now.

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

Why Your Reputation is So Important

Reputation in society dates back to prehistory. Tribes tracked debts, credit before cash.

Written ledgers, elders’ memory.

Beyond accounting, intangible vibe.

“John shoes horses well.”

“Jane best storyteller.”

“Jay’s battle courage saved us.”

Examples involve skill, not just being likeable.

Being chill helps, but charm alone doesn’t suffice.

Developer claims: “JavaScript expert, build anything JavaScript on any device.”

Or: “Ship code on time, under budget, always.”

How to verify? They could be lying.

Devious man said:

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

Then you’re good at everything.”

(Quote origin unknown, imagined 1920s con man in top hat.)

Anyone can lie. Some do.

Fired teacher for lying about master’s degree for years, higher pay.

Discrepancy tipped me off, university records revealed no degree.

Scooby Doo moment. “Would have gotten away with it, darn kids.”

Sucked, years of undeserved higher pay.

Spoils of lying always tempting. Some succumb.

Employers know this. Can’t trust all JavaScript full-stack claims. Cautious about company badges, emails, database keys.

Hiring process paranoid. Maybe should be. Harder for everyone to get developer job.

Developers need skill proof, work ethic proof.

Reputation is proof. Reduces ambiguity, counter-party risk. Safer job offers, contracts.

Strong reputation = side door entry, not front door lines.

In-house recruiters fast-track interviews. Strong reputation = salary negotiation power.

Build strong reputation, sought-after manager candidate.

How to Build Your Reputation as a Developer

Six time-tested ways to build developer reputation:

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

How to Find Hackathons and Other Developer Competitions

Hackathons: immediate reputation, network, skills building.

Most free, public. Time and travel budget needed.

Big hackathon cities: San Francisco, New York, Bengaluru, Beijing. Commute possible, sleep at home.

Santa Barbara hackathons infrequent, crash on San Francisco classmate’s couch for more events.

Hackathons used to be hardcore, energy drinks, floor sleeping.

Now more health-conscious, sustainable. Participants have kids, full-time jobs.

Google “hackathon [your city name]” for event calendars. Universities, employers, charities often run them.

Playing to win? Research sponsors. B2D companies, APIs, databases, SaaS.

Sponsors offer booths, developer advocates. Meet key employees, founders – networking.

Sponsor-specific prizes common. “Best Use of [Sponsor] API.” Easier to integrate sponsor tools, win sponsor prizes, still wins on LinkedIn/resume. Win is win.

High-profile hackathons, substantial prizes – aim for overall win.

Hackathon regulars often found venture-backed companies, launch open-source projects.

High ambition level, work week then work weekend. Not afraid of fire.

How to Contribute to Open Source

Open-source contribution: immediate reputation building. GitHub profile, commit history visible.

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

Find GitHub issues for bugs, feature requests. Code changes, open pull request. Merged pull request, major reputation boost.

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

Open-source contribution builds reputation publicly, social proof of code reviews and acceptance.

Getting started with open source guide: Hillary Nyakundi’s comprehensive guide.

How to Create Developer-Focused Content

Developers are people, want to spend free time.

Books, video essays, visual novels. “Content.” Not great word, makes it sound disposable.

Software development broad, many topics. Developer lifestyle vlogs, coding interview tutorials, Twitch live streams, podcasts like freeCodeCamp Podcast.

Unimagined developer content categories will emerge.

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

Pick topic, become expert.

Tutorial specialists for specific tech stacks exist.

Andrew Brown, former CTO, DevOps exam expert. Free AWS, Azure, Google Cloud certification prep courses, exam prep service.

30+ million developers worldwide. Large content consumer audience, will know you.

How to Rise in the Ranks by Working at Big Companies

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

Some tech companies have rigorous hiring, high standards. Job itself is an accomplishment.

Practical reasons for employers to value past companies. Reduces bad hire risk.

Build reputation laddering prestige. Local to Fortune 500, then tech giants.

Corporate giant work isn’t for everyone (Chapter 4). But reputation building option.

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

Freelance portfolio builds reputation. Local focus often.

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

“Hometown hero” advantage. Compete with online competition by being local, in-person meetings, local connections.

How to Build a Developer Portfolio of Your Work

Show off projects with short videos.

People busy. No time to download code, run it.

Websites? May not grasp specialness.

2-minute video demos using screen capture tools recommended.

2 minutes to show project, implementation details, design decisions.

Always start with demo. Visuals first.

Lure viewers with working app demo, then explain details. Context and interest gained.

2 minutes also Twitter magic length, auto-play on scroll. Auto-play videos higher watch rates, less friction.

Project demo videos on YouTube, Twitter, GitHub, portfolio website.

QuickTime (MacOS built-in), Game Recorder (Windows 10 free), OBS (free, open-source, powerful, harder to learn) for video capture.

Recording tips: large font, external mic (even cheap headphones mic better than laptop mic).

Invest time in recording/re-recording until nailed.

Demoing projects, presenting code is valuable career skill. Pitch practice never wasted.

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

Founder status: fastest, riskiest reputation building.

Risky due to time, money, relationship wagers on unknown outcomes.

Open source contributions for long enough = reputation building.

Hackathon grind long enough = reputation building.

Entrepreneurial projects might fail for decades, squandering time, money, connections.

Entrepreneurship beyond book scope. Quick advice:

Most entrepreneurs fail. Some external factors, many due to risk misunderstanding.

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

Paid learning, risk exposure, savings for eventual entrepreneurial venture.

How Not to Destroy Your Reputation

“It takes a lifetime to build a good reputation, but you can lose it in a minute.” – Will Rogers

Reputation building is marathon, not sprint.

Years to build reputation opening doors.

Marathon stumble costs time, injury ends race.

Don’t Say Dumb Things on the Internet

Dumb things used to dissipate quickly. Now, online, indelible ink.

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

Data existence provable, absence not.

Deleted remarks, accounts, Google scrubbing – someone probably backed it up on Wayback Machine. Database hacks resurface old data.

Scary time to be loudmouth. Don’t be. Think before you speak.

“If you don’t have something nice to say, say nothing at all.”

“Praise in public, criticize in private.”

Publicly recognize good work. Impressive projects, say so.

Refrain from tearing down, even deserving targets.

In a fight, everyone looks dirty.

Don’t look wrathful, tearing down arguments, dog piling dumb remarks.

Caustic wit gets internet points short-term, but makes people love you less, fear you more.

Refrain from complaining. Customer service threat tweets might work, but people are busy. Don’t want social media scrolling to be your groaning about minor inconveniences.

Social media advice: keep it positive.

Strong beliefs? Speak mind, but think before typing, before sending.

Don’t Over-promise and Under-deliver

Common developer reputation torpedo: over-promise, under-deliver. Bad, but not fatal.

Las Vegas hackathon, failed project, slideshow instead of working app.

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

Better to be modest estimating abilities.

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

Get Addictions Under Control Before They Damage Your Reputation

Untreated drug, alcohol, gambling addiction? Seek help first. Job search grueling, need full attention.

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

Not a doctor, no “drugs are bad” speech. But Silicon Valley fads of developers abusing drugs for coding/problem solving.

“Micro-dosing LSD,” pharmaceutical amphetamines trends.

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

Don’t feel drug pressure. Don’t feel happy hour drinking pressure. (Beer-free since daughter’s birth 8 years ago, haven’t missed out).

Recovery from addiction? Learning to code, job hunting is stressful. Pace yourself, avoid relapse.

Don’t reach career transition end, achieve so much, only to have old habits resurface, undo hard work.

Try and Separate Your Professional Life From Your Personal Life

“Don’t mix business with pleasure.”

Developer, you’ll become powerful, command respect in your city.

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

Talk with people who’d love to be in your shoes.

Don’t flaunt wealth.

Don’t act smarter than everyone.

Don’t abuse power dynamic in relationships.

Unlikable, online capture might haunt career.

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

Use the Narrator Trick

Narrator Trick to pump yourself up.

You’re hero of your coding journey. Mind theater, everyone watching, rooting for you.

Narrate actions in head as you do them.

Quincy strides across hackerspace, laptop under arm. Tea mug under hot water, teabag in. Lever pull. Steaming water fills mug, British accent: “Tea. Earl Grey. Hot.”

Energizing beverage, booth slide, laptop square, fellow dev glance. Lock eyes briefly. Quincy slight head bow, acknowledging presence. Dev bows back, telepathic sentiment: “I see you friend. I see you showing up. I see you getting things done.”

Ridiculous? Yes. Works? Yes.

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

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

How does this build reputation? Reputation is summary of who you are, what you mean to others.

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

Narrating actions shines brighter light. Why did I do that? What was I thinking? Better move?

Many sabotage reputations unknowingly due to bad habits.

Years of “funny” reflex. Self-deprecating humor. Some amused, some thought I was a jerk.

Grade school class clown reflex.

Decades later, humor reflex filling silence not serving me well.

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

Might have gone on longer without noticing bad habit. Narrator Trick exposed awkwardness.

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

Your Reputation Will Become Your Legacy.

Think of who you want to be at story’s end. How you want to be remembered. Work backward from there.

End-of-movie hero you want to be admired. Why not start acting like that now?

Imagine being successful developer. Built software people rely on.

Future you – how would they think? Approach situations, solve problems? Talk about accomplishments, setbacks?

Future self visualization clarifies thinking, priorities.

“Old Man Quincy,” bad back, toilet breaks every 30 minutes.

Old Man Quincy still works with what he has. Moves despite pain, ponders despite foggy mind.

Old Man Quincy still wants to get things done. Proud of past, but looks forward to today’s goals.

Think of Old Man Quincy, work backward to today.

Decisions today setting you up for admiration tomorrow? Decades to earn reputation? Borrow respect from future now?

Thinking like future self, make moves earning reputation now?

Leverage future reputation – legacy – now. Think future self, goals, waypoint guiding you forward.

Narrator Trick, future self visualization, help think about reputation, take steps to improve it.

Reputation building – making a name – surest path to sustainable developer success.

Success means different things. But most agree: putting food on table for self and family is success.

Next chapter: getting paid to code – freelance clients, job search.

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

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

Not complicated, but still work, can be 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 grind, even won some. Reputation as “dangerous” JavaScript dev. Not skilled, just dangerous…

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

California weather best thing. Renting expensive apartment, paying for the outside.

Goal: minimal time in cramped apartment, rest walking around town.

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

First Monday of month, mapped monthly tech events around SoCal, always event if energy levels high.

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

Not much Ruby on Rails knowledge, few small projects. JavaScript and Python dev mostly.

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

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

Year building skills, network, reputation. Held my own in conversation.

Felt limits of my abilities. Stayed modest, understated. Dev mannerisms at tech events.

Director of Engineering at table, reported to CTO directly.

Looking to hire Ruby on Rails developers.

Candid about background, abilities. “Adult education background. Teaching English, running schools. Coding started a year ago.”

Unfazed. “Interview, see if you’re a good team fit.”

Walked home electrified. More dread than excitement.

Felt nowhere near ready. Not even job hunting. Living off savings, health insurance via wife’s job.

Compulsive saver. Oil changes, haircuts, homemade rice for takeout savings.

Decade teaching, saved quarter of after-tax earnings. Old video game flipping on Craigslist/eBay, substantial income.

Saving for? Unsure. House in California? Didn’t have to hustle for job. Privileged position, maximized learning daily.

Didn’t think I was ready for job. Worried hiring mistake. Fired, failure explanation in future interviews.

Looking at opportunity wrong way. But story continues.

Job interview scheduled, resume requested. Past professional experience listed. Schools worked at over years. (Taco Bell drive-thru off resume).

No coding experience related work. But what else to do, blank sheet?

Online portfolio of projects, hackathon wins/placings listed.

Hours before interview, revisited Ruby on Rails tutorials, memory refresh. Hoodie, jeans, backpack, walked to office.

Office manager nice, developer bullpen, introduced to small team. Dozen devs, jeans/hoodies, early 20s to late 40s, two women.

Navigated desks, cables, shook hands, introduced myself. Teacher memory of student names helpful. Remembered names, followed up later: “Great meeting you [name], excited to work with you.”

Meeting with 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 unmentioned. Just sat intensely looking at me.

50-employee company, venture capital, thousands of paying small business customers. Pragmatic. No university, past work questions. All they cared about…

“Look. I know you can code,” he said. “Hackathons, portfolio projects, code quality OK for new coder. Real question – can you learn our way? Team player? Get things done?”

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

“Good. Good. OK. Wait in Pho restaurant downstairs. [CTO] should be down in a minute.”

Talked with CTO over noodles. Mostly listened. People project intelligence onto quiet people. Listening makes you smarter, looks smarter.

Hour-long meeting. Tasty noodles, company history, near-term goals. CTO: “OK, go back up, talk to [Director of Engineering].”

Did. Job offer.

Not typical first developer job story.

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

Less about interview skills, more about year of coding, networking, reputation building preceding it.

Not cushy big tech job, benefits, bowling alleys. Contractor role, paid same as teacher.

But developer job. Company paying me to write code.

Professional developer now.

What Employers Want

Decade later, both sides of table. Interviewed for jobs, interviewed devs as hiring manager.

Hours on calls with job-searching devs, hundreds of applications, few callbacks.

Hours on calls with managers, recruiters, understanding hiring process.

Developer frustration stems from misunderstanding.

Employers value one thing above all: predictability.

Which candidate preferred?

X: “Rockstar” 10x coder, genius flashes. Bursts of productivity. Grumpy colleagues, misses deadlines, meetings.

Y: OK coder, slower but consistent output. Good colleague, rarely misses meetings/deadlines.

Z: Like Y in output, colleague, deadlines. Job changes 3 times in 3 years.

Guess? Y preferred. Employers value predictability.

X trap candidate, first-time manager mistake. We fired our top talent. Best decision we ever made.

Z added to illustrate: avoid frequent job changes.

Laddering jobs increases income, but repels hiring managers.

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

6+ months for manager to onboard new developer, net positive for team.

Until then, drain on resources, onboarding, codebase guidance, bug fixing by peers.

Most Employers are Risk Averse

Manager hires wrong developer – team disaster.

Average 3 months to fill developer position.

• Budget approval
• Job description creation
• Job posting, recruiter communication
• Resume sifting (many low-effort, blind applications)
• Interview process, flights, hotels
• Multi-day interviews, HR, managers, devs
• Final candidate selection, offer negotiation…
• Many candidates reject offers
• Contract signing, onboarding
• Sensitive system access
• Team introductions, team fit
• Months of informal training, codebase understanding
• Team way of doing things

Lots of work.

New employee quits quickly, higher offer.

Unreliable employee, late arrivals.

Addiction, anger issues, passive aggression.

Restart entire process, new candidate search.

Hiring is hard.

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

Because Employers are So Risk Averse, Job Seekers Suffer

Hiring hard? Job application process nightmare.

• Resume/CV prep, constant second-guessing
• Online job search, employer research, fit assessment
• Job site webforms, retyping resume, server/JavaScript errors
• Job application submission, wait for processing
• Many applications, manual review impossible (Google 9,000 apps/day). Software filters, in-house recruiters 6-second resume review. Many applications never seen by human.
• No company feedback, “pursuing other candidates” emails lucky.
• Hours applying weekly, mentally exhausting, unpaid.

Hiring and job application process nightmares.

But persistence lands offers. When it rains, it pours.

freeCodeCamp contributor’s 12-week job search data:

291 applications, 8 offers.

Offers increased starting salary over time. San Francisco job market, high cost of living.

Strong interview rate, negotiation skills. Read more about his process.

Side door entry is easier.

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.

Throughout book, techniques to increase “luck” of job offer.

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

Book encourages simultaneous skill, network, reputation development, from day one, well before job search.

My job-not-looking-for-it story seems silly, but common.

Learning to code is hard.

Knowing code is important.

Every industry, company tries to push processes to software layer.

Developers needed.

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

Why lay off trained developers? Bankruptcy aside, unknown reason. Layoffs destroy long-term company value. CEO pressure from investors, herd mentality.

Layoffs despite growth expectations for developer jobs. US Department of Labor Statistics 15% developer job growth next decade.

Tight job market now, downturn expected to be temporary.

Strong skills, network, reputation land good jobs despite tough market.

Hopefully, employers and skilled employees find each other easier soon, without brutal application/interview process.

What to Expect from the Developer Job Interview Process

Job interviews landed, taste of developer interview process and coding interviews.

Typical interview flow:

1. Online coding assessment/Phone Screen.
2. Second phone/video technical interview.
3. “Onsite” interview, travel to company office. HR, managers, dev interviews.

Questions test problem-solving, algorithms & data structures, debugging, other skills.

Solve coding problems in code editor or whiteboard.

Interviewer seeks thought process, not just correct answer.

Fundamentals understanding? Or memorized solutions regurgitation?

Algorithm/data structure practice helps. Think out loud, explain thought process.

Practice by talking aloud while coding, or live streaming coding. Twitch “live coding” streams, “learn in public” projects, reputation building bonus.

Whiteboard interviews: interactive process. Interviewer watching, evaluating consciously/unconsciously.

Interactive interview. Smile, eye contact, judge body language, relaxed? Nodding?

Interviewer hints? Open-ended questions aloud, interviewer might step in, feel involved.

Interviewer liking you matters. Rooting for you, might overlook coding shortcomings, errors.

Selling yourself as candidate. Make interviewer feel good deal.

Behavioral Interviews test “culture fit.” (Every manager defines differently).

Convince interviewer of strong communication skills.

Fluency in interview language, jargon knowledge helps. Tech podcasts like freeCodeCamp Podcast helpful.

Are you cool-headed, team player? Polite, no profanity, focused topic.

Avoid debates, sports rivalry. Don’t correct interviewers, even if wrong.

Bad vibes from company, don’t accept offer. Candidates and employers can pass. Interview isn’t conflict time.

Should I Negotiate My Salary at My First Developer Job?

Polite salary negotiation generally doesn’t hurt.

How to negotiate developer job offer salary.

Negotiation leverage depends on your position.

Employer needs work done. How badly? Other options?

You need income. Other options? Backup plan?

Another job offer as leverage.

Backup plan grad school? Weak leverage, but mentionable.

Hiring process lengthy, employers expect negotiation, won’t be surprised.

Job offer out of blue like my story, might feel awkward negotiating.

My story, no negotiation.

Should I have? Probably.

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

Could have negotiated few more bucks/hour. In moment, ecstatic about developer job, compensation secondary.

Year as developer, ask for raise. How to ask for a raise as a developer. Leverage same principle.

Should You Use a Recruiter for Your Developer Job Search?

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

Why recruiters are underrated tool.

Employers pay recruiters finder’s fee for quality candidates.

Recruiters’ incentives align with job seeker goals:

1. Paid based on starting salary, help you negotiate higher.
2. More placements, faster, more recruiter money. Help you get job fast.
3. Paid only if you succeed (90-day stay), ensure competence, company culture fit.

If recruiter asks for payment, red flag.

Not all recruiters equal. Research before working with one. Time investment even if employer pays recruiter. Time is valuable.

Speaking of time, freelancing gets you paid sooner, even during job prep.

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. Freelance less risky, no day job quitting.
3. Get paid sooner, build professional portfolio sooner.

Freelance clients easier to get. Why?

Small local businesses. Family-run restaurants, shops, plumbers, law firms.

How many benefit from interactive websites, back office systems, workflow automation? Most.

How many afford full-time developers? Fewer.

Freelancers fill gap. Economical, case-by-case basis. Project-based or short-term engagements.

Network building, people met might become clients.

Accountant needing website update, scheduling, payment features. Common small business requests, you can become proficient.

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

Open-source tools exist for deployment and configuration. Teach them usage, bill monthly service fee for on-call support.

Should I Use a Contract for Freelance Work?

Standard contract template, customize it, lawyer approval.

Awkward to contract local bakery for website/social media help? Professional feel, handshake agreements less formal.

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

How Much Should I Charge for Freelance Work?

Day job hourly rate, double it. Sounds high, but freelance work harder, much to learn.

Project-based billing: “Deploy system for $1,000.”

Specify maintenance timeframe. Avoid calls 3 years later for unmaintained system fixes.

How Do I Make Sure Freelance Clients Pay Me?

Freelancers, including me, use: 50% upfront before work, other 50% at halfway point demonstration.

Full payment before project completion. Client can’t dangle money for extra work.

Paid in full, extra help conveys “going above and beyond,” not “are you even going to pay me?”

Should I Use a Freelance Website like Upwork or Fiverr?

Rural areas, no local clients, try freelance websites. Otherwise, avoid. Why?

Freelance website competition worldwide. Lower cost of living countries. Some prioritize cheap work over reputation, deliver sub-par work.

“Race to the bottom” – cheapest worker gets job.

Local network clients avoid competing with overseas freelancers.

Same for hiring freelancers. Local, in-person meetings, community ties recommended.

City resident, social gatherings, less likely to take advantage. Reputation matters to both, invested in working partnership.

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 possible.

US: Limited Liability Company (LLC), business as company, even if solo.

Tax simplification, personal liability insulation in case of client lawsuit. LLC bankruptcy, not personal bankruptcy.

Liability insurance consideration for further protection.

Freelance taxes due at year end, save for it.

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

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

Freelancing pays bills? Keep doing it. Build software development agency, hire developers.

Yearning for job stability? Freelance clients might convert to full-time jobs. Economical sense for client to offer full-time job at lower hourly rate. You get 40-hour stability, they get full-time skills.

Keep freelance clients alongside job, income supplement. But first job can be all-consuming responsibility (next chapter).

First year as developer, how wild? Let’s discuss.

Chapter 5: How to Succeed in Your First Developer Job

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

First developer job, real learning begins.

Productive teamwork, navigating legacy codebases, Version Control Systems, CI/CD, project management tools, engineering manager navigation, deadline shipping, ambiguity handling.

Most importantly, self-management.

Psychological barriers like imposter syndrome, learning limits, pushing beyond them.

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

Last time: Quincy first developer job at local tech startup. One of dozen devs, large codebase maintenance. No idea what he was doing…

Woke up 4 a.m., couldn’t sleep. Anxiety, panic burning chest.

Decade in education. Tutor, teacher, school director.

Starting over at bottom, as developer.

Past learnings, success, matter in new career?

Anxiety run. Hills bounded down, headlamp bobbing. Beach run at sunrise.

Home, wife leaving for work. “Don’t worry, still love you if fired for incompetence.”

Office arrival, nobody there. Teacher habit, 7:30 sharp. Devs start later.

Cross-legged in hallway, coding tutorials on netbook.

Employee nervously walked up, squatter suspicion. Reassured her I worked there, convinced her to let me in.

Surreal walk across empty office to developer bullpen, exit sign light only.

Netbook on empty standing desk, tutorial finished.

Lights flickered on. Boss arrived. No acknowledgement initially. Desk, mechanical keyboard keystrokes.

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

Wasn’t. Confidence signal needed. Words from Big Trouble in Little China: “I was born ready.”

Heard “I was born ready” a million times. First uttered 1986, Jack Burton to Wang Chi facing 1000-year-old wizard. Parents let me watch this, glad they did.

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

“Already have one,” netbook tap. “Linux Mint, customized .emacs file…”

“We’re a Mac shop,” closet walk. Rummaged, emerged. “3-year-old model, but should do. Factory reset.”

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

“Same tools for everyone. Easier collaboration. Convention over configuration.”

First time heard “convention over configuration,” but came up a lot.

Hours configuring work computer as devs trickled in.

Nearly 10 a.m., team “standup meeting.” Circle by whiteboard. Status updates.

Quick, precise updates.

My turn, started introducing self. Anxiety already high, Mike, ultramarathoner Startup Night guy walked in, baby carrots crunching, 30-mile morning run already.

After I finished, Mike welcomed me, events recognition. 15-second status update.

10-minute meeting, everyone back to desks.

Company codebase running on new laptop eventually. Ruby on Rails app, 5 years growth. rake stats command, millions of lines code. Shuddered. How comprehend all that?

Gruff, bearded neighbor, “Most of that packages. Actual codebase maybe 100,000 lines. Don’t worry, you’ll get it.”

Gulp, “Less than millions, good.”

“Name’s Nick by the way,” introduced himself. “Help needed, let me know. Stumbling codebase years, should help out.”

Next few days, peppered Nick with questions about every internal system.

Nick started setting chat status “code mode,” noise-canceling headphones, swiveled back, body language “leave me alone.”

Early team dynamics lesson. Don’t overstay welcome with questions. Learn things yourself.

Massive codebase, undocumented, sparse wiki.

Closed-source codebase, no Stack Overflow help. Feeling around in dark.

Rotated neighbors for questions. Wore out welcome with questions.

Over-corrected. Shy about asking simple questions. 2-hour unstuck rule before asking.

Hours thrashing, asked for help. Manager discovered morning struggle, “Why didn’t you ask earlier?”

Codebase understanding struggle – “monolith” and microservices.

Thousands of unit/integration tests. New code = tests. Ensure code works, doesn’t break existing functionality.

Frequently “broke the build,” committing seemingly tested code, broke other parts, hadn’t considered. Frustrated team, unable to merge own code until fix.

Build broke weekly. Not only me. But felt like me.

Days felt like not cut out for developer. “Who am I kidding? Decide one day I’m a developer?”

Echoes of developer friends’ comments a year earlier, starting coding journey.

“How compete with childhood coders?”

“Ocean of knowledge needed.”

“Stick to what you’re good at?”

Longer breaks, away from computer. Kitchen snacks. Delay crushing feeling of cluelessness.

First months rough. Morning standups, everyone fast. Bug closing, feature shipping. Felt like nothing to say. Same feature as yesterday.

Every morning, dread. “Today they fire me.”

But went to work, everyone kind, patient. Asked help if really stuck. Some progress, bug or two fixed.

Getting faster codebase navigation. Faster stack trace reading. Features shipped faster.

Boss called into office, “Firing today.” But assigned more bugs, features. Phew.

Surreal terror of firing, boss clueless.

Heard of “imposter syndrome.” But didn’t realize that was it. “Sucks at coding” syndrome more likely?

Nick next to me, frazzled. Soda offered.

Returned, soda cracked, sip, leaned back, code-filled monitor gaze. “This bug, man. Three weeks, same bug. Debugging in my sleep.”

“Three weeks same bug?” Never heard of that.

“Tough bugs exist. Devious one.”

Salmon slap across face. Job viewed as work chunks. Half-day bug fixes. Longer meant I was wrong.

Nick – CS degree, years experience, same codebase – stumped 3 weeks on one bug.

Maybe too hard on myself. Maybe bugs weren’t “half-day bugs,” but “two- or three-day bugs.” Inexperienced, slow, but unrealistic standards.

Feature time budgets, “5-day features,” “2-week features.” No bug budgets, but probably similar variation.

Home, read about Imposter Syndrome. Explained anxiety.

Months later, kept building features. Team collaboration. Still hard, brain-busting. Getting easier.

Team bonding at lunch, board games. Company chess tournament.

Round or two, played CEO.

Unorthodox chess style, silly opening, serious players avoid. Early game lead.

Next moves, slowly ground back control. Eventually won.

Asked how he keeps chess skills sharp, running company. “Oh, I don’t. Play once or twice a year.”

Pause, hand frozen, lecture prep. “Uncle competitive chess player. One advice: opponent moves, slow down, understand game from their perspective – why that move?“

Bow, excused himself, meeting.

Thought about advice years. Not just chess. Any adversarial situation applicable.

If You Keep Having to Do a Task, You Should Automate it

Software development lesson: junior person, grunt work assigned. “Build nanny” task.

Build broken, pull latest main branch, git bisect to find breaking commit.

Open commit, run tests, figure out wrong. Message breaker, fix instructions.

Got fast at it. Confusing bug reports, ambiguous features, build breaking welcomed. Chance to feel useful quick.

Soon, teammate: “Build breaks often, automate this.”

Defensive, didn’t say anything. Bad idea. Script can’t be as good as me, right?

Days later, teammate wrote script. Build nanny job gone.

Strange to see build fail message, then moment later message saying commit and person to fix it.

Indignant. “That’s my job. Script took my job.”

Now look back, laugh at reaction. 40s me, still build nanny.

If task automatable, break down to steps, computer reliably does it – automate it.

More interesting work to do with your time.

Lessons from the Village Elders

Learned much from team. Product design from Mike. Beach runs, forefoot running lessons.

Agile software engineering from Nick. Software development book recommendations, housewarming invite, met his kids.

Year working, time to strike out, online learning projects. CTO break news. Leaving.

“Grateful you hired me, clearly weakest developer.”

Laughed. “Sure, worst developer starting. Still worst developer now.”

Awkward smile, blinking, angry leaving?

“But that’s smart. You’re smart. Always want to be worst musician in the band. Surround yourself with better people. That’s how you grow.”

Two weeks later, code changes checked in, tickets handed off. Mac factory reset, manager handed it back.

Handshakes with teammates, California evening air.

Hit ground running, freelance contracts for lights on. Bay Area apartment scouted, across bridge from tech heart SoMa San Francisco.

Professional developer, year experience under belt.

Ready for new dreams, new moves.

Off to startup land.

Lessons From my First Year as a Developer

First year as developer, did many things right. B- grade.

Do it again, some changes.

Here are tips, maximize learning, minimize heartache.

Leave Your Ego at the Door

Many entering software development start at bottom. “Junior Developer” title.

Awkward middle aged with “junior” title. Patience, hard work, move past it.

Problem faced daily: 10 years professional experience. Not entry-level employee. New to dev, but experienced teaching, managing. (30 employee management at last teaching job).

Yet – entry-level developer. Novice, neophyte, newbie.

Wanted to scream “I used to be boss, no babysitting needed” – truth was babysitters needed.

Accidentally break production? Security vulnerability? Database wipe? Encrypt, lose key?

Disasters happen.

New developer, bull in china shop, walk carefully, smash everything.

Don’t be impatient with teammates. Resist temptation to mention degrees, awards, key to the city. (Last one never happened).

Distraction from task.

First months, used past accomplishments as pacifier. “Yeah, I suck at coding, phenomenal English grammar teacher. Ran a school.”

Fingers on keyboard, eyes on editor, past self let go. Revel in yesterday’s accomplishments tonight, after today’s work.

For now, accept beginner emotions. Focus on task, get job done.

It’s Probably Just the Imposter Syndrome Talking

Almost everyone experiences Imposter Syndrome. Feeling of not belonging, teammates will expose you as “not a real developer.”

Feeling doesn’t go away. Always there, ready to rear head when trying something new.

“Help with error message?” “Um… not best person to ask.”

“Pair program on feature?” “Um… if no one better.”

“Conference talk?” “Um… me?”

Senior engineers still get imposter syndrome, decade into career.

Inadequate, unprepared feeling might just be imposter syndrome.

Handed scalpel, “help heart surgery,” imposter feeling reasonable. Out of depth, reasonable feeling.

Problem: practicing dev, can do something, still feel anxiety.

Not a doctor. Instinct: imposter syndrome diminishes with time, practice, confidence.

But random pop ups possible. Admit it: “Probably just imposter syndrome talking.”

Keep going.

Find Your Tribe. But Don’t Fall for Tribalism

First developer job, work with other devs. Tribe found.

Spend time, tight unit feeling.

Don’t ignore non-developer people.

Mike, Product Manager, startup events guy, “non-technical.” Coding knowledge limited. Learned as much from him as anyone else.

Designers, product managers, project managers, IT, QA, marketers, finance, accounting. Learn much from these too.

Build developer team connections. Stay curious. Lunch room, company events. Next person to help build skills, network, reputation might be anyone.

Don’t Get Too Comfortable and Specialize too Early

“Learn general coding (JavaScript, SQL, Linux, etc.), specialize on job.”

Once common tool understanding, learn less common equivalents.

PostgreSQL -> MySQL. Node.js -> Ruby on Rails, Java Spring Boot.

Some specialize too early at work. Boss “owns” API/feature. Good job, boss keeps giving similar projects.

Boss manages many people, too busy for nuanced understanding of your abilities, interests. See you as “XYZ person,” give related tasks.

You know your skills, interests. Volunteer for projects outside comfort zone. Get boss to assign them, expand skills, work with new teams.

Boss responsible for job performance, you responsible for career performance.

Take projects fulfilling employer obligation and positioning you for long-term career goals.

Epilogue: You Can Do This

One message: you can do this.

Can learn concepts.

Can learn tools.

Can become developer.

Money for coding help, graduate to professional developer.

Learning to code, first job daunting. Don’t be daunted.

Persistence = success. Practice matter.

Build projects, show friends, build for friends.

Build network, help people met. What goes around comes around. You’ll get what’s coming.

Not too late. Life is long.

Look back on this moment years from now, glad you made move.

Plan for long time, uncertainty.

But keep coming back to keyboard. Events, share wins with friends.

Lao Tsu:

“A journey of a thousand miles begins with a single step.”

Finishing this book, already taken step. Maybe many steps already.

Momentum is everything. Keep forward momentum from this book.

Start next project today.

And always remember:

You can do this.