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 3 hours ago | parent | next [-]

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

	▲	emil-lp 3 hours ago \| parent [-]
		That might be the case for USA, but this was in a country with practically no firing.

▲

teiferer 4 hours ago | parent | prev [-]

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

	▲	emil-lp 4 hours ago \| parent [-]
		It was a "high tech domain", so institutional knowledge was required, problem or not. We had domain specialists with decades of experience and knowledge, and we looked at our developers as the "glue" between domain knowledge and computation (modelling, planning and optimization software). You can try to make this glue have little knowledge, or lots of knowledge. We chose the latter and it worked well for us. But I was only in that one company, so I can't really tell.