This is an awful SDL engine example. I've made rendering engines before. You should for example have a second windowless openGL context with its own thread so that you can be sending drawing commands at the same time you are updating GPU ram buffers. Generally the main thread is required to be handling input (due to cross platform requirements) and should only be doing that. Everything else including file loading should be running in async threads. It would require you to be a competent programmer though.
That crosses into personal attack, which we ban people for, and name-calling, which the site guidelines ask you not to do.
Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the spirit of this site more to heart? If you know more than others, the thing to do here is not to put others down, but to offer some of what you know, so we all can learn. Or you can ask about why they did X rather than Y. Perhaps they also know quite a bit, and chose X for an interesting reason.
"It would require you to be a competent programmer though." is not blunt criticism. It is simply unkind and unnecessary. You can be blunt without being nasty.
While I do sometimes think reactions on HN could use a little "lighten up already", I agree with 'dang' here. You definitely crossed the line in this case.
Although multi-threaded engines are now standard, this model adds complexity and is overkill for most games beginners will make (and many commercial indie titles). There is also no reason not to start with a single threaded renderer and move to multi-threading in a later article. Right now it isn't even past creating a window...
Honestly, if you're going to be so critical you should suggest the tutorial should use Vulkan instead of OpenGL, but wait neither of those support all gaming platforms so you have to write a low level API wrapper for Metal and DirectX12 as well, then write a shader translator... Etc. The gap is large between a toy engine and a commercial engine, but there are a lot of fun games you can make with a toy.
When I was younger my programs would start to fall apart after a few thousand lines. It took a LOT of practice, both writing programs from scratch and working on large programs that were correctly designed.
One thing to remember is the act of coding is a bit different from architecting a program. If you are unsure of how it is going to work it is probably not going to work and as your program grows in size will become unmanageable as you continually have to rewrite it to take things into account that you didn't plan on. It helps to become familiar with design patterns and to pseudocode the overall structure. Expressing your desired architecture into code is a big enough challenge without trying to do it at the same time.
There are better SDL tutorials from the 90's.