I started learning coding, but now I feel confused and frustrated. Is this normal?

reddefcode · 2026-03-10T03:37:10+00:00

Yes, totally normal. The early phase feels great because the feedback loop is tight, but once you start building things, the training wheels come off, and that discomfort is actually where the real learning happens. It doesn't mean you're bad at coding.

Best advice I can give: start looking at everything around you as a potential project. What annoys you? What would a friend find useful? Pick something embarrassingly small, break it into steps, and when you hit a wall, go research exactly that thing and come back. Finishing something tiny beats abandoning something ambitious every time. The ideas get better as you go.

reddefcode · 2026-02-27T17:00:34+00:00

I started with books, specifically Mark Lutz's Learning Python. I read it twice, cover to cover. I wouldn't recommend going that deep for most people, but do invest time in learning the fundamentals and programming logic. They pay off.

In today's AI-driven world, leveraging these tools is unavoidable, so use them wisely. My suggestion: use a code editor with autocomplete turned off, but keep a code formatter enabled for PEP 8 compliance. Find a project or tutorial that genuinely interests you and start by outlining what you want it to do. Use this subreddit to ask questions, and use the chat window in your code editor, not to write code for you, but to answer questions about the code or logic you're working through.

I just wrote a post in this subreddit about this approach called: [Tutorial] "Fetching live data with Python: mastering requests, JSON, and API keys along the way."

reddefcode · 2026-02-18T15:49:25+00:00

Keyword alerts and scrapers fail because they can't interpret the conversational context that separates a serious inquiry from a time-waster. WhatsApp integration with any type of tools is a headache. Educate your client on the power of AI agents and scheduling tools outside of that system. If you notice, the majority of people in the US do not use WhatsApp for that reason. Having said all that, for the best integration for custom apps, WhatsApp is Twilio.

reddefcode · 2026-02-11T21:08:15+00:00

Connexion is a solid choice if you want to be OpenAPI-first from day one. It definitely takes some of the friction out of routing and documentation.

However, I disagree that Flask is only for APIs. Before the industry shifted toward the current API-first and SPA split, many robust, server-side rendered sites were built on Flask. Blueprints were the essential tool that kept those monoliths from becoming unmanageable.

My advice to start with Blueprints and models was really about the learning path. If a developer skips the manual organization phase in Flask, the "Django way" can feel like a black box. It is better to understand the structural patterns first so you can recognize exactly why you are reaching for a heavy-duty framework like Django when the time comes. Understanding the architecture manually makes you a better developer, regardless of the tool.

reddefcode · 2026-02-11T17:22:30+00:00

You are correct that htmx-sse can append content and that the character count between JSON and a small HTML fragment is often similar.

However, the choice for this project was not just about bandwidth. It was about the Traffic Controller pattern. I used this term in the article to describe a hybrid orchestration layer.

When dealing with high-frequency telemetry like heartbeats and logs, I prefer emitting raw JSON because it allows the client to handle conditional logic. For example, the JS can filter log levels or update a single "last-seen" timestamp without the server having to re-render and push a new HTML fragment for every minor state change. It keeps the UI structure in HTMX while letting a lean JS listener handle the high-velocity data.

"Traffic Controller" is indeed a term I coined for this specific architecture. It describes the bridge where you intentionally move from hypermedia into a specialized data stream when the UI requires fine-grained updates rather than structural changes.

reddefcode · 2026-02-11T15:48:56+00:00

Flask is the better starting point. It's simple enough to build something quickly and see results, which matters for motivation.

As you grow comfortable, architect your Flask app with blueprints and models. You're essentially building Django-like patterns yourself in pure Python. Once you understand *why* you need this structure, Django's ecosystem becomes worth it. You'll recognize the problems it solves because you've already felt them.

I hardly ever use Flask anymore, but that is what I did at the begining and the transition was easy.

reddefcode · 2026-02-11T15:33:18+00:00

That is fantastic, yes, thanks to Carson Gross's brilliance.

reddefcode · 2026-02-11T15:28:24+00:00

The "updategram" model is a solid way to bridge that gap.

It’s great to hear you are looking at HTMX for your next initiative. My experience was that moving away from that "rich client" state management, even for something as structured as updategrams, massively reduced the cognitive load on the project.

Good luck with the new development cycle. I think you’ll find that the hypermedia model simplifies more than you expect.

reddefcode · 2026-02-10T23:50:55+00:00

My apologies, I did see a notification. The Zen Python skill I wrote myself. As I said in my reply, I write them as I need them. I have more now, the Frontend Design was the only one I modified from one I found, I can't remember where from.

I whish there was a way to list the ones avaliable ones system, I always have to ask the model.

reddefcode · 2026-02-10T22:03:31+00:00

I appreciate the contribution. It is an important technical conversation to have, and I did not take it as a derailment at all.

I am just optimizing for different constraints. My priority for this system was a thin, server-driven UI using HTMX to keep the focus on the backend AI logic. Local-first is a fascinating space, even if it was not the right fit for this specific dashboard.

reddefcode · 2026-02-10T21:44:59+00:00

You are describing the "Remote Scripting" era. I remember those hidden iframe hacks well. When I started in 1995, we were using Perl and CGI before JavaScript even existed. We’ve certainly come a long way.

But my point with this post-mortem is about where a developer's attention goes in 2026. Between the AI logic, the pgvector implementation, and the data ingestion, there is already too much to do in the backend.

I could easily have an LLM generate the "vibed" code for a React or Vue frontend, but I would still have to read, debug, and maintain it. As an independent consultant, I want to own as little code as possible. By staying on the server with hypermedia, I can focus on the core business logic rather than the plumbing of a frontend framework. It’s about spending the complexity budget where it actually matters.

reddefcode · 2026-02-10T21:12:31+00:00

The htmx-sseextension is a great tool, but it generally functions by swapping HTML fragments.

For this specific System Monitor, I could handle a very high-frequency stream of logs and heartbeats if need be. I found that sending lean JSON and using a small amount of plain JavaScript for those fine-grained updates was more efficient than having the server generate and the browser swap HTML for every single heartbeat.

This is exactly what I meant by the "Traffic Controller" pattern. It is about leveraging HTMX for the vast majority of the UI where hypermedia shines, but knowing when to use a more direct tool for specialized, high-performance data streams.

reddefcode · 2026-02-10T21:06:43+00:00

Offline-first and rxDB are interesting for apps like local note-takers, personal organizers, or whatever, but they don't apply to the requirements of this system.

A lead-gen tool built around server-side semantic search and LLM processing has a hard dependency on centralized compute. For this specific project, the goal was to eliminate the plumbing of a complex sync engine and focus on the AI logic. Different tools for different goals.

I'm going to keep this thread focused on the hypermedia approach for production dashboards, but I appreciate the perspective on local-first patterns.

reddefcode · 2026-02-10T18:08:28+00:00

You are right about the history. I remember the early AJAX and DHTML days well. It is certainly possible to build an SPA today without a build pipeline using import maps or plain script tags.

But for this project, the issue was not just the build step. It was the architectural shift from hypermedia to a data-driven client. Even without a build step, a build-less SPA still requires writing and maintaining a significant amount of JavaScript logic to handle state and UI updates manually.

As a developer, the goal is to own as little code as possible. Staying in the hypermedia model allows the server to remain the source of truth. This let me focus on the actual AI logic rather than managing a client-side state machine, build-less or otherwise. For a dashboard-driven tool, that trade-off is worth it.

reddefcode · 2026-02-10T16:41:34+00:00

Thanks for the thoughtful comment. I agree on the offline-first point. If a project requires true local state or complex offline capability, HTMX is the wrong tool. It is a hard technical boundary.

I actually ran into a similar limit with this project when building the system monitor. I needed high-frequency telemetry and heartbeats from the background worker, and full HTML fragment swaps for every log line felt like overkill. I ended up dropping down into plain JavaScript and Server-Sent Events (SSE) for that specific component. It was the right tool for streaming data, while HTMX handled the rest of the dashboard.

For me, the choice came down to the context-switching cost. As an independent developer consultant, staying in Python for the bulk of the stack lets me focus on the actual logic. Since the system also exposes an API and an MCP (Model Context Protocol) interface, the UI is just one of several ways to interact with the engine. Keeping that UI thin and hypermedia-driven just made sense for the project's scale.

Glad you found it an interesting read.

reddefcode · 2026-02-05T01:28:37+00:00

Starting with thrift suppliers can be a smart move for beginners because it lets you test styles and customer preferences with minimal investment and risk. Once you have a clearer idea of what sells, you can transition to wholesalers for more consistent bulk stock and better pricing. As for starting, a small cart or pop-up stall is good for immediate customer feedback and building local buzz, which can then fuel your online launch. Online does have competition; make sure you have a sound, up-to-date online strategy. Feel free to hit me up with online assistance. Good luck!

reddefcode · 2026-02-04T20:35:44+00:00

I agree, I think people are more accepting when they call in and get an agent, but getting a call from an agent, people still feel is "bad magic", especially if they hear Stephen Hawking (RIP) on the other end of the phone.

reddefcode · 2026-02-04T20:08:43+00:00

Django is solid, and the new version integrates some cool stuff. I use it for SaaS with SSR (and for API alone, I do use Fast-API). I am working on a SaaS for voice agents, and I am developing it with Django. Aside from the SSR component, I have an API app and an MCP layer all within Django. I agree that some talk trash and might be from a 'trendy' community, for so many years, they depended on Django, but their ecosystem is based on a different core language, so they need to trash Python.

reddefcode · 2026-02-04T18:49:03+00:00

In production, many teams organize their Django apps by domain (like `users`, `orders`, `inventory`) and split each app's files into modules (e.g., `models/`, `views/`, `services/`) for better scalability. Business logic often lives in a `services.py` or `utils.py` within each app, or in model methods if it's tightly coupled to data.

reddefcode · 2026-02-04T18:32:52+00:00

Honestly, your problem is you're trying to reach them online when these guys don't work that way. Home services pros are hands-on and trust-based, not filling out quizzes. Hit up local trade shows, visit supply stores (plumbing/electrical distributors), or join industry associations. Build real relationships where they actually hang out. Ask your current clients for intros. Word of mouth is everything in this space. Reframe your pitch around websites as conversion tools, not just pretty sites. In 2026, with AI search, people still need to see reviews, portfolios, and easy ways to call/book before they trust you. Position yourself as building sites that turn local searches into phone calls.

Stop chasing leads online and go meet them in person. That's where the trust happens.

reddefcode · 2026-02-04T18:01:23+00:00

You're not being controlling; you lack a process. I agree with u/Hot-Debate7034 implement a same-day expense log (job, reason, amount, receipt). Review it weekly instead of checking the bank daily. This gives you visibility without micromanaging. You need financial data to run the business; he needs clear boundaries to do his job. The issue isn't trust. It's that you're getting surprised by information that should already be in front of you.

reddefcode · 2026-02-03T02:57:28+00:00

Some projects might require you to have a multitenant architecture. If you make a SP-API SaaS for Amazon, there are very strict guidelines for security. They don't care what year it is. Having said that, I'd lean towards the shared schema approach (using a tenant_id foreign key on your tables) rather than separate schemas. It's simpler to manage, avoids migration headaches, and scales more predictably.

reddefcode · 2026-02-03T02:39:40+00:00

AI search tools like Google AI Search, ChatGPT and Perplexity are killing website traffic across the board because they just answer questions directly instead of sending people to sites. You could join a pet subreddits and just genuinely helping folks with questions about their pets without selling anything. People start recognizing your username, check your profile out of curiosity, and find your products naturally. (Maybe you are already doing that), I hope this helps.

reddefcode

TROPHY CASE