I don't practice TDD often but I've found that TDD can be particularly useful in rare cases when there is a long feedback loop for manually testing the logic I'm working on. In these situations, TDD is perfect for quickly validating a code change.

I also don't practice TDD directly, but I think trying to for a while made me a better developer. It gave me a better feeling for what a "unit" is, how to structure things etc that I feel is applicable even if not doing TDD.

> Amy Edmondson of Harvard, the leading researcher in psychological safety, defines it as the belief that you won't be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It encourages intelligent risk-taking by reducing interpersonal anxiety.

I've found that many tech workplaces seem to favor _always_ being complimentary over "psychological safety" per the definition above.

For example, there have been too many situations to count where folks don't feel safe enough to speak up if another coworker produces sub-par work.

Toxic positivity seems to destroy psychological safety.

I think this becomes a balance of peers. The psychological safety of one, may not necessarily be the psychological safety of another. Does the individual who wishes to speak up berate the underperforming co-worker for underperforming?

How can we get the new co-worker to start performing adequately? They are a member of the team, and unless there's some business motivation to fire or reassign them, they will remain a member of the team. I think the solution is to invest velocity to bring the co-worker up to the teams overall performance level.

That being said I do not condone being tolerant of intolerable performance, but I think that teams that consistently show grace and respect to each other will often yield the best results.

I suppose offering constructive criticism rather than beratement (is that even a word?) does require some minimum level or maturity. As does acknowledging the difference from the receiving end.

It's kind of the same discipline needed when pair programming and not ending up in a teacher/student dynamic. Words and actions need to delibrate and weighed, and the intent needs to be that the code base is above all else's ego

It's hard and scary to give critical feedback at first. You also don't want to damage relationships, especially when you're counting on peer feedback to eventually substantiate your own promotion.

All that said, if you put in the effort to learn and practice giving well-formed, critical feedback, I can almost guarantee the person on the receiving end will deeply appreciate it. Even if it's hard for them to hear, they'll know how it was hard for you to give, too, and most likely they will be grateful to you for it.

Next time, take that risk, and you will be glad you did.

As a musician I know a thing or two about group dynamics, especially given the fact that there is no objective best way to do music.

You are correct in that baseless positivity and silence can kill discourse, especially since this typically results in one member involuntarily abusing that freedom of criticism, e.g. by forcing things on others, doing the bare minimum etc. This can make others slowly build up resentment or them working against that person on purpose.

The problem is now, that the polar opposite (brutal honesty) will most of the time result in a similar disfunctional team, as negative feedback without trust will lead to a discourse where thebmain topic is no longer important (e.g. the music), but has become a battleground people use to carry out personal grievances. This can be often puzzling to nerds, since the criticism was just about the topic! Ehy does it suddenly become political when what I said seemed to me just to be the truth? The reason is of course that the best criticism goes to waste if you spell it out in a way and within a context within it cannot be taken to heart.

Let me give you an example: You are playing in a band and there is a new inexperienced singer who always sings out of tune in a specific spot. Now the singer is someone you chose to sing for you and you're still happy with them, if they just could not do that damn thing. Now the worst thing you could do is chew them out in front of everyone, even worse when there are outside people. This is because they are not secure in their position within the group (and to be real for a moment: some people will never be).

The better option is to show them trust and give them a way to improve, e.g. by talking to them 1:1, first explaining how you constantly made the same mistake yourself when you had less experience (or a similar anecdote that makes them understand that you are not stomping on them just because) and then you explain where you feel they could be better (note how this sounds less confrontational than "explain why they are wrong") and then even give them a practical waybout (e.g. a contact for singing lessons etc).

You are telling them the same thing, but without them having to "keep their face" in front of the group.

Later, when trust is there you can tell them that this part was shit, just like you would with your bestie, but not before

Unconditional positivity destroys moral, but I think the effect on psychological safety is more nuanced.

Your example is certainly a lack of psychological safety, but only you can speak to the causes of that.

A common reason would be a lack of accountability, which led to unconditional positivity as a veneer over the lack of constructive feedback.

You could just speak up to their manager?

Just today I was practicing how to tell my boss that one of the company's biggest problems is that failure and incompetence have no consequences. Great on recognising good work; atrocious at seeing bad.

I'm not asking for us to fire people; I'd like to see the consequence that people are guided and helped to be better at their jobs, and the company stops making the same errors over and over.

This general method has worked well for me, too.

Keep things as simple as possible for as long as possible, identify abstractions later rather than sooner, build the system knowing it will change and optimize for as little friction as possible when that change inevitably happens.

> Whatever the explanation, the continuing rollback of remote work options at larger employers creates a rare opportunity for startups and smaller employers to recruit employees who have sought-after skills.

We could be looking at a shift in talent from larger organizations joining smaller projects.

Wondering what the pros/cons are if this happens. I could see this putting more strain on entry-level folks getting a foot in the door of remote companies. But I could also see this being a net positive outcome for innovation.