1,128 karma · joined May 2, 2021
I'm interested in how you concluded the advice was so beneficial. Was it a reduction in conflict and fewer emotional outbursts from your BPD partner? A feeling that you're better able to soothe them and manage their feelings?
These are clinical standards for self-absorption and toxic personality traits. In their relationships, cluster-Bs select for supplicants who will love them despite their toxicity. What you're saying about the memoir is consistent with this.
Her mental health conditions aren't a reason to disregard everything she says, but she is providing social and interpersonal advice here, in a way that is likely to encode the dysfunctional schema and disordered thinking she suffered from in life.
For an opinion piece that is about how to empathize with other people, I think it is relevant information that the author probably had a clinical impairment in their own ability to empathize with and understand others.
The conscious analysis of tone and body language is obviously important for many people to get by socially, especially for neurodiverse people or people outside the norm of the situation. However, I think it is important to avoid remarking directly on body language.
You can still let these non-verbal observations guide a conversation, of course. Rather than remarking on someone's smile when they mention a subject, you might ask them to elaborate on the subject.
Unless they've asked to be psychoanalyzed, most people do not like the feeling of being analyzed.
First paragraph of the OP and I knew in my bones it was written by someone with a personality disorder. Since her death, her husband published his memoir in 2023. The serial cheating, open suicide ideation, unresolved childhood trauma and general toxicity to herself and others is completely consistent with the tone of the article.
Absolutely. One thing I notice is that the people sharing this "advice" - while positioning themselves as amazing listeners - seem to have a disgust reaction to people sharing details about their own lives in a conversation.
Personally, if I have something I would like to speak about and feel heard about, I feel most heard when the other person is able to share some of their own thoughts and experiences. I absolutely do not feel heard when they completely remove themselves and their life from the conversation, and hit me with lifeless "open-ended questions" and "that sounds tough" platitudes that could have come from a blog post.
I don't agree with this piece at all, and I don't like the vibe of the author. The very first paragraph has a narcissism in it that rubs me the wrong way. Like the whole world let her down for not centering her in conversations the way her therapist caretaker did.
> Some simple and powerful phrases to use when someone is feeling feels: “I hear you.” “I bet it is hard.” “That makes sense.”
All three of these seriously suck to hear. IMO these are actually worse than the phrases the author says to never say. Someone telling you "You have no reason to feel that way" can easily be challenged. Someone disingenuously saying "I hear you" like a robot can't be.
The entire idea that there are boilerplate "powerful phrases" you can drop to make someone feel heard is nonsense. These generic phrases are determined ahead of hearing someone speak, so they can not reflect the act of hearing.
There's a reason why this brand of non-communication is so popular in HR circles. What this author is advocating is that we import patronizing HR speak into every day conversation. No thanks.
>Replace all of the shocking, mean, hateful, incorrect, ignorant, offensive, cruel things coming out of this person’s mouth with “I’m hurt! I’m hurt! I’m hurt! I’m hurt. I’m hurrrrt.”
This is narcissistic logic. When people are angry at you, and attacking you - and they do not have a clinical mood or personality disorder - you must accept that there may be a reason behind it. Things said in the heat of the moment are not always fair or measured, but they are rarely meaningless. When you decide that nothing someone is saying is valid because they are hurt, you will probably just invalidate and hurt them further.
The idea that the most important thing in a situation like this is to not be upset yourself is also narcissistic logic. Although presented as practical advice to not escalate, it's really just the authors need to "win" the interaction. It says "I'm the level-headed and rational one, while the other person is crazy and flying off the handle." Acting this way can escalate the situation even more than becoming angry yourself, but it will do so in a way that allows you to avoid taking any personal responsibility for that escalation.
I have to wonder what situations and interpersonal relationships the author is in that she finds this to be such a relevant piece of advice. These experiences don't sound like a model for healthy communication.
>5. Don’t relate.
This entire section is deeply narcissistic. The one-upmanship thing does happen, for sure. But it's not the reason people share their own experiences in the course of you sharing yours. Her conception of why people share reflects a deeply disconnected view of other people. Reads as "sometimes I'm talking to someone who is so self-absorbed they don't understand the conversation is 100% about me!"
Of the whole article, this section was most reminiscent of the cognitive style of diagnosed NPDs I've known.
>6. Ask questions.
This is the only decent advice in here, and I can't really fault it. But there is still something off here. It's like the goal of asking these questions is to "make someone feel heard" rather than to actually hear them.
IMO, React repeatedly nerfing external stores and encouraging users more and more to shove their application state into React components has exposed what a poor model of reactivity React actually offers.
What is it about Tailwind that is unmaintainable, in your view?
And now you go down the same path.
If you are building real applications with this then you will find that OOHTML will need to be repeatedly extended in order to fit the more complex use cases that come with deeper usage. You will end up reinventing the wheel but worse. That's a great outcome if the project is a hobby or learning experience. But if you're trying to deliver real commercial outcomes with this tech I would start rethinking things now.
These seemingly simple template languages that promise an escape from the "unnecessary" bloat and complexity of the modern web are doomed to fail. Any level of adoption will drive deeper usage, which will drive more complex use cases, which will force more bolted-on general programming language features. Eventually your users discover (the hard way) why all the complexity in modern web frameworks exists, but now they're stuck programming in a shitty template language that is underbaked, awkward to use, has no ecosystem, shitty tooling and some rancid expression DSL you have to memorize. Cursed indeed.
Sometimes it looks like people are burning out because of extreme workloads. In these situations, I've always asked "why is the workload so extreme to begin with?" This gets you to the real source of stress.
I am. Completely sick of it! Thanks dang for your diligent moderation.
For the benefit of younger devs, I'd like to add that this is a rookie sales mistake that indicates lack of software sales experience.
I'm very skeptical about these situational anecdotes where someone with low impact complains about someone with high impact. "I was on a team where the guy who wrote everything left and then everything sucked" is not a compelling vantage point.
This whole article reeks of imposter syndrome. Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad, and that the author's inability to understand technologies like Rx, validation and testing frameworks is actually a hidden strength because it makes him some perfectly interchangeable lowest common denominator developer. I hate/hated working with Rx, but it is fundamentally not challenging or complex.
This story is common because the types of people who are capable of single-handedly building large parts of a software product in a short time are naturally the ones who are "hyper-productive" and leveraging a tonne of different technologies and paradigms. The unexceptional "slow and steady" devs are usually not capable of having that kind of impact. When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce.
Ultimately, the onus is on businesses to avoid crutching themselves entirely on a single developer's output. But there are a heap of shitty businesses that have no method for delivering software other than to let singular, highly motivated and passionate developers "go HAM" on the codebase with no oversight. These businesses deserve to fail, and the unmaintainability of the code base after the departure of their key players represents the correction of a market anomaly.
>Then suddenly, the frontend lead quit for greener pastures
What does this even mean? Key personnel do not "suddenly" quit.
If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.
From what I can tell, the only finding here is that teams with individual aptitude as the sole selection criteria performed poorly in competition against teams that had more traditional selection process. This would be an expected result for me.
The results are only unexpectedly poor if you assume individual ability directly composes into team ability. I think this was a common assumption in the 1980s, but I believe that managers nowadays will not be surprised by these results.
My feeling is we will probably all look back at the over-use of text based DSLs and configuration languages as a giant mistake. Not just with respect to K8s, but IaC, CI/CD config and the rest of the DevOps YAML/config language mess. In retrospect, it has been a case of simplistic instead of simple. "Declarative" config languages are hello world optimized, and what looked great at the beginning of the S-curve is starting to look pretty damn bad.
I think we can safely say this mentality goes well beyond ag-tech. There seems to be a founder/engineer specific flavor of "epistemic trespassing" - especially with respect to fields that tech types look down on as banal or unsophisticated.
Outsiders can make valuable contributions to fields beyond their own, but I'd imagine the chance of doing so steeply diminishes with arrogance. If you walk into a market thinking everyone is an idiot waiting to be disrupted, get ready to fail hard.
Cryptography and parsers simply do not belong in the same sentence. There is never a time when it is a appropriate to write your own cryptography. OTOH, most large compiler and interpreter projects have handwritten parsers, and many of them have handwritten lexers too.
Writing a parser can be simple enough to fit into a take-home assignment, and hand-written parser code ends up looking pretty similar to an LL grammar anyway. Parsing is also the easiest part of writing compiler or language tooling, so if a hand-written parser is too high a bar for the team then the entire project might questionable.
I'm not saying never use a parser generator, but I would personally prefer to work on a project with a well tested hand-written parser than a project using a parser generator. Especially if it complicates the build process with extra tooling, or is something really dated like Bison or ANTLR.
This sounds a bit like a variant of the old "lump of labor" misconception.
There's no such thing as needing programmers. In the long run, economic decisions in markets are made at the margin, and increases in marginal productivity make labor more valuable rather than less. This induces rather than reduces consumption. There are caveats of course: the benefits of induced consumption may not be distributed to all devs evenly, or may not be distributed evenly between capital and labor. But the idea that making programmers more productive reduces the need for programmers - ceteris paribus - is mistaken.
The degree to which the development market will expand as a result of increases in developer productivity ultimately depends on the elasticity of demand for development. But it's hard to say the market is anywhere close to saturated. This might come as a surprise to some in the HN bubble, but programming is so inefficient and difficult to engage right now that the default way for businesses to build software and software systems is through untrained office workers and consultants hacking together Excel formulas, no-code builders and workflow configurations in giant ERPs and CRMs.
With the exception of loss of smell and taste, these are all also associated with stress physiology. The exact mechanisms are unclear, but lifelong anxiety sufferers will be familiar with many of these. I've personally experienced all of these since I was a young teenager/child. Well before COVID was around.
I don't want to minimize long COVID, because it is very real. But we should be careful about encouraging people with generalized anxiety symptoms to over-identify as long COVID.
My observation is that it is ultimately organizational culture that frames the way people communicate and how they understand each other. Individuals can move the needle a bit depending on the size of the company and their position in it. But largely they are powerless against the prevailing culture.
In a healthy organization, your efforts to understand the rest of the business and its needs will be accepted as you intend and will benefit yourself, your team and the business. In the average toxic organization, your good intentions won't matter and your questions won't be received the way you intend. Staying upbeat and helpful in these environments might even result in you being punished.
Not defending the parent comment because it's way off base. But come on. You've never seen non-development stakeholders struggle to accept devs communicating uncertainty?
The managers who complain about their devs not thinking at the business level are usually the ones shooting them down when they do. Why are the coders questioning why we need the baby?