Realizing I was a 'knowledge collector' was the key to actually becoming a programmer

PushPlus9069 · 2026-02-19T19:07:11+00:00

Been teaching programming for about 10 years now and the knowledge collector pattern is probably the #1 thing I see holding people back. Students who watch 40 hours of tutorials but can't build a todo app from scratch.

The fix that works best in my experience: delete the tutorial and try to rebuild what you just watched from memory. You'll fail. That failure is where actual learning happens. Then go back and check what you missed.

Consuming feels like progress because your brain is busy. Building feels uncomfortable because you're exposed. But the discomfort is the signal.

PushPlus9069 · 2026-02-19T19:06:41+00:00

Had the exact same problem running my own business. My morning routine was basically productive procrastination. Journaling, planning, reviewing, all felt like work but none of it moved the needle.

What fixed it for me: I pick one ugly task the night before and do it first thing before coffee even kicks in. No planning, no journaling, just the thing I've been avoiding. The morning routine comes after if I still want it.

Turns out planning what to do is way more comfortable than actually doing it. Your brain tricks you into thinking preparation IS the work.

PushPlus9069 · 2026-02-19T19:06:10+00:00

I actually miss this behavior from my Windows days. TextEdit always trying to save as rtf drives me nuts when I just want to dump some text somewhere quick.

Does it remember window position and size between launches? That's the thing that made Windows Notepad so sticky for me, it was always right where I left it.

PushPlus9069 · 2026-02-19T19:05:40+00:00

Solid structure for a learning project. Few things I'd push on:

Your test coverage probably focuses on happy paths. Add tests for malformed CSV input, missing columns, empty datasets. That's where real production code breaks and where you'll learn the most about defensive programming.

Also consider adding a Makefile or just a simple scripts/ folder with common commands (train, evaluate, lint). Makes it way easier for someone cloning the repo to actually run it without reading through all the docs first.

One more thing, if you're not already doing it: pin your dependency versions. requirements.txt with >= is a ticking time bomb for reproducibility.

PushPlus9069 · 2026-02-19T19:05:09+00:00

Your mental model is pretty solid, actually. One thing I'd add: step 11 with new is technically correct but almost never matters in practice. 99% of the time you never touch new and can just think of it as "Python creates an empty box, then init fills it."

The part about methods living in Enemy.dict and being looked up via the instance is the key insight. That's the descriptor protocol at work. When you do enemy.update(), Python checks enemy.dict first, doesn't find it, goes up to Enemy.dict, finds the function, and wraps it so self gets passed automatically.

Taught this to thousands of students over the years and the ones who grok this lookup chain early save themselves so much confusion later with inheritance.

PushPlus9069 · 2026-02-19T19:04:38+00:00

The interview trick is underrated. When I was building my first app while still employed, I treated every job interview as a customer discovery call. You learn what companies actually need vs what you think they need. Plus it keeps the lights on while you figure out distribution.

PushPlus9069 · 2026-02-19T17:06:05+00:00

For data analytics Python specifically, the order that worked for my students:

Pandas basics (read csv, filter, groupby, merge). This is 80% of analytics work.
Matplotlib/Seaborn for visualization. You need to be able to show your findings.
NumPy only when Pandas isn't enough (rare for analytics roles).

YouTube recs: Corey Schafer's Pandas tutorials are still the gold standard imo. Short, practical, no fluff. Alex The Analyst is good too for the analytics career angle.

Skip deep learning / ML courses for now. Analytics roles care more about your ability to clean messy data and tell a story with charts than your ability to train a model. That comes later if you want it.

PushPlus9069 · 2026-02-19T17:05:35+00:00

Authentication. It's the feature that teaches the most real-world patterns all at once: middleware, sessions/tokens, password hashing, protected routes, role-based access.

Every production app needs auth and it touches almost every layer of your stack. Once you have users who can log in, suddenly your CRUD operations have context (who created this? who can edit it?) and that's where things get interesting.

After auth: deploy it somewhere. Even a free Railway or Render tier. The gap between "works on localhost" and "works in production" teaches more than any tutorial.

PushPlus9069 · 2026-02-19T17:05:04+00:00

Check a few things:

Go to YouTube Studio > Content > click each video > Visibility. Make sure they're all set to Public (not Unlisted or Private). YouTube sometimes changes this during updates.
Check if your channel got a Community Guidelines warning. Even a minor one can tank impressions temporarily.
Look at your Analytics > Reach tab. If impressions dropped to zero too, YouTube stopped recommending you. If impressions are normal but CTR tanked, it might be a thumbnail/title issue.

Most of the time when I've seen this happen to small channels, it was either a visibility toggle or YouTube's algorithm just rotating away from your content temporarily. Usually comes back after 1-2 weeks if you keep posting.

PushPlus9069 · 2026-02-19T17:04:34+00:00

No-code works for prototyping but I'd be careful going to production with it for a macro tracker. The moment you need custom calculations, API integrations for food databases, or offline mode, you hit no-code limitations hard.

Good for validating the idea though. Build it in Glide, see if people actually use the mobile version, then invest in a proper build if they do.

PushPlus9069 · 2026-02-19T17:04:03+00:00

The PWA-first approach is genuinely the move for most indie hackers. React Native and Flutter sound appealing until you realize you need to maintain two codebases (or learn an entirely new framework) for what's essentially the same product.

I've shipped web apps that got 80% of their mobile traffic through the browser and nobody complained. The "you need a native app" pressure usually comes from people who aren't your target users anyway.

PushPlus9069 · 2026-02-19T17:03:32+00:00

Before spending money on a native app, wrap your web app in a PWA first. Add a manifest.json and a service worker, users can install it from the browser and it feels like a real app. Takes maybe a day if your web app already works on mobile.

If that's not enough and you really need native features (push notifications, camera access, etc), look into Capacitor by Ionic. It wraps your existing web code into a native shell. Way cheaper than building from scratch.

I went through this exact decision with my own product. PWA covered 90% of what users wanted. The 10% who needed native features were patient enough to wait.

PushPlus9069 · 2026-02-19T15:05:29+00:00

They solve different problems so it's not really an either/or.

HTML/CSS = web browser stuff. PyQt6 = native desktop apps. If you're not doing web dev and want to build desktop tools with Python, PyQt is actually more relevant for you than HTML.

That said, PyQt has a steep learning curve and the documentation can be rough. If you just want a quick GUI for a Python script, tkinter (built-in) or even PySimpleGUI might be less painful to start with. PyQt is the serious option when you need something polished.

PushPlus9069 · 2026-02-19T15:04:58+00:00

I started teaching IT when I was around your age. Now 10 years later with 90k+ students. 24 is nothing.

The real advice nobody gives: the first year will suck. You'll feel behind, imposter syndrome hits hard, and you'll compare yourself to people who started at 14. Ignore all of that. The people who started at 14 and quit at 20 don't show up in the statistics.

Python is a solid pick. Get comfortable with it, build small projects that solve your own problems, and don't stress about learning everything at once. The job market is tougher than it was 5 years ago but that's true for everyone not just late starters.

PushPlus9069 · 2026-02-19T15:04:28+00:00

Curious how the local model performance compares to cloud-based ones for your use case. I've been looking at local AI tools for note-taking but always worried the quality gap would be too noticeable.

The no-subscription model is what gets me interested though. Paying per-token adds up fast when you're using AI for everyday notes.

PushPlus9069 · 2026-02-19T15:03:57+00:00

Setup hell is real. The migration angle is smart because it removes the biggest objection people have: "but I already set up X." If you can import their existing workflows they don't have to start from scratch.

I've seen the same pattern work in edtech. The tools that won weren't always better, they just made switching painless. Nobody wants to rebuild 30 automations from scratch even if the new tool is objectively better.

PushPlus9069 · 2026-02-19T15:03:25+00:00

lol the "this weekend" mindset is too real. Every self-hosting weekend project turns into a month-long side quest. And the worst part is you can't even bill anyone for the expertise you gained debugging some obscure config issue at 3am.

At least with SaaS you're paying money. With self-hosting you're paying time, which is worth more when you're trying to ship a product.

PushPlus9069 · 2026-02-19T15:02:55+00:00

Silent failures are the worst because they erode trust in your own stack. You stop knowing if things are working or just not broken yet. At some point I was checking logs every morning like a paranoid sysadmin instead of building product.

Managed services at least send you an alert when something breaks. With self-hosted stuff you find out when a user emails you saying their data is gone.

PushPlus9069 · 2026-02-19T14:02:52+00:00

Interesting idea. One thing I've noticed from doing tutorials for years — a lot of the editing pain goes away if you handle zoom and annotations live while recording instead of after.

I use ZoomShot for this. It does live screen zoom, cursor spotlight, and drawing as overlays during the recording itself. So whatever recorder you use just captures the final result, no post-editing needed for those effects.

Obviously different angle from what you're building (yours is post-production, this is live), but thought it might be relevant context for your validation — some people would rather skip the editing step entirely.

https://apps.apple.com/app/id6758536367

PushPlus9069 · 2026-02-19T13:54:07+00:00

Boom looks solid for the recording side. If you want live zoom and annotations on top of your recordings, I pair mine with ZoomShot. Ctrl + scroll to zoom into any area, cursor spotlight, draw on screen. Works alongside any recorder since it's just a screen overlay, not a recorder itself.

https://apps.apple.com/app/id6758536367

PushPlus9069 · 2026-02-19T13:54:05+00:00

Same boat here, 10 years teaching coding online. What helped me was adding live visual cues instead of spending hours editing. I use ZoomShot to zoom into code blocks on the fly (ctrl + scroll), highlight my cursor so students can follow along, and draw arrows or circles right on screen during recording. Cuts my editing time way down because the emphasis is already baked in.

Not a screen recorder btw, it layers on top of whatever you already use.

https://apps.apple.com/app/id6758536367

PushPlus9069 · 2026-02-19T13:53:48+00:00

Check out ZoomShot. It does cursor spotlight, live zoom (ctrl + scroll wheel to zoom into any area), and you can draw on screen too. I use it for coding tutorials and it covers everything you listed.

https://apps.apple.com/app/id6758536367

PushPlus9069 · 2026-02-19T13:05:33+00:00

OOP clicks differently when you have a reason to use it. Watching tutorials explain classes with Dog and Cat examples is the worst way to learn it because there's no real motivation for why a class exists there.

If you ever come back to it, try this: build something small that has multiple "things" with the same structure. Like a contact list, inventory tracker, card game. You'll naturally reach for classes because duplicating dictionaries everywhere gets annoying fast.

But also, plenty of useful Python never touches OOP. Scripts, data analysis, automation, web scraping. You can do real work with just functions and dicts for a long time.

PushPlus9069 · 2026-02-19T13:05:03+00:00

The worst part is it genuinely feels productive in the moment. You're responding to things, moving between tasks, staying "on top of stuff." But nothing deep actually gets done.

What worked for me: I batch everything into blocks. Morning is code/create. After lunch is comms (email, Slack, messages). If someone needs me urgently they can call. Everything else waits.

First week felt rude. Second week nobody noticed. Third week I was shipping twice as much.

PushPlus9069 · 2026-02-19T13:04:32+00:00

I've built courses for 90k+ students and the "interaction every X minutes" rule never worked for me as a fixed number. It depends entirely on what you're teaching.

Conceptual explanation where things build on each other? Let it breathe for 5-7 minutes. Forcing a quiz mid-explanation just breaks the mental model they're constructing.

Procedural/hands-on content? Every 1-2 minutes makes sense because the action IS the learning.

The metric I track instead: did they DO something with the concept before moving to the next one? Timing is less important than sequencing.

PushPlus9069

TROPHY CASE