DEV Community: John Liter

I Built DevCommand and Ended Up Changing the Way I Deploy Websites

John Liter — Fri, 04 Sep 2026 02:15:38 +0000

I originally set out to solve a much smaller problem.

As I've spent more time developing websites and applications, I've accumulated a growing list of commands that I use regularly enough to recognize but not always regularly enough to remember. Git, Linux, SSH, npm, Composer, Docker, database management—there is always some command where I remember what I need to do but not the exact syntax to do it. I could search for it every time, dig through old projects, or ask AI, but eventually I started wondering why I hadn't built my own reference.

That idea became DevCommand, which I'm building around a simple concept: Your developer command companion.

The project started as a practical tool for myself, but somewhere between building it and getting it online, it became part of a much larger change in how I'm approaching development.

Outgrowing the Way I Used to Work

For quite a while, Hostinger's File Manager was a normal part of my development process. If I needed to change something on one of my sites, I could log in, find the PHP, CSS, or JavaScript file, edit it, save it, refresh the site, and move on. For the kinds of websites I was building at the time, it worked well enough.

My projects aren't as simple anymore.

I'm working with React applications, PHP sites, APIs, databases, automation, and projects with increasingly more moving parts. At the same time, I've been using VS Code and Git more heavily in my local development. The disconnect started becoming obvious: I was developing more seriously on my computer, but I was still treating deployment like I had when my projects were much smaller.

Editing a production file directly is fast right up until something goes wrong. There is no commit to roll back to if you haven't created one, and it becomes easy for the copy on your computer, the copy in GitHub, and the copy actually running on the server to drift apart. I didn't want three versions of a project with me trying to remember which one was current.

So while working on DevCommand, I decided to change that.

I wanted the process to be simple: build locally, track everything with Git, push the finished work to GitHub, and have the production server receive that version automatically.

The concept was straightforward. Getting it working was not.

Building the Deployment Pipeline

GitHub Actions seemed like the obvious bridge between GitHub and Hostinger. My goal was to make a push to the production branch mean something. Instead of pushing code to GitHub and then logging into Hostinger to repeat the deployment manually, that push would trigger the deployment itself.

This meant setting up SSH access between GitHub and my Hostinger account, creating deployment keys, storing the necessary information in GitHub Secrets, configuring the correct server paths, and using rsync to synchronize the production files.

This was also where I spent a good amount of time staring at red GitHub Actions runs.

At one point, the workflow file itself was being flagged with errors claiming required properties like on and jobs were missing. After getting past that, the Action could run, but the files still weren't reaching the directory where they were supposed to go. Fixing one problem often just exposed the next one.

That process was frustrating, but it was also useful because I couldn't just click around until something magically worked. Each failure narrowed the problem. Was GitHub reading the workflow? Could the Action authenticate over SSH? Was it reaching the correct server? Was rsync pointing at the correct local directory? Was the destination path right?

Eventually, the pieces started falling into place. The deployment key authenticated successfully. The repository secrets were correct. The workflow appeared in GitHub Actions and executed properly. rsync reached Hostinger.

Then I pushed another change and watched the workflow finish with a green checkmark.

More importantly, I checked the server and the files were actually there.

That was the moment the whole thing clicked.

DevCommand Was a Little Different

Once I had the deployment process working for my other sites, DevCommand presented another challenge. Unlike some of my PHP projects, the files in the repository aren't the files that should simply be copied directly to the web server. DevCommand has to be built first.

That meant modifying the deployment process so GitHub could take care of the build as well. The workflow checks out the repository, prepares Node.js, installs the dependencies, runs the production build, and then sends the generated dist files to Hostinger.

In practical terms, I can now work on DevCommand locally, test what I'm building, commit the changes, and push them to GitHub. From there, the production build and deployment happen without me manually transferring anything.

That may be routine for developers who have been working with CI/CD pipelines for years, but actually building the process for my own projects gave me a much better understanding of what is happening between source code and production.

Before this, I tended to think of deployment mostly as moving updated files onto a server. DevCommand forced me to think about the distinction between the source of an application and the artifact that actually gets deployed. GitHub isn't simply storing a backup of my code anymore; it's now an active part of how that code becomes the production application.

A Better Foundation for Everything Else I'm Building

The biggest result of this project isn't that I no longer have to open Hostinger's File Manager as often. Saving a few clicks isn't particularly interesting. What matters is that my development process finally has a clear source of truth.

The project on my computer is where I work. Git records what changes. GitHub holds the repository and its history. The deployment workflow determines what reaches production. If something goes wrong later, I have a much clearer trail showing what changed and when.

It also changes the way I think about commits. A commit isn't just a checkpoint I create because Git expects me to. When a push can ultimately result in a production deployment, being deliberate about what I'm committing becomes much more important.

There is another benefit that I didn't fully appreciate until I saw the workflow running successfully: I can reuse what I learned.

DevCommand isn't going to be the only project I maintain. I already have several sites, applications, and client projects, and there will be more. I don't want to reinvent deployment every time I build something. Establishing this process gives me a foundation that can be adapted depending on whether a project is a traditional PHP site, a React application that needs to be built, or something more complex later.

What Started as a Command Reference

That's probably my favorite part of this entire project.

I sat down to build a tool because I was tired of looking up commands.

Instead, the project pushed me into SSH authentication, deployment keys, GitHub Secrets, YAML configuration, rsync, build artifacts, server paths, and automated deployments. Some of those were things I already understood conceptually, but there is a different level of understanding that comes from having to make all of them work together.

There were plenty of failed runs along the way, and I don't think hiding those makes the finished project any more impressive. If anything, those failures are the useful part. The green checkmark only meant something because I understood most of what had to happen for it to finally appear.

DevCommand is currently running at devcommand.johnliter.de, with devcommand.app planned as its eventual home. I have more I want to add to it, and I want it to become a genuinely useful command companion rather than just another static cheat sheet.

But even in its current state, the project has already done more for me than I originally intended.

I built DevCommand because I wanted a better way to reference the tools I use while developing.

In the process, I built a better way to ship the things I create.

Converting a Lead Into a Customer in PHP Without Creating Duplicate Records

John Liter — Thu, 27 Aug 2026 20:07:21 +0000

Converting a Lead Into a Customer in PHP Without Creating Duplicate Records

A practical PHP and MySQL pattern for checking existing customers before inserting another record.

Building a CRM has forced me to think about problems that look simple in the interface but become more interesting once I start working through the database logic behind them. One of those problems is converting a lead into a customer.

From the user's perspective, the workflow is straightforward: open a lead, click a button, and turn that lead into a customer. From the database's perspective, there is an important question that needs to be answered first:

Does this customer already exist?

Without that check, clicking Convert to Customer can easily create duplicate customer records. Those duplicates eventually affect everything connected to the customer: invoices, quotes, appointments, work orders, communication history, and reporting.

Here is the approach I use to think about this problem in a PHP/MySQL application.

The Basic Data Model

A simple CRM might begin with separate leads and customers tables.

A lead represents someone who has entered the sales pipeline but has not necessarily become a customer yet.

CREATE TABLE leads (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(150) NOT NULL,
    email VARCHAR(255),
    phone VARCHAR(50),
    status VARCHAR(50) NOT NULL DEFAULT 'new',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

The customer table contains people or businesses that have moved beyond the lead stage.

CREATE TABLE customers (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(150) NOT NULL,
    email VARCHAR(255),
    phone VARCHAR(50),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

The exact schema will depend on the application. The important part is recognizing that converting a lead should not automatically mean inserting a new customer.

First, I need to determine whether that person is already represented in customers.

Why Checking by Name Is Not Enough

An obvious first attempt would be something like this:

SELECT id
FROM customers
WHERE name = ?
LIMIT 1;

That is better than performing no duplicate check at all, but names make poor identifiers.

Two customers can legitimately have the same name. The same customer's name might also be entered differently:

John Liter
John A. Liter
john liter
J. Liter

Business names introduce similar problems.

Whenever possible, I would rather use stronger identifiers such as an email address or phone number.

For example:

SELECT id
FROM customers
WHERE email = ?
LIMIT 1;

The problem is that not every lead will necessarily have an email address. A practical CRM may therefore need to check more than one field.

Checking for an Existing Customer With PHP

Using PDO and prepared statements, the application can look for an existing customer before inserting anything.

A simplified example looks like this:

$existingCustomer = null;

if (!empty($lead['email'])) {
    $stmt = $pdo->prepare(
        'SELECT id
         FROM customers
         WHERE email = ?
         LIMIT 1'
    );

    $stmt->execute([$lead['email']]);
    $existingCustomer = $stmt->fetch(PDO::FETCH_ASSOC);
}

if (!$existingCustomer && !empty($lead['phone'])) {
    $stmt = $pdo->prepare(
        'SELECT id
         FROM customers
         WHERE phone = ?
         LIMIT 1'
    );

    $stmt->execute([$lead['phone']]);
    $existingCustomer = $stmt->fetch(PDO::FETCH_ASSOC);
}

This establishes a simple priority:

Email → Phone → No Match

If an email matches an existing customer, I can use that customer's ID instead of creating another record. If there is no email match, I can try the phone number.

The application now has a decision to make.

Insert Only When Necessary

If no customer was found, then I can create one from the lead information.

if (!$existingCustomer) {
    $stmt = $pdo->prepare(
        'INSERT INTO customers (name, email, phone)
         VALUES (?, ?, ?)'
    );

    $stmt->execute([
        $lead['name'],
        $lead['email'],
        $lead['phone']
    ]);

    $customerId = (int) $pdo->lastInsertId();
} else {
    $customerId = (int) $existingCustomer['id'];
}

Now $customerId points to the correct customer regardless of which path was taken.

That is useful because everything that happens after conversion can reference the same variable. The rest of the application does not necessarily need to care whether the customer was just created or already existed.

The Database Should Help Enforce the Rule

Application-level checks are useful, but I do not want PHP to be the only thing protecting the database.

Suppose two requests arrive almost simultaneously.

Both requests could potentially perform the duplicate check before either inserts the customer:

Request A → Customer doesn't exist
Request B → Customer doesn't exist
Request A → INSERT
Request B → INSERT

Now I still have a duplicate.

This is where database constraints become important.

If email addresses must be unique in the application, I can enforce that requirement at the database level:

ALTER TABLE customers
ADD UNIQUE KEY uq_customers_email (email);

The database is now protecting an assumption that the application depends on.

That does not eliminate the need for application logic. It gives me another layer of protection.

The PHP code should also be prepared to handle a duplicate-key exception rather than assuming every insert will succeed.

Normalize Before Comparing

Another lesson is that duplicate detection is only as reliable as the data being compared.

Consider phone numbers:

2545551234
254-555-1234
(254) 555-1234
+1 254 555 1234

Those might all represent the same number.

If I compare the raw strings, MySQL may see completely different values.

A better approach is to normalize information before storing and comparing it. For a U.S. phone number, that might mean stripping formatting characters and consistently deciding how country codes will be represented.

Email addresses also deserve normalization. At minimum, whitespace should not be allowed to create accidental differences between otherwise identical values.

The goal is not simply to ask:

Are these strings identical?

The more useful question is:

Do these records represent the same real customer?

Those are not always the same problem.

What Happens to the Lead?

Creating or finding the customer is only part of the conversion.

The lead also needs to reflect what happened.

One approach is to update its status:

$stmt = $pdo->prepare(
    'UPDATE leads
     SET status = ?
     WHERE id = ?'
);

$stmt->execute([
    'won',
    $leadId
]);

An even more useful design is to maintain a relationship between the original lead and resulting customer.

For example, the leads table could contain:

customer_id INT UNSIGNED NULL

After conversion:

$stmt = $pdo->prepare(
    'UPDATE leads
     SET status = ?, customer_id = ?
     WHERE id = ?'
);

$stmt->execute([
    'won',
    $customerId,
    $leadId
]);

Now I have traceability.

I can determine which lead produced a customer instead of throwing away that relationship once the conversion happens.

That becomes increasingly useful when I start asking questions about lead sources, conversions, marketing performance, or customer history.

Consider Using a Transaction

There is another failure scenario worth thinking about.

Imagine this sequence:

1. Create customer
2. Update lead
3. Something fails

If the customer is successfully inserted but the lead update fails, the database can end up in an inconsistent state.

A transaction can make the conversion behave more like one operation.

try {
    $pdo->beginTransaction();

    // Find or create customer.

    // Update the lead with the customer ID.

    $pdo->commit();
} catch (Throwable $e) {
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }

    throw $e;
}

The exact transaction boundaries depend on the application's workflow, but this is the point where I start thinking beyond whether each individual SQL statement works.

I need to think about whether the entire business operation succeeds.

That distinction has become increasingly important as I build applications with multiple related tables.

Security Still Matters on Internal Actions

A conversion button may only exist inside an authenticated CRM, but I still do not want a state-changing action to happen through an unprotected request.

At minimum, I want to think about:

Authentication
Authorization
CSRF protection
Prepared SQL statements
Server-side validation
Error handling

For example, a Convert to Customer action should generally be a POST request rather than something triggered simply by visiting a URL.

<form method="post">
    <input
        type="hidden"
        name="csrf_token"
        value="<?= htmlspecialchars($csrfToken) ?>"
    >

    <input
        type="hidden"
        name="lead_id"
        value="<?= (int) $lead['id'] ?>"
    >

    <button type="submit">
        Convert to Customer
    </button>
</form>

The server then validates the CSRF token and verifies that the authenticated user has permission to perform the conversion.

Internal software is still software exposed to mistakes and potentially malicious requests.

What I Learned

The interesting part of this feature was not the INSERT statement. It was realizing how many decisions surround that insert.

A reliable lead-to-customer conversion needs to answer several questions:

Does this customer already exist?
What fields determine whether two records represent the same person?
Is the database enforcing the same assumptions as the PHP application?
Can I trace the customer back to the original lead?
What happens if one part of the conversion fails?
Is the state-changing request properly protected?

That is a much different problem from simply copying information from one table into another.

It is also one of the things I enjoy about building database-backed applications. A button that looks trivial on the frontend can represent several important data-modeling decisions behind the scenes.

The more interconnected an application becomes, the more those decisions matter.

Linus Torvalds – The Reluctant Revolutionary Who Changed Everything

John Liter — Wed, 09 Jul 2025 13:08:43 +0000

When you think of modern computing, certain names echo through history. Today, we begin this series by spotlighting a man who didn’t just influence the tech world—he quietly reshaped it:

Linus Torvalds.

If you’ve ever used a phone, surfed the web, run a server, deployed to the cloud, or pushed code to GitHub—his work touched your life.

🧬 Who Is Linus Torvalds?

Born in Finland, 1969
Creator of the Linux operating system kernel (1991)
Creator of Git, the version control system that powers almost every modern dev workflow

What started as a personal side project—“just for fun,” as he called it—became the backbone of the internet, powering everything from Android devices to supercomputers.

💻 Why Is Linux So Important?

Torvalds released the Linux kernel as open source. That decision didn’t just start a movement—it defined the open-source culture we benefit from today.

Linux:

Runs ~70% of the web
Powers Android phones
Drives global infrastructure via servers, IoT devices, and embedded systems

Torvalds never intended to become a tech icon. He just wanted to build something better—and share it.

🔄 Oh, and Git? That Was His “Side Project”

When the Linux community needed a better way to manage code in 2005, Linus built Git—in just 10 days.

Now, Git is used by millions of developers around the world to collaborate, ship code, and build software at scale.

💬 Why It Matters to Us Today

Torvalds’ story is a reminder that:

You don’t need to be loud to be legendary.
You can change the world with a keyboard and a clear idea.
Great things often start with personal curiosity—not big ambitions.

🧠 Final Thought

Linus didn’t build Linux or Git to get famous.

He built them because he cared about doing it right.

And in doing so, he gave the developer world tools we can’t imagine living without.

📣 Let’s Talk

💬 What’s your favorite thing about Linux or Git?

🧠 Who should we feature next in this Tech Legends series?

Drop your thoughts in the comments 👇

Python in 2025: The Language That Still Does It All (and Then Some)

John Liter — Tue, 08 Jul 2025 13:27:32 +0000

It’s 2025.

New frameworks are born every week.

AI tools are reshaping how we code, learn, and build.

And yet… Python still holds strong.

Why?

Because Python isn’t just a language.

It’s a gateway.

To creativity.

To automation.

To AI.

To building that “what if?” idea you’ve had sitting in your notes app for months.

🧠 Python Is the Language of Curiosity

You can start with print("Hello, world") and wind up building:

A full-stack web app with Flask or Django
A trading bot using real-time market data
An AI chatbot that helps manage your calendar
A data dashboard tracking your fitness stats
A game. A script. A tool. A business.

Python isn’t limited by discipline—it connects them.

🤖 Python + AI = A Whole New Level of Possibility

With AI becoming a daily tool for developers, Python has become the connective tissue between human ideas and machine intelligence.

Want to train a model? Python.

Want to deploy an LLM to a web app? Python.

Want to analyze data, generate images, run automations, or scrape content? Python.

It’s not hype. It’s happening.

Whether you're using frameworks like TensorFlow, PyTorch, or LangChain, Python is the backbone of so much of the AI ecosystem in 2025.

🛠️ Python Isn’t Just for Pros—It’s for Problem-Solvers

What I love about Python is how inviting it is.

You don’t need to be a "real developer" to start writing useful Python code.

You just need a problem you're passionate about solving.

And in this AI-powered future, Python lets you go from:

“I wish I could…”

to

“I built this to fix it.”

🌍 What Are You Using Python For in 2025?

That’s the conversation I want to have.

Are you using it for AI? For automation?

Building a SaaS? Hacking on side projects?

Teaching your kids to code? Creating tools that help your community?

Let’s stop thinking of Python as “just a scripting language.”

In the hands of someone who’s curious, it’s a superpower.

💬 Drop your thoughts below:

What’s the most creative thing you’ve built in Python?
Where do you see Python going in the next 5 years?
What’s one use case people don’t talk about enough?

Let’s have a real dev-to-dev conversation.

Because this language?

Still changing lives. Still elevating skills. Still just getting started.

Why Teaching Our Kids About Their Tech Is More Important Than Ever

John Liter — Sat, 05 Jul 2025 13:07:52 +0000

Image generated using DALL-E

As I start my next college class, Introduction to Information Security, I’ve had a wake-up call:

Most people—even those who use the internet every day—know almost nothing about their own home Wi-Fi.

They get internet service from a provider, the installer hands them a router, and they just…start browsing. The password? Usually the default one printed on the sticker—never changed, never thought about again.

Reading through my classmates’ responses this week, I saw a pattern:

“I didn’t realize how much I was lacking when it comes to securing my time online.”

And it hit me:

If adults don’t understand the basics of the hardware and networks they rely on, how can we expect our kids to grow up safe and smart online?

🛡️ Digital Safety Starts at Home

It’s not enough to teach kids how to avoid suspicious links or choose strong passwords.

We need to teach them:

How a router works
Why you should change default passwords
What encryption is and why it matters
How devices connect to Wi-Fi and share data

Understanding the hardware and connections gives them power—so they don’t just use tech blindly, but know what’s happening under the hood.

🧠 Why It Matters

Our kids aren’t just watching YouTube and doing homework online—they’re building habits that will stick with them for life. If we teach them now how to:

Secure their devices
Recognize insecure networks
Question the default settings they’re given

We’re giving them tools to protect themselves in an increasingly connected world.

💬 Let’s Talk

Did you grow up learning how your own Wi-Fi or devices worked?
What have you taught your kids (or wish you had) about tech safety?
How can we make understanding the basics of our devices as normal as teaching kids how to ride a bike?

If we want the next generation to thrive online, we need to start by teaching them what’s happening offline—right at home.

Why I Fell in Love with Coding (and Why I’m Still Addicted to It)

John Liter — Thu, 26 Jun 2025 13:24:42 +0000

For me, coding didn’t start with a job listing, a college course, or a trendy tech video.

It started with FreeCodeCamp.

Their guided tutorials gave me structure. The community gave me encouragement. And the moment that really stuck with me? When I got stuck on a problem—and instead of giving me the answer, someone helped me understand it.

That’s when I realized:

Coding isn’t just about getting things to work. It’s about learning how to think.

🔤 It Started with the Basics

HTML, CSS, and JavaScript were the first tools I used to bring my ideas to life.

I didn’t need anything complex—I just needed something to get started.

Once I finished the basics, my curiosity exploded. I began exploring new languages, frameworks, and tools—not to be trendy, but to make my original ideas even better.

🤖 How AI Made Me a Smarter Coder

When I hit a wall, I don’t panic. I ask AI.

But I don’t just want a copy-paste answer—I want an explanation.

Why does this work?

What’s the logic behind it?

Can I see the original docs or pages this came from?

That’s how I grow. I don’t just collect answers—I collect understanding.

Even when debugging, I’ll have GitHub Copilot walk me through what I did wrong. Often, that small spark of explanation is all I need for the solution to click.

🧠 I Document Everything in Notion (So I Can Teach It Later)

I take every insight, every “aha” moment, and drop it into Notion.

It’s not just my second brain—it’s a place I turn ideas into mini lessons I teach to my kids.

There’s something powerful about learning and sharing that knowledge.

When I see my kids light up after understanding a concept I just struggled through? That’s better than any shipped feature.

💡 The Ideas Never Stop

My mind is constantly buzzing with ideas for web pages, apps, and tools.

So I keep a running checklist—a digital playground of possibility.

Some will get built. Others won’t. But every one of them fuels the fire.

🔥 Coding Is My Passion—And AI Made It Even Deeper

AI hasn’t made me lazy—it’s made me more curious.

More experimental.

More obsessed with understanding how far I can take my ideas.

Every project I finish teaches me something new.

Every bug I fix reminds me why I started.

And every time I teach what I’ve learned, I fall in love with coding all over again.

💬 Let’s Talk

What made you fall in love with coding?
How are you using AI to learn, not just code faster?
Do you document what you learn—and if so, how?

Drop your thoughts.

Let’s celebrate the journey—not just the results.

Why StackEdit Became One of My Favorite Tools as a Developer

John Liter — Wed, 25 Jun 2025 12:51:58 +0000

There are a lot of tools that come and go in my workflow.

But every now and then, one sticks—and for me, StackEdit is one of them.

If you haven’t used it (or forgot it existed), it’s basically a browser-based markdown editor with offline support, seamless syncing to Google Drive, GitHub, and more.

And for something so lightweight, it’s quietly become one of the most reliable parts of how I organize thoughts, drafts, and even code-adjacent ideas.

🧠 It’s Where I Think in Markdown

I spend a lot of time writing—not just code, but notes, ideas, outlines, README drafts, architecture explanations, blog posts, and documentation snippets.

For me, writing in markdown just feels right. It’s fast, clean, minimal—and StackEdit handles it beautifully.

No fluff. No distractions. Just structured text, exactly how I want it.

🔄 Sync Is Seamless (and Low-Key a Lifesaver)

StackEdit’s Google Drive integration is kind of underrated. I’ve closed tabs, changed devices, and even lost power—and the content is still there. No install, no stress.

There’s a weird comfort in knowing your half-finished thought is waiting for you exactly where you left it.

And the GitHub sync? Super clean for working on docs or markdown-based repos. I’ve even written full API docs in StackEdit before pushing them to a project.

🧩 It Fits in the Gaps Most Tools Miss

It’s not a code editor. It’s not an IDE. It’s not Notion.

It’s not trying to be everything.

But when I need to brainstorm, jot down an idea in markdown, or draft something before making it public—it’s often the first place I go.

There’s something refreshing about a tool that does one thing really well.

💬 My Take

Is it fancy? No.

Is it fast, free, and surprisingly powerful? Absolutely.

Not every tool in my stack has to be groundbreaking.

Some just have to work—quietly and consistently.

And StackEdit does that better than most.

🙋‍♂️ Curious to Hear From Others:

Have you used StackEdit for your dev notes or docs?
Do you still write in markdown outside of GitHub?
What’s your go-to spot for thinking through technical ideas before you commit?

Let’s normalize loving the tools that keep our heads clear—even if they don’t get all the spotlight.

Want to Keep Kids Safe Online? Teach Them How the Internet Works

John Liter — Tue, 24 Jun 2025 12:57:39 +0000

We live in a world where children are growing up with more access to the internet than ever before—but with very little understanding of how it actually works.

We teach them how to use phones, tablets, and apps...

But what if the real safety net isn’t just parental controls—it’s digital literacy?

I believe one of the best ways to protect children online is to teach them how the internet is built—and that starts with learning to code.

🧠 Understanding = Empowerment

When kids learn the basics of how websites, web apps, and networks function, they gain more than technical skills.

They learn:

What’s real vs. what’s manipulated
How to question what they see online
Why security matters
What personal information should (and should not) be shared

In short: they go from passive users to active thinkers.

🌍 Start With the Foundations

You don’t have to wait until high school to teach the internet.

Even younger kids can grasp the fundamentals of:

HTML (how structure is created)
CSS (how it looks)
JavaScript (how it works)
Browsers, domains, IP addresses, links, cookies, and basic safety

💡 Free Resources to Help Kids Learn the Internet

Here are free, beginner-friendly platforms that make it fun and accessible:

✅ W3Schools

Simple, clean, interactive. A great way for kids (and adults) to test out HTML, CSS, and JS with zero setup.

✅ FreeCodeCamp

Step-by-step learning with real-world projects. Their "Responsive Web Design" and "JavaScript Algorithms" sections are gold.

✅ Sololearn

Interactive mobile learning. Great for kids who love gamified experiences with bite-sized coding lessons.

✅ CS First by Google

Aimed at younger students (grades 4–8), using Scratch to teach coding in a visual, story-based format.

✅ The Web Literacy Map (by Mozilla)

A fantastic breakdown of core web concepts: from understanding URLs to building trustworthy content.

👨‍👩‍👧 Tech Isn’t the Enemy—Ignorance Is

We can’t shield kids from every corner of the internet. But we can equip them to understand what they’re seeing and how things work behind the scenes.

When kids learn to code, they don’t just become tech-savvy—they become more confident, critical, and curious about the world they’re growing up in.

💬 Let’s Talk

How are you teaching your kids (or students) about the internet?
What age do you think is right to introduce coding?
What tools or platforms helped you understand how the web works?

If we want a smarter, safer internet for the next generation—we need to start teaching them how it’s built.

W3Schools Still Slaps — Here's Why I Keep Coming Back to It

John Liter — Mon, 23 Jun 2025 12:33:09 +0000

Photo is a snippet from W3 Schools:

There’s this unspoken idea in developer circles that once you reach a certain level, you should stop using sites like W3Schools.

But let me be real with you—I still use it. A lot.

And honestly?

I don’t just use it…

I recommend it.

🧠 It's Not Fancy. It's Fast.

W3Schools isn’t trying to impress you with animations, AI chat, or deep dives into obscure frameworks. What it does do is this:

“Here’s how to do the thing you forgot how to do.”

Clear. Simple. To the point.

I don’t need a YouTube course to remind me how flex-grow works or how to write a basic onclick function.

I just need it now. W3 delivers.

🛠️ It’s Perfect for the "I Know This... But I Forgot" Moments

You know that feeling—you’re working on something more advanced, but your brain blanks on a basic syntax or method. It happens to all of us.

That’s when I hit W3Schools.

It’s my mental Post-it note.

A quick refresher so I can keep building without going down a rabbit hole.

🤝 It’s Not Just for Beginners—It’s for Builders

People label W3Schools as a “beginner site.” But that’s not a downside. That’s a superpower.

When I’m deep into React or Node or wrangling a REST API, the last thing I want is to get lost in overcomplicated documentation.

Sometimes, the best way forward is just going back to the basics—fast.

💬 My Take

W3Schools is like that friend who never left your hometown.

They didn’t become flashy or trendy.

But when you come back for help—they’re still there.

Still solid. Still useful.

🙋‍♂️ I’m Curious:

Do you still use W3Schools when you need a quick syntax check?
What other go-to resources do you rely on for fast refreshers?
Why do you think devs sometimes feel weird admitting they use simple tools?

Let’s normalize using what works—not what looks good in a tweet.

Because at the end of the day, building things matters more than impressing people with how you got there.

Time, Code, and Chaos: What I’m Learning About Balance as a Developer

John Liter — Sun, 22 Jun 2025 13:36:30 +0000

Some days I feel unstoppable—deep in the zone, code flowing, tabs organized, energy locked in.

Other days… it’s 4 PM, I’ve bounced between Slack, VS Code, Notion, and six Stack Overflow threads—and I can’t tell you what I actually finished.

Being a developer comes with freedom. But no one talks enough about the pressure that freedom brings.

Time is weird in this work.

🧠 I’ve Learned That “Busy” Isn’t the Same as Productive

I used to think being constantly active meant I was making progress.

But now, I catch myself asking:

“What actually moved forward today?”

Some days, the only real win was deleting code that no longer served a purpose—and that’s okay.

💻 Deep Work Is Rare… and Priceless

There’s something powerful about a solid 2-hour coding window—no notifications, no background noise, just solving.

Those moments don’t happen by accident. And they don’t happen every day.

But when they do, they remind me why I started coding in the first place.

🔁 Routines Help, Until They Don’t

I’ve tried Pomodoros, strict schedules, even time blocking.

Sometimes they work.

Other times, I need flexibility more than structure.

The trick—for me, at least—is knowing which version of me is showing up that day. And adjusting without guilt.

😮‍💨 I’ve Felt Burned Out from Doing “Too Much Nothing”

Burnout doesn’t always come from shipping too much.

Sometimes it comes from staring at the same problem too long, getting nowhere, and losing the joy of the work.

That’s when I step away. I don’t “quit”—I just give myself space to come back stronger.

🧭 I Don’t Have It All Figured Out

Some weeks I feel aligned. Others, I feel scattered.

But I’ve learned to check in with myself—not just my code.

“Am I creating, or just reacting today?”

“Am I learning, or just collecting tabs?”

“Do I feel behind—or just tired?”

That’s made all the difference.

💬 I’m Curious

How do you manage your time without losing momentum?
Have you found a rhythm that works for you—or are you still figuring it out like me?
What makes you feel in control of your time as a dev?

Drop your thoughts. Let’s talk about the messy, honest side of productivity—no hustle posts, no hacks, just real dev life.

Encouragement Over Ego: Why Helping New Developers Is All of Our Responsibility

John Liter — Fri, 20 Jun 2025 12:42:06 +0000

Every day, I scroll through posts about React components, side projects, and coding journeys—some polished, some raw, some still figuring it out.

And honestly? I love it.

Not because every post is groundbreaking… but because every post is someone showing up.

You’ll see yet another calculator app, another to-do list clone, or a portfolio site with colors too bright to stare at for long. But behind every one of those posts is a new developer trying to grow. Trying not to quit. Trying to matter.

And that’s where we come in.

👣 We’ve All Been There

Whether you’ve been coding for 10 months or 10 years, you didn’t start by building full-stack SaaS platforms. You started with console logs, broken loops, and endless hours debugging things that seem trivial now.

That’s why we can’t roll our eyes at beginner projects.

We were them.

And they will become us.

❤️ Every Like Counts

We underestimate how powerful small gestures are.

A simple:

"Great job!"
"Keep going!"
"Here’s a helpful article I used at that stage..."

Can completely change someone’s mindset. It can be the difference between giving up and pushing through.

Because let’s be real—early dev work is fragile. Not in code, but in confidence.

🧭 Feedback Is a Gift—If You Give It Right

Being supportive doesn’t mean sugarcoating everything. Constructive feedback is love—when delivered with care.

Say:

“Your site looks clean! One suggestion: here’s a great article on accessible color contrast—could help sharpen the UX.”

That shows you care about their growth, not just your opinion.

🌱 Growth Starts With Recognition

If we want stronger developers tomorrow, we need to nurture them today.

Celebrate their small wins. Encourage them to publish. Show them the ropes. Remind them that progress is messy—and that’s okay.

Because the next person who builds a breakthrough dev tool, or revolutionizes front-end workflows, or launches the best open-source tool of the year…

Might be that same new dev building their third to-do app right now.

Let’s Talk 👇

What’s the best encouragement you received early in your dev journey?
How do you give feedback that’s honest but uplifting?
What’s one piece of advice you wish someone gave you when you started?

Let’s keep showing up for the next generation.

Not because we have to.

But because someone once did it for us.

Tools I Use as a Developer (And Why They Keep Me Growing)

John Liter — Thu, 19 Jun 2025 12:52:13 +0000

As developers, we don’t just write code—we build systems around our learning, creativity, and progress. Whether you're launching projects, writing docs, or sharpening your skills, the tools you choose can shape your entire journey.

Here’s a quick look into the ecosystem I use every day to stay sharp, stay organized, and stay building 👇

🧠 Notion – My Digital Brain

Notion is where everything lives:

Coding notes
College class takeaways
Project ideas
Even random bug fixes I never want to forget

It’s more than a notebook—it’s my developer journal. Clean, flexible, and always evolving with me.

💻 GitHub – My Code Vault

Every project, big or small, lives on GitHub.

It’s not just for version control—it’s a portfolio, a backup plan, and a personal timeline of my evolution as a dev. I can look back and see how far I’ve come, line by line.

🌐 daily.dev – My Learning Hub

Every day, I log into daily.dev to discover something new—

A framework breakdown, a Git trick I didn’t know, or a mindset shift from another dev’s blog.

It’s not just a feed. It’s my launchpad for lifelong learning.

✍️ dev.to – Where I Share and Reflect

I’ve started publishing articles on dev.to, and it’s become a place where I clarify what I learn by teaching others. I share those posts on daily.dev too, hoping to give back to the same community that’s helped me grow.

Writing makes the knowledge stick—and helps someone else in the process.

🌐 Hostinger – My Web Publishing Engine

I use Hostinger to host my business websites and personal projects.

Fast, clean, and beginner-friendly—I can deploy sites without overthinking infrastructure. That’s more time for building and less time fighting DNS configs.

🎬 Adobe Premiere Pro – For My YouTube Journey

I just learned Adobe Premiere Pro, and now I’m creating content for my YouTube channel.

Video editing felt overwhelming at first—but now it’s another way to express what I’ve built, learned, or want to teach. Sharing knowledge visually is powerful—and a new skill that’s already opening doors.

💬 What Tools Power Your Dev Journey?

I’m curious:

What’s your go-to app for organizing your brain?
Which tools do you actually use daily?
Have you started sharing your work—or are you waiting for it to be “perfect”?

Whether you’re a full-stack veteran or just starting out, the tools you build with say a lot about how you’re growing. Let’s swap ideas and sharpen each other.