Changing Careers Into Software Development at 25–45: An Honest Guide

You are 28, or 36, or 44. You work in sales, accounting, logistics, teaching, or some office role that pays the bills and stopped being interesting three years ago. You have read that developers earn more and can work from anywhere, and you want in. The question is not whether people your age can do this — plenty do it every year. The real question is whether you survive the middle, the part where the excitement has worn off and you still cannot build anything on your own.

This is the version of the advice I wish someone had handed me: the actual timeline, what the person screening applications really looks at, how to find study hours inside a full-time job, and what the first search feels like when nobody in the industry knows your name. What it will not tell you is that this is easy. It is not.

The honest timeline: six to twelve months

Bootcamp ads sell three months. Three months is enough to write your first working program. It is almost never enough to get hired. For someone starting from zero while holding a full-time job, the realistic distance between your first line of code and your first paid developer role is six to twelve months, and twelve shows up far more often than six.

That estimate assumes 10 to 15 hours a week, every week, without a two-month hole in the middle. Consistency beats intensity here by a wide margin. Someone doing 10 focused hours a week for nine months ends up dramatically further along than someone who does 40 hours a week for six weeks and then disappears.

If your life honestly only allows five hours a week, do not pretend otherwise. Just redraw the map: the same journey becomes 18 to 24 months. That is still a completely valid plan. What kills career changers is not slow progress. It is stopping.

What employers actually check

Junior hiring is a filtering problem, not a talent search. A small company in Bangkok or Vientiane advertising a single junior role gets 80 to 300 applications. The person reading them has maybe 90 seconds for yours. Here is roughly what happens, in order.

1. 1They click your portfolio link first. If it does not load in five seconds, or it is a dead deployment from last year, that is the end. Nothing further on your CV gets read.
2. 2They open one project and try to use it. Can they sign up, add something, and see it saved? A beautiful page that only scrolls tells them nothing about whether you can program.
3. 3They open your GitHub and look at the commit history before they look at code quality. Small commits spread over months say this person works steadily. One giant commit named final project says you copied someone else's tutorial.
4. 4They skim your README. Two paragraphs explaining what problem the project solves, what you built it with, and one hard thing you had to fix will beat a gorgeous interface with no explanation, every time.
5. 5Only then do they read your CV, mostly to confirm you are a real person who can hold down a job and work with others.

In the interview the filter changes completely. Junior candidates are rarely rejected for not memorising enough syntax. They get rejected for not being able to explain their own code. If you cannot say why you put that data in a database table instead of a JSON file, or what happens when two people submit the same form at the same second, you look like someone who followed a video. Because you did.

• They do not care much which school or bootcamp you attended, beyond a quick sanity check that you learned in some structured way.
• Certificates carry almost no weight, except in government roles or large enterprises where a document ticks a procurement box.
• Knowing three frameworks shallowly loses to knowing one properly, in every single interview.
• Age matters far less than career changers fear. What a manager actually worries about is whether you will still be learning in year two, not what year you were born.

How to find twelve study hours inside a full-time job

This is the part that decides the outcome, and almost nobody plans it. Do not resolve to study when you have time. You will not have time. Put it in the calendar like a dentist appointment you already paid for. A schedule that survives contact with a real job usually looks like this.

• Weekday mornings, 05:30 to 07:00, three days a week — 4.5 hours. Morning study survives a terrible day at work. Evening study does not.
• One weekday evening, 19:30 to 21:30 — 2 hours. Use this for your live class or the hardest material, while you are still sharper than you will be at 23:00.
• Saturday morning, 09:00 to 13:00 — 4 hours. This is your project block. It has to be long enough to reach deep focus and actually finish something.
• Sunday off, with no guilt. Burnout is the number one reason career changers quit in month four, and it usually arrives disguised as a busy weekend.

Two more rules that matter more than they sound. First, end every session by writing one line about what you will do next; without it you lose the first 20 minutes of the next session just remembering where you were. Second, keep one file called questions.md. Whenever you have been stuck for more than 25 minutes, write the question down and move on. Half of them resolve themselves by the weekend, and the other half are exactly the questions worth taking to a teacher, a senior developer, or a community.

Pick one stack and stop shopping

The single biggest waste of a career changer's first three months is stack shopping. Rust today, Go next week, then four more videos comparing which language pays best. Choose one of these two paths and refuse to change it for at least six months.

• The web path: HTML, CSS and JavaScript, then React and Next.js, plus a small backend and a PostgreSQL database. Most junior openings in Thailand and Laos are web work or internal business systems, so this path has the widest door.
• The Python path: Python fundamentals, then Pandas and SQL for data work, plus automation that talks to APIs. Slower if you measure by the job title Developer, but excellent if you already work in accounting, logistics, HR or operations — you can automate your current job first and change careers from inside your own company.

Everything else — Docker, Kubernetes, TypeScript generics, distributed system design — is real and you will need some of it eventually. None of it belongs in your first six months. Add a tool when a project forces you to, never because a job ad listed it.

One thing you should start in week one is Git, and committing until it is a reflex. Screeners look at this before they look at your code. Here is the shape they want to see.

$ git log --oneline --since=3.months | wc -l
147

$ git log --oneline -6
a3f9c21 fix: handle empty search results
7bd10ee feat: add pagination to the booking list
2c84f0a test: cover overlapping-date validation
9ee3b17 refactor: move API calls into lib/api.ts
41d0c5b feat: send confirmation email after booking
d92aa4e chore: deploy to Vercel, document env vars

That history — 147 commits over three months, small chunks, messages that say what changed, visible progress — does more for you than any certificate you can buy. It is evidence of a habit, and a habit is exactly what a company is purchasing when it hires a junior developer.

Build three projects that look like work, not tutorials

Three is the right number. One is not enough to show range, and five half-finished ones look worse than three finished ones. Each should be something a real business could plausibly pay for.

1. 1A tool for a job you already understand. If you worked at a clinic, build an appointment booking system with a schedule and confirmation emails. Your domain knowledge from your old career is an advantage almost no computer science graduate has — lean on it hard.
2. 2Something that pulls real data from an API. A price tracker, a bus timetable, a converter for baht, kip and dollars. This proves you can handle other people's messy data, which is roughly 80 percent of the actual job.
3. 3A real client site or an internal tool someone will use. Your cousin's restaurant, a friend's tutoring business, the spreadsheet your current team complains about every month. Real users produce real feedback and real bugs, and that gives you ten unrehearsed minutes of interview material.

Every project needs three things without exception. A live URL — Vercel, Netlify and Render all have free tiers that are more than enough for portfolio work. A README with screenshots that says what problem it solves. And a two-minute screen recording walking through it. That video costs you twenty minutes to make and gets watched far more often than you would expect.

What the first job hunt really looks like

This is the part people are least prepared for. Your first search is a numbers game with a low conversion rate, and that is normal rather than a sign you chose wrong.

That process usually takes two to four months of active searching. Send in batches of ten to fifteen a week rather than two a day, and keep a plain spreadsheet with company, date sent, role, contact name and status. By week six you genuinely will not remember otherwise, and following up on the ones that went quiet is where a surprising number of interviews come from.

• In-house IT teams at non-tech companies — hospitals, insurers, logistics firms, retail chains. Less glamorous, considerably more junior-friendly, and they expect to train you.
• Agencies and software houses with 10 to 50 staff. They hire juniors constantly and you will touch every part of a project in your first year.
• Your own network, first and always. In Thailand and Laos a message from someone who has worked with you outweighs a cold application by a large margin. Tell everyone what you are learning and post your projects publicly.
• Small freelance jobs along the way. A single-page site for a few thousand baht is not a career, but on a CV the phrase delivered for a paying client outranks yet another tutorial project every time.

On money, be realistic. In Thailand a first junior developer offer commonly lands somewhere around 18,000 to 35,000 baht a month, with Bangkok product companies at the upper end and provincial in-house roles at the lower. After two or three solid years, 45,000 to 80,000 baht is a band you see frequently. In Laos, local salaries in Vientiane for entry-level roles are often nearer the equivalent of 250 to 500 US dollars a month, which is why many Lao developers aim at remote or contract work with Thai, Vietnamese or international teams, where the rate is set by the market rather than the city. These are ranges commonly seen in the market, not a promise. Your first offer may sit below them, and if the team genuinely teaches you, taking it is still a good trade.

The mistakes that quietly add six months

• Quitting your job before you have an offer or six months of savings. Financial panic makes you a worse learner and a worse interviewer at the same time.
• Studying alone with nobody reviewing your code. You will repeat the same five mistakes for a year without noticing. A teacher, a mentor, a study group or a code review community all work. Zero feedback does not.
• Restarting the beginner course for the third time because you feel unready. You will never feel ready. Build the ugly version now and improve it later.
• Only applying to roles you match 100 percent. Junior job ads are wish lists written by someone who is not the hiring manager. If you match around 60 percent, apply.
• Hiding the career change. Ten years in logistics is not a gap to apologise for; it is the reason you will understand a warehouse system faster than any fresh graduate in the room.

Your first thirty days

1. 1Week 1: choose your path, web or Python, and write the decision down so you stop reopening it. Install VS Code, Git, and Node or Python. Push one repository to GitHub even if all it does is print hello.
2. 2Week 2: block your study hours in the calendar for the next three months, and tell one person about it so skipping costs you something socially.
3. 3Week 3: finish one tiny thing end to end and put it online. A two-page site, a script that renames files. Feeling the full loop early matters far more than the size of the thing.
4. 4Week 4: choose the subject of your first real project based on the job you have right now, write down the three features it must have, and start building it badly.

None of this requires paying anyone. The official documentation is free, and a laptop plus stubbornness is genuinely enough — a lot of working developers got here exactly that way. What a class buys you is the two things that are hardest to arrange alone: someone who reads your code and tells you the truth about it, and a fixed slot each week that you cannot quietly skip. If that structure is what you are missing, the Web Development and Python & AI courses at ALL IN ONE STATION are built around it — six students per teacher, a capstone project, and a schedule that assumes you already have a job. And if you would rather do it alone, do it alone. Just start this week, and still be going in month seven. That is the entire trick.