Hacker News Reader

Comment by glasss | Hacker News Reader

From the blog:

> I am here to tell you that the reason so much of the world seems incomprehensible is that it is incomprehensible.

This statement rubs me the wrong way, in a similar fashion to what you've pointed out. All of the world's systems and technologies haven't been able to be understood by one human for (most likely) a very long time now.

The world is incredibly complex, but at this point in history I can go and learn about pretty much all of it whenever I want. By definition that means it is very comprehensible. It just isn't practical for me to do so.

Modern scale as you've pointed out, and speed at which things are expected to happen to keep that modern scale going, are the bigger factors I think.

View on HN

When I started programming, i expected that I would have a learning curve that went like this: the more I learned, the less I needed to learn.

Instead, I found that the more I learned, the more I realized I didn't know. Finding answers inevitably lead to more questions that I had answered in the first place.

I don't know that we will get to the point that will stop being true, or how many lifetimes it would take a single person to understand it all. It certainly feels like we are past 1 already.

[Edit-] My comment originally focused more on natural sciences in general, but then I changed the opening quip to the personal anecdote about programming. The last paragraph, however, was geared more towards science, and knowledge in general, not programming languages per se.

That hasn't been the experience for me. I have much fewer questions now than I had when I started to program 30 years ago. Not to say that there aren't a lot of new things I don't know about that are coming up every day but that doesn't impact in any meaningful way my ability to solve real problems with software.

What previously was an issue of "I have no idea how to even approach this problem, not to mention write code that solves it" it is now a question of "I have at least 5 ideas how to solve this problem, I need to analyze which one is best solution for this particular context". It's much less about learning the tools and a lot more about how to correctly apply those tools for the right situation. I feel that this latter part could take my entire life but I can definitely tell I'm getting better at it every year, even if I significantly change the problem domain I work in.

As a matter of fact, every time I change the problem domain now I noticed less and less time necessary to become proficient in the new domain as I am able to pull from the experience I gathered previously. Computer science seems like an "infinite" problem domain but actually what I found in practice is that the more problem domains I move through the more I notice similarities and solving the same problem over and over again (albeit, with some small differences which may matter if you work in a performance or resource constrained environment).

> That hasn't been the experience for me. I have much fewer questions now than I had when I started to program 30 years ago.

I would guess poster above doesn't yet have 30 years experience. Perhaps 10 or less.

My experience echoes both yours and the above poster's - following a sort of bell curve - after initial ramp up, there was a significant period where every question led to several more. At some point that peaked, and by the time I'd been writing code for 20 years the rate of questions was dropping quickly.

Also the character of problems changed a lot. There's a point where QA sites like StackOverflow become largely useless for your problems, as they're too broad, complex, and dependent on specifics to fit the QA format. Even relevant blogs and academic papers become thin after 20 years.

I started in the 8-bit days. So learned BASIC. Then learned assembly language for the computers processor. Then next computer learn changes to the BASIC and the new processors assemble language. But after a point more languages became available on those computers and eventually I had to decide which was best for me to focus on. Now I try to what there is I could be learning about and decide how much about each I should learn about and how deeply. Starting now I don't know where I'd start.

I did too.

And I want to introduce my young children to programming, and also find that there is no obvious good modern starting point. Scratch isn't it. Python isn't it. JavaScript most definitely isn't it.

I'm considering Logo and BASIC -- possibly even a BASIC with line numbers and no multiline procedures/functions. Everything modern has a huge barrier to entry for just-learned-to-read children (and the otherwise uninitiated).

Assembly is easy to grok, but hard to use. Modern stuff is easy to use, but takes a while to grok. BASIC seems to hit the right spot for Beginners (All Symbolic Instruction Code).

Use QB64 on your modern computer then they can skip the whole mess of line numbers from BASIC and still use BASIC. https://www.qb64.org/

I walked a similar path and feel a similar sort of way. I'm not sure I'd have ever made it in this industry if it wasn't for the fact that I grew up when things were either simpler or had an illusion of simplicity around them that made them more approachable.

Yes there was only one path to learning which was as it happened. Now you have to figure out a good starting point looking back.

I guess my experience has been a bit different. Yeah I mean there are some really esoteric programming topics, like actually implementing compression algorithms, which I will probably never invest the time to learn. But in terms of "general programming", I feel like at some point over the past ten years, I developed a pretty clear mental model for how a line of high-level code maps to how the CPU/GPU is manipulating memory. I feel like once you start thinking in terms of hardware, the pace of revelations slows way down, and different programming topics mostly seem like different ways of doing the same thing.

I don't agree with this... Just because you know how the CPU and GPU work, doesn't mean you can write say a search engine.

Information retrieval is its own domain with its own body of knowledge that you don't understand if you haven't done it.

Ditto for dozens of other subfields. (And subfields of subfields like AI.)

Distributed programming is its own thing now. That's why there are so many HN articles on say Raft, eventual consistency, or CRDTs -- those weren't topics of interest when I went to school, etc. People are learning them on the job.

In other words, there's really no such thing as a "programming" expert.

Ok I see what you mean, and I think my point was more that programming as a skill does seem to be something which can be saturated. However I do agree that that no one person can master all the domains of what you can do with programming.

But I would also say, while it's probably impossible to really master more than a handful of domains in one lifetime, an awful lot of problems really can be reduced to inputs and outputs, and the more experience you get with solving diverse programming problems, the easier it is to penetrate some of these "advanced" sub-fields, at least at a superficial level, and solve a problem or two using tools from that domain.

As someone without formal CS background, I definitely feel like understanding computer systems is the missing level in my knowledge: Computer architecture, how it's interacted with by the kernel & OS, compilers, and computer networking.

It makes me want to go back and get a Master's in CS, focusing on those topics. But I am unsure if I would just be paying for a credential for something I could learn myself. On the other hand, it would be hard to beat the structure of good program.

I also don't have a CS degree. The book CS:APP (Computer Systems: A Programmer's Perspective) is recommended on HN frequently. I picked up a copy about 4 years back and have slowly worked through it and my understanding of computer systems has grown tremendously. I spent the first 7 years of my career in embedded, I thought that I had a good handle on these topics already. I was wrong.

Thanks, I will check it out!

I recently started working through Network Programming in Rust, but it wasn't as low-level as I wanted.

I am also planning to take a hack at the open source Illinois CS 241 book & course

Don't forget how your knowledge becomes out of date with frightening speed. I can read a novel and that knowledge will be good for decades. Documentation on your favorite web framework? 6 months if you're lucky.

I think this is a unique problem for a subset of front-end developers. In the rest of the software engineering world, "old" software seems to work just fine if you're not easily distracted by shiny baubles, and in some sectors (e.g. embedded systems) the state of the art hardly changes much in any single person's career.

I would say even in a shifting landscape of different tools/frameworks, the differences are mostly aesthetic, and the fundamentals mostly carry over.

For instance, at various stages in my career, I've done professional work in a lot of different languages and ecosystems: c/c++, objC, Java, Node.js, Swift, React, Rust - and each one of these has it's unique features, strengths, and weaknesses, but I think in general the more different tools you use, the more you see how much they have in common.

For instance, when I pick up a new framework or language, I'm looking for the same basic things: like how does the build system work, and how do I make an http request, how do I optimize for performance, and then I'm generally plugging the new tool into the same design patterns I've been using for years.

The domain of "software engineering" keeps changing. It used to include (what is now) DevOps as an integral part, but now it's becoming its own discipline.

If you do algorithms, nothing changed. If you do frontend, everything changed. If you do backend, change is slower - you are now expected to master (the misleadingly named) serverless; and you are once more not considered uncool for preferring an RDBMS to a NoSQL.

That’s overblown, jQuery for example hasn’t changed much in the last 5 years.

The bleeding edge changes rapidly, but that’s what it’s there for.

> This statement rubs me the wrong way, in a similar fashion to what you've pointed out.

I agree but more due to the blog author combining interesting topics like complex systems with value judgements asserting that a) the net effects are a major problem that needs to be worried about/addressed more than before, b) it's reached a tipping point, c) it could now get much 'worse' much faster than before and in new, unexpected ways.

It's common these days for authors to try to elevate the relevance or urgency of their topic this way but how we should feel about the 'way the world is' is uninteresting. The world has always been complex and it's always been growing more complex at increasing rates. Such transparent present-day exceptionalism just evokes the "but this time it's going to be different (and much worse)" echoed by every concern troll and prophet of doom for hundreds of years.

In reality, change is constant, net effects at large scale (ie global and decadal) are, on average, generally both positive and negative in roughly similar proportions to broad past trends. While there are certainly significant disruptions and calamities, the long-term, global meta-balance of pos/neg tends to eventually regress to the historical mean. In any given localized context there are always winners and losers and determining whether the net impact is "good" or "bad" is a subjective value judgement which varies based on perspective, context and how one chooses to count.

To apply a financial analogy I once read in the money/finance network on the Stack Exchange "we can afford to buy anything, we cannot afford to buy everything"

Maybe the problem is not that any one person can't deep dive whenwhere needed, but rather that as a group we are having more situations where we can't steer the complexity we have created.

For example, it is understood how to safely run a nuclear plant. But human nature being what it is it might not be possible for that large a group to correctly and consistently do so. Someone is going to be lazy or greedy. More processes and controls are added, making it more complicated, etc.

Another example is voting for president. We've made a political system that puts so much authority and influence in the hands of one person, over such a complex society and economy, and we ignore all of the important issues of the day instead squabbling over irrelevant details.

In practicality things keep becoming more complex and the risk of major incidents increase because of this, incidents that nobody sees coming and nobody knows how to fix right away. A serious problem.

> but at this point in history I can go and learn about pretty much all of it whenever I want.

You could learn any of it, but most certainly not all of it. And that’s a subtle but crucial difference. As the number of pieces/interactions in even a single end-to-end pipeline multiply, it would be extremely difficult for you (or anyone) to stay on top.

Reply on news.ycombinator.com