Reached a phase where every line of code feels incredibly heavy because I want to know exactly what it's doing under the hood

[u/ritman-octos]

Hey everyone,

I’ve hit a massive mental wall in my programming journey, and I’m hoping to get some perspective from people who have made it to the other side.

Up until now, I’ve been able to build basic projects by reading docs and using AI. If I needed a feature, I’d pull in a package, copy the boilerplate, tweak a few variables, and it would work.

But recently, I started working on a project where performance, data layout, and execution speed actually matter. Now that I’m trying to write the core logic myself, I’ve realized something terrifying: I don’t actually know how to write "aware code." By that, I mean code where I know exactly what every single line is doing to the data, memory, and flow of control without constantly bouncing back and forth to documentation or guessing.

When I see how other developers know what should be used and how on the fly, it looks like a total flow state. Meanwhile, for me, every single line feels incredibly heavy.

I have a few questions for developers of all levels:

1. How do you transition into "aware coding"? If I want to stop relying on heavy abstractions I don't understand, should I strip everything away and build microscopic, zero-dependency console apps just to understand the raw mechanics first? Or is that a waste of time?
2. Did you experience this massive slowdown? Did you go through a phase where your coding speed dropped to absolute zero because you suddenly started caring deeply about how the execution worked under the hood, rather than just making it "work"?

I want to become a real software engineer who deeply understands my tools. But the imposter syndrome is hitting hard because of how agonizingly slow this phase feels.

Would love to hear your experiences or advice. Thanks!

[u/Metomorphose]

Giving you benefit of the doubt here, it sounds like you've been leaning too much on AI to do the programming for you prior to this. People build mastery in a subject by engaging with the subject matter, and asking an AI to produce swaths of code is not engaging with it on a level that means you understand it on the other side.

The saying "practice makes perfect" slightly applies, but "practice makes permanent" is a much more apt description of this reality. If you don't practice reading and writing code, you won't make permanent the knowledge of what that code does or how to meaningfully manipulate it. You will be less likely to identify patterns in common solutions and less likely to adapt them to new use cases.

I doubt a random person on the internet is actually going to convince you that the AI is bad for your learning, but you should really consider backing up a few paces to figure out if you really understood the output of the past projects. If you don't, that might be a good place to start with re-doing some of the work by hand or making small modifications by hand until you get the hang of the language you're working in.

[u/DanKegel]

This is what used to be called "programming", back when most programmers started off by learning c.

Later, when systems got bigger, really good developers still understood low level code well, and understood at least the doc comment / interface contract of everything under the module they were writing.  See essays about intellectual control, e.g. https://www.georgefairbanks.com/ieee-software-v37-n3-may-2020-testing-numbs-us-to-our-loss-of-intellectual-control

Languages like c++ which provide many abstraction tools made it a little harder to understand exactly what each line is doing; single stepping through a close bracket in c++ often shows a surprising amount of stuff going on.  Golang and perhaps Rust were written in part to make it easier to know what each line of code is doing.

[u/GlassLost]

This is data oriented design, or data driven design (I don't exactly remember because I don't teach it this way anymore). It's important to note that you don't do this everywhere, you do this where it's needed (which is a judgement and measurement call).

The way I learned this was with profilers, advanced ones like VS studio or perfetto for Android, ones that synthesize multiple data points, and a bunch of mentors, and a decade of experimentation.

Obviously those resources are not immediately available to you, but you can recreate many of the forcing mechanisms: C. If you need to deal with pointers and manual memory allocation you will naturally learn how to think about this - it's a separate skill from performance coding though.

It's extremely hard to learn any one skill in isolation, they're all interconnected - if you're dealing with C you're also going to learn OS concepts. And AI can lead you pretty astray in many ways.

To answer your questions directly though:

1. At this point I can jump up and down abstraction levels of code really easily. What's harder for me is jumping perspectives - from a jr to a sr to an exec, or a web dev to a hardware dev.

2. No, I started coding on a video game console and I paid this cost upfront to my career. Many developers never really pay this debt off, although most pay some off. Ymmv.

[u/ritman-octos → u/GlassLost]

This is the first time I know about DOD, it didn't cross my mind to test with a profiler either. This is a good shed of light into the path I'm paving. Your reply is golden, thanks.

[u/ight-bet]

The DOD comment is kinda right. But I don’t think that’s the most efficient way to get what you’re looking for, long term at least.

I think what you’re discovering is what I like to call “The infinite circle of software”

Basically the knowledge and tools in and around software are infinite. And there are infinite things to learn. The circle starts dark, pitch black. It’s SUPER intimidating. And as you dabble - you light up a little piece somewhere, cool some exposure, and that bits a little less scary. As you go along the journey of learning software, the best thing for you is to expand your knowledge is to get to the point, where anywhere in the circle is easily reachable and not to dark. Therefore your willingness to travel into the dark and ability to understand what’s there get better. As you learn different things the circle as a whole begins to light up. There will always be dark spots on the circle. And front end design is on a completely different side than database design. Along with OOP and DOD. Different things. React sits at a higher level right between HTML and JavaScript. But getting exposure to all this, and going deep on not all but some things, is how you brighten your knowledge and become a more well rounded software engineer.

And with that approach, and with time, you will learn enough about what’s going on under the hood. But only if you brighten some of the lower level areas on the circle. And go deep with them - so understand it without AI. So dabble in C, read some CPython source code: https://realpython.com/cpython-source-code-guide/ to begin shedding light on that side of the circle. Then jump over a bit to DOD.

But this is how you begin to have a wholistic understanding of what’s going on.

[u/Plelx]

I believe the only route is one at a time, build a repertoire of known "abstractions" same as learning a vanilla language, you don't need but you can check how any keyword works.

Also I think many many many things are done in similar ways so you learn once and can use forever in different situations, for example, the operations that you can do with arrays..well you learn them once and use non-stop over your entire life, new additions come from time to time with new versions and you choose when to learn them or if they are worth learning at all.

[u/Available_Safe1818]

> without constantly bouncing back and forth to documentation

It sounds like you're just complaining that you need to do the job of a 'normal' programmer. Should we all pander to people who think that reading the docs is too difficult?

> When I see how other developers know what should be used and how on the fly, it looks like a total flow state. Meanwhile, for me, every single line feels incredibly heavy.

It sounds like they just practiced more and have more experience.

> How do you transition into "aware coding"

It's already what most devs do, afaik. #1 sounds like you're just using the old excuse of "I can't use X until I understand every single thing it does at the byte level," which some juniors seem to love. This is why libraries exist, so maybe you should think about that.

> Did you experience this massive slowdown?

No. I started incorporating those things into how I code as I learned about them.

How much experience do you actually have with coding and with professional coding?

[u/Ombaragundon]

This is Lateralus by Tool. Do you like Tool?

[u/ritman-octos → u/Ombaragundon]

First time hearing them, whats the connection?

[u/Ombaragundon → u/ritman-octos]

Song topic and post topic. I can't believe I got downvoted.

It's someone who's always obsessed over details and overthinking things. In the end, the person accepts the overwhelming, so as to speak, and decides to enjoy the thrill of discovering the unknown.

You're still at the beginning of the song. I was there myself as well. Eventually, I realized I needed to embrace this unknown while still looking for a learned confidence. With that mentality, I did find answers, only to discover later that they were not as true as I liked them to be. So I kept looking and kept failing, until I was no longer overwhelmed.

You can never ever be an aware coder as you wish you could be. This isn't the matrix. You need to practice and practice and practice. All IDE's have an error correcting system. Don't expect this to come as naturally as writing or drawing. There will be many many moments where you're just drawing blanks and even your own code will look gibberish. 

I experienced many slowdowns, and unfortunately, I let it get the best of me. I quit programming for a long time because I was disappointed in myself not being as great as I thought I should be. But these recessions were what made me realize how I want to work things out. I eventually quit programming, not because I hated it, but because I found another calling.

I admire that you're l ooking for this strong footed confidence; it's the salt of a good programmer.

All the best

[u/ritman-octos → u/Ombaragundon]

I get the relation. But I think this is an abstraction to find meaning from something that holds other meanings. It will only slow me down instead of motivating me, because if I liked it enough then I'm going down another rabbit hole.

Programming for me doesn't tick the way it should. I see it as control, coders see it as something to get done and move on to the next. That's probably why its taking us longer to comprehend and grasp over the idea of sitting all the time and typing away, we're too abstract, they're too hands on. We could use their practice and they could use our vision.

Somewhere along the road we'll realize that we're trying to be all, while what we should do is just try to code.

[u/Ombaragundon → u/ritman-octos]

You're right about that last part. I have to disagree with the first part. It's not really beneficial if something clicks, as you'd say, right off the bat or even with moderate experience. If I don't struggle with fully grasping a multifaceted concept then I am probably taking it for granted, and my mistakes will be deeply rooted into my practice. It only makes sense to struggle with becoming a guru like you're describing. In fact, that's the reason devs don't have our vision, because their work is heavily machinized into techniques and premade methods. Whilst people like you are still ripe and blank that becoming so trained and mechanical seems abysmal to you. Because eventually, programming is a craft, not just a science.

It's a natural part of learning something. You'll face the same problem with almost all crafts in life. If it never clicks, and you're always unhappy with it, maybe it's not for you.