HackerTrans
トップ新着トレンドコメント過去質問紹介求人

cmbothwell

no profile record

投稿

Chasing the Myth of Zero-Overhead Memory Safety

verdagon.dev
1 ポイント·投稿者 cmbothwell·2 年前·0 コメント

コメント

cmbothwell
·5 か月前·議論
The irony of the agentic/mimetic interview question is not lost on me. I wonder if it is on the hypothetical interviewees?

Answering “agentic” is the most “mimetic” answer you could give.

The most “agentic” response is probably “Fuck you”.
cmbothwell
·昨年·議論
I’ve come to believe a more depressing take: they _want_ to believe it, and therefore do.

No disclaimer is gonna change that.
cmbothwell
·昨年·議論
This hits at the true nature of the problem which has _nothing_ to do with Redis at all (which is a fine piece of technology written by a thoughtful and conscientious creator) and has everything to do with the fact that our industry at large encourages very little thinking about the problems we are trying to solve.

Hence, fads dominate. I hate to sound so cynical but that has been my experience in every instance of commercial software development.
cmbothwell
·昨年·議論
What was it about Elixir that you found dissatisfactory? I am currently evaluating Clojure vs. Elixir for a new project.
cmbothwell
·昨年·議論
Feel free to contradict me with personal experience, but I actually posit that (like many interesting phenomena in life), the truth is exactly the opposite. The number of people in a team expands to fill the budget allocated. That budget flows from a legible & convincing narrative told to the check-writers (internal or external) that may or may not overlap with reality.
cmbothwell
·2 年前·議論
> If you can't isolate and articulate the problem without referencing your tech stack and tooling, or your explanation gets all muddy and convoluted, you haven't actually identified the essential complexity of a problem

100%. I don't have much to add but I've really enjoyed our discussion.

Have you seen this talk by Mike Acton? If you haven't, it might really resonate with you. https://www.youtube.com/watch?v=rX0ItVEVjHc
cmbothwell
·2 年前·議論
This rings so true. I noticed a consistent level-up in my abilities once I started to seek the essence of the problem. I ask myself: “I start with this information. The desired output is X. What is the essence of the data transformation that takes me from the input to X?”

When I boil down the task to its nature as a data transformation, the solution flows from my understanding of the problem, and I’ve found that my choice of tools flows transitively from there pretty easily. The problem is “isolated” from the software as you said which makes it so much easier to reason about things.

I sadly have not gotten much traction when I try and advocate for this mindset in our industry.

As an aside: It reminds me of a funny point from secondary education. Did you take AP tests in high school? If you did, you might remember as I do a consistent refrain that teachers used to beat into students preparing for the tests: “Answer the question” Over and over we heard this ad nauseam until it became second nature, whether for AP English or AP Physics - and it was good advice! Because the number one mistake students make on those exams is not actually answering the question asked, which even when couched in the most wonderful prose, results in a failing mark.

I think software engineering is often pretty similar. Even the best, most sophisticated tools will not produce a working solution if you don’t understand the problem.