If your reflexive response to “my program is slow” is “use a faster language,” you’ve likely never had the experience of a development-speed-prioritizing language allowing you to iterate rapidly on ideas until you discover your feature topology.
If your reflexive response to “use a faster language” is FUD and mystification, you’ve likely never had the experience of switching to a faster language and having the performance gains open up new feature possibilities.
A great way to lose credibility with someone is to tell them their truth is false when it’s actually just incomplete.
Good design is as much a function of intelligibility, which in turn is a function of a variety of human factors and local context, as it is about flexibility under changing requirements.
“Object-oriented”? Now you have two problems.
Good intentions are worth their weight in gold.
Writing Lisp is intensely satisfying in a way that’s hard to describe. Doing anything complicated in a functional language gets painful earlier, so you’re forced to abstract away complexity with less conscious effort than it takes in an object-oriented one. There are fewer temptations to design beyond realistic needs, and no importing of a design pattern’s attendant conceptual baggage or latent constraints, which can end up becoming hazardous in the long run. The syntax lets you focus on the heart of your problem. Compared to especially expressive languages, there’s no cognitive overhead from needing to choose between three or four different ways to express the same logic. Everything leans hard in the direction of simplicity.
Everyone I’ve worked closely with has had some gift, some exceptional ability or inclination, that I really appreciated about them. A knack for debugging, an intense bias for simplicity, a willingness to either break or carefully improve things no one else wants to touch (code, conventions, habits). In a strong team these predilections are superadditive, modulo the efficiency of collective information processing. But the ur-skill, and probably the skill I admire the most, is change-discipline. The metaphor for software development most commonly operative for me, somewhere in the depths of my consciousness, is of a bounding fire-team.
Software engineering is a lot like macroeconomics in that (as with most knowledge domains) the underlying phenomenon is high-dimensional, so in practice we employ simple models that are only reliable under strong assumptions but (unlike most knowledge domains?) both suffer from a pretense of knowledge problem driven by a combination of economic incentives, epistemic naivete, and physics-envy (or something akin to it, in the case of the former).
Much of what constitutes expertise in the field is less knowledge than folk wisdom, with a short shelf life and tight bounds on applicability. Situation normal. We enter failure modes when we don’t attend to this provisionality (consider, e.g., fetishized best practices, the risible claim that the tech interview is a standardized test, vulgar meritocracy in hiring and promotions).
“Strong opinions, loosely held” degenerates into “cheap talk, loudly voiced.” It’s not as catchy but I prefer something along the lines of “Well-informed opinions, held as tightly as warranted by the context.”