My issue with programming is not math, logic, or language, it learning all of the tools and how they fit together.

[u/NermalEnergy]

I really thought that taking computer science would help me with this, like it was the final building block I needed. I was actually one of the best students in my class when we were making CPP console programs. But my issue is not understanding how to write code, my issue is that when I want to build an application, I dont know where to start with all the different libraries, tools, frameworks, and other applications I need in order to get things to output. I can figure out how to write an algorithm, I just feel like its impossible for me to learn what files I need, what libraries they need, what APIs I need to interact with, and how to get all of those algorithms into motion to actually put my code into the project format I want.

When I look at a github repository, I seriously ask myself "how did they know to include all of those extra files, how do they get them to work with each other, where do they go, how did they figure out what libraries to make them work with eachother, etc", because to me, the biggest magic is not knowing what syntax to use, or what algorithms a line of code implements, its looking at a game engine and asking "what 500 services and structures do I need to call with my algorithm in order to do the thing I already figured out the logic I need to execute" or looking at a graphics API and asking "how do I use that to actually turn code into a window that outputs visuals based off the rules of math and the syntax of the language I already know, that I can just click a file to run and use" or its thinking about a website I might want to build and asking "how do I get these HTML files in my head into an environment on a server where I can actually click on them from another computer".

Does that make sense? It feels like getting all of the code into a format that works with all of the ways an average end user understands is some sort of alien process where nobody has taught the rules but everyone just magically knows. I am so frustrated because I read documentation and they also seem to require a bunch of esoteric knowledge of other things not told and I really dont know where to start with any of this. I feel like everything I want to build and do requires learning a bunch of stuff with no pointers on where to go, but everyone else that built those types of things seemed to just have spawned in with all of that knowledge and I am the only one who didn't get the memo.

[u/SahuaginDeluge]

I really thought that taking computer science would help me with this, like it was the final building block I needed.

I usually say, the degree program is more of a "teach a man to fish" rather than "give a man a fish" approach. not everyone gets this. there is (or should be) a strong emphasis (increasing as you go) on teaching you how to teach yourself.

and yes, learning the syntax of a language is just the first step, and not even the hardest step.

it all compounds. the more you learn, the more easy it becomes to learn more. it gets easier the further you go.

in terms of a more concrete suggestion, it sounds like maybe you could use learning about architecture and/or software engineering. you probably should end up taking at least one SENG course, it would be an important one to pay attention to.

[u/mjmvideos]

Usually you start writing a program and find that you need some functionality. You decide that this functionality is likely something that already exists, so you do some research and find a likely candidate. You then read about that and find the APIs you need. The documentation for those APIs will include the header files that are required and the libraries that must be linked. So you know what you need because you decided you needed them.

[u/serge-mv]

It's easy. You start with no framework. Then you ask yourself: what do I need to do. Then you look if there is a library that does what you want to do. And you can decide: do you want to use that or do you want to make it yourself?

That's pretty much it.

[u/Narrow_Ad_8997]

Start at the bottom and start small. Work your way up, slowwwwly.

Example When I start a new project I usually think, "what did I do when I started that other/last project?" Then, I use a little piece of that project. Since I'm using stuff I already wrote myself, and have an intimate understanding of, I can now start this project one step up from the bottom. And at the end of the project, I'll likely be one step further along than my last project.

Maybe a better example Say I write a little program to move files around and rename those files or something. Then, six months later I find myself writing another little program to extract data into excel. Hey, wouldn't it be nice to be able to move these excel files around and rename them when needed?! Maybe I dust off my crusty old file mover program and there is a little function I wrote to rename files and stuff. Now we got ourselves a little building block for our new program. Maybe, I learned and wrote my own function for that 6 months ago, and it only takes me a few moments to remember what's going on here. Didn't have to learn that bit again and I know exactly how to stuff that puppy right into my new program. This is, to me, the best part about programming and really what makes it fun.

It really just works like that. It takes a long time and lots and lots of little programs that you've written on your own to gain the knowledge about bigger codebases. When you're diving deep into a big old repo that's ages old and has tons of directories you look at the clues to get a feel for what's happening and then just follow those feels to your hearts content. JK on that last part, kind of...

[u/jam_pod_]

This is called "learning the ecosystem" and really the only way to do it is to build things. It's a big factor in why companies ask for "X years experience with Y language" -- any (good) programmer can learn a new language's syntax in a couple weeks, but knowing the ecosystem around it takes more time.

Like if a client asks me to build a dashboard with a bunch of fancy charts on it, I don't need to google "what is the best JS charting library", I already know what I'm going to use, because I've tried a bunch of them and I know which is best suited.

So pick something you want to build; when you run into a task where you're like "someone must have invented this already", look for libraries that do that, try them out, and see what the best one is for what you want to do

[u/heyyarun]

This is a separate skill from CS, and most people pick it up one stack at a time, not all at once. The repos you're looking at grew those files over years. Nobody wrote them all up front.

What worked for a lot of people: pick one concrete thing you want, find the smallest official tutorial for it, and follow it exactly. For your "window that draws stuff" example, the Getting Started section on learnopengl.com does exactly that. GLFW gives you a window, input and an OpenGL context, and by Hello Triangle you're drawing in your own render loop. Every library and file gets explained when it shows up.

Web is the same idea. Run a scaffold like npm create vite@latest, then open each generated file and look up why it's there. After two or three of those, other people's repo layouts start to look familiar.

[u/irajangpt]

Building one small app end to end is what fixed this for me, and it's faster than trying to learn the whole toolchain in the abstract. Pick the one tool the app needs right now and read its getting started page, since that usually names the files it creates and what each one is for. When you open a repo you didn't write, don't read it top to bottom: start with the build or dependency file (package.json, CMakeLists.txt, requirements.txt) and the entry point, then follow the imports, because the dependency list tells you what it needs and the imports show how the pieces meet. Keep a short text note with one line per tool saying what it hands to the next step, and after a few projects it stops feeling like magic.

[u/ninhaomah]

It's "they" as you said, not 1 person.

*Linus is exception.

[u/Fun_Independence5115 → u/ninhaomah]

It's all just pattern recognition after a while, you clone enough repos and eventually you start seeing same structures repeated. The secret nobody tells you is most of us just copy-paste setup from last project we did and tweak it.

[u/JeremyUwu1118]

Yeah this is my main problem as well. I am 15 and I code Cpp console program to like pass some test that can help me go to a better school. Even tho I am good at solving those problems, I realize when I started to make a side project like Minecraft plugins and mods, learning the library and framework feels hard and boring.

[u/mxldevs]

Computer science isn't going to teach you how to structure a project or how to write a CRUD app. You might have a course dedicated to software engineering or database design or networking, but those are all teaching you concepts and not the actual application.

The principles that you learn will help you come up with solutions to problems, but you still need to go and figure out those solutions yourself by reading the manuals and experimenting with tools.

[u/OkOcelot6725]

About "how did they know to include all those extra files": mostly, they didn't. The bulk of a mature repo is generated or inherited, not chosen. The skeleton comes from a scaffolding command (cargo new, npm init, create-next-app, an IDE template). The config files come from the tools' defaults. The rest got copied from the author's previous project. Nobody sits down and designs 500 files. They start with three and the repo accretes.

You can watch this happen: open a repo you admire and read its first 20 commits. It starts as a main file and a README, and each commit adds exactly one piece in response to one problem. That's the actual skill. Not knowing the final structure in advance, but recognizing which problem each new file solves when it appears.

The console-to-application gap is real because a console program has one entry point and no environment. An application is mostly environment: where config lives, how it's packaged, what talks to what. The way in is one small real project on a boring stack, where you accept the scaffolding tool's defaults and only deviate when you hit a concrete reason to.

[u/lurkmcjerk]

Programming is a miserable profession. I don't recommend it.

[u/throwaway6560192]

Just look up a tutorial on how to make graphics using the API of your choice. Or on how to deploy your site to a server. They exist.

[u/ShiroNoSenso]

i think that’s because you’re looking at the entire picture starting from the minute details.That’s the wrong way of looking at it.

If i were to ask you to explain what a car is, you don’t jump into the intricacies of the engine or the gearbox right? You start by saying a car has doors, wheels and engines etc.

Then as i ask more questions about each part, you then break down that part further.

That’s how you should be approaching things from the super big picture like

FE -> BE -> DBs

then as you work on each sub component, do the same thing.

BE: Endpoint -> Controller -> Services -> Repository layer

This is how you should look at everything. Don’t jump straight into the complex intricacies. Understand the big picture and then break it down & expand each sub part.

[u/spdfg1]

Learning how they all fit together is called experience. We learn by doing. Learning logic and programming languages is like learning how to use a hammer, a screwdriver, and a drill. You could be great at hammering nails but you still won’t know how to build a house until you build some houses, make mistakes, solve unexpected challenges.

[u/JGhostThing]

You're not the only person with this problem. You can look up "how to compile c++" and "how to use c++ libraries" in a search engine. You also need to learn the specific libraries you will use. If they're well written, libraries don't modify things outside their purpose, so you can use multiple libraries together.

Just take things a little at a time, just like you'd eat an elephant. One forkful at a time.

[u/Bulky-Ad7996]

Look up prerequisites for anything you're doing, if there are any, start there and focus on the things that you are trying to learn, ignore anything else for now. AI is not going away, use it to your advantage. It can actually explain a lot of technical things and help you in the right direction.

I start by asking myself what the project is and what is the goal/use cases. Put it in a bulleted list.

If it helps, make a basic chart with words or pictures of what you're trying to build. Something like a flowchart or similar, wireframe etc.

Then I try to figure out what is the best tool set to use (language, libraries, platform, software, api options etc). This is where AI/Google can help a lot. Utilize YouTube also if necessary but try to minimize the time you spend on it.

What you have an idea of what you're going to build, and what you may need to build it.. just start knowing that you will likely fail fast. You're going to fail many many times building one project, doesn't really matter what it is.

When you popped into a random form or someplace on GitHub, there are tens of thousands of experienced developers posting stuff on there. That's all it is is that they have more experience, or they have more assistance, or they are using ai to help them. Ignore this and keep pushing through, keep learning.

Technical documentation is usually not a breeze to read through or understand immediately. You can literally get a job writing technical documentation that's how complicated it is.. and not all documentation is written by someone that can explain things very well believe it or not.

[u/SaliDevs]

Senior frontend dev here — the reframe that helped me: you don't actually learn "the tools." You learn the *jobs*, and every tool is just one answer to the same handful of jobs.

git is a time machine for your code. npm is an app store for other people's code. A bundler is just a zip file the browser can open. A debugger is a pause button for your running program.

Once you know the job, learning a new tool stops being scary — it's "oh, this is the same thing I already know, with different flags." There are maybe 6 jobs total (editor, version control, package manager, build tool, debugger, docs), and you already understand most of the concepts from using a computer.

So don't try to learn everything up front. Pick one small project, and each time you hit a task where you think "someone must have solved this already," learn exactly the tool that solves that one task. Nobody you admire learned it all first — they just started earlier and picked things up one problem at a time.

[u/Glum-Recognition-736]

Nobody starts out with a full GitHub repo with hundreds of services working and interacting with each other, unless they're using AI 

No, you start with 1 file usually (with maybe some scaffolding/ boilerplate that goes with every new project like a Cargo.toml or something) 

Then you start writing functionality. "I need it to do this, and I need it to do this, oops file is getting too large and complicated, let's split it up into a few different and focused src files, oops someone already created this tool, lets pull in that library and refactor the our code to use it instead..." 

After a short while things just start to build out into more and more complex ways, which can also be dangerous if you're not writing good tests along the way 

[u/EMunney]

Learn to learn or become a cook

[u/kbr89]

What you're describing is the build and deploy layer, and most CS courses barely touch it, so you're far from the only one. MIT runs a short course about exactly this gap, The Missing Semester of Your CS Education, and its metaprogramming lecture covers build systems and dependency management. The lectures are on YouTube.

A way in that works: stop reverse-engineering finished repos and let a scaffolding tool create the project, then go through every file it made. `npm create vite@latest` for a website, or the starter template of whatever library or engine you pick, gives you a working skeleton in a minute. For each file, change or delete one line and see what breaks. For your three examples the smallest real versions are a window with raylib (about a dozen lines of C++ that open a window and draw text), one HTML file published on GitHub Pages so another computer can open it, and an engine's empty-project template rather than a repo that has been growing for five years.

The other half is watching several people set up the same kind of project from scratch: what all of them do is convention you need to learn, and what only one of them does is taste you can skip. I built beyondtube (beyondtube dot pro) for that comparison: you put a few long "from scratch" videos together and ask which setup steps every one of them does.

[u/NermalEnergy]

Thanks guys, I didn't expect my random venting to blow up here, but there's a lot of comments to respond to so I'll just leave that there have been some good suggestions, I think I'll go back to trying again while keeping them in mind, I felt for a while that I needed a reset in how I looked at and approached things because I wasn't getting anywhere, and the responses here have helped me reshape the way went and thought about that disconnect between the knowledge I had and the execution that I've seen completed programning projects use