I admit that I was not very good at reading technical documents as a kid.
I had a commodore 64 but never really read the manual. I skimmed and hunted and pecked for information.
That's why I got a D- on my first computer programming final in high school.
You see, every code example in the section on BASIC programming that I looked at used single characters as variable names: A$, B$, etc.
The dollar sign designated the variable as a string.
I remember the manual stating that variables can have multiple characters, but only the first two were significant.
In my sophomoric mind, this translated to instantly seeing no point to using two characters as the extra letters would consume extra ink and paper when printed out. And I was lazy.
I obviously didn't know at the time that my laziness was prepping me for a career using the shortened command names in UNIX.
I had written a role playing game character creator. Because I didn't read the manual I had used GOTOs instead of GOSUBs for code branching, so my code was strung together like the random back yard zoomies map of a caffeinated corgi.
Each GOTO section also reused the same variable names. Because I knew that variables consume memory, I had gotten it into my head that the less unique variables, the better.
So combining unreadable variables with the cohesiveness of repelling magnets, I proudly turned in a thick stack of text filled paper to have a D- written in red across the top.
My ego recovered in due time but those lessons remain to this day.
Lessons learned:
1. Variables need descriptive names.
2. Organize code into sections that make sense, functions, classes, etc.