Maybe not exactly the same thing, but I think one related representation of this in any good codebase is documentations in the code:
Good documentation always focuses on the why and not the what. i.e. things that are not represented by or representable in code.
It may describe not only why a certain choice was made, but also why not something else.
In general, the whole point of these documentation is to account for things that are beyond what can be understood from just reading the codebase including other existing documentation, that you may never even imagine with all the tokens in the world otherwise, which were yet a critical part of our coding choices.
If we are to believe that LLMs can build complex systems, then it's equivalent to saying that LLMs can make similar decisions equally well without any of that... which also then implies that we essentially never needed these documentation to begin with other than as redundancy for human needs.
I'd much prefer people just stay away from reading it altogether if they find it difficult... If it's difficult, then it probably isn't for you.
At least I wouldn't bother wasting my time, unless I treat it as some kind of exercise.
I read his writings because they read like my own thoughts from the very start and I never had any trouble finishing. He is the only writer who's works I've read countless times (never thought about counting, but Idiot, Karamazov at least 20 times).
That would make him what would normally be called my "favorite writer", although I do not say that either.
On the other hand, I have difficultly reading most other writers.
I agree.
We seem to enjoy getting excited about ways of improving education in our heads, but somehow keep forgetting or think lightly about the actual teachers in reality.
Teachers are always going to be one of the biggest bottlenecks: no matter what fancy perfect education method people come up with, it's still not going to be any better than what an average teacher can teach. Or equivalently, what an average teacher understands herself. And in fact, the greater the discrepancy between the theory and the teachers, the worse the actual outcome will probably be...
If we still want to introduce some new fancy ways, at the very least, we have to begin by teaching the teachers, not the students.
I think this is true even if we suppose that all the teachers are "gifted" so to speak. Otherwise, teaching isn't a science so each teacher will just do things their own way, which again will probably be a mess. Even gifted people are not all the same. Or if we say that's ok, then we wouldn't need an education system to begin with: just let each teacher teach in their own way and the world should still be great a place-- but I doubt it.
On a side note, I've come to see textbooks as a great invention in that sense: the students can learn a bare minimum even from the dumbest teacher as long as you make sure they follow the text book. Put another way, the textbook is like a baseline meta-teacher teaching the teacher along with the students..
I'm not a teacher myself but I have a lot of teachers around me including family members from whom I've heard this.
Thank you for putting out a clear message. I completely agree.
> parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
and of course, this isn't even the worst. A lot worse can happen, such as data loss and corruption. Things that can directly affect people's lives in real life.
As a developer, these things are constantly on my mind, and I believe this is the case for people who do care about the quality.
As has been said elsewhere many times, AI producing code is not the same as say, a compiler producing machine code. It is not such a well-defined strong abstraction, hence why code quality still is highly relevant.
It is also easily forgotten that code is as much a social construct (e.g. things that have to be done in certain ways due to real life restrictions, that you wouldn't have to do in an ideal world).
Sometimes I feel very powerless though.
It feels as if some of us are talking past each other, even if we seemingly are using the same words like "quality".
Or in a way, that is what makes this more futile-- that we are using the same words and hence seemingly talking about the same thing, when we are referring to completely different things.
It is difficult to have a conversation about a problem when some of us don't even see it as a problem to begin with-- until it reaches a point when it starts affecting their lives as well, whether it be directly or indirectly.
But that takes time.
> The recent trend is to increase the output called programs, but decrease the output called programmers. That doesn't exactly bode well.
Perhaps on a related note, I've noticed that a lot of the positive talks about AI are about quantity.
On the other hand, there is disproportionately very little deep discussion about quality.
And I mean not just short term, local quality, but more long term and holistic quality (e.g. managing complexity under evolving requirements in a complex system with multiple connected parts) at real production scale, where there is much less tolerance for failure.
In all the places I've worked in throughout my career, I've felt that there have always been a tension between those who cared more about things like the mental model and holistic quality, and those who seemed to care less or were even oblivious about it.
I think one contribution of the current AI hype is that it gave a more concrete shape to this split...
Also reminded me of Kafka (Kafka as a database!) and microservices (monoliths are evil, microservices are the future). I'm sure we can dig up similar hypes on various scales throughout the history of this industry...
Perhaps so-called AI is slightly different from hypes like NoSql and microservices in that these reduced to usages that practically apply to only a fraction of the engineering population (albeit, it's still good for anyone to know about them even if we never use them), whereas AI will probably still affect us all even after the dust settles. Just in much less spectacular ways than is being trumpeted currently by some groups.
Reminded me of No Silver Bullet: "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. "
I agree.
For instance, with cars, the essence of a car is driving, and hence the only thing that a common user cares about is learning how to drive one.
In particular, a common user should not need, and are usually not interested in, having automechanic skills.
On the contrary, that's the whole point of car manufactures and workshops, so that a common user doesn't have to care about those technical details under the hood, but just focus on the main task i.e. driving.
I think it's similar with computers and programs.
The essence of a computer is information, so the main skill a common person needs is knowing how to work with information
e.g. in the present day, navigate the web safely, how to research appropriately + identify reliable sources, organize and analyze data, manage privacy, etc
They shouldn't have to be programmers themselves, and indeed, that's the whole point of software, so that a common person can focus on their main task of working with information, and not have to be concerned about technical details under the hood.
note: things like excel macros where a software has a programming-like feature is a different matter, since it's a feature exposed explicitly by the software for users to exploit if need be. In any case, it's a software choice and hence specific only to that software.
I also agree.
In fact, I have a feeling it is not simply a matter of allure, but one of the most decisive and important factors if not the single most.
I think we tend to underestimate the importance of this kind of uniformity (aka homogeneity, consistency, sameness, equivalence etc) that allows us to freely shift back and forth and work across different environments (aka contexts, mindsets, etc) without any essential changes and translations.
i.e. in a sense, minimizing the boundary such that the difference effectively disappears and it feels as if it's all just one same.
In this case the environments being shell <-> script. But I think I see similar patterns in many other places, including outside of tech.
So, similar to as you also mentioned, as long as there is no language that beats the current shell as both a shell language and a scripting language, and one that sufficiently matures for real practical uses as both, I have a hard time imagining the most perfect scripting language alone still being able to make shell scripts go away. At least, I have a hard time imagining myself abandoning shell scripts otherwise.
More a question than a comment: if you think it's all only decline now and were really done with life, why are you still here?
If you were truly done all the way through, I'm sure you would have long done away with life without even questioning it.
But you haven't and are still here. Great!
I think this fact means something: there is still something holding you here, no matter how seemingly small and trivial.
And somehow I get the feeling the secret is actually somewhere in there, whatever it may be. And so maybe it's not really that small and trivial.
p.s. I've been running in circles like this myself for decades..
I am rather skeptical it is a matter of software or any tool for that matter with problems like this.
Similar to Paul Grahma's design paradox: " I call it the design paradox. You might think that you could make your products beautiful just by hiring a great designer to design them. But if you yourself don't have good taste, how are you going to recognize a good designer?" (http://www.paulgraham.com/gh.html)
As long as people (including the business owners, customers, the rest of society, the rest of the world, etc) don't recognize the cost or don't care sufficiently even if they do recognize it, the best tool still won't have any effect nevermind solve.
Usually, that's the critical problem, not the tools.
And of course, tools won't fix people either.
Software is useful only if used by the right people in the right way, which is usually much later.
In general, I'm pretty skeptical of imperative guides like this.
Such statements only focus on one side of the coin. So while it may have an element of truth as long as you are absorbed only on that one side, you risk completely missing the other side.
For example:
> Deprecate yourself. ... Don't own the code.
On one hand, this is true: ultimately, you want the code to be independent of you.
But on the other hand, I've witnessed bad code quality proliferate in a repo many times because no one is taking ownership of the code they write: they just write enough to finish the task and move on.
And it rarely gets caught in code reviews either because all the other members are operating in the same mindset too.
His principle misses this side of the coin.
Over the years, I came to realize that at least for me, there is one root force behind almost everything for me, including how I code, how I interact with members, etc.
It is: responsibility.
I am simply trying my best to write responsible code, create a responsible product, be responsible to my team members and colleagues, etc.
The rest of the stuff (like what you might call 'principles') are just specific manifestations of this feeling.
e.g. code ownership: I need to own my code to the extent that I need to be responsible for my work, but on the other hand, it is also my responsibility to ensure the code does not depend on me forever.
Albeit this probably may be too abstract to call a principle. In that case, I'd rather not have any.
It depends on the type of relationship to some extent e.g. friends, acquaintances, business relations, etc.
But in general, I feel like we are too self-conscious about staying in touch.
And often because we have experiences where something happens in our lives and we find ourselves regretting "I wish I had stayed in touch with ----".
But when that happens, maybe we can ask ourselves: even if I had stayed in touch, would it really have turned out as I am fantasizing now in my regret?
If we think about it carefully, I think the answer is probably no. A meaningful relationship is not that simple nor easy.
As others have mentioned, a relationship is two-ways so it takes both sides.
And it only takes one to remember occasionally to stay in touch, so if we both were interested in each other, most likely we would have remained in touch already.
And even if we had not, it's never too late. With such relations, I find that I can just reach out now and resume the same relationship no matter how much time passes in between.
Even in the worst case where I don't have the contact anymore, if I were truly determined, I will do everything I can to find a way to reach that person.
On the other hand, a shallow relation is bound to not get too far: it will fail (or break, or be lost, etc) at some point in one way or another anyway.
So it most likely wouldn't have turned out as my regret is fantasizing anyway.
I agree, there is often a deep discrepancy.
The things people say (like what they say they believe, what they say they value, etc) often do not match up with what they actually think (e.g. if you watch how they actually behave, make choices, go about their lives, etc).
I sometimes hear people say it's a matter of how you define words like "believe" but to me, that only to complicates the matter.
I think almost all if not all of our serious problems can be traced to this kind of discrepancy.
Maybe that's my outrageous belief, heh :S