Live data from Hacker News

Anxiety in product development

andreschweighofer.com

81–90 of 162 posts

Re: Anxiety in product development

#81

Earlier quoted context omitted.

I also appreciate this quote, because it sets up a mature way of looking at things, categorising, and dealing with them. However, I'm less of a fan of the opening words; it's not so much that this should be magically granted on to us with a wishing wand, it's something we need to consciously work on, from within. Somehow that slogging, gritty aspect is less represented.

That is not what praying is about. A healthy prayer is a form of meditation, like "meditate on how you want your future to look like". It is a reconnection with the higher self. It is already an attempt to access something from within. It is a technique to understand thing about oneself, to build up internal structure and organize inner spiritual work. But if you base your conception of prayer on a sketch from Monty…

Whether it's intentional or not, saying something like, "That is not what praying is about," is inviting an ecumenical squabble.

Prayer's about a lot of things to a lot of people. Regardless of whether you think a way that other people do it is correct or not, it still exists and is a thing. And offering strangers uninvited, prescriptive advice on how a religious practice should be done is a form of proselytization.

I think, in this case, it's more useful to recognize and observe the context. For example, I am inclined to agree that the "God grant me the..." at the start of that particular prayer is typically understood, at least in the community where I grew up, as more of an idiom than an actual request of God. Very much like how neutronicus put it in a sibling comment. Even atheists will use it that way without any sense of dissonance. But there are also plenty of Christians who understand God as being a lot more hands-on about things, and that would support a different understanding of the prayer's connotations, which is every bit as valid.

Re: Anxiety in product development

#82
post #59
post #34

I've spent around 34 years writing code so far. My last project was an online order system for a lunch restaurant. To get an idea what kind of problems they're dealing with, I started by working two weeks in the restaurant. To my surprise I found that I actually enjoy delivering food more than writing code. As long as the customers get the food they ordered delivered in time, everyone is happy. And once I'm done, I'm…

I get this entirely. And for me, this is driven by broken feedback loops in software. Some years back, I started a company with an excellent product manager, one very focused on actual user impact. One of the first things we did is build a tiny, cheap usability lab; every Tuesday we'd have 4 users in to try things out. We rigged it so engineers could watch the sessions remotely, and for the sessions we didn't watch,…

Tight feedback loops that include everyone from the customer through to developers have been the key to success on every successful product I’ve been a part of.

It’s been difficult for me to reconcile these feedback loops and whole-team involvement with the current online push for asynchronous workflows. In my experience, the developers who want to isolate themselves at home or in their office, pull tickets out of a queue and submit a PR at their leisure were the least likely to succeed at improving the product. The developers who never hesitated to jump into a discussion or meeting with the rest of the team or get involved with the product planning sessions were the ones who moved the product forward the most.

Don’t get me wrong: There’s a time and place for isolated, heads-down work. Frivolous meetings and endless planning sessions must be minimized in favor of action. However, the current online mentality in favor of asynchronous work, minimal real-time in-person interaction, and strict “not my job” separation of developer/product manager roles is swinging the pendulum too far in the other direction, IMO. Everyone, from developers to customers, tends to be happier when they’re all included and active in the decision making processes.

Re: Anxiety in product development

#83
I live by this. Anxiety fuels increased work speeds. Without unnecessary anxiety I wouldn't have gotten anything done.

Mixed with weed driven development it seems to get positive results but awful for meetings.

Re: Anxiety in product development

#84

Earlier quoted context omitted.

I also appreciate this quote, because it sets up a mature way of looking at things, categorising, and dealing with them. However, I'm less of a fan of the opening words; it's not so much that this should be magically granted on to us with a wishing wand, it's something we need to consciously work on, from within. Somehow that slogging, gritty aspect is less represented.

That is not what praying is about. A healthy prayer is a form of meditation, like "meditate on how you want your future to look like". It is a reconnection with the higher self. It is already an attempt to access something from within. It is a technique to understand thing about oneself, to build up internal structure and organize inner spiritual work. But if you base your conception of prayer on a sketch from Monty…

A prayer is not a meditation. A prayer is a conversation. Meditation is either focusing on something or nothing. A conversation with your higher self is probably more like a prayer.

Re: Anxiety in product development

#85
post #83

I live by this. Anxiety fuels increased work speeds. Without unnecessary anxiety I wouldn't have gotten anything done. Mixed with weed driven development it seems to get positive results but awful for meetings.

The article is talking more about making product design decisions that are fueled by anxiety. While it's not directly stated, it's clear from the examples that the author is particularly concerned about the phenomenon slowing you down by causing you to waste effort on building features that you don't need.

Re: Anxiety in product development

#86

I think the serenity prayer, sans unnecessary theological content, is relevant here. Grant me the serenity to accept the things I cannot change, the courage to change the ones I can, and the wisdom to know the difference. For a lot of software products, there is no winning in the long run. You've got good product-market fit and customer loyalty, but your code base is a huge mess and the hard technical problems are so…

I find that emotional compartmentalization is a critical skill. A couple years ago, I faced a very tough time in my life. My business was collapsing, my family's finances were in jeopardy, and there was a serious health issue going on. The emotional stress was incapacitating. I couldn't sleep, let alone focus enough to fix my problems. It was the downward spiral nightmare scenario. If I didn't have dependents (wife +…

This is a really wonderful way to reframe your perspective.

Re: Anxiety in product development

#87
Yes, but what leads to anxiety? Toxic team dynamics. Google did a study and found the number one predictor of strong teams was a feeling of "psychological safety."

> Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety — a group culture that the Harvard Business School professor Amy Edmondson defines as a ‘‘shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’ Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,’’ Edmondson wrote in a study published in 1999. ‘‘It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

https://www.nytimes.com/2016/02/28/magazine/what-google-lear...

My takeaway is you need to be nice, be respectful, and fire toxic people even if they do jump through all the right hoops.

Re: Anxiety in product development

#88

While I agree with this framing of the problem, it feels like another expression of dysfunction in development increasing as direct interaction with clients and users decreases.

One good "tell" is when the organization requires more and more metrics, tracking, analysis and "data-driven" solutions into user behaviors. Not that these things are necessarily bad in of themselves (assuming user consent) but sometimes it feels like an indicator that the organization has grown so large or added so many layers the management no longer have a gut instinct about their users' needs and so they increasingly rely on the numbers.

Re: Anxiety in product development

#89

I've had a few engineers who struggled with the issues mentioned at the beginning of the article. They were skilled engineers who typically knew the right thing to do, but felt they needed permission or approval to do the things. And the solution I took was to gently encourage them, but also let them be just a little bit uncomfortable. They need a safe environment they can fail in with no repercussion, but also need…

Well, you're probably training them to be autonomous just like I'm training my dogs to use the dog door.

They're still uncomfortable doing so because they're used to me letting them out, but every so often I let them do their own thing and they eventually find their way out.

Soon it will become habit and they won't depend on me so much anymore.

Re: Anxiety in product development

#90
post #83

I live by this. Anxiety fuels increased work speeds. Without unnecessary anxiety I wouldn't have gotten anything done. Mixed with weed driven development it seems to get positive results but awful for meetings.

The key for productivity is finding the right amount of anxiety. Just a little so you're not comfortable sitting around, but not so much that it's crippling.

Minor amounts of anxiety when properly channeled isn't a bad thing -- maybe that's just another word for "motivation."

Post reply on HN