Originally Posted by JVene
I thought I'd go off on a tangent, like I'm known to do, on this topic.
This is about when my wife will leave the room to do something, anything, else :)
Back in the late 70's, Radio Shack released their TRS-80 Model 1, which featured interpreted BASIC as the primary programming language. Included in the box was a tutorial on programming in BASIC. It was probably the most entertaining, well written primer on the elementary (to a flaw) introduction on making this machine do the simplest things.
It was fantastic and fun to run through. Within a few pages the author included an instruction to look up, shout out to the family (and I think check the time, too), because they might not hear much from you for a few hours, or days. It was fascinating, especially in an age when barely 1% of the population of the world had ever experienced such a thing.
One of the popular games on that (and several other BASIC oriented machines) was the 'Trek' board like shoot 'n kill Klingon game. It used a 2D array to store the board area, took in some commands to move, fire, displayed remaining shield energy, simple stuff like that. At 2 AM, with Holsts Planets or Tomita's Firebird (played on 12" vinyl records) in the background, it was gaming at nearly it's best for home PC's. And....you had the source code!
It looked miles beyond anything I could fathom, at first. It didn't resemble the 'tutorial's' contents at all. Thick, complicated, and poorly (if at all) commented. It was a mind bending experience just to read through it, but I was fascinated.
It took me some time, as I was, what, 13 or so - but it was worth it. Not long before that, Star Wars was out - and still playing at some of the $1 theaters, and I had progressed to the point I could make a crude X winger animated shoot 'em up, and factually THAT was miles above the 'Trek' board game. After all, it had crude sound effects (oh, right - this was written on my OSI Challenger 2P - that had crude sound built in, the TRS-80 didn't), and was 'real time' - not a board game.
I had a friend over about 2 days after I finished it. He wouldn't leave for hours. I had to literally FORCE him out of the house and go home. I sold that game to the 'shop' that sold the machine to me (a little one owner place) for $5. My first 'for pay' programming task.
Fast forward a few years. I had learned C, but, as strange is this sounds even to me, the best language I could use for business programming on PC's (in 1982) was a proprietary BASIC called BB3. It fit into a PCXT and offered 3 'terminals', or, later, on an AT for 16 terminals. That was big stuff in those days. It meant I could charge BUCKS to save large corporations a mint compared to the 'data processing' fees they'd paid before, and I launched a career for myself based on that.
Of course, I move upwards into C, then C++, and all over the map. Every turn there was a new technology, new operating systems (AIX, versions of Unix), new standard for accessing memory beyond 1Mbyte in DOS, first 32bit programming model extensions for DOS, then another OS (OS/2), then another (Windows 3.1), and another extension to C++ - it was exhausting just to keep up.
Every turn meant a couple of 1,000 page books to read. Sometimes the reading was dense, like Ferraro's EGA/VGA programmer's reference. I learned a great deal about direct access to the graphics card, and put it to good effect in two products that needed to display text as quickly in graphics mode as the standard text mode of the PC, while showing engineering detail drawings (in DOS, a trick I assure you). It's utterly useless knowledge today.
Through all of that there are a couple of things I can tell you that will help.
First, confusion is the state of mind you can expect to experience before you understand something. Get accustomed to it, and avoid letting it fill you with anxiety. Relax about it, and learn that the sense of confusion is connected with the act of wrapping your mind around the subject, becoming aware of what you don't know. That's important, because the brain is a pattern searching instrument. The outline of what you don't understand is an outline of it's solution, and your brain understands that at an intimate level. If you let it work, and stop interrupting it with anxiety and negative emotional reactions, you'll realize the solution's imprint is already making sense to your subconscious before your conscious mind realizes it. It's a delicate sense, and emotional noise interferes with it. You'll gain confidence with it over time. It may be a little like feeling around a room when you can't see (darkness, blindfold, whatever). If you panic, you won't bother to remember the obstacles you run into. If you take it patiently, you'll remember the outline of the room before long, and as you practice such a task, it becomes nearly trivial.
There is something of an exercise/strengthening effect that results from learning this kind of material. It works with the calculus, algebra, physics, maybe not so much with Shakespeare (I never really 'got into' Shakespeare), but for the most part there's a mental fitness that does come into play. Part of that may be genetics and raw talent, but the rest is going to relate to patience, stamina, concentration, grit, focus, pace and confidence. Type A personalities may have more trouble with it than the rest of us. Intoxicants will not help, but valid therapies might for those that need it.
I know people that kvetch at the compiler for every complaint. They scream at every application crash, blush at every design oversight. If programming is an emotional experience of that nature, you're either going to have to change attitudes, or you'll need Valium.
My first learning on the TRS-80 and the OSI Challenger (an 8bit CPU with 16K of RAM - K, that's not a misprint) was just over 30 years ago. By the time I was 19 I started my own firm, landing contracts with large and small firms.
When I look back and the stuff I did at age 19, I wonder just how much of my work was bravery born of ignorance. I actually pulled off the work (there were a couple of bozo moves in there, but not many), but I know for a fact I didn't understand 1% of what I do now. For that matter, I didn't understand 2% of what I had learned only a few short years later.
I will say this, too - looking at the source code is not exactly going to inspire anyone. To this day we all despise having to dive into some new existing codebase, because it's a dense, tedius and painful learning experience to map out in our mind what it means.
If we've developed something that looks like that to everyone else, no matter how well structured and documented, it still makes more sense because it's fresh in the mind. The experience is like knowing the back roads of your hometown so well that you can think of 4 or 5 different ways to get somewhere, and can dodge around roadblock obstacles with alternatives at a snap. This, as opposed to navigating with a roadmap or following someone's narrative description of how to get somewhere in a city you've never visited before.
The complex applications, or the operating systems or frameworks or libraries, etc... it's all like that. A mesh of detail that's no more mysterious than the left/right/north/east.... of navigating a major city.
Having good documentation makes a huge difference, of course. Documented code is miles easier to navigate than non-documented code, but the same is true for operating systems. Ask anyone who's miffed over the occasional behavior of Windows that just doesn't quite fit the documentation's claim of how it should work (or, at least, the caveats and qualifications for making it work were, uh, somewhere else in someone else's book).
Not one of us hasn't spent a wasted late night debug/development session on some single, obscure, seemingly simple concept that we would SWEAR the OS is just not cooperating with, only to discover a misplaced byte, some unspecified parameter we didn't read in the documentation (explicated by some other friendly poster on CodeGuru, for example).
In some ways there is a resemblance to mountain climbing, or rock climbing.
It will be some few years before you feel genuinely masterful.
As an example, now that I've got 25+ years of professional work behind me, I wouldn't want to work with an engineer that has less that 5 years behind them. I'd probably prefer someone with 10 years experience. It's not a practice that comes to anyone quickly and easily - not with the kind of detail and moving target that comprises the study.