Hacker News Reader

Comment by zdragnar | Hacker News Reader

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.

View on HN

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 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 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 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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com