DEV Community: G105g

How to Build a LinkedIn Profile That Recruiters Actually Find

G105g — Sun, 04 Oct 2026 11:25:55 +0000

Recruiters do not scroll LinkedIn the way you scroll it. They search it. A typical search looks like a job description pasted into a search box, plus a location filter, and the results are the profiles whose words match those words. That single fact changes how you should think about your profile: it is not a showcase that waits to be admired, it is a document that a search tool reads. Most people write theirs like a resume summary or worse, like a polite placeholder, and then wonder why outreach never arrives. The fix is not luck and it is not paying for visibility. It is a few hours of deliberate writing so that the exact phrases people search for appear in the places the search actually reads. Here is how to do that, section by section, with no jargon and no gimmicks.

First, Understand How Recruiter Search Works

When a recruiter searches, LinkedIn scans specific parts of your profile and ranks the matches. The headline and the skills list matter most, then your job titles, then the About section and the rest. Profiles that contain the searched words near the top of the profile rank higher, which means the first lines of your headline and About section carry the most weight. Two more details matter. First, profiles with complete sections tend to rank better than half-empty ones, because the platform treats completeness as a quality signal. Second, a profile written in third person or in vague slogans simply contains fewer searchable phrases, so it loses to plainer writing even when the underlying person is more qualified. Everything below follows from those facts: put real terms in the real fields, front-load them, and keep the document complete.

Your Headline: The Single Highest-Leverage Line

The headline follows you everywhere on the platform. It appears next to your name in search results, in connection requests, on every comment you leave, and in every message. The default, your current job title at your current company, wastes this space, because it says nothing about what you can do. Rewrite it as a plain statement of what you do and who you help, using the words people in your field actually type. A payroll specialist should not write a slogan about people first; a phrase like payroll specialist, multi state payroll, ADP and Workday is worth more than any motto because it matches real searches. Same logic for a career changer: teacher transitioning to instructional design communicates both the past and the target. You have room for a couple of phrases separated by vertical bars, so spend them on searchable nouns, not adjectives.

The About Section: Write for Skimmers and Search

The About section has two audiences: the search system, which scans it for keywords, and the human who reads the first three lines before clicking to expand. Serve both. Open with two or three concrete sentences in your own voice stating what you do, the tools and domains you work in, and the result you are known for, because those opening lines are all most readers see. Then list your core skills as a short, readable block so that terms like grant writing, bookkeeping, on camera video, or customer retention appear as exact phrases. Close with one line inviting the specific contact you want, for example: open to freelance editorial illustration projects. Write in the first person, skip the buzzwords, and aim for the whole section in five or six short paragraphs. This is the one place on the profile where some personality is welcome, as long as the searchable nouns come first.

Experience Entries: Titles First, Results Second

Every entry has a structure, and the structure matters more than length. The job title field is weighted heavily, so write the standard version of your title even if your company used a creative internal name. If the official title is obscure, such as wizard of onboarding, use the common industry phrase instead and explain the internal title in the first line. Under each title, write two to five bullets that state what you did and what changed because you did it. Numbers help at every level: a number of customers, a percentage, a dollar figure, a time saved. If your work is hard to measure, measure scope instead, such as team size, budget, or volume handled. Keep the paragraphs tight, put each major point in its own bullet, and use plain industry terms. Recruiters and search both reward the same thing here: specific, standard vocabulary in the title field, evidence in the bullets.

Skills and Endorsements: The Tag System That Drives Results

The skills list is not decoration. Recruiters filter search results by skill, and the platform can surface your profile for a search when the searched term matches one of your listed skills even if the word appears nowhere else. That makes this the easiest ranking win on the whole profile. Add every skill you genuinely have, up to the limit, and put your strongest, most searched skills in the top three positions, because those are the ones displayed prominently and endorsed most often. Pin the three that best match the work you want next. Endorsements add credibility but matter less than coverage, so do not campaign for them; a complete, accurate list beats a sparse list with vanity endorsements. Revisit this section whenever your direction changes, because stale skills keep surfacing you for the wrong searches.

The Photo and Banner: Small Details, Real Effects

Profiles with a clear, recent headshot get measurably more views than profiles without one. You do not need a professional shoot. Face a window, wear what you would wear to an interview, and crop from the chest up with nothing distracting behind you. The banner image is a free billboard most people leave blank: a plain image of your work, your workshop bench, a city skyline if you are location bound, or simple text stating what you do. Neither image is searchable, but both change whether a human who finds you decides to click through and read. This is packaging, and packaging is worth an hour.

Your URL, Location, and Open To Settings

Three small fields do quiet work. Claim a custom URL, such as linkedin.com/in/yourname, and use it on your resume so the two documents reinforce each other. Set your location to the metro area where you actually want to work, because recruiter searches are almost always filtered by location; if you are remote, say so in your headline or About section rather than hiding your location. Then turn on the Open To Work setting, choosing either the public green banner or the recruiters only version, which is visible to recruiters using the platform's hiring tools and not to your current employer. The recruiters only setting is the standard choice for people who are employed and exploring. These settings take five minutes and directly affect how often you appear in the right searches.

A 90 Minute Profile Sprint

Do the whole job in one sitting with this order:

Minute 0 to 15: collect the vocabulary. Open five job postings you would love to have, and copy the repeated nouns and tool names into a scratch file.
Minute 15 to 35: rewrite your headline and About section using those exact words, searchable nouns first.
Minute 35 to 60: fix every experience entry, standardizing titles and adding at least one number to each.
Minute 60 to 75: complete the skills list, pin your top three, and clean up your photo, banner, and custom URL.
Minute 75 to 90: set location and Open To settings, then search for yourself the way a recruiter would and adjust.

The self test at the end is the important one. Search LinkedIn for your own target role plus your city, the way a stranger would. If your profile is not plausibly on the first page of results, the fix is almost always vocabulary: the words in the posting are not yet the words in your profile.

Common Mistakes That Keep Profiles Invisible

Leaving the default headline. It is the most viewed line you own, and it currently says almost nothing searchable.
Writing the About section as a vague mission statement with no nouns. Search cannot match adjectives.
Using an internal or joke job title as the official title. Recruiters search standard titles.
Listing only a handful of skills, or burying the strongest one in the middle of the list.
No location set, or a location nowhere near the target job market, so location filtered searches never surface the profile.
An empty or blurry photo. It costs clicks, and it is the easiest fix on the list.

None of these are character flaws. They are five minute fixes, and together they compound, because each one widens the set of searches that can surface you.

Keep It Alive After the Sprint

A profile is not a one time project. Small, regular touches keep it current and keep it circulating: update the headline the week your focus changes, add a bullet the week you ship something real, and refresh the skills list each quarter. If you want the underlying skill instead of the profile, the library has you covered: our guide to resume skills that get interviews pairs naturally with this one, since the two documents should tell the same story in the same words. If speaking up is the harder part for you, the plan in your first public presentation builds that muscle in a week. And for the long game of turning one career into another, the playbook in an accountant's eight month switch into UX design shows what deliberate, documented skill building looks like. Every guide in the Learn To library follows the same idea: plain steps, beginners first, no fluff. Pick your next skill today at learnsto.com.

This guide was originally published on LearnTo — step-by-step guides for learning real-world skills as an adult.

Resume Skills That Get Interviews: Before and After Rewrites

G105g — Sun, 04 Oct 2026 11:20:50 +0000

Most resumes are never read; they are scanned for a few seconds while the reviewer decides whether to keep going. That decision rests on what jumps out of the first screen: job titles, companies, dates, and anything with a number in it. The candidates collecting interviews are rarely the most qualified people in the pile. They are the ones whose resumes read like evidence instead of essays.

The gap between an ignored resume and a called-back one is usually a small set of fixable habits, not a missing degree. This guide covers the changes with the biggest payoffs: replacing adjectives with evidence, matching the job posting's language, putting numbers on ordinary work, and rewriting bullets. Each technique comes with a before-and-after example, plus a section for career changers.

What a Reviewer Actually Sees

A typical posting draws hundreds of applications, and the realistic first pass is 20 to 30 seconds each: a skim to sort the pile, then a closer read of the short pile. On that first pass the reader is answering three questions without deciding to: what does this person do now, where, and is there anything that matches what we asked for.

That is why the top third of the first page carries so much weight: your name, headline, most recent title, and the start of your current role. If that block is clear and specific, the reader slows down; if it is vague or padded, they are already reaching for the next file. Every choice should serve one unconscious question: prove it.

Rule One: Trade Adjectives for Evidence

Adjectives are claims nobody can check, which makes them worthless in a document whose entire job is to be checked. Words like hard-working, detail-oriented, results-driven, and passionate appear on nearly every resume, which means they carry no information at all. Evidence is different: it is a specific thing you did, for whom, at what scale, with what result.

Before: "Detail-oriented professional responsible for managing inventory." After: "Managed inventory for a 3-store retailer, cutting weekly stockouts to roughly one per month." The first sentence tells the reader you know what adjectives are. The second tells them you have actually run inventory, at a specific scale, and understood what the job was for. The first asserts character; the second reports something that could be checked in an interview. When in doubt, delete the adjective and describe the thing you did that would have made the adjective true.

Rule Two: Speak the Job Posting's Language

Applications get filtered by software as well as people, and both are matching words. If the posting says "inventory management" and your resume says "stock control," a literal keyword match can miss you even though you are qualified. The fix is simple and honest: use the posting's nouns for things you have genuinely done, in the same form the posting uses.

Treat this as its own pass: open the posting, underline every skill, tool, and responsibility phrase, and check whether each appears on your resume somewhere it legitimately can. Where the truth allows, copy the exact wording. If you genuinely lack a listed requirement, do not claim it: indefensible claims are worse than gaps. And do not lose points for vocabulary: "Led a team of 5" and "managed a 5-person team" are the same fact wearing different words, and one of them matches the posting. Ten minutes of mirroring vocabulary is the highest-paid editing you will ever do.

Rule Three: Put Numbers on Ordinary Work

The most common objection to quantifying is "I don't have impressive numbers." The numbers do not need to be impressive; they need to be true and concrete. Customers served per shift. Tickets closed per week. Dollars of sales on an average Saturday. Estimates are fine when labeled as estimates, because a rough number still proves you knew the scale of your own work.

A number does two jobs. It makes the claim concrete, and it shows you paid attention to outcomes rather than just showing up. Before: "Responsible for preparing beverages at a high-volume cafe." After: "Prepared roughly 120 drinks per shift during morning rush while maintaining order accuracy above 98 percent." Same job, completely different credibility. If your workplace never measured anything, estimate yourself, sanity-check the estimate against what a coworker would say, and use it. Vague honesty loses to specific honesty in resume scans, reliably.

Before and After: Four Bullets Rewritten

Four rewrites from common backgrounds, using the three rules above.

Retail sales. Before: "Helped customers and maintained store appearance." After: "Served about 80 customers per shift; suggested add-on accessories at checkout, adding roughly $400 per week in sales."
Office assistant. Before: "Responsible for scheduling and paperwork." After: "Scheduled 15 staff across 3 weekly shifts; moved scheduling into a shared calendar and cut shift conflicts to near zero."
Restaurant server. Before: "Provided excellent customer service in a fast-paced environment." After: "Sold desserts and drinks to 1 in 3 tables on average, the highest attach rate on a 6-person team."
Career-change coding student. Before: "Currently learning Python and web development." After: "Built and deployed a personal recipe tracker in Python and HTML; about 400 lines, with tests, source available on request."

Notice what every After has: a concrete action, a number or a specific comparison, and an outcome. The Before sentences are honest; they just prove nothing, so they read as filler. When you truly cannot find a number, add specificity instead: what you did, for whom, how often, and what changed. That alone separates your bullets from the pile, because half the resumes in the stack contain only duty lists.

Career Changers: Make Self-Taught Skills Legible

Career-change resumes fail in two distinct ways. The first is burying transferable work under old titles: the nurse who managed supply budgets gets filed under "healthcare" by a skim reader. The second, more common, is claiming new-field skills without evidence. Anyone can write "learning Python," so the sentence has zero value; the artifact you produced while learning is what has value.

So the work happens before the resume: finish something small and showable. If you are moving toward software, a single finished project from something like our first 30 days of Python plan, deployed and described in one honest bullet, outweighs three courses you started and abandoned. The same pattern holds for every field: a portfolio of six edited photos, a dinner menu you planned and costed, a workout program you ran on real people for eight weeks. One modest finished thing beats five half-finished impressive things, because finished is the evidence. It is the deliberate-practice idea behind our guide to practicing any skill faster, applied to careers: short sessions aimed at a checkable result, not accumulated hours.

Structure-wise, career changers need two adjustments. Put a two-line summary at the top that states plainly where you are going: "Retail manager moving into operations, with 4 years of scheduling, vendor, and inventory experience." And lead the skills section with the target field's tools, so the scan finds matching keywords before it finds your old job titles.

The Skills Section, Done Right

The skills section gets mishandled two ways: stuffed with every tool ever touched for ten minutes, or filled with filler like "communication, teamwork, Microsoft Office." Both read as padding. The version that works is short, specific, and honest: roughly 6 to 12 items, split into tools and skills, named at the level the posting uses. Write "Excel: pivot tables, VLOOKUP, and conditional formatting" if that is true for you, because it is a defensible claim. A bare "Microsoft Office" on a 2026 resume tells the reader nothing except that you own a computer.

The test for every item: an interviewer can point at any line and ask "walk me through how you used that," and you have a real answer. Anything you could not spend two minutes explaining does not belong. A shorter list you can defend beats a longer list that turns the interview into an audit of things you half-know.

Formatting: Boring Wins

Every rule here points the same direction: remove friction from the scan. Export to PDF so it renders identically everywhere. Name the file Firstname-Lastname-Resume.pdf, not resume-final-v3(2).pdf. Keep it to one page unless you have more than 10 years of directly relevant experience, and even then be skeptical. Use reverse-chronological order, standard headings, and a single column. Skip photos, text boxes, tables, columns, icons, and skill-rating bars; they are where screening software and hurried humans both lose the thread. A plain, slightly dull resume that parses perfectly beats a designed one that stutters.

Mistakes That Quietly Kill Applications

A few habits sink otherwise fine resumes. Duty lists: a row of "responsible for" sentences proves presence, not contribution. Objective statements about what you want: cut them; a summary of what you bring is more useful. Functional resumes that hide dates behind skill clusters: reviewers treat them as concealment, rightly. Three-page life histories including the high school job: the last 10 years is plenty. Typos in the first third: brutal, and avoidable with one read aloud. Unexplained gaps: a one-line note, such as a year of caregiving or contract work, removes the question entirely. None of these are moral failures; they are friction, and the reader has 200 more files waiting.

Get One Honest Reading

Your own resume is the hardest document you will ever proofread, because you know what you meant and your brain fills it in. Trade reviews with a friend, or better, find someone in your target field; our guide to finding a mentor online covers how to ask without making it weird. Ask one question: "would you interview me on this?" Then run the 6-second test: hand the resume to someone, take it back after six seconds, and ask what they remember. If the answer is not your target role plus one number, rewrite the top third.

Start Tonight

Pick one real posting you would genuinely accept. In an hour: underline its nouns, rewrite your summary line to name the direction you are moving, rewrite five bullets using action plus number plus outcome, trim the skills list to what you can defend, and export a properly named PDF. Treat each job application as a revision, not a mass mailing, the same loop we describe in our guide to the fastest way to learn a skill: short, targeted, with feedback before the next attempt. For more evidence, see the weekend-sized capabilities in our skills that pay roundup: every demonstrable skill becomes a bullet you can defend. Interviews go to resumes that prove things. Yours can be one of them by the end of tonight.

This guide was originally published on LearnTo — step-by-step guides for learning real-world skills as an adult.

How to Negotiate Your First Salary Offer (Without Blowing It)

G105g — Sun, 04 Oct 2026 11:20:46 +0000

Your first real salary offer is the single highest-leverage conversation of your early career. One good negotiation can be worth more than a year of raises, because every future raise and bonus is calculated as a percentage of your starting number. Yet most first-job candidates either accept instantly or fumble through a negotiation so awkward they wish they had not tried.

The fix is not charisma. It is preparation plus a few short scripts you rehearse out loud before the call: what to do before the offer, what to say in the first thirty seconds, how to counter, and how to close without damaging the relationship.

Why the first number matters so much

Companies usually budget raises as a percentage of current salary - commonly 3 to 5 percent a year. Bonuses, retirement matches, and equity refreshes often scale off base pay too. If you start at $52,000 instead of $56,000, you are not just $4,000 behind this year. At 4 percent annual raises, the gap grows every single year you stay, and even switching jobs later tends to anchor off your current pay.

There is a second reason: the first negotiation sets your own default. Once you have survived the silence, heard "let me check," and still gotten a yes or a graceful no, the second one is dramatically easier.

Before the offer: build your evidence

Negotiation strength comes from data, not confidence. Start collecting it the moment you begin interviewing, not the day the offer lands.

Market ranges: Look up the role title and your city on at least three salary sources - large job boards with salary data, professional association surveys, and public pay databases where available. Write down a realistic low, mid, and high.
Your specific proof: List three to five concrete things you bring: an internship with a measurable result, a portfolio project, a certification, a skill the job posting called "preferred" that most candidates lack. These become the reasons in your counter, not bragging.
Your walk-away number: Decide the minimum you would accept before you are emotionally in the room. Once an offer arrives, adrenaline distorts judgment. Decide now, in calm conditions.

Your resume is the evidence base here: negotiation scripts only work when there is substance behind them. The guide to resume skills that get interviews shows how to phrase results so they are quotable in a salary conversation.

Rule one: never negotiate on the spot

The most common first-timer mistake is not a bad counter - it is responding to the offer in real time, on the phone, with no preparation. The recruiter calls, reads the number, and asks, "How does that sound?" Caught off guard, people say "great" or they panic-counter with a random figure.

Both are avoidable with one rehearsed sentence:

"Thank you - I'm really excited about this role. Before I respond, I'd like to review the full package. Could you send the offer in writing, and can I get back to you by Thursday?"

It does four things: shows enthusiasm, requests the full written package (base, bonus, equity, benefits, start date), buys you 48 to 72 hours, and signals you evaluate decisions carefully. No company rescinds an offer for a reasonable review window - a week is fine; a month is not.

During the review window: run the numbers

With the written offer in hand, work through it like a checklist:

Compare base to your market research. Does it land low, mid, or high?
Total the whole package. A $55,000 offer with strong health coverage, a retirement match, and a real training budget can beat a $58,000 offer with none. Put dollar estimates on the differences.
Decide your single ask. First-timers often ask for three things vaguely and get nothing. Pick one priority - usually base salary - and make it your headline ask. If you have a second item (signing bonus, start date, extra PTO), name it as a lighter follow-up.
Set your counter number. A common approach: counter at or slightly above the top of your researched range, so the likely settlement lands near your real target. If your target is $56,000 and research shows $54,000-$58,000 for the role, counter at $58,000.

The counter script

Whether by email or phone, a first-offer counter has three parts: appreciation, one specific number with justification, and an easy yes.

"Hi [Name], thanks again for the offer - I'm genuinely excited about the team and the work. Based on my research for this role in [city], and the [specific experience/project] I'd bring, I was targeting a base salary of $58,000. Is there flexibility to get to that number? If so, I'm ready to sign and get started."

Notice what the script avoids: no ultimatums, no comparisons to other offers unless you have one in writing, no apologizing. "Is there flexibility" is a question, not a demand, and "I'm ready to sign" tells them the only thing between them and a committed hire is a small adjustment - exactly the trade they want to make.

By email, keep the counter under six sentences - long ones read as anxiety.

What they might say - and your responses

"That's above our range for this level." Ask: "What is the top of the range for this role?" Sometimes the range has more headroom than the first number suggested. If it truly does not, pivot to your backup item: "Understood - could we look at a signing bonus of $3,000 to bridge the difference?"
"We'll get back to you." Normal. Wait the number of days they name, then follow up once, politely. Three business days of silence is not a no.
"We can do $56,500 - final." A split-the-difference counter usually means yes. If $56,500 clears your walk-away number, take it and say so warmly: "That works - I accept." Do not keep pushing after the word "final." You will spend goodwill you need as a new hire.
"We can't move on salary at all." More common with government, education, and very small companies. Shift to what they can control: start date, title, a development budget, or a six-month review with defined raise criteria - agreed in writing in the offer email.

The mistakes that cost first-timers real money

Saying the first number when asked "What are your salary expectations?" early in the process. Deflect once: "I'd like to learn more about the role first - what range is budgeted for this position?" If pushed, give a researched range whose bottom is your real target, never a single number.
Negotiating against yourself. After you counter, stop talking. Make the ask, then be quiet. Nervous candidates fill the silence with "but I'm flexible..." - which the other side hears as an invitation to reject the counter.
Justifying with personal needs. "I need more because rent is high" gives them nothing to work with - everyone's rent is high, and needs are not leverage. Justify with market data and what you bring.
Accepting verbally, then trying to renegotiate. Once you say yes, you are done. Any change after acceptance burns trust before day one.

Practice out loud - twice

Reading scripts is not enough. Negotiation lives in your mouth, not your head. Say the review-window sentence and the counter script out loud twice - once alone, once with a friend playing a recruiter who pushes back. It feels silly for ninety seconds; then the sentences come out smooth instead of shaky.

It is the same rehearsal method used to survive your first public presentation: short script, spoken reps, one simulated pushback.

If you have a competing offer

A written competing offer is legitimate leverage; a claimed one is not. With one in hand: "I have another offer at $X. This role is my first choice because [specific reason]. If you can match or come close, I'll sign here." Never invent an offer - recruiters in the same market talk, and a called bluff ends the process immediately.

Closing the loop

Whatever the outcome, end warmly. If you accept, confirm the number and start date by email the same day. If you decline, thank them by name and leave the door open - entry-level markets are small, and the recruiter you turned down gracefully this year may hold the budget for the job you want in two.

And once you are in the seat, keep a wins file: projects shipped, numbers moved, praise forwarded. Your first negotiation set the baseline; your second, eighteen months in, will be argued from that file. Nobody negotiates brilliantly the first time - the accountants who retrained as designers in eight months without a degree simply did it, learned, and did it better the next round.

Quick reference: the five sentences

Buy time: "Could you send the offer in writing? I'd like to review the full package and respond by Thursday."
Deflect early: "What range is budgeted for this position?"
Counter: "Based on my research and the experience I'd bring, I was targeting $58,000. Is there flexibility to get there?"
Backup ask: "Could we look at a signing bonus to bridge the difference?"
Accept: "That works - I accept. Looking forward to joining the team."

Learn the scripts, do the research, take the two days, and make one calm, specific ask. Worst realistic case is a polite no and the original offer - which is exactly what you would have gotten anyway. Best case is a permanently higher baseline for your entire career.

Want more no-fluff guides to practical skills that pay off fast? Head back to Learn To.

This guide was originally published on LearnTo — step-by-step guides for learning real-world skills as an adult.

Your First 30 Days of Python: A Day-by-Day Roadmap

G105g — Sun, 04 Oct 2026 11:14:58 +0000

Ask around and you will notice a strange pattern: plenty of people "started learning Python," and very few finished a month. Python is not the problem. It is famously the friendliest major programming language, close enough to plain English that reading it feels like reading instructions. The problem is that most beginners have no plan. They drift through random videos, hit week two, get busy, and quietly stop.

This roadmap fixes that. It is a day-by-day plan for your first 30 days of Python, built for adults with jobs, kids, and full lives. The commitment is thirty focused minutes a day, six days a week. By day 30, you will have written and actually finished three small projects that do useful things in the real world, like cleaning up a messy Downloads folder and keeping a running log of your workouts. No prior experience is needed. If you can rename a file and write a grocery list, you can do this.

Before day 1: one hour of setup

Do not skip this part, and do not spend more than an hour on it either. Setup is where perfectionists go to procrastinate. You need exactly three things:

Python installed. Go to python.org, download the installer for your computer, and run it. On Windows, check the box that says "Add Python to PATH" during installation. That one checkbox saves you a headache later.
An editor. Visual Studio Code is free, popular, and has excellent Python support. Install it, then add the official Python extension.
A notebook. A paper notebook or a plain text file. Every day you will write down one sentence about what confused you. This tiny habit is what turns thirty scattered sessions into actual skill.

Resist the urge to install twelve tools or research the perfect setup for a week. The best environment for a beginner is the one you already understand.

Week 1 (days 1-7): the core vocabulary

Your only goal this week is to get comfortable typing code and running it. Think of these seven days as learning the vocabulary of a language before you try to hold a conversation. If you want a wider view of the journey before you start, our guide on learning to code from scratch pairs well with this week.

Day 1: Install everything, then write and run a one-line program that prints a message on the screen. That moment of "it worked" is the entire assignment.
Day 2: Variables and numbers. Store a value, change it, print it. Do a few calculations like tip splitting on a dinner bill.
Day 3: Strings (text). Join them, turn everything to uppercase, count letters. Printing the first and last letter of your name counts as real practice.
Day 4: Getting input. Ask the user a question with input(), store the answer, and print a reply that uses it.
Day 5: Making decisions with if statements. Write a tiny program that says whether a number is big or small.
Day 6: Repeating things with loops. Print every number from 1 to 100 without typing 100 lines. Feel the power.
Day 7: Review. Reread your notes, redo anything that felt fuzzy, and take a real rest day. Rest is part of the plan, not a failure of it.

A warning for this week: your code will be full of errors, and that is the normal state of programming, not a sign you are bad at it. Errors are not alarms. They are the computer's way of saying "almost." Read them, fix one thing, run again.

Week 2 (days 8-14): structures and functions

The second week is where scattered commands start becoming actual programs. Everything still costs thirty minutes, but the payoff grows daily.

Day 8: Lists. A list is exactly what it sounds like: a row of values in order. Make a grocery list, then print the third item on it.
Day 9: Growing and shrinking lists. Add items, remove them, sort them alphabetically. You are now doing data entry without the spreadsheet.
Day 10: Dictionaries. Store pairs, like the price of each thing on your list, and look them up by name.
Day 11: Loops over collections. Walk through your list and print each line with a number in front of it. You just built a numbered to-do list generator.
Day 12: Functions. Wrap code you have already written into a named block you can reuse. If you copy-pasted anything this week, today you learn to wrap it in a function instead.
Day 13: Files. Read a plain text file, print it, and write something new into another file.
Day 14: Review plus a mini-challenge: a program that takes items you type and saves them to a file as one grocery list. It is small, and it is yours. That feeling matters.

Week 3 (days 15-21): project one, something that cleans your clutter

Weeks 1 and 2 were drills. Week 3 is your first real project, and it is deliberately boring in the best way: a program that tidies your Downloads folder. Every computer owner has one, a landfill of receipts, screenshots, and final_v2_FINAL files.

Days 15 through 19 follow the same shape. Each day, learn one small piece, then immediately wire it into your project. Day 15, list the files in a folder from your program. Day 16, group them by file type. Day 17, create subfolders for each type. Day 18, actually move the files, first with a dry-run that only prints what it would do. Moving files around with code for the first time is nerve-wracking, which is why the print-then-run habit you build today is permanent professional practice. Day 19, polish it and run it for real on a folder that matters slightly less than Downloads, just in case.

On day 20, customize it: skip PDFs, handle duplicate names, print a tidy summary of what moved. Day 21, review and write down what the project taught you. You will notice it is a longer list than any tutorial could give you, because you made every decision yourself.

Week 4 (days 22-30): project two, something you will actually use

The final stretch is a project of your own choosing, kept deliberately small. The rule: it has to be finished by day 29, so pick something skinny. Good candidates that require nothing beyond what you learned:

A workout logger that appends each session, with date and exercise, to a single text file. Pair it with a simple routine like our 5-move full body beginner workout, and your logs will fill up fast.
A spending tracker where you type an amount and a note, and the program keeps a running total by month.
A split-the-bill calculator for your next group dinner, with tips and uneven shares.
A random "what should I cook" picker from a list of meals you actually know how to make.

Days 22 to 26 are building. Day 27 is the bug hunt day: try to break your own program with weird input, then fix what breaks. Day 28 is cleanup, with better names and a few comments so a stranger (including future you) could follow it. Day 29, show it to one person and let them use it. Their confusion is free usability testing. Day 30, write down everything you can do now that you could not do on day 1, then take the evening off. You earned it.

The daily thirty-minute routine (this is the actual secret)

The single best predictor of who finishes this roadmap is not talent or free time. It is structure. Split each thirty-minute session like this:

5 minutes: reread yesterday's notebook note and rerun yesterday's code to re-verify it works.
20 minutes: today's new material, typed by hand. Not pasted. Typing syntax is how your hands learn it, and hands have longer memory than you would think.
5 minutes: write your one-sentence note. Even "still confused about dictionaries" is a perfectly good entry.

Thirty minutes is not very long, so protect the practice itself. This is exactly the principle behind learning any skill faster: short, focused, slightly uncomfortable reps beat long, fuzzy sessions every time. If you only have ten minutes on a commute, do the review and note portions. Streaks survive on flexibility.

Three traps that kill month one (and how to dodge them)

Tutorial collection. The urge to watch one more course before "really starting" is the most common way beginners stall for months. Watching someone cook is not cooking, and watching someone code is not coding. Spend your minutes typing. If you recognize yourself here, our piece on why tutorial spiraling wastes your time is worth ten minutes of your life.
Comparison speed. Some teenager somewhere learned this in a weekend. So what. Your race is against your own day 1, and the clock that matters is daily minutes, not weeks.
The perfect environment. New editor, new font, new theme: all procrastination in a trench coat. This roadmap assumes one boring editor for all thirty days. Change nothing until day 31.

After day 30: keep the ball rolling

Thirty days makes you a beginner with momentum, which is the most valuable thing in programming. Keep the thirty-minute window, pick one new small project per month, and let every project force you to learn just one new thing. That is the whole engine, and it never needs to change.

When you want structured, human-led guidance to go with your own practice, the coding lessons on LearnTo are built for exactly this stage: real practitioners, real projects, no fluff. Your first 30 days prove you can learn this. The next 30 prove you will not stop.

This guide was originally published on LearnTo — step-by-step guides for learning real-world skills as an adult.

How to Learn Coding from Scratch in 2026 (No Degree Required)

G105g — Sun, 04 Oct 2026 11:14:55 +0000

82% of working developers learned to code through online resources, not formal education. That's not a marketing stat — that's from the Stack Overflow Developer Survey.

The barrier to learning coding isn't talent. It isn't math skills. It isn't age. The barrier is that most beginners follow the wrong roadmap: they try to learn everything, get overwhelmed, and quit.

Here's how to learn coding from scratch — the roadmap that actually works in 2026.

Pick one language. Just one.

The #1 mistake beginners make: trying to learn multiple languages at once. "I'll learn Python and JavaScript and Rust and..." No. Pick one. Learn it well. Then branch out.

Which language to pick in 2026

If you don't know which to pick: Python. It's the gentlest learning curve, the most versatile, and the job market is strong. You can learn Python in 2-3 months and build real projects.

If you specifically want web development: JavaScript (then TypeScript). Every website uses it. The job market is enormous.

Don't pick: C++, Rust, Java, or Go as your first language. They're powerful but the learning curve will slow you down. Learn them later when you have a reason to.

The 3-month roadmap

Month 1: Fundamentals

Learn the basics of your chosen language. Not frameworks. Not libraries. The language itself.

What to learn:

Variables, data types (strings, numbers, lists, dictionaries)
Conditionals (if/else)
Loops (for, while)
Functions
Basic error handling

What NOT to learn yet:

Frameworks (React, Django, Flask)
Git (learn it in month 2)
Deployment
Data structures and algorithms (wait until you can build things first)

How to practice: Build small things. Not tutorials — actual small programs.

A calculator
A number guessing game
A program that converts temperatures
A text-based adventure game

Each one teaches you something new. None of them require frameworks or libraries.

Time commitment: 1-2 hours per day. 30-60 hours total in month 1.

Month 2: Build real things

Now you know the basics. Stop watching tutorials and start building.

What to build:

A to-do list app (the classic — but actually build it, don't copy a tutorial)
A weather app that fetches data from a free API
A simple website with a contact form
A script that organizes files on your computer

What to learn alongside building:

Git and GitHub (version control — essential)
How to read documentation (more valuable than any tutorial)
Basic debugging (reading error messages, using print statements)
How to search for answers (Stack Overflow, documentation)

The key principle: Every time you get stuck, try to solve it yourself for 15 minutes before looking up the answer. If you look up the answer immediately, you learn nothing. If you struggle for 15 minutes first, you'll remember the solution forever.

Time commitment: 2 hours per day. 60 hours total in month 2.

Month 3: Build something someone would use

This is where most beginners plateau. They keep building tutorial projects that no one would actually use. Break out of that pattern.

What to build:

A project for a real person (a friend's portfolio site, a small business's contact page)
A tool that solves a problem you actually have (a habit tracker, a budget calculator)
An open-source contribution (fix a small bug in a project you use)

What to learn alongside:

How to deploy a project (Vercel, Netlify, Railway — all free)
Basic HTML/CSS (if you're doing web development)
How to write a README
How to present your work (portfolio, GitHub profile)

Time commitment: 2-3 hours per day. 60-90 hours total in month 3.

By the end of month 3: You should have 3-5 projects on GitHub, one deployed live, and the ability to build a simple application from scratch without following a tutorial.

What about data structures and algorithms?

Most beginners panic about this. They think they need to learn Big O notation, dynamic programming, and LeetCode before they can build anything.

You don't. Here's the order:

Learn to build things first. Get comfortable writing code. Ship projects.
Learn basic data structures (lists, dictionaries, sets, stacks, queues) — you'll pick these up naturally while building.
Learn algorithms when you need them. Sorting, searching, basic optimization — you'll encounter these in real projects.
Study for interviews when you start applying. That's when you grind LeetCode. Not before.

Learning DSA before you can build a function is like studying architecture before you've laid a brick. Learn the craft first, the theory second.

Should you use AI coding assistants?

Yes — but not as a crutch. AI coding assistants (Cursor, GitHub Copilot, ChatGPT) are powerful tools, but beginners often use them wrong.

Right way: Use AI to explain concepts you don't understand, debug errors, and suggest approaches. Then write the code yourself.

Wrong way: Let AI write all your code. You'll never learn. When the AI makes a mistake (and it will), you won't know how to fix it.

Rule of thumb: If you can't explain what the AI-generated code does, don't use it. Write it yourself first, then compare to the AI's version.

How to know when you're ready for a job

You don't need to know everything. You need to be able to:

Build a working application from a spec
Debug your own code
Read and understand someone else's code
Use Git confidently
Deploy a project live

If you can do these 5 things, you're ready for junior-level interviews. You won't pass every interview — but you'll pass some. And each interview teaches you what to learn next.

The biggest mistake you can make

Waiting for permission. Most beginners spend 6 months "preparing" before they build anything real. They watch tutorials, read books, take courses — and never ship a single project.

The developers who get hired are the ones who build things. Badly, at first. But they build. Their GitHub has commits. Their portfolio has projects. They can talk about what they built and what they learned from it.

Stop preparing. Start building.

Ready to learn from real professionals?

Browse Lessons ->

Learn coding from a senior software engineer who writes code daily — not from a YouTuber who learned Python last month. Short, practical lessons that teach you what you actually need to know.

LearnTo provides video lessons from vetted, credentialed professionals — not content creators. Every instructor is verified with real credentials and experience.

This guide was originally published on LearnTo — step-by-step guides for learning real-world skills as an adult.