DEV Community: Frank Smith III

What Field Operations Taught Me About Debugging Software

Frank Smith III — Tue, 30 Jun 2026 10:32:43 +0000

I work in field operations in water treatment, and I also build full-stack software projects. Those two parts of my background may look different from the outside, but they have shaped the same way of thinking: understand the system, document what is happening, isolate the issue, and work toward a dependable fix.

Field operations taught me that troubleshooting is not about guessing louder. It is about slowing down enough to observe what the system is actually doing. When a real-world process is not behaving the way it should, the first step is not to force a solution. The first step is to gather facts.

That mindset transfers directly into debugging software.

When an application fails, I try to avoid jumping straight to the line of code that looks suspicious. I ask what changed, what input caused the behavior, what the logs show, and whether I can reproduce the issue. I want a repeatable path to the problem, not just a lucky fix.

In field work, documentation matters because the next person may need to understand what happened. In software, that same principle shows up in readable commits, useful notes, clear README files, and code that explains its intent. A fix that only lives in my head is not a complete fix.

Safety also changes how I think. In water treatment and field operations, reliability is not theoretical. Systems affect people, schedules, and daily work. That makes me respect process. I do not want to create new problems by rushing past verification.

In code, that means I look for small checks before large assumptions. If I am working on an API route, I want to know how the request is shaped, what validation exists, what the database expects, and how errors are returned. If I am working on a front-end workflow, I want to understand the user path before changing the interface.

Projects like Cutz By Casper, Jukebox Pro, and Book Buddy gave me practical places to apply that approach. Each one required more than writing code that worked once. I had to think through application state, user actions, API behavior, authentication, data flow, and what should happen when something goes wrong.

I still have plenty to learn, but field operations gave me a useful foundation: stay calm, be specific, communicate clearly, and keep improving the system.

That is how I try to debug software now. I look for the cause, not just the symptom. I document what I learn. I test the fix. And I keep building better habits with every project.

Portfolio: https://franksmithlll.com

Developer resume: https://frank-smith-developer-resume.netlify.app

GitHub: https://github.com/frankbjj23

Projects: https://franksmithlll.com/projects

Jukebox Pro API Notes: JWT Auth, Postgres, and Protected Playlist Routes

Frank Smith III — Wed, 17 Jun 2026 15:31:22 +0000

When Frank Smith III built Jukebox Pro, the useful part of the project was not just storing playlist data. The application needed a backend structure that could separate public behavior from authenticated user actions and keep the playlist workflow predictable.

Jukebox Pro is an Express and Postgres playlist API. The verified project stack includes Node.js, Express, PostgreSQL, JSON Web Token authentication, bcrypt password hashing, protected playlist routes, seed data, and Vitest/Supertest coverage.

The problem

A playlist API looks simple until the application needs account-based behavior. Users need to register, log in, and access routes that should not be available without a valid session token. That changes the shape of the backend. The project needs clear route boundaries, predictable error handling, and a database model that supports repeatable local development.

Authentication workflow

The authentication flow uses registration and login endpoints. Passwords are hashed with bcrypt before storage, and successful login returns a JWT that the client can use when calling protected routes.

That structure keeps the important responsibilities separated:

Express handles route behavior.
Postgres stores application data.
bcrypt handles password hashing.
JWT authentication controls access to protected playlist actions.
Tests help confirm that the API behaves correctly as routes evolve.

Why protected routes matter

Protected routes are where a small API starts to feel like a real application. Instead of every endpoint being open, Jukebox Pro can distinguish between general API behavior and actions that belong to an authenticated user.

For Frank Smith III, that was the point of the build: practice the backend decisions that make full-stack applications more reliable. A useful API is not only about returning data. It also has to enforce boundaries consistently.

Seed data and testing

Seed data makes the development environment easier to reason about. Instead of manually recreating records every time, the project can start from known data and make route behavior easier to test.

Vitest and Supertest coverage also matter because authentication bugs are easy to miss manually. A route can appear to work in the browser or API client while still failing edge cases around missing tokens, bad credentials, or protected behavior.

Lessons from the project

Jukebox Pro reinforced a few practical backend lessons:

Keep authentication logic clear and isolated.
Make protected routes explicit.
Use seed data to make local development repeatable.
Test user flows that affect access control.
Prefer boring, readable API structure over clever abstractions.

This kind of project fits Frank's broader work as a full-stack developer and Field Operations Specialist in water treatment. Both environments reward clear process, reliability, and predictable systems.

Read the full official project note here: https://franksmithlll.com/jukebox-pro-api-authentication-frank-smith-iii

Project portfolio: https://franksmithlll.com/projects

GitHub: https://github.com/frankbjj23/jukebox-pro

Why Systems Thinking Is a Web Developer Superpower

Frank Smith III — Wed, 18 Feb 2026 15:59:29 +0000

A lot of people treat switching careers like starting over.

I do not.

Because if you have ever been responsible for outcomes with real stakes, you already understand what most early developers spend years trying to learn: systems.

I came into web development with a background that is not the typical straight line. I have led operations as a COO. I built and ran a financial services company. I have spent years as an independent trainer building structured programs, tracking progress, adjusting inputs, and owning results. Now I build web applications with JavaScript, React, Node, Express, and PostgreSQL.

On paper that looks like a pivot.

In reality it is the same job, just a different interface.

The part nobody tells career changers
Most “learn to code” advice makes it sound like the key skill is memorizing syntax.

Syntax matters, but it is not the game.

The game is:

understanding a problem clearly
breaking it into smaller parts
choosing constraints
building something reliable
improving it over time without breaking what already works

If you have ever run a team, managed performance, handled compliance, or fixed operational bottlenecks, you already know this cycle.

Software engineering is operations, but the system is the product.

My foundation: building systems that actually run
As a COO in a high volume finance environment, the work was not “being busy.” It was building accountability, tracking performance, and creating repeatable processes so the organization could scale without chaos.

As a business owner, it was even more direct. When the system breaks, you feel it immediately: clients churn, timelines slip, cash flow gets weird, and stress goes through the roof. The only fix is structure.

As an independent trainer, the same thing shows up in a different way. You cannot guess your way to results. You measure, you adjust, you plan phases, you respect recovery, you test what works, and you hold yourself accountable.

That is systems thinking.

That is also engineering.

Why I chose full stack web development
Web development is a perfect match for how I think.

You are constantly balancing tradeoffs:

user experience vs speed of delivery
clean architecture vs quick iteration
security vs convenience
scalability vs simplicity

My training and current toolset includes:

JavaScript, HTML, CSS, SQL
React and React Router for UI and navigation
Node and Express for backend fundamentals
PostgreSQL for data modeling
Git and GitHub for version control
authentication concepts like JWT and bcrypt
practical use of AI tools to accelerate debugging and iteration

That combination lets me build real applications, not just tutorials.

And I am building real applications.

Projects that translate directly to real world product work
I build portfolio projects that are not abstract. They are tied to real users and real needs.

A public facing advocacy site (in progress)
A responsive site that showcases an attorney’s work and advocacy. This is not just design. It is communication, structure, and clarity.

A barber booking app (in progress)
Scheduling is a workflow problem. That is where my background shines. Booking is not just a calendar. It is real life logic: availability, customer communication, reliability, and smooth UX.

A wedding experience page
Mobile friendly, photo forward, clean presentation. This is UI work with real constraints: it has to look good, load fast, and work on phones.

A group trip planning prototype
Centralizing options, links, dates, comments, voting. That is product thinking. It is a small collaborative system, the kind teams actually use.

None of these are random.

They are practice reps for building user focused software.

The real value I bring to engineering teams
Here is the uncomfortable truth.

A lot of early developers can code, but they cannot deliver.

They struggle with:

unclear communication
messy prioritization
shipping things that work but are impossible to maintain
ignoring edge cases until production finds them
working solo instead of collaborating

My edge is that I have lived in environments where results are non negotiable.

I bring:

accountability and follow through
strong written communication
comfort with ownership
an instinct for building repeatable workflows
respect for process without being a process robot
systems thinking that supports scale

And yes, I can build.

But I can also help a team ship.

AI assisted development is not cheating, it is leverage
I use tools like ChatGPT and Copilot the same way I used dashboards and tracking systems in operations: to shorten feedback loops.

AI does not replace fundamentals. It makes iteration faster.

The skill is knowing what to ask, how to validate, and how to integrate what you learn into your own understanding. That is how you become dangerous quickly.

If you are hiring, here is the simplest summary
I am a full stack trained web developer who is building applications right now.

I also have years of experience running systems, managing accountability, improving processes, and owning outcomes.

That combination matters.

Because code is not the product.

Reliable delivery is.

And I am here to build scalable, user focused software with a team that cares about quality and execution.

Organization Is a Developer Superpower

Frank Smith III — Sun, 11 Jan 2026 22:19:13 +0000

Medium Article

Jiu-Jitsu and Coding Bootcamp:

Frank Smith III — Mon, 08 Dec 2025 18:24:00 +0000

How Physical and Mental Stress Shape Resilience — By Frank Smith III

In both the martial arts world and the world of software development, the path toward mastery demands discipline, humility, pain tolerance, problem-solving, and the willingness to stay calm under pressure. As Frank Smith III, a software developer from Mahwah, New Jersey, I’ve learned that the stresses of jiu-jitsu training and coding bootcamp are more similar than most people realize.

Jiu-jitsu challenges the body.
Coding challenges the mind.
But both challenge the spirit.

And both force you to evolve.

The deeper I get into my coding journey—and the more I advance in jiu-jitsu—the more I see the overlap between these two demanding paths. They grind you down in different ways, but they build you up using the same principles.

Both Jiu-Jitsu and Coding Bootcamp Push You Into Discomfort

Jiu-jitsu places you in physically uncomfortable positions that force you to breathe, think, and find solutions under pressure. Coding bootcamp does the same thing—except the pressure is cognitive.

In jiu-jitsu:

Someone is crushing your chest

Your grips are failing

Your muscles are burning

Your lungs want to quit

In coding bootcamp:

Your brain overheats

Your logic loops collapse

Your debugging attempts fail

Your self-doubt creeps in

In both worlds, discomfort is not a sign that you’re failing—it's a sign that you’re growing.

Technique Beats Strength — In Jiu-Jitsu AND in Coding

A beginner in jiu-jitsu uses strength.
A beginner coder uses pure effort.

But experts in both fields rely on:

Technique

Strategy

Efficiency

Calm problem-solving

The black belt conserves energy.
The senior developer conserves mental bandwidth.

Jiu-jitsu teaches you that brute force burns you out fast.
Coding teaches the same thing: working harder is not the same as working smarter.

In both arenas, finesse wins.

Failure Is a Requirement, Not a Setback

In jiu-jitsu, you tap repeatedly—sometimes dozens of times in one session.
In coding, you break your code repeatedly until it finally works.

Both forms of stress feel personal, but neither is punishment.

They are part of the process.

You cannot learn jiu-jitsu without tapping.
You cannot learn software development without breaking things.

Over time, you stop fearing failure. You start using it.

That shift creates resilience, and resilience is your real advantage.

Mental Fatigue and Physical Fatigue Feel Different—But Hit the Same Wall

There’s a point during hard jiu-jitsu training where your forearms lock up and your legs shake.
There’s a point in coding where your focus collapses and your ability to think logically falls apart.

Both are signs that you’ve pushed your internal system to its limit.

The exhaustion may be different, but the solution is the same:

Breathe

Reset

Recover

Get back in

Apply what you learned

Both practices train your nervous system to operate under a higher threshold of stress.

That is why they both make you better—not just physically or mentally, but holistically.

Jiu-Jitsu Builds the Grit You Need for Coding Bootcamp

A lot of people quit jiu-jitsu in the first month.
A lot of people quit coding bootcamp before the real growth happens.

What keeps people in both arenas is grit—the ability to keep going when things aren’t comfortable, easy, or fun.

The more time you spend on the mats, the more you understand:

Progress comes from repetition

Mastery comes from consistency

Breakthroughs happen suddenly after long plateaus

Coding bootcamp delivers the same lessons.

You grind through hours of frustration…
…until suddenly, a concept clicks.

That moment—just like hitting your first armbar or escaping your first choke—reminds you why you’re doing this.

Mindfulness Is the Secret Skill That Connects Both Worlds

To survive intense training in either discipline, you learn to stay present.

In jiu-jitsu, if your mind wanders, you get swept or submitted.
In coding, if your mind wanders, your logic falls apart and bugs multiply.

Mindfulness becomes your anchor.

It helps you:

Focus

Stay calm under pressure

Handle frustration

Reset when overwhelmed

Make smarter decisions

The mental fitness you develop on the mats directly improves your cognitive endurance in software development.

And coding strengthens your patience when you're fighting exhaustion during rolls.

Both worlds refine the same muscle: controlled awareness.

Jiu-Jitsu and Software Development Build Identity

Through jiu-jitsu, I learned who I am under pressure.
Through coding bootcamp, I learned what I’m capable of building.

Together, they shape a stronger version of me:

More disciplined

More focused

More resilient

More adaptable

🏋️‍♂️ Spartan Racing, Software Development, and the Power of Relentless Grit

Frank Smith III — Sun, 07 Dec 2025 18:57:15 +0000

By FranK Smith III, Software Developer & Fitness Professional in Mahwah, Bergen County, NJ

When people hear the name Frank Smith III, they usually associate me with fitness, discipline, and my work as a software developer in Mahwah, New Jersey. What most don’t realize is how deeply my two worlds — Spartan racing and coding — overlap.

Both demand resilience.
Both require strategy.
Both force you to level up — mentally and physically.

And both shaped who I am today.

In this article, I’m breaking down how Spartan Racing and software development reinforce each other, and why grit is the ultimate advantage for anyone looking to grow in tech, fitness, or life.

💡 1. Spartan Racing Taught Me That Preparation Is Everything

Whether I’m training for a Spartan Race in Bergen County or preparing for a build session as a software developer, the rules don’t change:

You can’t fake the work.

On the race course, your conditioning tells the truth.
In code, your logic does.

Both expose gaps immediately and reward consistency.

As I've learned firsthand in Mahwah, NJ, progress rewards daily discipline — not shortcuts.

🧱 2. Every Obstacle Is a Bug in Disguise

The first time I failed an obstacle in a Spartan Race, I felt the same frustration as staring down a stubborn JavaScript bug that refused to resolve.

Obstacles slow you down.
Bugs slow you down.

But neither stops you unless you quit.

I’ve learned that:

Obstacles = opportunities

Bugs = breakthroughs

Failure = data

Progress = problem-solving

The mindset I built on the race course made me a stronger, more focused software developer.

🔁 3. Iteration Beats Speed (In Racing and in Code)

A lot of people think Spartan Racers sprint the whole race.
They don’t.

Just like new coders think senior developers code fast.
They don’t.

The truth?

The best racers and the best developers are the ones who pace themselves, iterate, and stay consistent.

As Frank Smith III, balancing fitness, software development, and entrepreneurship, the biggest lesson I keep learning here in Mahwah is this:

Slow is smooth.
Smooth becomes fast.

🤝 4. Community Makes You Grow Deeper, Faster

Spartan races are built around teamwork. So is software development.

The communities I’ve been part of — from fitness groups in Bergen County to developer circles like Hashnode, GitHub, and Fullstack Academy — constantly push me forward.

Being surrounded by motivated people:

accelerates learning

increases accountability

expands perspective

reinforces discipline

Community is a multiplier.

🧠 5. Spartan Racing Built the Mental Toughness I Needed in Tech

A Spartan Race breaks you in ways the gym can’t.
Software development challenges your mind in ways a race never will.

Together, they forged the mental toughness that defines who I am as Frank Smith III — a software developer, fitness professional, and athlete continuously growing in Mahwah, NJ.

Both fields reward:

patience

problem-solving

self-discipline

emotional control

resilience under stress

When you learn to push through both physical and mental limits, everything else becomes easier.

🏆 Final Thought: Grit Is the True Competitive Advantage

Whether I’m coding an app, training clients in Bergen County, or competing in Spartan Races, one truth remains:

Grit beats talent when talent stops grinding.

I’m Frank Smith III, and my journey from Spartan courses to software development taught me that success is simple:

Show up daily.
Do the work.
Face the obstacle.
Solve the bug.
Keep going until the job is done.

Everything else follows.

🔗 Learn More

To see more of my work as a software developer in Mahwah, NJ and read additional articles, visit:

👉 []https://franksmithlll.com

Check out my new article on Mindfulness for Devs!

Frank Smith III — Sun, 07 Dec 2025 03:05:01 +0000

https://franksmithiii.hashnode.dev/mindfulness-for-developers-reducing-coding-burnout-increasing-focus

My Journey Into Fullstack Development — Frank Smith III (Mahwah, NJ)

Frank Smith III — Fri, 05 Dec 2025 14:50:15 +0000

Hey everyone — I’m Frank Smith III, a fullstack developer based in Mahwah, New Jersey with roots in Brooklyn. I’m currently training at Fullstack Academy while building real-world applications using JavaScript, React, Node.js, and modern frontend tools.

Where I Started

Before software, I spent years as an entrepreneur and personal trainer. I founded TheYardLLC and Eagle Holdings Corp, developing discipline, structure, and problem-solving skills that now shape my coding approach.

Why I Chose Software Engineering

I wanted a career where I could build things that scale — tools, apps, ideas that live online and impact people at any time. Coding gives me creativity and technical control.

What I’m Building Now

React applications

DOM utilities

API-driven tools

My Facility-Tree family tracking app

JavaScript practice challenges

Where I’m Going

My long-term goal is to create tech that blends fitness, wellness, and community impact. I love building systems and structured workflows — software lets me bring that to life.

If you want to connect or follow my journey, check out my links below:

Portfolio: https://www.franksmithlll.com

GitHub: https://github.com/frankbjj23

LinkedIn: https://www.linkedin.com/in/franksmithiii23/

Thanks for reading — more posts coming soon.