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 solved by third-party libraries. Your tech is a liability and eventually someone with better tech will be smart enough to study your customers, or the students who will eventually replace your inevitably-retiring customers on the front lines and push adoption going forward.
And this is okay. The advantage corporations have over government institutions is that they can be created and destroyed with much less friction.
If you're lucky, your growth curve looks like double-sigmoid table-top. Probably it looks like an asymmetric Gaussian. What it doesn't look like is an exponential. Understand where your product is in its life-cycle, and maximize ROI.
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 + 3 kids), I might have withdrawn into depression. Instead I was forced to fix my emotional state...
I constructed a personal prayer...
I am the man in the dark room.
In here, I am my loves, my principles, and my ideas.
Who I am cannot be changed by circumstances outside this room,
My loves are my legs which carry me to life outside this room.
My principles are my shield from the burdens the world assaults me with.
My ideas are the sword with which I shape my life.
When I return to myself in this room, the world remains outside, and I evolve to be better prepared tomorrow.
I found that even just stopping to say "I am the man in the dark room" was often enough remind myself that I wasn't defined by my circumstances.
To sleep, I found I could play the audio from old familiar TV shows to drown out the worries to fall (and stay) asleep - it was a surprising turn-around.
These two things changed my life. Hope this helps someone else.
“If there is no solution to the problem then don't waste time worrying about it. If there is a solution to the problem then don't waste time worrying about it.”
-- The Dalai Lama
I've spent a lot of my career working to correct projects that have been in a terrible state and had the privilege to mentor and help pull people out of bad situations.
One of the big things I try to do is to get people to think about what they care about and how much they care. Good people do a lot of harm to themselves by caring about the wrong things: they want to be the hero in their story, but forget that six months from now nobody will remember the sacrifices they made.
One part of this is to accept the amount of work that needs to be done is only impacted in a small way by the work you've done today. If you work 8 hours or 16 hours there's still going to be too much work tomorrow.
Working longer hours generally does nothing than hide structural issues. By encouraging teams to cut their workload from 60+ hour weeks to 40, you are forcing these issues into the open.
For those that are ever in a bad situation I'm happy to listen (my contact details are in my profile), sometimes you just need somebody with an external perspective.
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.
I've always loved that (also, sans theological content). It's good advice for anyone. It's strong statement because in one sentence it can give someone something that a lot of people may not have - self awareness in the face of anxiety.
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 done. No more lying awake at night going back and forth over some design decision and worrying about consequences from choices already made.
It's not as mentally stimulating, and I earn way less money, but I'm finding it harder and harder to find the motivation to go back to writing code.
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, he'd share key bits. It was really satisfying to see stuff getting used, what worked, what didn't.
Later, as we grew, we still kept the user tests, but added on a slick system for experiments. All of us were involved in thinking about what to test next, how we could make things better. My cofounder was definitely the best at that, but we all made contributions. We all were engaged. We all paid attention to what we were doing for users.
And it helped that despite being a startup, we were big on automated testing and pair programming. When my mom got sick, I took two weeks off and everybody was fine without me. They carried on releasing a few times a day, trusting in each other and in the safety net we had built for ourselves.
It seems to me that the average development process, which is generally about building whatever people with organizational power want, is emotionally corrosive. It wears us down, because it isn't satisfying on a human level. Which, IMHO, makes it way less efficient.
My wife does live production (AV) for big shows and concerts. It's a stressful job; for a lot of it, you're on tight timelines and have one chance to get it right. Any mistake you make is pretty clearly obvious to all of the people in the room. You plan the shit out of it ahead of time: one missing item on a truck can be a (pardon the pun) show stopper.
But like you said, at the end of the night, when the trucks are all packed up, you get to go home and never worry about that particular job ever again. If something went wrong, there might be a post-mortem the next day with lessons learned for next time, but it's over.
Some days I am thankful that I don't have her job. Some days I am jealous that she gets to walk away from it all at the end of the night.
As someone who has both coded and worked in restaurants for over a decade each, I assume that once the novelty wears off, you'll a) probably get start getting frustrated with restaurant life, overall and b) the lower income has its own long-term stressors that will grate on you.
I could be wrong though. If you end up just genuinely being a restaurant person, maybe occasionally doing some coding to supplement your income, that's fantastic. There are many things I loved about the restaurant industry.
A few years ago I picked up a dumb mechanical second job at a rental store where I worked ~20h/month after work an on weekends. I didn't need the money but I needed the feeling of truly getting something done.
When I left the store at night, every customer had been served, every piece of equipment had been cleaned, the money had been counted. I was just done. It felt great.
I solve problems every day, I never get done, every day its something new that needs fixing. Every year that passes I feel more and more that I'm just not made for this kind of work :(.
I find I like lots of "menial" work a lot better than programming. As long as it didn't wreck my body (I like doing construction labor but it'll destroy you) I'd much, much rather do that than programming. Food delivery seems like it'd be great, bonus if it's bike delivery. Clerking at a small non-chain retail business would probably be a great time (if the owners weren't dicks—always an important qualifier with these sorts of jobs).
A while back (I'd guess about 15 years ago, so suddenly I feel old), Jack Ganssle (http://www.ganssle.com/tem-subunsub.html) said he was selling his embedded tooling company, SoftAid because after doing it for so long, he had gotten tired of "pushing the same bits around."
At the time, I simply couldn't understand that. Sure, I hadn't been writing code as long as he had, but I couldn't imagine enjoying anything more than that. I absolutely loved twiddling bits and watching mechanical systems do what my code told it to.
Fast forward to now. I still really enjoy software/hardware/mechanisms/coding/design etc., but if I had to give it up tomorrow, I know I could find something I love just as much.
It's a really big world and there are a lot of sandboxes to play in.
I'm reminded of that time I got an after-work part-time job at a higher-end sports store. At first they might not have wanted to hire me for being overqualified and leaving, but they had trouble hiring anyway so there I was. They provided a full week of training on textiles and other things I found fascinating. Surprisingly, it was actually quite enjoyable. I just talked to customers about products and things and there was really no preparation or follow-up after the day is done.
The only stressful parts were getting there on time after work (because I tend to linger at work doing that one last thing) and the parking tickets because it was so limited and some spots required top-up payments (before apps). I ended up in tennis-wear because a mature person giving frank opinions of how things look on people (mostly women shopping) seems effective. Anyway I lasted longer than most of the younger hires and gave it up part way through the winter because driving/parking in that was just too much. Maybe something like that but outdoors might be a great thing to try.
As The Little Prince would say were he a coder: you are forever responsible for the code you write.
Every new system an organization takes on requires maintenance, training, etc. This takes time from the coders and is frequently not taken into account.
Literally. This is another reason why meditation is important.
Anxiety is always accompanied by patterns of muscle tension. It can be relieved by mechanical relaxation of the tissues. Relaxation is achieved by awareness, which is fostered by meditation.
A calm, clear mind flows from a calm and relaxed body.
- - - -
In my career I've observed that business is a kind of theater for people's ego trips to play out within, and the form and methods of a business reflect the karma, if you will, of the people running it. It's one of those things that sounds trivial once you type it out.
I read Keith Johnstone's "Impro" earlier in the year, and realised that almost all human group interaction is theatre. I never really understood "all the world is a stage" until now
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.’’
I wonder if the same effect holds true if a team is made up of mostly confident/brash people, or if safety-to-project-yourself can be trained and elevated independent of any other aspect of social environment.
Maybe improv classes or subsidizing employees to exhibit art or publicly perform music?
Classifying formal methods as a 'fear response' strikes me as asinine in the same way that calling safety belts a fear response would be.
If it's software where failure can cause a lot of damage, why wouldn't fear be a natural response?
Frankly, I'd be outright horrified if say the people responsible for autonomous driving weren't anxious about mistakes, since I'd either have to assume that they just didn't care or - perhaps even worse - do not realize the potential consequences of their actions.
Its a little known secret that managers deliberately promote anxiety driven development because it keeps workers at "peak productivity". A couple of the major things i've seen companies do in the past over and over again to myself and to others I worked with:
1. Ambiguous or no deadlines, frequent check ins, "crunches" when their deliberately poor planning doens't work, keeping an air of uncertainty around everything.
2. Giving the same tasks to multiple groups and deliberately pitting them against one another in a kind of unhealthy competition. Constant fear of obsoletion.
3. Little or no positive feedback, only give feedback when things are wrong. Deliberately vague about future career prospects or growth, holding the carrot out but with no promise to deliver.
The problem is that each of these are tied into natural "sources" of anxiety that are likely to happen with or without the company actively promoting it, but the company promoting it can make people work even more frantically. The problem is they don't realize people produce their "best" work when they have creative freedom from anxiety.
1. They don't keep an air of uncertainty on purpose most of the time, generally it's because a lot of businesses are uncertain and a lot of the time product/project managers don't have a good idea of what's going on!
2. Again this could be incompetence rather than cunning
3. Most great bosses and a lot of rubbish ones aren't great with positive feedback. Have you read Steve Job's biographies or Shoe Dog? Not much praise there. One guy I really respected once told me I wasn't a great programmer, but I got the job done and that was probably the nicest thing he said about anyone...I was pretty happy with that!
I agree with all of your points, but maybe not your reasoning behind them.
They're wrong though. It keeps their developers at peak churn, not peak productivity. They fill a great amount of tickets, and make a great amount of critical mistakes that become fires to put out later because everyone's focused on covering their own butts than making a great product.
Key developers leave the project for greener pastures, and business people wonder how the project failed despite the fact everyone was working so hard.
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 to practice overcoming the unknown and being willing to take on some risk.
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.
I loved the Permit A38 (too much specification and process) description.
I once came into an app project that was really bogged down. The team was good, but inexperienced, as was the management. The devs weren't doing anything. When I came on they said they told me there were no specs for what they should work on. I found a folder with several folders with ten, twelve page documents for individual features for the app. They would include nice mock ups, documentation including back end features, analytics hooks and so forth. And we are talking features that were generally changes to a screen or a UX widget.
"Why don't we do some of these?" Answer: They needed to go through some executive review meeting. Or, they weren't really specific enough because some lazy team member could say all the edge cases weren't defined. The key was convincing the team that as capable people that if the intent was clear, and important details specified, they were smart enough as a team to figure out the rest. And they were.
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.
It's funny this came up because I was about to create this throwaway account and post an Ask HN for advice anyway.
Me and my team are in the process of delivering a new infrastructure provisioning system that will bring 9 figures worth of equipment online this year. For the most part we're on time modulo the usual bobbles that come from a year-long project this size.
My upper management regularly says We're in a new safe space and there's room to fail, we're trying to be more like Silicon Valley, etc. My new manager told me in our last 1:1 'If you don't take your application stack you're delivering and turn it into a service in the next 60 days, I'll eliminate your job by year end.'
So we're right back to Go Big or Go Home pressure that the company has always exerted on people despite lip service to the idea we've shed our bad old ways. At least it feels that way to me. Maybe I'm overreacting. Maybe I should look for another job. LOL.
One of the things about fear, is that it is not a useless reaction.
Fear isn't really an "emotion." It's a "reaction." It's a temporary state that we are designed to engage when we are in danger, and exit when the danger is past.
And it works very well. When we are scared, our adrenaline amps up, our capillaries expand, our blood pressure increases, our senses sharpen, etc. There's been a gazillion studies on the physiological manifestations of a state of fear.
Our thinking also gets affected. It becomes fairly "binary." Stand very still, or run away. Don't just stand there thinking. Make a decision. Do something. No time to evaluate. No grey areas. It's either good, or bad.
Anger is really a manifestation of fear. The reactions are quite similar.
They are both reactions that are designed to be temporary. Being in either a state of fear, or anger, for extended lengths of time, is corrosive to our health; both mental and physical.
But the really dangerous thing, is that the "binary" thinking is bad; especially in areas where we are making long-term decisions. If we need to make a decision to run, we don't look further than the next bend. That's why a squirrel runs in front of a car, escaping someone walking down the sidewalk (happened to me a couple of days ago. The squirrel was fine, because the driver saw them, and jammed on the brakes).
Many managers work on fear. They like to keep a state of anxiety going. I won't dwell on the reasons, but I feel as if it is a bad thing, for engineers, because it encourages us to take tactical shortcuts and "patch" fixes, as opposed to considered, strategic reasoning, and long-term, "holistic" fixes.
I was a manager for many years, and I feel that one of my most important jobs was to shield my team from the immense pressure that was piled onto me.
The good bit I get out of this is to provide value but in a way that isn't making you into a commodity. A way I do that is have some area of the business that I know very well that someone cannot just know with skills alone and then have some set of ownership of code that I created around this. Then repeat that in other areas to increase that value etc. You can also think of it as entrenchment...meaning if you don't know the point of what you are doing and don't have ideas on the roadmap and improvements etc., you probably are less important and can be replaced without much issue.
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.
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."
I’ve often thought that pair programming and daily stand ups work because they align with our natural social behavior. This could be fear or anxiety driven but it doesn’t have to be. Do scientists have a non-intrusive and accurate mechanism to continuously monitor the endocrine/nervous system response over hours/days? Working on a software project is often an emotional roller coaster ride.
Fear is just a source of information. The emotions we have we have because they provide information in one way or another. Much like the senses. One cannot let oneself be paralyzed by it, though. If one doesn't dare to refactor anything because of fear, something needs to happen. E.g., one needs to be able to test more effectively or something like that.
Do whatever you can to move forward. Every time you start getting anxiety, stop. If you can do it harder, while taking care of you, do it harder. If you are doing your best, but still thinks its slow, don't try to force the situation. Sometimes negative results lead to better results. Just keep trying.
As a new developer, I think I fall into this trap a lot! I always don't want to touch other people's methods or introduce bugs, so I only make tiny, tiny little changes before thoroughly testing everything. It really slows me down.
You should be slow with other people's code. I bet that if you work on something solo you'd be much faster and that is because you're intimate with the code, you know what could go wrong, where, etc..
Second, the slowness comes from the fact it takes a lot more time to read and understand code that to write it, let alone trust that it is doing what is doing correctly. If you don't introduce bugs and are very careful you won't have nightmarish surprises. Keep up.
Good! You should be slow. Slow and deliberate. Break stuff (not in production!) and watch how it breaks. Learn from your mistakes. Right now you're laying the foundation of your confidence as a developer. That confidence is built upon your failures and your successes. Have fun newbie!
[+] [-] neutronicus|5 years ago|reply
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 solved by third-party libraries. Your tech is a liability and eventually someone with better tech will be smart enough to study your customers, or the students who will eventually replace your inevitably-retiring customers on the front lines and push adoption going forward.
And this is okay. The advantage corporations have over government institutions is that they can be created and destroyed with much less friction.
If you're lucky, your growth curve looks like double-sigmoid table-top. Probably it looks like an asymmetric Gaussian. What it doesn't look like is an exponential. Understand where your product is in its life-cycle, and maximize ROI.
[+] [-] koheripbal|5 years ago|reply
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 + 3 kids), I might have withdrawn into depression. Instead I was forced to fix my emotional state...
I constructed a personal prayer...
I found that even just stopping to say "I am the man in the dark room" was often enough remind myself that I wasn't defined by my circumstances.To sleep, I found I could play the audio from old familiar TV shows to drown out the worries to fall (and stay) asleep - it was a surprising turn-around.
These two things changed my life. Hope this helps someone else.
[+] [-] gav|5 years ago|reply
I've spent a lot of my career working to correct projects that have been in a terrible state and had the privilege to mentor and help pull people out of bad situations.
One of the big things I try to do is to get people to think about what they care about and how much they care. Good people do a lot of harm to themselves by caring about the wrong things: they want to be the hero in their story, but forget that six months from now nobody will remember the sacrifices they made.
One part of this is to accept the amount of work that needs to be done is only impacted in a small way by the work you've done today. If you work 8 hours or 16 hours there's still going to be too much work tomorrow.
Working longer hours generally does nothing than hide structural issues. By encouraging teams to cut their workload from 60+ hour weeks to 40, you are forcing these issues into the open.
For those that are ever in a bad situation I'm happy to listen (my contact details are in my profile), sometimes you just need somebody with an external perspective.
[+] [-] danielbarla|5 years ago|reply
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.
[+] [-] Minor49er|5 years ago|reply
[+] [-] pastorhudson|5 years ago|reply
[+] [-] hateful|5 years ago|reply
[+] [-] kupopuffs|5 years ago|reply
Time, how brief my allotment
Fate, how small my roll to play
Self, all that can be mastered
[+] [-] codr7|5 years ago|reply
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 done. No more lying awake at night going back and forth over some design decision and worrying about consequences from choices already made.
It's not as mentally stimulating, and I earn way less money, but I'm finding it harder and harder to find the motivation to go back to writing code.
[+] [-] wpietri|5 years ago|reply
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, he'd share key bits. It was really satisfying to see stuff getting used, what worked, what didn't.
Later, as we grew, we still kept the user tests, but added on a slick system for experiments. All of us were involved in thinking about what to test next, how we could make things better. My cofounder was definitely the best at that, but we all made contributions. We all were engaged. We all paid attention to what we were doing for users.
And it helped that despite being a startup, we were big on automated testing and pair programming. When my mom got sick, I took two weeks off and everybody was fine without me. They carried on releasing a few times a day, trusting in each other and in the safety net we had built for ourselves.
It seems to me that the average development process, which is generally about building whatever people with organizational power want, is emotionally corrosive. It wears us down, because it isn't satisfying on a human level. Which, IMHO, makes it way less efficient.
[+] [-] tonyarkles|5 years ago|reply
My wife does live production (AV) for big shows and concerts. It's a stressful job; for a lot of it, you're on tight timelines and have one chance to get it right. Any mistake you make is pretty clearly obvious to all of the people in the room. You plan the shit out of it ahead of time: one missing item on a truck can be a (pardon the pun) show stopper.
But like you said, at the end of the night, when the trucks are all packed up, you get to go home and never worry about that particular job ever again. If something went wrong, there might be a post-mortem the next day with lessons learned for next time, but it's over.
Some days I am thankful that I don't have her job. Some days I am jealous that she gets to walk away from it all at the end of the night.
[+] [-] chefandy|5 years ago|reply
I could be wrong though. If you end up just genuinely being a restaurant person, maybe occasionally doing some coding to supplement your income, that's fantastic. There are many things I loved about the restaurant industry.
[+] [-] aeyes|5 years ago|reply
When I left the store at night, every customer had been served, every piece of equipment had been cleaned, the money had been counted. I was just done. It felt great.
I solve problems every day, I never get done, every day its something new that needs fixing. Every year that passes I feel more and more that I'm just not made for this kind of work :(.
[+] [-] karatestomp|5 years ago|reply
But, money and easy to find a job.
[+] [-] HeyLaughingBoy|5 years ago|reply
At the time, I simply couldn't understand that. Sure, I hadn't been writing code as long as he had, but I couldn't imagine enjoying anything more than that. I absolutely loved twiddling bits and watching mechanical systems do what my code told it to.
Fast forward to now. I still really enjoy software/hardware/mechanisms/coding/design etc., but if I had to give it up tomorrow, I know I could find something I love just as much.
It's a really big world and there are a lot of sandboxes to play in.
[+] [-] wnmurphy|5 years ago|reply
LOVE this.
[+] [-] karmakaze|5 years ago|reply
The only stressful parts were getting there on time after work (because I tend to linger at work doing that one last thing) and the parking tickets because it was so limited and some spots required top-up payments (before apps). I ended up in tennis-wear because a mature person giving frank opinions of how things look on people (mostly women shopping) seems effective. Anyway I lasted longer than most of the younger hires and gave it up part way through the winter because driving/parking in that was just too much. Maybe something like that but outdoors might be a great thing to try.
[+] [-] forinti|5 years ago|reply
Every new system an organization takes on requires maintenance, training, etc. This takes time from the coders and is frequently not taken into account.
[+] [-] carapace|5 years ago|reply
Literally. This is another reason why meditation is important.
Anxiety is always accompanied by patterns of muscle tension. It can be relieved by mechanical relaxation of the tissues. Relaxation is achieved by awareness, which is fostered by meditation.
A calm, clear mind flows from a calm and relaxed body.
- - - -
In my career I've observed that business is a kind of theater for people's ego trips to play out within, and the form and methods of a business reflect the karma, if you will, of the people running it. It's one of those things that sounds trivial once you type it out.
Anyhow, it reminds me of Conway's Law. https://en.wikipedia.org/wiki/Conway%27s_law
[+] [-] circlefavshape|5 years ago|reply
[+] [-] asdfman123|5 years ago|reply
> 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.
[+] [-] gramontblanc|5 years ago|reply
Maybe improv classes or subsidizing employees to exhibit art or publicly perform music?
[+] [-] openfuture|5 years ago|reply
I've been talking (with my friends) about how all development is 'fear driven development' for quite a while now.
Of course I don't mean just software development, but the way it manifests in software is instructive.
The different fear responses range from formal methods to FOMO but in general we latch onto something as a source of comfort.
Conway's law expanded to how you communicate with yourself.
[+] [-] ImprobableTruth|5 years ago|reply
Frankly, I'd be outright horrified if say the people responsible for autonomous driving weren't anxious about mistakes, since I'd either have to assume that they just didn't care or - perhaps even worse - do not realize the potential consequences of their actions.
[+] [-] pogorniy|5 years ago|reply
Do you have examples of fear-driven and non-fear development approaches? And what flavors of "non-fear" development are possible?
[+] [-] sjg007|5 years ago|reply
Can you please clarify?
[+] [-] nautilus12|5 years ago|reply
1. Ambiguous or no deadlines, frequent check ins, "crunches" when their deliberately poor planning doens't work, keeping an air of uncertainty around everything.
2. Giving the same tasks to multiple groups and deliberately pitting them against one another in a kind of unhealthy competition. Constant fear of obsoletion.
3. Little or no positive feedback, only give feedback when things are wrong. Deliberately vague about future career prospects or growth, holding the carrot out but with no promise to deliver.
The problem is that each of these are tied into natural "sources" of anxiety that are likely to happen with or without the company actively promoting it, but the company promoting it can make people work even more frantically. The problem is they don't realize people produce their "best" work when they have creative freedom from anxiety.
[+] [-] thorin|5 years ago|reply
2. Again this could be incompetence rather than cunning
3. Most great bosses and a lot of rubbish ones aren't great with positive feedback. Have you read Steve Job's biographies or Shoe Dog? Not much praise there. One guy I really respected once told me I wasn't a great programmer, but I got the job done and that was probably the nicest thing he said about anyone...I was pretty happy with that!
I agree with all of your points, but maybe not your reasoning behind them.
[+] [-] asdfman123|5 years ago|reply
Key developers leave the project for greener pastures, and business people wonder how the project failed despite the fact everyone was working so hard.
[+] [-] mikegioia|5 years ago|reply
[+] [-] vorpalhex|5 years ago|reply
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 to practice overcoming the unknown and being willing to take on some risk.
[+] [-] asdfman123|5 years ago|reply
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.
[+] [-] georgeecollins|5 years ago|reply
I once came into an app project that was really bogged down. The team was good, but inexperienced, as was the management. The devs weren't doing anything. When I came on they said they told me there were no specs for what they should work on. I found a folder with several folders with ten, twelve page documents for individual features for the app. They would include nice mock ups, documentation including back end features, analytics hooks and so forth. And we are talking features that were generally changes to a screen or a UX widget.
"Why don't we do some of these?" Answer: They needed to go through some executive review meeting. Or, they weren't really specific enough because some lazy team member could say all the edge cases weren't defined. The key was convincing the team that as capable people that if the intent was clear, and important details specified, they were smart enough as a team to figure out the rest. And they were.
[+] [-] jmhnilbog|5 years ago|reply
[+] [-] maximum_stress|5 years ago|reply
Me and my team are in the process of delivering a new infrastructure provisioning system that will bring 9 figures worth of equipment online this year. For the most part we're on time modulo the usual bobbles that come from a year-long project this size.
My upper management regularly says We're in a new safe space and there's room to fail, we're trying to be more like Silicon Valley, etc. My new manager told me in our last 1:1 'If you don't take your application stack you're delivering and turn it into a service in the next 60 days, I'll eliminate your job by year end.'
So we're right back to Go Big or Go Home pressure that the company has always exerted on people despite lip service to the idea we've shed our bad old ways. At least it feels that way to me. Maybe I'm overreacting. Maybe I should look for another job. LOL.
[+] [-] ChrisMarshallNY|5 years ago|reply
Fear isn't really an "emotion." It's a "reaction." It's a temporary state that we are designed to engage when we are in danger, and exit when the danger is past.
And it works very well. When we are scared, our adrenaline amps up, our capillaries expand, our blood pressure increases, our senses sharpen, etc. There's been a gazillion studies on the physiological manifestations of a state of fear.
Our thinking also gets affected. It becomes fairly "binary." Stand very still, or run away. Don't just stand there thinking. Make a decision. Do something. No time to evaluate. No grey areas. It's either good, or bad.
Anger is really a manifestation of fear. The reactions are quite similar.
They are both reactions that are designed to be temporary. Being in either a state of fear, or anger, for extended lengths of time, is corrosive to our health; both mental and physical.
But the really dangerous thing, is that the "binary" thinking is bad; especially in areas where we are making long-term decisions. If we need to make a decision to run, we don't look further than the next bend. That's why a squirrel runs in front of a car, escaping someone walking down the sidewalk (happened to me a couple of days ago. The squirrel was fine, because the driver saw them, and jammed on the brakes).
Many managers work on fear. They like to keep a state of anxiety going. I won't dwell on the reasons, but I feel as if it is a bad thing, for engineers, because it encourages us to take tactical shortcuts and "patch" fixes, as opposed to considered, strategic reasoning, and long-term, "holistic" fixes.
I was a manager for many years, and I feel that one of my most important jobs was to shield my team from the immense pressure that was piled onto me.
[+] [-] sebringj|5 years ago|reply
[+] [-] MattGaiser|5 years ago|reply
[+] [-] david_draco|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] wolco|5 years ago|reply
Mixed with weed driven development it seems to get positive results but awful for meetings.
[+] [-] mumblemumble|5 years ago|reply
[+] [-] asdfman123|5 years ago|reply
Minor amounts of anxiety when properly channeled isn't a bad thing -- maybe that's just another word for "motivation."
[+] [-] sradman|5 years ago|reply
[+] [-] cjfd|5 years ago|reply
[+] [-] hammock|5 years ago|reply
[+] [-] alexheikel|5 years ago|reply
[+] [-] gtm1260|5 years ago|reply
[+] [-] onemoresoop|5 years ago|reply
Second, the slowness comes from the fact it takes a lot more time to read and understand code that to write it, let alone trust that it is doing what is doing correctly. If you don't introduce bugs and are very careful you won't have nightmarish surprises. Keep up.
[+] [-] chooseaname|5 years ago|reply