mvaliente2001

One factor in favor of the use of LLM as a learning tool is the poor quality of documentation. It seems we've forgotten how to write usable explanations that help readers to build a coherent model of the topic at hand.

The idea of tensors as "a matrix of numbers" or the example of a cube with vectors on every face never clicked for me. It was this (NASA paper)[https://www.grc.nasa.gov/www/k-12/Numbers/Math/documents/Ten...] what finally brought me clarity. The main idea, as others already commented, is that a tensor or rank n is a function that can be applied up to n vector, reducing its rank by one for each vector it consumes.

Math and Physics equations are full of beauty capable of transmit the same joy as poetry. The main difficulty is that they require more study.

For me, looking at Maxwell equations is a source of pleasure. Also, after improving my understanding of the Laplacian, I came to appreciate the heat equation.

My same thoughts. The inventors of that revolutionary toggle button should all be tied to the South side of an ass walking towards the North.

The alternative, using general programming languages, is a terrible idea. The last thing I want to do when dealing with a domain specific configuration is trying to figure the meaning out of hundreds of poorly written, badly abstracted, totally undocumented, lines of code.

For one moment I thought this was the equivalent of SQLite for EdgeDB and the idea made me very happy.

I think parent comment (by @sebzim4500) is the clearest most concise summary of the argument stated in the article.

Another evidence is to ask GPT for a link with a reference for the answers it gives: it'll generate them instead of copying them.

I think we never get over animism completely, like this old Ikea Lamp ad shows: https://www.youtube.com/watch?v=dBqhIVyfsRg

May I suggest you to take another look at refactoring? I think that if you love unit testing and debugging, you probably would love refactoring too. I like that I don't have to worry to find the perfect name for my functions and methods _on the first try_, and that I can focus in making code that works first, and after that I can worry in making clearer and more understandable.

Now, to be fair, I also like the common practices in the industry too. Scrum or kanban, ticket creation and estimation, and daily stand ups. When you're part of a team you need a lot of communication and effort to keep everybody working in the same direction. Besides, managers want to be kept informed. The how is not as important as the why.

Although I sympathise with the sentiment, that's just half of the story. Today, I can deploy a high available cluster in minutes using any cloud technology + kubernetes and my favourite web framework. True, I need to learn half dozen of frameworks, and _it feels_ like I'm not working in the core problem, but had I tried to implement an equivalent system without those tools would have taken me months, and I would end with an ad-hoc half tested non-reusable mess.

The best part is the last lines:

If we pay attention to the legend then we'll have to accept that in Earth is one less dog and in heavens one more star

(The C4 model)[https://c4model.com/] is a nice way to capture (IMO) the most important characteristics of a system, and you can learn it in half an hour. Optionally, you can add state transition and sequence diagrams for selected parts of the code.

One important thing to take in consideration is that diagrams are not blueprints. What they don't represent is as important as what they include. That's why I like C4: it's limited to answer an important but small subset of questions about your system.

asdf is very nice, with the exception of its interface. You have `asdf <context> <command>`, `asdf <command> <package>` for others. It's actively hostile for memorisation.

Mine was that I had forgotten to take a class or that the records were lost and I had to redo the last years of college. It was a nightmare I had even a decade after getting my degree.

I've been reading The Courage To Be Disliked” about Adler's theories, and it's very interesting. According to him, we all have feelings of inferiority. It's normal and could even be healthy, it'll help us to improve. What's negative is the inferiority complex: when we internalise our feelings of inferiority and use them as an excuse to avoid changing.

The idea of feelings of inferiority being a normal part of living is freeing, it helps to accept them.

GitOps not necessarily means developers should define every aspect of it. In my current work, SRE uses gitops and they are the main contributors to most repositories. But things like creating an AWS ECR repo for a new project or creating k8s resources is happily delegated to developers.

No. In my current company k8s + helm + istio + argocd + good support from SRE/infra team has made things pleasurable. Seniors introduce the complexities of the system to juniors in a controlled paced way. One thing I would change is to replace terraform for crossplane.

https://www.libelektra.org/home is an attempt to bring a registry to linux. It doesn't have the problems of its windows equivalent. I wish this project was more popular.

The thing that helped me the most to design maintainable systems was the use of Clean Architecture. In particular, the [Cosmic Python Book](https://www.cosmicpython.com/), which offers practical examples on how to implement Clean Architecture in Python, and which design patterns are more useful to keep every layer independent.

I was lucky and that was also the first thing I learned about programming (with the amazing 80's "The Home Computer Course" magazine). I still remember the first program I read:

    10 REM Computers are never wrong
    20 PRINT "Please type a number"
    30 INPUT A
    40 LET A = A + 1
    50 PRINT "The number you typed was"
    60 PRINT A

After a few paragraphs of explanation I learned that computers do what you tell them to do, not what you want them to do.

My interpretation of UT has evolved after I began using Clean Architecture. My original approach was to test functions and methods, which had as a consequence the calcification of the code: changes were painful because they broke a lot of test. Their granularity level was too low. Now, my units of test are use cases. They naturally offer great coverture, test and document business logic, and easily allow refactoring.

OP criticizes dependency injection, and comment that its unique purpose is making UT easier. I strongly disagree. I've been able to easily replace web frameworks and OORDB libraries using DI, and even develop business logic before selecting infrastructure technology. In that sense, the fact that UT are easier to write is an indicator that the system is easily adaptable.

A good UT allows me to reduce integration testing to the minimum. What my IT do is verify that two systems can exchange messages, but as soon as I get a request or response representation stripped from any I/O reference, it's UT time for me.

If your type system or log formatter is turing-complete, it can be exploited to do arbitrary unintended things.

Copying an old comment: "The New Drawing on the Right Side of the Brain: A Course in Enhancing Creativity and Artistic Confidence" by Betty Edwars.

She taught drawing classes and discovered that one reason why people is bad at drawing is that they symbolize what they see before drawing it. For example, when we see a face, we tend to focus on the eyes and mouth and ignore other features like the front. That contributes to a distorted representation that is reflected in the drawing.

She devised a series of exercises to avoid that problem. For example, try to draw a picture upside down, or try to draw an object shape using negative space (you focus on the shapes outside the object).

The difference I see is that before, when they had to use practical effects, they had a more earnest appreciation of their limitations. The toy planes and ships in old movies appeared only for a few seconds since they knew they didn't fool anybody. On the first days of CGI they used to do the same, keeping the effects short. Then... somehow someone lost perspective and though scenes like this one didn't look like a joke[1].

What's worse, the abuse of retouching is making real things look fake. I remember watching the ending of Indiana Jones and the Crystal Skull at the cinema and thinking "why did they chose to make the top of the pyramid CGI? It's so cheap." Later I discovered it was a practical effect, color "corrected" to the point of removing any resemblance with reality.

[1] https://www.youtube.com/watch?v=ZxzyARI2lPQ

I think it's important to keep a consistent style in a repository. Ideally, the style should be kept _among_ repositories too, but given that different people like different thing, allowing them to explore the pros and cons might be a better strategy to achieve it.

Thank you very much for sharing this. In more of one occasion I've asked myself this exact question, even if for only as a thought experiment.

I prefer to use webpages as much as possible. I liked google Reader, and once they killed I migrated to https://theoldreader.com/

I've always thought that AWS conceptual model and implementation is a big mess. Root accounts different from other account, big numbers & ARNs exposed to the user, meaningless names for services, multiple names for same concepts (do I need to say Ireland-1 or is it eu-east-1?). It's inhuman and overly complex. I assume people hasn't revolted because that baroque and unnecessary obfuscation feeds a lot of consultants whose time could have been cut significantly have Amazon had someone to think before implementing such monstrosity.