Career change to programming: a plan that fits a real week

Open your calendar and look at the last two weeks. Not next month’s plan, the record of what happened: when you got home, which evenings went to things that couldn’t be moved, how many times you sat down to something difficult after ten at night.

That column decides a career change to programming.

Not the choice between C# and Python. Not whether you were good at maths at school. The material is everywhere and mostly free, and hours are the one input you can’t buy more of.

The plan below is one calculation and four stages. The calculation: how many hours you have in a week, counted honestly. Language basics come next, until you stop guessing at syntax. After that the tooling nobody covers in a language course. Last, one project finished to the end, and only then your CV.

Do the hours audit once, honestly

Take your last ordinary week, no holiday and no flu, and write down every free block over an hour. Subtract the ones where you’re too tired to read anything new.

What’s left is your budget.

The subtraction hurts. An evening with a commute, a shop and dinner in it leaves ninety minutes, not the three hours it looked like on paper. Monday after a long meeting is a write-off, though the calendar shows it as identical to Thursday. An hour before bed logged as study is usually an hour of reading about study, which is a different activity entirely.

Full-time job plus a child at home lands most people between five and ten hours. No kids and a job that ends at five, and twenty is real. Between jobs or on notice it goes higher, but that window closes fast and makes a bad foundation for anything longer than a quarter.

Write the number down. Treat it as an input. Everything else in the plan derives from it, not the other way round.

The common failure looks like this: someone writes down fifteen hours because fifteen sounds like what it takes, does two, and a month later shelves it convinced they have no aptitude. Planning five and doing five is the identical rate, and it would have felt like winning.

Five, ten, and twenty hours a week

Rather than estimate, count against a real syllabus. The course “Mastering C# and .NET 10” has 10 parts, 60 chapters and 670+ lessons, and the material is costed at roughly 100 hours.

The hundred hours cover the material alone.

It excludes the evening you lose to a typo in a filename, and the time a project takes when nobody tells you what to type. Double it for a number closer to the truth: two hundred hours, counting everything.

At five hours a week that’s forty weeks. At ten, twenty weeks. Twenty hours a week cuts it to ten, except you won’t hold that rate unless somebody else is doing the shopping and cooking while you do it.

Here is five hours written into a calendar instead of a resolution: Tuesday and Thursday from 8:15 to 9:45 in the evening, Sunday from 9 to 11 in the morning.

Ten: Tuesday and Thursday 8pm to 10pm, Saturday 9am to 1pm, Sunday 9am to 11am.

Twenty: Monday to Friday, 9am to noon, plus Saturday 10am to 3pm.

The catch is defending the blocks, which is a separate skill. Tell the people you live with which evenings are taken, concretely: Tuesday and Thursday after eight, not “some evenings”. Silence your phone for the block: after a glance at a notification you come back to the start of the problem, not the same line of code. Leave one evening a week empty, as slack for when something lands on you.

Add the times up on your own calendar before deciding which is yours. Three evenings a week looks harmless in a table and looks different in the fourth week of November, when it’s dark by four, your employer is closing the quarter, and you sit down to loops and collections.

What a quarter actually buys

A quarter is 13 weeks, so every budget multiplies out into something you can look at without hope in the way.

Five hours a week is 65 hours, less than half the material. After a quarter you know types, loops, collections and classes, you write console programs a few dozen lines long, and you don’t have a project yet. It isn’t failure. It’s the rate of five hours, and knowing that in January beats discovering it in May.

Ten hours gives you 130 hours: most of the material, plus the start of something of your own. You can read an error message, you know what a debugger is for, and one program on your disk was in no course.

Twenty hours is 260 hours in a quarter: the whole syllabus and a finished project. Somebody else spreads the same learning across nine months, and repeats more of it.

A quarter broken by a two-week holiday doesn’t cost two weeks, it costs three, because the return starts with rebuilding what was clear before you left. A smaller unbroken budget beats a larger ragged one, and five hours every week is worth more than twenty every third.

None of those three lines says anything about getting hired. They describe material covered and nothing more.

The order that doesn’t waste months

Language first, until you stop guessing. Types, loops, collections, classes, exceptions. Exercises get you there rather than video: this syllabus carries 328 exercises against 200 explanatory lessons, and the ratio is deliberate, because writing code isn’t something you can watch.

Tooling next, and this is the stage that falls out of most plans.

A debugger, so you can look at variable values instead of printing them in ten places. Git as far as commits, branches and merging, including one conflict resolved by hand, because a conflict is what finally explains what a branch is. SQL to the level of a JOIN, a foreign key and one index. HTTP with its status codes, so that 404 and 500 stop being the same outage. Then a handful of unit tests, run by a command rather than by clicking around the app.

In a junior interview, questions from that list come up more than syntax questions, and “I haven’t used it” three times in a row ends the conversation.

Then the project. One, finished.

Your CV goes last, and not out of principle. Sent during stage two it comes back as silence, and silence after twenty applications turns study into something you avoid in the evening.

What counts on the CV isn’t the course name, it’s what sits next to it. A link to a repository with a few months of history, one sentence on what the program does, and an honest list of what you can’t do yet. Whoever reads it opens the repository before the cover letter, and sees the order of your commits rather than the final state of the files.

The same order sits behind the course syllabus: from a first program, through objects and LINQ, to tests, an ASP.NET Core API, and a project with a database. Still choosing a language? The C# and Java comparison settles that one in an evening.

A first project with files in it

A project at this stage isn’t a portfolio piece. It’s evidence you can carry something to the end, and the first place where nobody tells you what to type.

Pick something you use yourself. A household budget is enough.

Two weeks in, the directory holds this:

budget/
├── Budget.csproj
├── Program.cs
├── Expense.cs
├── Category.cs
├── ExpenseStore.cs
└── expenses.csv

Five code files and one of data. Program.cs reads commands from the console, Expense.cs describes a single expense, Category.cs is an enum, and ExpenseStore.cs writes and reads the CSV file.

Look at what the list leaves out. No login, no browser panel, no charts, because a first project has to get finished, not impress anyone in an interview. Six months later you’ll add things you can’t name today.

The first real bug will hit you on the amount. Write 12.50 to the file, hand it to a machine where the comma is the decimal separator, and the parse either fails or hands back 1250. That’s the evening you learn what CultureInfo is, and why data gets written in a format independent of whoever’s machine reads it.

The second bug waits in an empty CSV your program has never seen, and teaches you to write code for data you didn’t invent. An empty file isn’t the same as a missing one, and the program has to tell them apart.

Once that works, swap the CSV for a database, add tests, and expose the same data as an API. The course closes on a multi-file project called TaskTracker.

What this plan doesn’t promise

A career change to programming comes with no promise of being hired. Nobody can promise that. Anyone who does is selling something other than teaching: hiring depends on the market in your city, on how many people are looking for a first role at the same time, and on whether anyone at the company has time to bring a junior up to speed.

Finishing a course doesn’t equal being ready for the work either. A course gives you material and an order. The rest you do on your own mistakes, and that part can’t be compressed.

No schedule survives a sick child and a quarter-end at once. A budget with slack in it does, which is why five real hours beat ten hopeful ones.

Whether learning to code still makes sense while models write code needs its own article. In the hours calculation it changes one thing: time spent transcribing syntax is better spent reading somebody else’s code and checking whether it does what it claims.

Worth knowing what the tool itself doesn’t promise: DevJourney runs on Windows 10 and 11, needs the .NET SDK 10 installed, and has no macOS or Linux build. On a Mac the plan is unchanged, you assemble the environment yourself.

When to stop or change approach

Three weeks without opening the editor isn’t laziness. It’s information that the plan doesn’t fit your week, and the right response is halving the budget, not another restart from chapter one.

If the course goes fine but a blank file paralyses you, stop the course halfway and write something small. The block doesn’t clear by watching more lessons.

If you’re starting a fourth course without having finished the first, the problem isn’t which course you picked.

Sometimes changing the approach is cheaper than a break. Two months of video with no program written from scratch means the next course won’t fix anything: put it down and rewrite from memory the simplest program you’ve seen in that time. It’ll come out badly, and it’ll be the first evening you spend learning to write instead of learning to watch.

There’s also the case few people write about: sometimes the right decision is to drop it. When you sit down out of obligation after four months, nothing in it interests you, and the only thing holding you there is a picture of a better salary, that’s a calculation too. Plenty of roles sit next to writing code, and what job ads actually ask for is worth reading before you decide you’re out of the field.

Start on Wednesday evening

Write study blocks into your calendar, with times, for the next two weeks. Then, the same evening, install the .NET SDK 10 and write a program that asks for your name and answers you by it.

If those blocks are still standing on Friday and nothing has eaten them, you know your budget, and you can plan in months rather than in bursts of enthusiasm.