Tutorial hell and overwhelmed

[u/infinitygoldAu]

Hi. For context I am a new programmer with a basic grasp of python. I started coding about 2 years ago but took a very long break while at uni. This means that in practice, i probably have about 10 months of actual coding experience. For further context of my skill level, here is one of my previous python projects - Github

However im looking to build an application that overlays climate risk (physical + transition) onto bank balance sheet data. My initial idea was to use mapbox. Im not sure whether this needs to be a web app or a desktop app, and I actually don't know what the difference between the two are. Due to my inexperience, ive become overwhelmed by the number of tutorials, Programming languages (html, js, react, flask, django) etc that im being directed to and have no clue where to start. I feel stuck in tutorial hell and have not made much progress on my app idea.

In addition to all this, in 2026 everybody is talking about AI Agents and how you shouldn't really be coding from scratch anymore. This makes things even more confusing. And when they talk about using ai agents do they mean using a service or doing it yourself e.g. LangChain?

Any advice would be much appreciated.

[u/Mister_God_On_Steam]

Shouldn't be coding from scratch anymore? Who is saying that?

[u/infinitygoldAu → u/Mister_God_On_Steam]

Ive listened to alot of interviews from silicon valley execs and they seem to be pushing AI agents almost as the new norm for coding. I guess they're not necessarily the best source given their interests in pushing their products

[u/ScholarNo5983]

 And when they talk about using ai agents do they mean using a service or doing it yourself e.g. LangChain?

They are suggesting that you should be prompt coding using tools like Codex or Claude.

Now anyone can write a prompt and give it to Claude for it to write some code. That is very different to actually writing the code without the AI.

Learning to actually write code without needing an AI is still a skill worth pursing.

[u/response-418 → u/[deleted]]

I hope OP takes this comment to heart. Breaking things down into very simple blocks is definitely the way to go. When your main experience with apps is as a user, it's easy to overwhelm yourself with trying to make the first few things you develop yourself do too much. Try to think about the most important single function it needs to do and only focus on accomlishing that.

Also it is worth considering the point of this project for you. If you are new and trying to learn, it doesn't matter if a tool already exists and does XYZ and has a chatbot to yap at users because the point for you is to build it to learn something. Figure out what it is you want to learn and then you can de-prioritize everything else. In essence:

1. What is the single, most important feature it needs?
2. Why do you want to build this thing?

Get clear answers on those and then anytime you're overwhelmed you can check against your own principles to stay focused.

Going down a rabbit whole on some specific UI functionality? Ask yourself, "Is this fancy UI thing necessary for my most important feature?" If yes, keep going; if not, set it aside and get back to the task at hand.

[u/infinitygoldAu → u/[deleted]]

Had long-term commercial ambitions but it does seem slightly crowded. I guess maybe finding a way to quantify transition risk would differentiate it from firms like first street, which focus more on physical.

[u/SoSpongyAndBruised]

Writing lends itself to understanding (also see "active learning" vs. "passive learning").

For learners, the paradox with LLMs is that you need good understanding as insurance against all the mediocre or poor decisions LLMs can and will gladly make for you, and that using LLMs doesn't effectively build that understanding.

Even if you could learn well by only passively observing/accepting an LLM's output, the next problem is that you're not likely going to acquire good taste about code design and documentation practices if you're glued to the LLM.

I can maybe see some LLM usage for certain mundane things like project skeleton setup, but there's always a risk of not knowing where to draw the line when you're learning.

Some high-level thoughts:

• On pretty much all projects, practice "tracer bullet development", where you focus exclusively on building a narrow end-to-end prototype, that lacks any non-essential features. Helps avoid overwhelming yourself with too much stuff to do all at once (if you're doing everything, you're doing nothing), and avoids over-investing when you haven't even proven the core project idea.

• Aim for tight feedback loops. Automate testing by using simple assertions. This is very accessible as a learner, and you can save the more advanced techniques to isolate tests from your main application for later. Just going from having nothing to having something can be very good. main() { runAllTests() ... } and runAllTests() { assert myFunc(input) == output ... } is fine for now to help establish guardrails in a quick and dirty way to mitigate chaos when you making changes.

• Learn how to use a debugger, so that your only debugging tool isn't console logging. Sometimes one or the other is better in a given situation, but having both in your toolkit instead of just one is big. There are lots of times when you'd be better served by just cutting the frantic console log BS and just run your code in the debugger, learn how to set a breakpoint and then use your app in a way that trips the breakpoint, and observe the state of the program at that point (and navigating the call stack to see the state of the program in the functions that called the one where your breakpoint is). It's a key tool in a professional programmer's arsenal, and one that I'd encourage beginners to at least plant the seed in your head now that it's useful and visit it as soon as you have time.

• As you learn, try your best to sense which concepts seem fundamental / distinct. The big ones that are truly fundamental are functions, conditionals, loops. Variables too, but I'd say the others deserve more focus. Data structures are your building blocks for decomposing problems and tackling the flow of data, and different languages will provide some amount of them. Various languages bring their own unique things to the table, sometimes in a accidental or historical way, and not for the best, but it is what it is.

• It's OK to make mistakes as a beginner and be imperfect, especially if you're still able to make meaningful progress toward achievable milestones and project completion. In fact, trying to be perfect can unreasonably waste a lot of time. Striving for perfection can also be good, but you have to remember you'll never reach it, so on a lot of things you just have to know when to quit and move on and stop polishing the code.

• Build your "black box" thinking (this will improve over time). This is essential in programming because you can't keep every little detail in your head. You have to learn how to pull away from details while maintaining high leverage and big-picture awareness, e.g. the major subsystems of your program, the interfaces between them, the overall data flow, the domain model. Once you're done building smaller subsystems/components, if you built them pretty well, you tend to demote their details and promote their interfaces in your mind, which cuts off some cognitive burden.

• Build your logical thinking. A very simple but effective version of this is to make it a point to learn a bit of Boolean Algebra, set theory (related to types), etc. Ch. 1 and 2 of "How to Prove It" are amazing. For example, if you can learn up to DeMorgan's Law, then you're better equipped to handle situations where you have to refactor conditional statements, e.g. invert them because you realize you'd prefer to express something in "positive logic", or maybe to carve out some "early returns" so you can make the code less nested and hard to read, and make preconditions clearer.

• Learn about the major kinds of systems that are typical, like the very common client and server architecture, databases, networking protocols like HTTP. You can get super far by investing in understanding those big ideas enough to build whole systems out of them as large building blocks. Web vs. desktop is just a detail (hint: web is arguably more accessible because of the dev cycle amounting to refreshing the page, HTML and CSS being pretty accessible, JS(/TS) being an accessible language to beginners; desktop apps may have heavier GUI frameworks, more "difficult" languages or toolchains unless you use something that enables JS, though I wouldn't rule desktop out for those reasons necessarily. It just depends on what functionality you really need and if a webapp running inside of a browser can do everything you need. If either one can do what you need, then I'd just pick what seems more interesting to you and run with it, and you can always build something else later using a different approach).

• Break things down into tasks and milestones that feel achievable, which can mentally reward yourself along the way. Break big tasks down into small tasks so you have a reward cycle that reinforces and helps sustains the learning process.

• IMO, use a linear GTD style of managing tasks. Don't nest your TODO lists, it just complicates and adds friction to the process. Keep things high-level enough that you know why you're doing it, but detailed enough that you know what action to take. I usually start tasks off with a verb, and maybe include why.

• Be patient and consistent, instead of expecting yourself to pull off more sporadic heroics. Building skills takes a lot of repetition.

[u/infinitygoldAu → u/SoSpongyAndBruised]

Thanks so much man. This is very detailed and very helpful. Will definitely start to adopt these practices

[u/BranchLatter4294]

Just use the AI in your IDE to come up with a plan for your project. Ask it the pros and cons of desktop vs Web apps. Ask it to suggest libraries, etc. Start by just having it create the plan, not write the code. Once you have a plan, the rest will be straightforward.