So You Haven’t Done Much Dev Work in 15 Years. Good News!
I’ve been spending a lot of time coding lately.
Like, a lot.
And one of the things I keep realizing is just how different software development feels now compared with the way a lot of us first learned it.
I have a few friends who are smart, nerdy, technically inclined people, but for one reason or another they haven’t really been following the software development world for the last 10 or 15 years.
Maybe they wrote some PHP years ago. Maybe they know HTML. Maybe they took a programming course. Maybe they built things in Visual Basic, Java, Perl, C, or whatever else was handy at the time.
And when I start showing them the tools I use now, there’s often this assumption that they have an enormous amount of catching up to do.
They really don’t.
There are certainly more technologies than ever before. The JavaScript ecosystem alone has apparently made it its mission to ensure nobody can ever learn all of it.
But the actual process of making useful things with computers has become ridiculously accessible.
Especially if you’re curious and willing to experiment.
The big change: you don’t have to know how to do something before you start doing it
This might be the single biggest difference.
The old model of learning to program was something like:
- Pick a language.
- Buy a giant book about it.
- Learn the syntax.
- Learn the standard library.
- Spend three evenings trying to figure out why your compiler hates you.
- Eventually make something.
There was obviously plenty of experimentation involved, but there was a fairly high knowledge barrier between “I have an idea” and “I have something running.”
That barrier has collapsed.
These days, if I have a complicated problem, my first thought is increasingly:
I can probably solve this with code if I can explain the problem clearly enough.
That doesn’t mean AI magically does all the work.
It means I don’t necessarily have to know the exact Python library, shell command, browser API, Astro feature, regular expression, or obscure configuration syntax before I begin.
I can figure those things out as I go.
That is a pretty massive shift.
“I don’t know Python” is not much of an obstacle anymore
Imagine I have a directory containing 800 photos.
The filenames are useless, and I want to rename them using the date each photo was taken.
Years ago I might have thought:
I should probably learn enough Python to do this someday.
Now my thought process is more like:
This is repetitive. The input is predictable. The desired output is predictable. A computer should absolutely be doing this.
So I can explain the problem to an assistant:
I’m on macOS. I have a directory of JPEG images. I want to rename them using their EXIF capture dates. Make me a safe Python script that shows me what it would rename before it changes anything.
A few seconds later, I have something to inspect and try.
Then maybe it breaks.
Great.
I paste in the error.
We fix that.
Then I notice some photos don’t contain EXIF dates.
Great.
Now we handle that case.
By the end of the exercise I’ve probably learned quite a bit about Python, EXIF metadata, file operations, error handling, and whatever library we ended up using.
But I learned those things while solving an actual problem.
That feels much more useful to me than spending three weeks studying Python before I’m allowed to touch a file.
This does not mean you don’t need to understand anything
There is an obvious trap here.
If you blindly paste instructions into an AI and blindly run whatever comes back, you are going to have a bad day eventually.
Possibly an exciting one.
The skill isn’t simply:
Get AI to write code.
The skill is:
Describe the problem, inspect the proposed solution, try it safely, observe what happens, and iterate.
That’s engineering.
And the better you understand the fundamentals, the better you become at all of those steps.
I still want to know what a variable is.
I want to understand roughly what an HTTP request does.
I want to recognize an array, an object, a loop, a function, a database query, and a filesystem path.
I just don’t think I need to memorize every method and argument anymore.
There is a big difference between understanding something and remembering the precise incantation required to make it happen.
Computers are pretty good at helping with the second part now.
Modern development is mostly a collection of surprisingly simple ideas
Some of the terminology makes the modern development world sound more intimidating than it really is.
Take JSON.
JSON is everywhere.
APIs return JSON. Configuration files contain JSON. VS Code uses JSON. JavaScript projects contain package.json. AI tools generate JSON.
That sounds like another technology you need to learn.
But then you look at some:
{
"name": "Simon",
"skills": ["HTML", "CSS", "JavaScript"],
"available": true
}That’s basically it.
It’s a boring, standardized way for computers to write down structured information.
Objects have things in them. Lists have things in them. Text has quotes around it.
Congratulations. You are now dangerously close to understanding JSON.
A surprising amount of modern development is like this.
The individual idea isn’t particularly difficult. You just encounter a whole bunch of them at once.
VS Code is basically a cockpit
If you haven’t done much programming lately, install Visual Studio Code.
There are lots of other editors, and nerds are legally required to argue about them, but VS Code is a very good place to start.
At first it looks like a text editor with a bunch of buttons.
It’s really more like a cockpit for your project.
You have your files on the left.
Your editor in the middle.
A terminal underneath.
Git integration.
Extensions.
Search across everything.
Debugging tools.
AI assistance.
You can spend most of your working day inside one window.
The important conceptual change is realizing that your project is mostly just a folder full of files.
Open the folder.
Look around.
Change something.
See what happens.
You do not need to understand everything in there.
In fact, this is another useful modern development habit:
Look at the files.
Seriously.
A shocking amount of figuring out unfamiliar software begins with simply looking at what is in the project.
The terminal is not just for wizards anymore
The terminal used to have a particular mystique around it.
You’d see somebody furiously typing commands into a black window and assume they had spent 20 years memorizing Unix.
Sometimes they had.
But the terminal is better thought of as an interface where you can tell your computer exactly what to do.
That’s incredibly useful.
You don’t need to memorize 500 commands.
You need to get comfortable with the idea that commands exist.
If I forget how to find every file larger than 500 MB?
I look it up.
If I need to convert 100 images?
There is probably a command for that.
If I need to search 20,000 files for a weird bit of text that somebody injected into a compromised WordPress site?
There is definitely a command for that.
The terminal becomes especially powerful when combined with AI because you can describe what you’re trying to accomplish instead of already knowing the exact command.
Just make sure you understand what a command will do before pasting something destructive into your computer.
That little bit remains important.
Git is your permission to screw around
Git is another tool that gets taught in a needlessly intimidating way.
Technically, yes, Git is a distributed version control system with a fascinating internal object model.
You absolutely do not need to care about that on Tuesday afternoon when you are trying to change a button.
The most useful beginner explanation I know is:
Git remembers changes to a folder.
That means I can experiment.
I can change something.
Then I can ask:
What changed?If I like it, I keep it.
If I don’t, I undo it.
Once I have a chunk of work I’m happy with, I make a commit — basically a named checkpoint.
That changes the way you work.
Instead of being afraid to touch something because you might break it, you start thinking:
Eh. Let’s try it.
That is incredibly freeing.
It is also why I think git status and git diff are more important things for a beginner to understand than half the fancy Git commands people like teaching.
Change something.
Look at what changed.
Test it.
Keep it or throw it away.
That loop is modern development in miniature.
Websites got weird, and then they got easy again
Web development went through a period where everything seemed to require an application server, a database, a complicated framework, a pile of JavaScript, several build systems, and probably a Docker container running somewhere for reasons nobody could quite explain.
There is still plenty of that.
But there is also a wonderfully simple approach available again.
If I want to make a fast website today, I might use something like Astro.
I can run a project generator, edit a few files, type a command, and have a development server running locally almost immediately.
Then I connect the project to GitHub and something like Cloudflare can build and deploy the site when I push changes.
Suddenly I have:
- HTTPS
- a CDN
- automated builds
- Git history
- deploy previews
- globally distributed static files
…for something that may basically be a fancy collection of HTML pages.
That is wild.
This general approach is often associated with the term JAMstack.
The exact label is less important than the idea:
Start simple. Add complexity only when you actually need it.
If the website can just be files, let it be files.
If you need some dynamic data, fetch it.
If you need an API endpoint, add one.
If you need a database, then add a database.
You don’t have to begin every project by constructing a tiny imitation of Amazon.
Packages mean somebody probably already solved the boring part
Another big change is how much software development now involves assembling existing pieces.
Need to parse Markdown?
Install a package.
Need authentication?
There are libraries and services for that.
Need to resize an image?
Someone has already spent an unreasonable portion of their life solving that problem.
This is another mindset I try to encourage:
Before building something complicated, check whether somebody already built the boring part.
Modern development is often less about writing every component yourself and more about choosing good components and connecting them sensibly.
That makes understanding the shape of the problem extremely valuable.
AI is especially good at helping you cross unfamiliar territory
This is where I think things become really interesting for people who are returning to development.
You don’t need to spend six months catching up before you are allowed to build something.
Suppose you encounter this in some JavaScript:
const response = await fetch(url);
const data = await response.json();You vaguely know what’s happening but await is new to you.
Ask:
Explain these two lines to somebody who understands older procedural programming but hasn’t used modern JavaScript.
That explanation can meet you where you actually are.
Then ask:
Show me what happens if I don’t use
await.
Then try it.
Then break it.
Then ask why it broke.
This is an unbelievably powerful way to learn.
AI isn’t just a code generator.
It can be a tutor sitting beside you while you experiment.
And unlike a book, it is perfectly happy to explain the same thing six different ways until one of them clicks.
Ask better questions, get dramatically better results
One thing you learn pretty quickly is that the quality of what you get back depends heavily on how well you describe the problem.
Compare:
Make a website.
with:
Make a small Astro site for a local landscaping business. It should be mostly static, load very quickly, have a homepage, services page and contact form, and be easy for somebody comfortable with HTML and CSS to maintain. Avoid adding JavaScript unless it solves a specific problem.
That second prompt contains decisions.
Constraints.
Context.
Intent.
Those things matter.
And this skill transfers well beyond AI.
Explaining a technical problem clearly has always been valuable.
Now you just happen to have a machine sitting there that can immediately do something useful with the explanation.
Learn how to navigate ignorance
This might actually be the most important thing I’d teach somebody getting into development today.
You are never going to know all of this.
Neither do I.
Nobody does.
There are too many languages, frameworks, services, packages, APIs, configuration formats and extremely enthusiastic people releasing JavaScript libraries.
The goal isn’t to reach a point where you know everything.
The goal is to become comfortable saying:
I don’t know how that works yet. Let’s find out.
That little word — yet — makes a big difference.
An experienced developer often isn’t somebody who immediately knows the answer.
They’re somebody who recognizes what kind of problem they’re looking at.
They know where to look.
They know what questions to ask.
They know how to make a small experiment.
They know how to tell whether the result seems plausible.
And they know enough not to type sudo rm -rf just because a confident robot suggested it.
Usually.
Make the smallest thing that works
This is another lesson I keep relearning.
You have an idea.
Your brain immediately imagines the finished system.
User accounts! Databases! Dashboards! Notifications! Mobile app! AI! Blockchain!
Maybe not blockchain.
Hopefully not blockchain.
But all of that imagined complexity can stop you from beginning.
Instead, make the stupid version.
Can the first version be one HTML page?
Do that.
Can the first version read a local JSON file instead of using a database?
Do that.
Can you manually run the script before worrying about scheduling it?
Do that.
Once the little thing works, you have something concrete to improve.
This approach pairs extremely well with modern tools because creating that first tiny version has become so cheap.
My current development loop is basically this
I have a problem.
I try to describe it clearly.
I look at what I already have.
I ask questions.
I make the smallest change that might work.
I run it.
I read the error.
I check the diff.
I change something else.
Eventually, the computer does the thing I wanted.
Then I commit it before I break everything again.
That’s most of it.
The tools are better now.
Deployment is easier.
Libraries are everywhere.
Documentation is easier to search.
AI can explain unfamiliar code, write repetitive pieces, propose solutions and help decipher errors.
But the fun part is still the same thing that made me interested in computers in the first place:
You can make the machine do stuff.
And once you start seeing annoying, repetitive, complicated problems as things that might be solvable with code, the world gets considerably more interesting.
So if you used to program but feel like the industry disappeared over the horizon while you were busy doing something else, I wouldn’t worry too much about catching up.
Grab VS Code.
Open a terminal.
Make a folder.
Build something small.
Ask a ridiculous number of questions.
Break things.
Use Git so you can unbreak them.
And whenever you catch yourself thinking:
I have no idea how to do that.
Try adding:
…but I can probably figure it out.
Because these days, you probably can.