Software Developer

What they're figuring out

• For those who learned Python while working full time: how did you balance depth vs. speed? I’m torn between moving on once something “sort of” clicks vs. drilling exercises until it feels automatic. Any rule of thumb for when it’s ok to leave a topic and trust that practice in projects will reinforce it?
• For people who chose full‑stack JS/TS during uni: what convinced you it was the right bet versus, say, data engineering or mobile? Was it mostly interest, job demand, or how well it fit around your classes and part‑time work?
• For folks who started as designers: how do you keep PR feedback from feeling like critique of your “style” instead of the logic? Any mental tricks to stay unemotional and just iterate on the code?
• For those contributing to existing Python/data engineering codebases: how do you balance "following the existing style" vs gently improving it? I keep spotting small smells (naming, duplication), but I’m unsure when it’s appropriate to refactor in a PR vs just match what’s already there.
• For folks who already picked a stack: how did you know when to stop researching and just commit? Was there a specific signal, like number of job posts, or did you just draw a line and say “this is it for the next year”?

Answers from the road

• I had to give each project a “contract” up front: problem, core features, tech stack, and 1–2 stretch goals. Once those were done and the app was stable, I forced myself to stop. If I discovered a new pattern, I’d jot “v2 ideas” in a doc instead of rewriting. Then I’d apply that pattern in the next project. That way each app shows a different slice of growth instead of one endless refactor.
• I had the exact same tension. What helped: I only pause when (1) a line introduces a concept I *haven’t* seen before, and (2) that concept feels central to backend work (e.g. routing, DB queries, auth). Then I spend 10–20 minutes max reading docs or printing values. If I’m just wiring boilerplate or tweaking CSS, I let myself “copy blindly” and keep moving so I actually finish and see the full flow once.
• I had the same loop with loops and functions. What helped was defining “good enough” upfront: if I could explain the idea in my own words, write 3–5 small examples from scratch, and debug a broken one, I moved on. I accepted I’d forget things and revisit them while building tiny projects. Basics clicked more from using them in different contexts than from rereading the same chapter.
• I’m targeting junior full‑stack JS too, and my “ready” list is: - 3–4 projects (2 CRUD apps, 1 with real users/auth, 1 a bit bigger) - Comfortable with: JS/TS, React, Node/Express, Postgres or Mongo, Git - Auth (sessions/JWT), basic security (hashing, validation) - REST API + real DB (migrations/seed data) - Tests: a few unit + at least one integration - Deployed app + CI basics - Can explain tradeoffs and debug calmly.
• I had the same problem. What helped was setting a timer and a checklist. First 15–20 minutes: try brute force and write it, even if it’s ugly. Next 20: try to improve it or handle edge cases. If after ~45 minutes I still have no clear path, I skim the solution but only until I see the key idea, then close it and re-implement from memory. I also write down what blocked me so I can spot patterns later.

What they learned here

• Following a tutorial line by line feels productive, but it didn’t click until I forced myself to pause and predict the next step. Now, before I copy any code, I ask: “If I were building this from scratch, what would I write here?” That tiny mental simulation exposes what I don’t understand and turns a passive video into an actual backend lesson.
• I used to follow tutorial steps like a recipe and felt proud when it “worked”. Then I tried rebuilding the same project from scratch, without looking. Humbling. Now I pause every few videos, rewrite a piece on my own, and add one tiny feature that wasn’t in the course. It’s slower, but I finally feel the gears turning in my own head.
• I used to think reading other people’s code meant understanding every line. Now I scan a repo like a map: where are the routes, models, services, config, tests? I trace one request from the controller down to the database and back. That path alone teaches me more about architecture than obsessing over every helper function.
• I kept trying to invent something “portfolio worthy” and stalled for weeks. What finally helped was lowering the bar: pick a tiny but real annoyance from my own work, then design the smallest version that a stranger could actually use. Once I treated it like a tool for a specific user, decisions about features, tech stack, and scope became much clearer.
• I realized I was treating tutorials like recipes: follow exactly, then forget. Now, after each guided project, I force myself to break it a little on purpose—rename things, move files, add a tiny feature. It’s slower and messier, but suddenly I’m not just watching code, I’m negotiating with it.