abrbhat

Maybe an angle here is that tokens are being looked at as pseudo-currency..

Learning is not about what you put in, it is about what you can take out. It is also not zero-sum, but rather exists on a wide spectrum for any given knowledge domain. A good idea could be to prompt the LLMs to keep quizzing you on what you have read and test on both recall and understanding.

Also learning is not just about truth, it is about curiosity as well. The pop-sci metaphors could actually good for satisfying the curiosity of let's say a 10-year old. What to learn and how to learn is ultimately at the judgement of the learner. The better the judgement, the more the learner can stay closer to the exact scientific details.

On a side note, since the author has included a detailed explanation that the text is not AI generated and this is her default writing style, I just find it very difficult to read this style of extra punchy writing. I don't know if it is just me or anyone else as well.

Taste seems something that should be more related to a craft but when doing engineering we don't talk about taste, we talk about theory, systems, practices, skill, intuition, experimentation, teaching and learning. So the debate on whether taste matters or not might come down to whether creating software can be called craft or engineering. In my opinion, maybe programming was more of a craft before LLMs but it looks like it is being squished between the engineering aspects of producing and maintaining software going ahead.

P(i|j) != P(j|i)

> Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.

Agreed. If I have to guess, the relevant fields in physics for software engineering would be quantum mechanics and thermodynamics. Of course, we don't see any direct relation as of now but it feel it should be important to determine the physical basis of software. The basis of software cannot be just math. It has to be physics.

The link is from Internet Archive. The original post was on geocities which has long been dead.

My problem with such articles is that they mix the creation of software with the servicing of the software. It can be pretty complex to serve sophisticated software at scale in a cost-competitive and secure manner and it will remain so. So the engineering will remain important and domain expertise will remain important as well, as it has always been. Different business will rely on different combinations of these to create their own specific moats.

I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles(https://agilemanifesto.org/). Values are not right or wrong, they are just values you agree to or don't.

The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called process experts under pressure from management which does not know any better. The authors of Agile Manifesto have frequently said the concept of Agile has been badly twisted.

The actual post and this comment shows how early we are when simple and obvious ideas look novel when first conceptualizing them. Nothing against these ideas though, they are indeed good.

It seems that the cause of the difference in opinion is that the anti camp is looking at the current state while the pro camp looking at the slope and projecting it into the future.

The advice is not bad, just tailored towards someone looking for a good stable boring job, which is all ok. Therefore the chaos of startups is highlighted as a red flag. Might be good to add here that there are good learnings in the chaos of startups as well, for particular people, at particular times.