I did not start by wanting to be a software engineer.

I started with a simpler question:

What skill can I learn that pays and can be done online?

That question led me to digital marketing.

I started a Google certificate. Then I got to SEO. Then SEO put HTML in front of me, and I remember basically asking: what is that?

That was the first thread.

I pulled on it and got bit by the code bug.

I finished the Google cert, then enrolled in a coding bootcamp.

The bootcamp did not make me a complete developer. What it did was get me to the point where I could ask better questions. Instead of looking at the whole field as one giant unknown, I could start asking:

• What is the most modern framework?
• What are the best practices?
• How do people actually ship this?
• What should a real app use?
• What is the known solution here?

That is how I found Next.js.

By the time capstone came around, I was already reaching beyond the baseline because I was not only doing the assignments. I was following the questions.

Then I graduated into terrible market timing. The COVID software hiring boom was imploding. Entry-level roles were brutal, and the straightforward path into software did not open cleanly for reasons that were not only about ability.

So I asked another question:

How can I use these skills anyway?

That question changed the route.

I found a warehouse job at a startup distribution center. They were hiring for a systems team, but I did not just apply and wait. I got hired as a picker. I got close to the actual operation. I introduced myself to the systems manager and told him the truth: I can do this, I know SQL, and I can build apps.

I worked the floor. About a month later, I got the interview.

I killed it and got the job.

That became the next compounding loop. I went from Operations Systems Analyst II, the lowest level, to senior in less than two years. I took the operations knowledge from the floor and combined it with the software development knowledge from the bootcamp and self-teaching.

That combination is why I am here now.

The pattern underneath

I think of that path as question-driven development.

Not development as in "writing code only." Development as in building a skill, building a system, building a career, building a useful thing from the outside in.

The pattern kept repeating:

1. Ask what skill or path creates leverage.
2. Find the domain.
3. Learn enough terms to search and ask better questions.
4. Follow the questions into the next layer.
5. Get close enough to real work that the questions become practical.
6. Use the answers to create proof.

Digital marketing was probably the first place I saw it clearly. At first, the field looked like a pile of tools: ads, landing pages, analytics, email, SEO, funnels, copy, tracking pixels.

Then the words started to connect.

Conversion rate. Attribution. Intent. Creative fatigue. Offer. Segment. Retention.

Once I had the terms, I could ask better questions:

• Where is the drop-off?
• What is the user's intent?
• Is the offer clear?
• What are we measuring?
• What would make this page convert better?

Coding started the same way.

At first, code looked like syntax and errors. Then the recurring questions started to matter more than the syntax:

• What is the known solution for this?
• What is the standard pattern?
• Is this secure?
• What breaks in production?
• How can this be simpler?
• What are the edge cases?
• What would a senior engineer check before shipping?

That is what I mean by question-driven development.

It is not building by asking random questions. It is learning the question set that reveals how a domain actually works.

Technical is not one wall

The biggest shift was realizing that "technical" is not one wall you climb over.

It is a stack of smaller translations.

You learn the nouns. Then the verbs. Then the patterns. Then the failure modes. Then the taste.

At the beginning, you ask broad questions because you do not know the shape of the terrain. Over time, the questions get sharper:

• "How do I build an app?" becomes "What framework fits this use case?"
• "Why is this broken?" becomes "Is this a state issue, an auth issue, or an environment issue?"
• "Can AI code this?" becomes "What constraints, examples, and acceptance tests does the agent need?"
• "Is this done?" becomes "Would I trust this in production?"

That progression is the work.

The same thing happened when I moved from learning code to working in operations systems. The warehouse floor gave me context a tutorial never could. I was not only learning software anymore. I was learning how work moves through a real business: inventory, orders, labor, exceptions, scanning, picking, packing, reporting, escalation.

That changed the questions again:

• Where does the process actually break?
• What does the system think happened?
• What did the worker experience?
• What data is missing?
• What manual workaround has become invisible infrastructure?
• What would make the operation simpler tomorrow?

That is where software became more real for me.

Not because the code got more abstract. Because the code had to touch the floor.

Keywords are handles

Keywords are underrated.

When you do not know the right word, you cannot search well, prompt well, or ask for help well. You describe the symptom from the outside. The answer lives under a term you do not know yet.

Once you learn the term, the map opens.

You stop asking "why did the login thing disappear?" and start asking about sessions, cookies, callback URLs, token expiry, middleware, redirects, and environment variables.

You stop asking "how do I make this better?" and start asking about latency, accessibility, validation, error states, caching, observability, threat models, and maintainability.

The keyword is not trivia. It is the handle that lets you grab the concept.

This is also why AI tools are so powerful and so dangerous for beginners. They can answer almost anything, but the quality of the answer still depends on the shape of the question. If you do not know the terms, you cannot steer. If you do know the terms, the tool becomes a way to move faster through a domain.

The difference between a vague prompt and a useful prompt is often the difference between:

"Make this better."

and:

"Review this for security issues, production failure modes, accessibility gaps, and simpler known patterns. Explain tradeoffs before changing code."

Same tool. Different question.

The team version

The more I learned through questions and keywords, the more obvious it became that teams have the same problem.

Every team has a private dictionary, whether they admit it or not. People can use the same word and mean different work.

Take "launch."

One founder says, "I want to launch next week."

Depending on who hears it, that can mean:

• The app is deployed.
• The website is live.
• The first payment link works.
• The announcement post goes out.
• The onboarding flow is usable.
• The first customers are invited.
• The product is stable enough to support.

Those are not synonyms. They are different scopes of work hiding under one familiar word.

Question-driven development starts by refusing to treat that word as obvious.

Founders coming from engineering, design, sales, operations, finance, or media do not carry the same default meanings. A technical founder may hear "launch" and think release branch, production deploy, database migrations, auth, error monitoring, rollback plan. A marketing founder may hear the same word and think landing page, email sequence, announcement copy, offer positioning, social proof, and press timing.

Neither is wrong. The problem is that both can leave the conversation believing the team agreed.

That is where context drift starts.

In async teams, the drift gets worse because the disagreement has fewer chances to become visible. A Slack thread says "launch." A Notion page says "launch checklist." A ticket says "ready for launch." Each person fills in the missing definition from their own background. By the time the mismatch is obvious, the team has already built toward different targets.

Questions are the cheapest way to stop that:

• When we say "launch," what has to be true?
• What is included?
• What is explicitly not included?
• Who is the launch for?
• What breaks if we call it launched too early?
• What proof would make us comfortable saying it is live?

That is question-driven development too.

It is not just a way to learn or create. It is a way to keep meaning from drifting while you create.

The method

If I had to reduce the method, it would be this:

1. Find the word you do not understand.
2. Ask what it means in practice.
3. Ask what good looks like.
4. Ask what usually breaks.
5. Ask what the known solution is.
6. Ask what a better practitioner would check.
7. Use the answer to build something real.
8. Repeat until your questions change.

That last part matters.

The goal is not to have the perfect question at the start. The goal is to move from weak questions to sharper ones. Better questions are evidence that your understanding is improving.

That is how I learned digital marketing.

That is how I learned to code.

That is how I got into systems.

That is how I build now.

Question-driven development is not a slogan for me. It is the path.

FAQ

What is question-driven development? Question-driven development is learning the question set that reveals how a domain actually works, then following those questions from terms to patterns to failure modes to proof. It's not asking random questions — it's moving from weak, broad questions to sharper ones, where better questions are evidence that your understanding is improving.

Why do keywords matter so much when learning something new? Keywords are handles. When you don't know the right word, you can't search, prompt, or ask for help well — you can only describe a symptom from the outside while the answer lives under a term you don't know yet. Learning the term ("sessions," "token expiry," "observability") opens the map and lets you grab the concept.

How does this make AI tools more useful? The quality of an AI answer still depends on the shape of the question. "Make this better" and "review this for security issues, production failure modes, accessibility gaps, and simpler known patterns, and explain the tradeoffs" are the same tool with very different questions. If you know the terms, you can steer; if you don't, you can't.

How can a team use question-driven development? By refusing to treat shared words as obvious. Words like "launch" hide different scopes of work for engineering, marketing, and operations people, and async teams drift when each person fills in their own definition. Cheap, specific questions — what has to be true, what's included, what's explicitly not, what breaks if we call it done too early — keep meaning from drifting while you build.

---

Stride TechWorks ships production systems for small teams with this same question-driven approach. See what we build or start a conversation.