A precise and formally verified specification is WAY harder to write then the code for it
A precise and formally verified specification is usually just referred to as "PROD".
Readit Newsnoobker commented on Software 2.0 (2017) karpathy.medium.com/softw... · Posted by u/gtirloni
The short version, from a reference in the article.
“The primary purpose of narrative,” media scholar Katherine Hayles argued several years ago, “is to search for meaning,” which makes “narrative an essential technology for human beings, who can arguably be defined as meaning-seeking animals.”
His "narrative vs database" essay talks around the problem. Narratives tend to discuss causation, either explicitly or by implication. Raw data does not contain causation information. That's the real distinction here.
We know that humans are hard-wired to find causation, even when it may not exist.[1] This has survival value. In a hostile environment, an excessive false alarm rate is better for survival than missing a threat.
If you do correlation on enough data, you find what looks like causation. Often it's just noise. This is a well known phenomenon. Intelligence analysts, investment quants, and people who analyze research data have to be trained to watch for it. Most people don't have that kind of training.
Under information overload, this gets worse. Combine this with the human tendency to find causation when it doesn't exist, and you get false narratives. Even without wishful thinking or bias.
It's not mysterious. It's how human brains work.
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4008651/pdf/nih...
You appear to be strawmaning this piece to a large degree.
The necessity for humans to find meaning isn't ignored or argued as anything other than "how human brains work", in the piece.
The Database metaphor isn't a separation of raw data from narrative -- it's recognizing that in the modern zeitgeist, the abundance of data is so vast that a new experience has emerged that supersedes any Narrative, that's the Database: a super collection of all raw data as well as the known paths through it.
The existence of the Database then calls into question the validity of any one Narrative, and the rest of the piece follows.
* No need to reference NIH.
Brilliant synthesis:
Globally humans have transitioned almost overnight from information/knowledge scarcity to information flood. Once we had plenty of time to forage information to construct narratives and share them and agree/disagree on them before the next influx. Now we are literally waterboarded with information that has no context, minimal sharing and no real conversation attached. We are left with whatever individual narrative our pattern matching can construct, and it's usually inadequate. Narrative is definitely a superpower of the group not the individual.
We may need to wait a generation until people who have grown up in this world and can filter feed on the information can create/disseminate narrative adapted to the new rate of information flow and yet somehow true to reality.
The situation invites comparisons to the obesity epidemic or perhaps (more of a stretch) the introduction of alcohol into American tribes.
Regardless, it's critical to recognize that we as a people need to develop a greater worldview/metacognition to go any further forward together.
noobker commented on Elitism as the mid-career growth engine stkbailey.substack.com/p/... · Posted by u/peterhunt
I don't have many complaints about the language itself, but I've found the packaging ecosystem to be the most complicated and frankly dysfunctional that I've used in the last decade.
I never understand this complaint when Javascript/Typescript is sitting there with a mess of .lock and .json files across multiple tools that sometimes interoperate and sometimes don't.
Package management isn't a solved problem; Python employs standard patterns for it; Significantly better than chained Makefiles from my C-development days.
noobker commented on Elitism as the mid-career growth engine stkbailey.substack.com/p/... · Posted by u/peterhunt
Interestingly, I feel like this sort of attitude is a real issue at the precise moment the author describes it as a boon.
When you are early to mid career, it is crucial to look for ways to amplify the good you can do in your workplace and solidify your brand as an individual. To do this, you should be looking, ironically, to elevate others. Doing so is the only way to build a reputation that people are going to actively WANT to talk about (e.g. "oh, having trouble? You should call in Jim, he helped me with a related thing"). This is invaluable.
Perhaps I am speaking through a lens, but had I taken the authors advice and taken a more combative role at such a juncture, I believe I would have far fewer opportunities now.
This transition from junior to senior includes another important skillset: balancing social dynamics against engineering realities.
The key is illustrated in the book club parable: The elitism is directed outside of the group and becomes only a means of alleviating the fear of judgement for misjudging the paper. The grad student's approach clearly communicates the socially agreed upon reality: the whole paper is crap. This stance and boundary provides a clear decision space to the learning junior members: "if you think you see a mistake, those here will be happy to hear it; no sacred cows".
Bringing this practice into a situation where the target is a member of the group's work changes the dynamics such that you have to mind your Ps and Qs again -- and so, dampens learning.
noobker commented on Betting on things that never change (2017) collabfund.com/blog/betti... · Posted by u/Brajeshwar
What rings true for me in this article is the notion that, as a founder, it’s better to pick a problem space than it is to pick a solution. Amazon chose to live in the problem space of how to bring consumers more products, more conveniently, at a lower price. Geico chose a similar goal but in insurance.
Technical founders often focus on a particular cool way of solving a problem and burn lots of capital building that thing. Sometimes the thing is the right thing and everyone makes money. But sometimes it’s not. Yet if you stick with the same problem space for long enough, and aren’t too connected to your particular solution, I think you have a greater chance of succeeding.
Okay, go ahead and poke at my pontifications now. I’m ready.
I was once at a talk with several medical technology founders. One of them namechecked specific legislation that enabled their solution to come to market. And so I asked, "How do you survive if only 1 law is prying open the opportunity for your business?"
They replied that their business exists to solve a need -- a need that exists regardless of the specific regulations. Should the regulations shift, a company motivated beyond a specific solution will adapt to keep meeting its customers' needs.
noobker commented on We are sorry to inform you that you are in a cult labskausleben.bearblog.de... · Posted by u/memorable
In summary, every religion.
> every religion
The world's beliefs are many and varied. There are plenty of religious groups that provide a foundation for a healthy life instead of insisting they are the only means to achieving it.
You'll be hardpressed to apply this list of grievances to the average Buddhist community, for instance. Sikhs, Jains, Baha'i, Quakers -- many more come to mind.
100% this, what ends up happening is product wedges themselves between business and technical so they wield the power due to having business' ear, and any attempt by technical to communicate directly with business is met with severe reactions.
The thing to understand is that very likely your technical people are smarter than your product people. In addition, part of software development is being able to identify what needs to be solved. Any developer with a modicum of experience knows how to do this.
Just as you have a technical leader on the team, you need a technical architect on the team. That person can interface with the business or the business analyst (or both) as needed.
separate teams is a degenerate case for strong software development.
I once literally had a business person ask "who should be involved in this conversation" and my response was "product and technical so we can advise". Product responded after me with "Product" and the lack of technical there was deafening.
It becomes a power play, the theory of the different departments works out about as well as putting a racist and a black man in a room to collaborate on race relations.
>very likely your technical people are smarter than your product people
Intelligence is multifaceted. That business listens to product and not to engineers could be seen as a type of social intelligence of which engineers are notoriously unskilled.
Regardless, framing any portion of your organization as "smarter than" (implicitly "better than") isn't going to help in terms of fostering collaboration.
If there are things in your community you can change, then stoicism certainly does not say dont do it. Marcus aurelius, one of the most famous stoics, was roman emporer. Hardly a position someone who felt they could change nothing in their community would take on.
> things in your community you can change
There are a class of problems that are immovable to an individual yet conquerable by a community.
The author's fear in this piece is that a follower of Stoicism would too readily accept one of those problems as unchangeable.
Like other have mentioned here, the author seems to have missed some core tenets of stoicism.
Stoicism, nihilism, various forms of the Buddhist tradition all seem to focus on the message: "You are the leaf, not the river".
You can't control the river/universe. It will happen with or without you. Worrying about it or what it will do to you is almost a waste of time and energy. Like if the sun were to explode right now, it almost wouldn't warrant reaction. Because the outcome is set. Any reaction is going to be erased in 8 minutes.
On a much smaller scale, you also can't control other people. They're going to do their things. If something they do affects you, do what you can to mitigate or enhance the effects depending on if the results are wanted or not. Like if I were to get fired from my job, there's little I can do to change that outcome. Even if I wanted to. So there's no point to dwell on it. I need to focus on the next thing now. I would pack up my things, scrub my work machine, turn it in, and go home to look for a new job. No crying, no yelling, etc. Disappointment, sure, but I got shit to do.
> "You are the leaf, not the river"
I'm curious why you think the author misrepresents/misunderstands stoicism on this point.
The entire piece is that Stoicism is an individual's philosophy -- one that solves an individual's struggles. The philosophy helps confront that which you can't control...but the author is arguing that it will tempt you to throw up your hands, that you can't control anything.
The short of it is that Stoicism encourages an individual to draw within themselves and create a worldview that is acceptable. All well and good for the individual, but the world's problems will be fixed by collective action -- not individuals withdrawing.
Too much Stoic navel gazing might decrease the likelihood you join the community action board.