The question
A colleague asked me recently how to get started with coding. Not a career change question exactly - more a "I want to learn, I don't know where to begin, there's too much out there" kind of thing. We were grabbing coffee and I gave them the short version. This is the long version.
Picture a stone thrown into still water. The moment it leaves your hand, you've already started. The ripples don't ask permission - they just spread. Learning to code works the same way. The stone is the first thing you build. The question isn't where the ripples go. The question is whether you throw it.
I'll answer it the way I wish someone had answered it for me.
Read. Actually read.
Before anything else: if you want to learn something, you need to read. Not scan, not skim, not have it summarised at you by a chatbot. Read.
AI generates enormous amounts of text and code now, and it's easy to consume that output passively - to have things explained at you without any of it actually landing. But reading is not a passive act. It's the mechanism by which ideas become yours. You slow down, you process, you argue with it, you re-read the part that didn't click. That's learning. The rest is just scrolling.
A note on this site specifically: some of what you find here was written with AI assistance. All of it was read, reviewed, and edited by me. Every opinion is one I actually hold. Every fact is one I've checked. Nothing goes up because a model produced it convincingly - it goes up because I read it, agreed with it, and am willing to put my name on it. That's what you get here. Elsewhere on the internet, nobody is making you that promise - so read critically.
The starting point is not the problem
The internet has an unlimited supply of starting points: bootcamps, degrees, YouTube tutorials, FreeCodeCamp, LeetCode, "the best Python course for beginners," "learn Rust in 30 days." Pick any of them. The starting point is not the bottleneck.
The bottleneck is shipping something real.
The people who succeed at this don't pick the best starting point - they pick a good enough one, and then they build something. Everything else follows from that.
How I got here
My background is geophysics. But I was already writing small scripts on the job - automating data processing, building little tools to make the team faster. That was already programming, I just hadn't called it that. So while I was still working as a geophysicist, I went back and did a degree in Software Engineering. Not to escape the field, but because it was the natural next step from writing scripts that worked to understanding why they worked.
The full story is in From Geophysics to Red Hat. The short version: analytical thinking transfers, domain knowledge transfers, and coming in "late" is less of a disadvantage than it looks from the outside.
Pick a language - any language
A programming language is how you give instructions to a computer. The computer only understands electrical signals - ones and zeros - but a programming language lets you write something a human can read, and a translator (called an interpreter or compiler) converts it into something the computer can run.
There are hundreds of languages: Python, JavaScript, Go, Rust, Java, C, Swift. They all do roughly the same thing in different ways. For a first language, pick Python. Here's why: it reads almost like English, the error messages tell you what went wrong instead of just crashing, and there's a library (a collection of pre-written code) for almost anything you'd want to build.
Download Python from python.org. Install it. Then open your terminal - on Mac, search "Terminal" in Spotlight; on Linux, it's usually in your applications menu; on Windows, use Git Bash (explained in the Git section below) rather than Command Prompt, as it gives you the same commands as Mac and Linux. Type:
python3 --version
If you see a version number, Python is installed. Now create a new file called hello.py in any folder, open it in a text editor, and type:
print("Hello, world")
Back in your terminal, run it:
python3 hello.py
You just wrote and ran a program. That's it. That's coding. Everything else is just more of that.
Don't spend two weeks deciding between Python and JavaScript. Pick Python, watch three hours of tutorials on YouTube, and try to build something small - a script that tells you the weather, a quiz, a simple calculator. The friction of building something real teaches you more in an afternoon than a week of passive watching.
Learn Git early - not after
Imagine you're writing a long essay and you save a copy every few pages. If you mess something up, you can go back to an earlier save. Git does that for your code - automatically, precisely, and in a way that works across multiple people working on the same thing at once.
Git is how the entire software industry manages code. Every team uses it. Every interview assumes you know it. Learn it now, before your projects get big enough that losing work actually hurts.
First, install Git. On Mac and Linux, open your terminal and type:
git --version
If you see a number, it's already installed. If not - or if you're on Windows - download Git from git-scm.com. The installer includes Git Bash, a terminal application for Windows that gives you the same commands as Mac and Linux. Use Git Bash for everything in this section, not the regular Windows Command Prompt. All the commands below are written for Mac, Linux, and Git Bash on Windows.
Tell Git your name and email. You only do this once:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Now use it on your project. Navigate into your project folder in the terminal:
cd path/to/your/project
git init
git init turns the folder into a Git repository - it starts tracking changes. Now every time you finish a meaningful chunk of work, run:
git add .
git commit -m "describe what you just did"
That saves a snapshot. You can always go back to any snapshot.
Put it on GitHub. Go to github.com, create a free account (pick a username you'd be happy putting on a CV - this is your public developer identity), and create a new repository. Follow the instructions it gives you to push your local project up. Your code is now online, backed up, and something you can show people.
My profile is github.com/c4rt0 - you can see what an active developer's commit history looks like day to day, follow along, or use it as a reference for what to aim for.
Build something real, fast
DSA stands for Data Structures and Algorithms - the fundamental patterns that underpin almost every program ever written. How do you store a list of things? How do you find something quickly? How do you sort a million names in under a second? These aren't abstract puzzles. They're the reason a Google search returns in 0.2 seconds instead of ten minutes.
The DSA Tracker on this site is a free 15-week curriculum that walks you through all of it - from basic arrays to graphs and dynamic programming - with LeetCode problems mapped to each topic. If you're starting from zero or want a structured path through the fundamentals, work through it.
But alongside the curriculum - or instead of it if structured plans bore you - build something. A real thing. Something that would be useful to you or someone you know. Not a tutorial project, not a "follow along with the video" clone - something where you have to figure it out yourself, where Google and error messages are your guide.
The first real thing I built was tradegame.org: a crypto trading simulator, because I wanted to practise trading without real money on the line and nothing free existed that I liked. I used Go and Next.js - both largely new to me at the time. I looked up almost everything. That's the point. The looking-up is the learning. The confusion is the learning. The error message you read three times before it clicks - that's the learning.
Use AI as a learning tool, not a crutch
This is important enough to say clearly: coding with AI is not cheating. It is a different skill than coding without AI, and it's the skill you'll actually use.
The tools to know about: Claude, ChatGPT, and GitHub Copilot (which works inside your code editor and suggests code as you type). All of them are useful. Claude and ChatGPT are good for explaining concepts, debugging errors, and generating whole chunks of code from a description. Copilot is good for autocompleting lines while you work. Start with whichever one you can access for free.
Think of your code as still water. When you hand a task to an AI - "write me a function that takes a list of numbers and returns the largest one", "explain why this error is happening", "refactor this so it's cleaner" - it's a stone breaking the surface. Ripples radiate outward: the AI reads what you've written, cross-references what it knows, generates code. Then they collapse back. It returns its answer. The water settles. Your code has changed, and you didn't have to hold every detail in your head at once.
You throw another stone. This is the rhythm of building with AI.
When I built circl.pl, I worked this way throughout - describing what I wanted, reviewing what came back, shipping in tight loops. The post I wrote about it covers what that feels like in practice.
The thing I learned: the AI moves fast. But it doesn't know if the thing you're building is right. The biggest bug in circl was a privacy model that looked secure but wasn't - and the AI didn't catch it. I caught it because I stopped and read the code carefully. The ripples can spread fast. They can also spread in the wrong direction if you're not watching where you threw the stone.
Use AI to explain, not just to generate. When it writes code you don't understand, ask it: "explain this line by line." Read what it produces before you use it. If you find yourself running code you can't explain, slow down - that's not learning, that's copying. The decisions are still yours. The water is still yours.
Get something in front of people
Deploy means making your code run on a computer that anyone on the internet can reach - not just your own laptop. Right now your project lives on your machine. If you close the lid, it's gone. Deploying puts it somewhere permanent and public.
For a first deployment, you don't need a server or a VPS or anything paid. Netlify and Vercel let you deploy a website for free by connecting your GitHub account and pointing at a repository. Render does the same for simple web apps. You push code to GitHub, and the platform picks it up and puts it online automatically.
Do this as early as you can, even with something unfinished. The gap between "code that works on my machine" and "code that works for someone else" is where the real learning is. You'll hit errors you've never seen, discover things your code assumed about your machine that aren't true elsewhere, and start thinking about what happens when real people use what you built.
Once you're comfortable with the basics and want to understand how servers and operating systems actually work underneath all of this - the Fedora CoreOS self-hosting series goes deep on that. It's not a beginner series, but it's the next step once you've shipped something. You only need a spare laptop or an old mini-PC to follow along - don't let it push you into buying more equipment or setting up complex virtualisation software before you've learned anything from the simplicity.
Contribute something to open source
It doesn't have to be big. Add a test. Fix a typo in the docs. Browse the issue tracker of a project you use and find one labeled "good first issue."
I got to Red Hat by finishing a Software Engineering degree and covering a lot of ground - not through a single clever contribution, but by being broadly capable when the opportunity came. Open source contributions came after and helped me go deeper once I was already there. The Packit post covers one in depth - it's technical, but it shows what the feedback loop looks like on a real project. You submit something, a reviewer asks for changes, things break, you fix them, it merges. That loop teaches you how professional engineering actually works, in a way no course can replicate.
If you want the full walkthrough - how to find a project, how to fork and open a PR, what to expect from review - I wrote a dedicated post: How to Make Your First Open Source Contribution.
The short version
- Pick Python. Build something small. Don't overthink it.
- Learn Git from day one. Push everything to GitHub.
- Work through a DSA curriculum - the tracker has one ready to go.
- Build something real that you actually want to exist.
- Use AI as a pair programmer. Review everything it writes and understand it.
- Deploy it. Get it in front of people.
- Contribute something small to open source.
The path isn't linear. It doesn't have to be. But at every step, the goal is the same: make something real, ship it, learn from what breaks.
Throw the stone. Let the ripples sort themselves out.