26 years ago, I was already building real software at 15 — no AI, no Stack Overflow, no modern web.
🧠 A Confession Most Developers Won’t Like
Most developers today would struggle to build software without Google, AI, or Stack Overflow.
That’s not an insult — it’s reality.
Because I learned to code before any of them existed.
❌ No tutorials
❌ No YouTube
❌ No GitHub
❌ No AI
And somehow… I was still building real software at 15.
And the strange part?
I didn’t feel limited.
So this isn’t a nostalgia post. This is a question:
Are we becoming better engineers
or just tool operators?
This isn’t about what I built.
It’s about how building without tools forced me to think differently.
A simplified view of how my development journey evolved over time:
From curiosity to real-world software — built before modern tools existed.
🖥️ Before VB6 — There Was QBasic
Even before QBasic, there was GWBASIC.
And it wasn’t just for experiments.
Here’s a real example.
GW-BASIC financial software from ~1989 — built by my uncle, still running today.
And yes — it still works.
All screenshots in this post are from my original apps, still running on my machine today — decades after the last line of code was written.
It powered real business:
- Accounting systems
- Inventory tools
- Software companies actually depended on
Before Visual Basic, I was writing in QBasic:
- quizzes
- text-based logic
- small experiments
❌ No GUI
❌ No frameworks
Just:
Code + imagination
That’s where the real foundation was built.
And once you build it that way…
you never forget it.
🎮 At 15, I Started Building Games
One of my first projects was a simple XO game.
Nothing special.
But it worked.
Soon after, I built a full Poker game — distributed on CDs with the local magazine "INFO" (2001).
Still just a hobby.
❌ No company
❌ No team
Just:
Curiosity + persistence
And somehow…
That was enough.
🎨 No Designer. No Standards. Just Functionality
❌ No UX thinking
❌ No design systems
❌ No Figma
UI was whatever you could build.
Basic forms.
Standard controls.
Some creativity.
Not beautiful by today’s standards.
But:
✅ It worked
✅ Users got value
And in the end…
that’s what actually mattered.
--
🧩 Games That Never Really “Ended”
I built multiple small games.
- Puzzle games (like Clix)
- Word and quiz-based games
A Hangman game used by university students
My sister was an assistant at the faculty of arts.
I built the game for her students.
And they actually used it.
Clix (2007) — inspired by early puzzle games like Bubble Breaker.
I’ve open-sourced this game. 👉 GitHub link
Yes — it still runs today.
Vockice (2005) — inspired by a slot machine game.
Students would play Vockice whenever lectures got boring 🤣
Years later, after learning OOP and C#,
I rebuilt Vockice in .NET 2.0 😂
In 2010, I also built a small Windows Phone 7 game called Magic Symbol — one of my first steps into mobile development.
(Fun fact: the only screenshot I have today was reconstructed from an XAML file using AI.)
Real users. Real usage.
❌ No analytics
❌ No feedback tools
Just:
“People are using this.”
And somehow…
that was enough.
🎓 Software People Actually Used
At some point, it wasn’t just games anymore.
By the time I was 18, I was building software for learning, a system for practising driving license exams.
Selection Screen
Visual Basic 6 Form Designer View
And this wasn’t just a side project.
People actually used it.
A lot of them.
In fact…
An entire generation learned using this.
❌ No marketing
❌ No distribution platform
Just software… finding its users.
💾 Software Was Not “Deployed” — It Was Delivered
In 2003, I built a PC & PlayStation inventory system.
As a hobby.
But it included:
✅ Custom licensing system
✅ Hardware-based key
✅ Unique installation per machine
✅ Usage tracking
❌ No libraries
❌ No guides
Just:
Figuring things out
And looking back…
That was probably the real education.
But then I started thinking bigger.
After analysing the business and the market, I realised that a simple PlayStation tracking system wasn’t enough.
So I decided to build something more ambitious.
That same year, I started working on PC Counter — a much more advanced system designed for managing PC gaming clubs.
It was supposed to be a serious upgrade:
more features, more control, more flexibility.
But reality had other plans.
Between limited time, gaps in knowledge, and life getting in the way —
the project never became fully functional.
And yet…
This is where things get interesting.
❌ There were no AI tools.
❌ No code generators.
❌ No shortcuts.
Every step forward came from trial and error.
From thinking.
From understanding.
Even though the project failed.
The process didn’t.
And that’s something we’re slowly losing today.
Login and main screen:
💾 Visual Basic 6 Wasn’t “Bad” — It Was Reality
Today, people love to laugh at old tech:
“VB6? That’s ancient.”
But it powered real businesses.
- Accounting systems
- Inventory tools
- Internal enterprise apps
This wasn’t toy code.
This was production software.
And not just for experiments.
For years.
🎬 Small Tools That Solved Real Problems
Back when movies came on CDs, I built a simple autoplay app.
(1)Insert CD → (2)click to PLAY -> FILM.
That was it.
One click.
Problem solved.
And that’s what most software really is:
Solving one small problem… really well.
🧩 No OOP. No Architecture. Still Working.
❌ No design patterns
❌ No clean architecture
❌ No SOLID
Just:
- forms
- events
- raw logic
My code?
- spaghetti logic
- global variables everywhere
- zero documentation
If I saw it today...
I’d probably panic.
But…
It worked.
And somehow…
It kept working.
🌐 The Web Wasn’t What It Is Today
Today, everything is web.
Back then?
- static
- slow
- limited
“Web apps” barely existed.
If you wanted real functionality…
You built desktop apps.
That was the only option.
🤖 I Built an “AI Bot” Before AI Was a Thing
In 2008, I built a bot for a Facebook game (Word Challenge).
It:
- detected letters from the screen (custom OCR)
- searched a word database
- generated combinations
- played automatically
❌ No AI
❌ No ML
❌ No libraries
Just:
Logic + persistence
At the time, I was already learning .NET, but I needed something fast and practical.
So I went with what I knew best: Visual Basic.
The OCR part was the hardest.
The first version took nearly 2 minutes to recognise just 5 letters — completely unusable.
So I optimised it.
And eventually…
it became fast enough actually to play the game.
And no — I didn’t call it AI back then.
It was just… solving the problem.
Most of the projects I shared here were hobby experiments — mainly built in VB6.
But after 2008, my journey naturally shifted toward C# and the .NET ecosystem, where I continued growing professionally.
VB6 was my playground.
C# became my real battlefield.
🧱 The World Without Tools
❌ No AI
❌ No ChatGPT
❌ No Copilot
❌ No Stack Overflow (usable)
❌ No YouTube
❌ No GitHub
❌ No package managers
❌ No cloud
What we had:
- Official documentation
- Trial and error
And somehow… that was enough.
👤 You Were the Entire Team
❌ No QA
❌ No designer
❌ No product manager
❌ No DevOps
Just you.
You were everything.
🚀 Production Didn’t Exist
Production = 💿 CD
❌ No updates
❌ No patches
❌ No monitoring
❌ No logs
If there was a bug…
It stayed there.
❌ No hotfixes
❌ No second chances
And interestingly…
There were fewer bugs than today.
🧠 And Yet… Old Software Was Surprisingly Good
Games were built with:
- limited resources
- strict memory constraints
- no engines
- no massive assets
And still...
Incredibly playable. Addictive.
Because of one thing:
Smart design
No more features.
Not better tools.
Just better thinking.
⚡ Old Developer vs AI Developer
Then:
- You solved everything yourself
- You understood every line
- You built from scratch
- There was no fallback
Now:
- You move faster
- You integrate tools
- You rely on AI
- You don’t always understand everything
Neither is wrong.
But they are not the same.
And that difference… is bigger than it looks.
🔥 The Slightly Uncomfortable Truth
Modern developers are more powerful than ever.
We build faster.
We ship more.
We have better tools than any generation before us.
But here’s the uncomfortable part:
Then vs now — not better or worse, just different.
Many of us are becoming tool operators more than problem solvers.
Not because we’re worse.
Because:
We don’t need to struggle anymore.
We don’t always understand the system.
We understand the interface.
This isn’t about being better or worse — it’s about how our role is changing.
And now, we’re entering a new phase.
Prompt-driven development
Instead of writing logic…
we describe intent.
Instead of building step by step…
we guide systems to build for us.
This is incredibly powerful.
But it changes the role of a developer:
From someone who builds
to someone who instructs
The real question is no longer:
“Can you build it?”
But:
“Do you understand what was built?”
Because prompting without understanding…
is just a faster way to build things you can’t explain.
🧠 What That Time Taught Me
I wasn’t just building software.
I was learning:
- how systems really work
- how to break problems down
- how to own the entire solution
There was no safety net.
If you didn’t understand it — you were stuck.
And that changes how you think.
Not just as a developer… but as a problem solver.
🤖 A Quick Note on AI
This is not an anti-AI post.
AI is one of the most powerful tools we’ve ever had.
✅ It accelerates learning
✅ It removes friction
✅ It makes developers incredibly productive
But:
Tools should amplify understanding — not replace it.
The risk is not using AI.
The risk is:
Using it without thinking.
And that’s where the problem begins.
🔚 Final Thought
Today, many people laugh at old tech.
But that tech:
- powered real systems
- solved real problems
And most importantly:
It forced you to understand what you were building.
Not just how to use it.
But how it actually worked.
Today, more and more of what we build… feels like a black box.
It works.
But we don’t always understand why.
💬 Let’s Be Honest
Could you build software today?
❌ without AI
❌ without Google (as we know it today)
Or would you get stuck?
Maybe the real question isn’t whether tools are good or bad.
Maybe it’s this:
What happens to our thinking when we no longer need to struggle?
🤔 So Let Me Ask Again
At the beginning, I asked:
Are we becoming better engineers — or just tool operators?
Now that you’ve seen both worlds…
Be honest.
Are we still engineers — or just tool operators?
Top comments (0)