From Drag-and-Drop to Hand-Typed SQL: A UX Engineer’s Journey Into the Backend

How a design student at the Art Institute of Philadelphia fell in love with databases, PHP, and putting it all together — and never looked back


There’s a moment every designer-turned-developer remembers. The moment when looking good wasn’t enough anymore. When you stopped being satisfied with making something beautiful and started obsessing over how it actually worked underneath.

For me, that moment happened around a blog.


The Art Institute of Philadelphia, Early 2000s

I was a web design major at the Art Institute of Philadelphia. Design was my world — layout, color, typography, the way things felt when you landed on a page. But the school sat in the middle of a city with Drexel and UPenn practically around the corner, and that changed everything about the quality of instruction we got.

We weren’t just getting art teachers. We were getting developers and technologists who taught at prestigious universities and doubled as our instructors. That’s not something every Art Institute campus could say. Being in a metro city with that kind of academic density meant we had access to people who were genuinely deep in the field — not just teaching from a textbook.

I took full advantage of it. I snuck into classes I had no business being in. I hung around the advanced development students. I absorbed everything I could from anyone willing to talk to me. Good times.


Falling for SQL Before I Knew What I Was Doing

It started with Microsoft Access. We got introduced to it in school as a way to understand relational databases — tables, relationships, queries. And I genuinely liked it. The visual relationship builder, those drag-and-drop arrows connecting tables together, gave you a picture of something that was otherwise completely abstract.

But what really got me was when I started typing the actual SQL by hand.

sql

SELECT * FROM users WHERE city = 'Philadelphia';

Something clicked. There was a directness to it — you asked the database a question in plain, structured language and it answered you. No arrows, no GUI, no guessing what was happening behind the scenes. Just you and the data having a conversation.

Access was great for visualizing the concept. But typing raw SQL felt like actually understanding it. I liked the control. I liked knowing exactly what I was telling the system to do.


JavaScript, XML, and a Growing Appetite

At the same time I was getting into SQL, I was also picking up JavaScript and XML. These were the building blocks of the early dynamic web — before frameworks, before jQuery had even launched, before any of the tooling we take for granted today existed.

JavaScript was exciting because it lived in the browser and responded to people. XML was exciting because it was structured data you could actually read and reason about. And SQL was exciting because it was the engine behind real, persistent information.

I could feel these things wanting to connect. I just needed the piece in the middle.


The Blog That Changed Everything

Then came blogs. Our instructors introduced us to early blogging platforms and content-driven websites, and something shifted in my thinking. I didn’t just want to look at a blog and make it pretty. I wanted to know exactly how a piece of text typed into a form ended up on a webpage that anyone in the world could read.

Someone was writing PHP in the advanced dev classes to make that happen. For a while I let them. And then I decided I needed to understand it myself.

So I went harder. I pushed deeper into databases, folded SQL work into my web design major wherever I could, and eventually went serious on PHP and object-oriented programming. I didn’t abandon design — I never have — but I needed to know both sides. I needed to know how the front and the back connected.


Manually Connecting PHP to a Database in 2002

Here’s the thing about doing this in 2002 that nobody really talks about: it was genuinely hard, and there was no LocalWP, no MAMP, no one-click installer, no Stack Overflow to bail you out when something broke. There was documentation, there were teachers if you could get their attention, and there was trial and error.

A lot of error.

Connecting PHP to a MySQL database manually looked something like this:

php

<?php
$host     = "localhost";
$username = "root";
$password = "yourpassword";
$database = "your_db_name";

$connection = mysql_connect($host, $username, $password);

if (!$connection) {
    die("Connection failed: " . mysql_error());
}

mysql_select_db($database, $connection);

$query  = "SELECT * FROM posts ORDER BY date DESC";
$result = mysql_query($query);

while ($row = mysql_fetch_array($result)) {
    echo "<h2>" . $row['title'] . "</h2>";
    echo "<p>" . $row['content'] . "</p>";
}

mysql_close($connection);
?>

Every line of that was typed by hand. And if anything was wrong — a typo in the database name, a permission issue, a misconfigured Apache server — you got a white screen or a cryptic error message and started hunting.

There was no abstraction. No ORM. No framework holding your hand. You were writing the connection string, selecting the database, running the query, looping through the results, and closing the connection yourself. Every time.

It was hit or miss. Some days it worked on the first try and you felt like a genius. Other days you’d spend hours chasing a missing semicolon or a database that wasn’t running because Apache wasn’t configured correctly — which you’d also configured by hand, editing httpd.conf files directly.

But when it worked? When you typed something into a form, hit submit, and saw it appear on the page pulled live from a database you’d built yourself?

That feeling was everything.


What It Taught Me That Tools Can’t

Going through that manual process taught me something that modern tools, as good as they are, can make easy to skip: understanding what’s actually happening between the layers.

When you write the connection string yourself, you understand what a connection string is. When you handle your own query results, you understand what a result set looks like. When your server isn’t configured and you have to fix it by hand, you understand what a server does.

That knowledge doesn’t expire. Twenty years later, when I’m debugging a LocalWP site and need to update database credentials, or when I’m auditing a hacked WordPress installation and need to know where malware hides — that foundational understanding is why I know where to look.


Twenty Years Later

I graduated from the Art Institute of Philadelphia and never left the field. I’m still in it — still building, still learning, now working as a UX Engineer. The arc from that design student sneaking into advanced dev classes to where I am now feels both surprising and completely logical.

The tools have changed almost beyond recognition. What used to require a full day of manual configuration now takes thirty seconds in LocalWP. What used to mean hunting through files with a text editor now means asking Claude Code CLI to scan an entire directory for malware signatures in seconds.

But the fundamentals — understanding how a browser request hits a server, how PHP processes it, how a database responds, how that response becomes a webpage — those are the same. And understanding them at a foundational level, the way you can only really understand something when you’ve done it the hard way, is still the thing that separates developers who can debug from developers who can only build when nothing goes wrong.


For Anyone Who Came Up the Same Way

If you learned this stuff the hard way — hand-typed SQL, manual Apache configs, mysql_connect() before PDO existed — that experience is more valuable than it might feel right now, when frameworks and AI tools can scaffold an entire application in minutes.

You know what’s happening underneath. That’s not nothing. That’s actually everything.

And if you’re just starting out now, do yourself a favor: before you let the tools do it for you, try doing it yourself once. Type the SQL. Write the connection. Configure the server manually at least once. Not because it’s more efficient — it isn’t — but because you’ll understand things that the people who skipped that step never quite will.


This is part of an ongoing series about my journey from web design student to UX Engineer. Next up: how I recently recovered three hacked WordPress sites using LocalWP and Claude Code CLI — and what that process taught me about how much (and how little) has changed.

//Let’sBuildSomemething

//INFO [LEONARD_MALCOM]
UX Engineer & Frontend Developer _ 10+
Response within 24h
//TECH_STACK
  • JavaScript
  • Responsive Design
  • WCAG Accessibility
  • Semantic HTML
  • Design Systems
  • Reusable Components
  • Front-End Performance
  • Scalable Front-End Systems
  • WordPress
  • Drupal
  • Twig
  • Enterprise CMS Platforms
  • Figma
  • Wireframing
  • Prototyping
  • Git
  • Agile Workflows
  • Cross-Functional Collaboration
//CONNECT RESUME.pdf
Portv2.2026
//PRIMING
Portv2 - Inspired by Eric Jordan