Before I ever wrote a line of code, I was a graphic designer. That's where it all started — Photoshop, Illustrator, print layouts, branding. I was designing logos, brochures, and websites long before I understood what was happening under the hood. I thought my career would be visual, creative, purely design.
Then I discovered Flash. And that changed everything.
Back in the early 2000s, Flash was the internet. If you wanted animation, interaction, or anything remotely cool on a website, you opened Macromedia Flash and made it happen. As a designer, I was drawn to the creative possibilities — but Flash had this thing called ActionScript. And the moment I started writing code to make my designs interactive, I was hooked. I went from designing static visuals to building full games, interactive banners, and Flash websites. People are always surprised when I tell them I went from graphic design to game development — but honestly, it was the most natural transition in the world.
That world is completely gone now. Flash is dead. ActionScript is a relic. And yet, everything I learned in that era — game loops, state management, event-driven programming, thinking in frames and timelines — all of it still applies today. Just with different syntax.
That's actually the first lesson.
1. Syntax Changes. Logic Doesn't.
I've written production code in ActionScript, PHP, JavaScript, TypeScript, Dart, Python, and more. Every time a new language or framework came along, the syntax was different but the thinking was the same. Loops are loops. Conditions are conditions. State management is state management — whether you're doing it in a Flash game or a React app.
When I was building Flash games, I had to think about collision detection, frame rates, user input, and managing complex state across scenes. Guess what? That's exactly what you do in modern web development — just with requestAnimationFrame instead of onEnterFrame.
You don't need to memorize syntax. You need to understand the logic behind it. The syntax is just the language you use to express your thinking — and languages can always be looked up.
I've never been someone who memorizes method signatures or API parameters. I know what I need to do, I know why, and I know the pattern. The exact syntax? That's what documentation is for. More on this in my next post.
2. The Best Code Is the Code You Don't Write
Early in my career, I measured productivity by output. More code meant more progress. More features meant more value. I was wrong.
Every line of code is a liability. It needs to be maintained, tested, debugged, and eventually replaced. The most impactful developers I've worked with over 20 years are the ones who solve complex problems with surprisingly little code. They question whether a feature is truly needed. They reach for existing solutions before building custom ones. They resist the urge to create frameworks for problems that don't exist yet.
I've seen entire projects collapse under the weight of over-engineering. And I've seen simple, focused solutions outlive every "enterprise-grade" alternative that was built alongside them.
3. From Designer to Game Dev to Full-Stack: Everything Transfers
People are often surprised when I mention my background. "Wait — you were a graphic designer? And then a game developer?" Yes. And honestly, that unusual path gave me advantages that a traditional CS education wouldn't have.
Design taught me to think about users first — layout, hierarchy, readability, flow. Game development taught me to think about systems, performance, and interactivity. Together, they gave me instincts that web development tutorials skip entirely:
- Performance thinking — when your game runs at 30fps on a 2004 computer, you learn to optimize. That mindset carries over to building fast web apps.
- User experience instincts — games punish bad UX immediately. Users close the tab. You learn to think about every interaction.
- State management — a game is nothing but state. Player position, score, level, enemies, power-ups. Managing that cleanly in ActionScript prepared me for Redux, Vuex, and every state library that came after.
- Creative problem-solving — when you're building a game with limited tools, you find creative solutions. That resourcefulness is priceless in any development role.
My journey from graphic design to Flash games to PHP websites to full-stack JavaScript to mobile with Flutter to AI research — every chapter built on the last. The designer's eye never left. The game developer's instincts never faded. Nothing is wasted.
4. Frameworks Come and Go. Fundamentals Stay Forever.
In 20+ years I've used: ActionScript, PHP, jQuery, Backbone, Angular, React, Vue, Svelte, Flutter, and more. Each one was "the future" at some point. Most of them aren't anymore. Some don't even exist.
What has stayed constant:
- Understanding HTTP and how the web actually works
- Writing clean, readable code that others can maintain
- Database design and data modelling
- Debugging skills and the patience to trace a problem to its root
- Knowing when to use a framework and when it's overkill
If you invest in fundamentals, picking up a new framework takes days, not months. I picked up Vue in a weekend because I already understood reactive programming from years of building interactive Flash content. The concept wasn't new — only the syntax was.
5. Ship It. Then Improve It.
Perfectionism killed more of my projects than bad code ever did. The graveyard of side projects I never launched because they "weren't ready yet" is enormous. Meanwhile, the things I did ship — even in rough form — taught me more than anything I kept in development forever.
One of the best games I ever built in Flash was hacked together in a weekend. It was messy, the collision detection had edge cases, and the code was held together with duct tape. But people played it. They gave feedback. I improved it. Version 3 was solid.
If I had waited for version 1 to be perfect, there would never have been a version 2.
The feedback loop of shipping, learning, and iterating is the most powerful tool in software development. Version 1 doesn't need to be perfect. It needs to exist.
Twenty-plus years in, I'm more excited about building than ever. The tools are better, the problems are more interesting, and I'm now combining everything — design, development, game logic, UX, and AI — in my PhD research. Every chapter of my career fed into the next one. If you're just starting out: learn the fundamentals, ship early, and don't be afraid to take the weird path. It all connects eventually.