well joej how did you get good at programming?

pbivens67 said:
well joej how did you get good at programming?

There are better programmers, but i think i've learned it easily because i've started early, maybe at the age of 10 using C64 and it's BASIC language.
I remember i've had only one problem. The C64 manual showed how to animate a sprite, and they did it with a loop. The loop was moving it one pixel each step in one direction.
So i thought i have to use loops to animate any sprite, but it was difficult to implement player movement this way.
It took me a long time to figure out i can just change position variables with if else sections of code responding to joystick inputs.
But after this enlightenment i never had any coding problem again, up to the current day. Thus i did need not read further programming books. It all felt second nature to me and i could do what i wanted. The only problem was performance.

Later in teen age i've switched to PC and i've learned the C language, using Kernigham Ritchies C Language book. It was the perfect language and super fast. I loved it. Finally i could do 3D graphics with software rendering.
I also adopted some C++ concepts, but slowly over years. I still lack behind regarding features introduced with C++11 and later. I also use and know very little about STL. Using std::vector often, but for maps, sets, queues etc., i have to google each time to figure out how to use those things.
E.g. after reading your post i've realized i could have used sets for code i've just written days before. But i did not think of STL, so i have implemented the stuff myself with more work, code and eventually slower.
That's a typical limitation coming from my bad education. I constantly reinvent wheels. However, that's not really a problem regarding programming. But it is a problem when it comes to math. I can't read math notation, so literature is inaccessible to me and i have to reinvent everything myself. Learning math is hard and takes years of time, while learning about programming is not really needed anymore since decades.

Beyond basic programming itself, there are also higher level concepts and goals. Writing reusable and modular code, keeping big projects maintable, etc. Senior programmer stuff, maybe.
I have learned about those things mainly from my own mistakes, and from paying attention to what experienced people say. Not really from reading books, but more from forums like this.
By listening to many others, my subconscious mind filters out some kind of averaged general truth, and this way i can learn from experience and mistakes of others without effort, i guess.
Today my code surely looks amateurish in many ways, but i manage. Programming feels like second nature and never is the problem.
The problem always is to understand all aspects the actual problem, and to figure out potential solutions. Coding itself is rarely hard.

It's maybe interesting to discuss how we do this problem solving in our mind. How we imagine it, and how we imagine potential solutions so we can figure them out.
I think i do this mostly using natural language to describe things i imagine visually. Later i translate my imaginary natural language to computer language.
I found it interesting that such programmer work makes me truly understand the difference between knowledge and assumptions.
E.g., i can read Newtons laws of physics, and it's simple math everybody assumes to understand.
But then, when we try to simulate using code, we realize that we know almost nothing. Only after we can code a simulation which works, we have proof for our assumptions to be valid knowledge.
That's a skill and realization normal people totally lack. They think they know stuff, but remain unaware about all the uncertainty and wrong assumptions they just take for granted without proof.
So in that sense, programming is the way to verify knowledge to me. It turns vague assumptions expressed in imaginary language into knowledge expressed in strict programming language.

But i'm not sure if this method to translate imaginary natural language to computer code can work for you as it does for me.
Maybe your handicap regarding communication also gives you a similar handicap regarding programming. So eventually you need / use a different way to turn imagination into code.
Many people draw block diagrams on paper to plan their code ahead for example. I never did this, so for me it would not work, but it works for them.

Anyway, i feel you need some kind of Eureka-moments, similar to what i had as a kid when turning the C64 sprite loop into if elses.
And expect those moments from using data structures and from using functions instead duplicated, similar code sections.
And i think you switch topics too much. You work on this game, then that game, then working through a book, etc. That's quite noisy imo.
I would rather focus on a very small project but stick at it until it works, like those Breakout / Space Invaders Atari games.
It seems you work on that, but then at some point you feel it's to difficult, and maybe you need learn more about general programming first to succeed on the game later.
But this creates some forth ad back cycle, lacking focus and a clear goal.

I remember this moment maybe a year ago, when i showed you some Space Invaders game and the collision detection of the missile against multiple enemies.
And you have concluded that's too hard for some reason, and you could not implement the same or change my code so it works for you. So you stopped at this point, moving on to something else, planning to come back later.
But that's wrong imo. It's wrong because the problem was neither hard nor complex just because there are more than one enemies. It requires some larger amount of code than usually, maybe - but this does not make it harder. You have to insist, remain focused, and keep working on it until you got it.
That's the only way to get good at programming, i think.

wow you are really smart!

Do not return an STL container. Pass it into the function by reference:

void func(set<size_t> &s)
{
	….
}

I figured out my problem, thanks for all the help.