[omnicognate]

An important aspect of this for professional programmers is that learning is not something that happens as a beginner, student or "junior" and then stops. The job is learning, and after 25 years of doing it I learn more per day than ever.

[cyclotron3k]

I've reached a steady state where the rate of learning matches the rate of forgetting

[sph]

How old are you? At 39 (20 years of professional experience) I've forgotten more things in this field than I'm comfortable with today. I find it a bit sad that I've completely lost my Win32 reverse engineering skills I had in my teens, which have been replaced by nonsense like Kubernetes and aligning content with CSS Grid.

And I must admit my appetite in learning new technologies has lessened dramatically in the past decade; to be fair, it gets to a point that most new ideas are just rehashing of older ones. When you know half a dozen programming languages or web frameworks, the next one takes you a couple hours to get comfortable with.

[TeMPOraL]

That's one of several possibilities. I've reached a different steady state - one where the velocity of work exceeds the rate at which I can learn enough to fully understand the task at hand.

[everdrive]

But just think, there's a whole new framework that isn't better but is trendy. You can recycle a lot of your knowledge and "learn new things" that won't matter in five years. Isn't that great?

[epolanski]

I use spaced repetition for stuff I care for.

I use remnote for that.

I write cards and quizzes for all kind of stuff, and I tend to retain it for years after having it practiced with the low friction of spaced repetition.

[bryanrasmussen]

to fix that you basically need to switch specialty or focus. A difficult thing to do if you are employed of course.

[emil-lp]

I worked as an "advisor" for programmers in a large company. Our mantra there was that programming and development of software is mainly acquiring knowledge (ie learning?).

One take-away for us from that viewpoint was that knowledge in fact is more important than the lines of code in the repo. We'd rather lose the source code than the knowledge of our workers, so to speak.

Another point is that when you use consultants, you get lines of codes, whereas the consultancy company ends up with the knowledge!

... And so on.

So, I wholeheartedly agree that programming is learning!

[mlrtime]

>One take-away for us from that viewpoint was that knowledge in fact is more important than the lines of code in the repo. We'd rather lose the source code than the knowledge of our workers, so to speak.

Isn't this the opposite of how large tech companies operate? They can churn develops in/out very quickly, hire-to-fire, etc... but the code base lives on. There is little incentive to keep institutional knowledge. The incentives are PRs pushed and value landed.

[teiferer]

> We'd rather lose the source code than the knowledge of our workers, so to speak.

Isn't large amounts of required institutional knowledge typically a problem?

[1718627440]

Obligatory link: https://pages.cs.wisc.edu/~remzi/Naur.pdf

[hnthrow0287345]

It can be I guess, but I think it's more about solving problems. You can fix a lot of peoples' problems by shipping different flavors of the same stuff that's been done before. It feels more like a trade.

People naturally try to use what they've learned but sometimes end up making things more complicated than they really needed to be. It's a regular problem even excluding the people intentionally over-complicating things for their resume to get higher paying jobs.

[dude250711]

> The job is learning...

I could have sworn I was meant to be shipping all this time...

[rTX5CMRXIfFG]

Have you been nothing more than a junior contributor all this time? Because as you mature professionally your knowledge of the system should also be growing