Teach Yourself Programming in Ten Years (1998)

That’s good - keep striving for that!

I am at times more of a book learner, but find that attitude is often more helpful for non-CS disciplines that change slower (eg, math/physics).

A recent negative book example for me is the Quantum Programming book from O'Reilly. I found that it did not discuss quantum circuits in a detail that helped me really understand what I was doing -- though I suppose that is a conceit of quantum computing. Perhaps I will return to it later (I am working through Nielsen/Chuang now, which is very theoretical, but explains things very clearly)

My policy is that a book is nothing more than a learning tool, which a hobby project can also be (perhaps more effectively due to the experience gained).

Then again, knowledge is power, and books are great at pointing you in the right direction -- assuming you found the right one for your needs, of course.

I know some people who won't open a book unless they know they can read the whole thing, which I think is a ludicrous attitude.

I did just order O'Reilly's Generative Deep Learning book, and am hoping to get something out of that, and if I only retain a handful of snippets to use in my career, that is profitable for me.

The least I can count on is that it will look nice on my shelf.

Reminds me a lot of when I was 13 and had learned Visual Basic 6 and wanted to make a game so my mother bought me a book on how to make games. “How to make games” she said excitedly as she handed me the book. “How to Make Games” it indeed did say. It also said under it “in C++ and OpenGL”. I had no idea what I was doing or what was going on. Enter high school. An elective called “Computer concepts and programming” was the only computer class outside of “Keyboarding”. It was taught by a female teacher who used to write punch cards for a living. She introduced us to C. All of the sudden, that book from a few years ago clicked in my brain and next thing I knew, I was writing games in C++. They were crap. Horrible performance. But I made them from scratch.

Fast forward another decade and then a lot of these Packt publishing style books on making games and learning coding - except for the holy grail of book series - GPU Gems… if you ever want to feel stupid, go read some GPU Gems articles. Today there’s a lot of choices - PBR - Vulkan - anything Eric Lengyel.

I still feel like it’s a trap. All these “Teach yourself…” should really be titled “Become obsessed with…”

All of these things are the craft of software. If you don’t find figuring out how to efficiently debug and understand things that are complex you’re probably in the wrong field.

The point isn’t that day to day is full of brilliant insight, but that process year over year you become really adept at these things you’re struggling with and you see patterns more clearly and can cut through the struggle faster and focus more on doing cool things with that ambiguity.

Frankly today is better in these respects than it’s ever been. The tooling for insight and debugging is mind bogglingly powerful relative to 30 years ago. But that doesn’t make struggling in your own ignorance without a clear guide through any more fun. That feeling of desperate helplessness and idiocy is the feeling of LEARNING, which is compounded by ambiguity. It’s easy to feel angry with X for not doing Y (I.e., lack of documentation) for your situation, but the right answer is to buckle down and figure it out and focus on developing skills to make it easier next time you have to learn.

There are layers here. The purest theoretical CS is like mathematics in general. Also necessarily structured around cognition, but seemingly groping for something more fundamental or universal.

I'd agree lots of software is like engineering in that it is further tilted towards the practitioners and marketplaces and their limitations. It has more focus on cost-effective repeatability and risk management. But, traditional engineering is more rooted in some physical reality. I.e. civil engineering has basis in physics and materials science, because those drive failure modes and design criteria. The more social aspects---say evacuation routes for fire safety---developed within an existing practice that already been formalized to manage risks of structural failure etc.

But, lots of software is far detached from such a physical realm. It is more like legislation or contract law, or the arts. It's all about what people want to say or hear and display to each other. Massive influence from the cognitive and social context. It may be colored by technique and available materials or resources, but thanks to Moore's Law and friends, these practical limits have less and less influence on the shape of the outcome. Significant failure modes can be rooted in the vagaries of psychology, social sciences, or even political sciences.

However, software diverges from law or arts when we attempt to scale it up. We want to reach speeds that cannot be supervised and quality controlled by a human operator, or volumes of support tasks that cannot be managed by an affordable human workforce, or impactful decision-making and effects that cannot be adjudicated by a higher court. You need something like engineering here to manage risk, but there is no physical basis for building codes etc. Not only the new software products, but even the elements of risk are social constructs.

But I think the metaphors are broken as one pushes too hard "up the stack", into AI replacing knowledge workers and analysts. Our current best social systems completely depend on human adjudicators in hierarchical layers of oversight. Courts that can comprehend the big picture and resolve differences when our other abstract social activities go wrong. I am nervous about a future where tech behaviors become too complex for such oversight. Or worse, where naive practitioners think they can solve it with another layer of unproven tech. Instead of turtles all the way down, it becomes some faith-based electronic oracles all the way up?