I would argue that if you have this problem, it is fundamental, and your team will never be firing on all cylinders until you fix it. Admit it is not easy if the dysfunction is well set in.
Testing takes time, but we factor it into our schedule.
When new people join the team, they make more mistakes than experienced people, which can be very demoralizing for them. There are a couple of things that I find helpful for this:
1, I warn them during training that they will make a lot of mistakes, but it will get better as they get practice, and I ask them to be patient with themselves. You can only learn one thing at a time, so some of the training won't click right away.
2, I tell them that even those of us who are experienced make mistakes; that's whole reason we have this feedback process. I ask them not to shy away from pointing out issues if they notice anything in anyone else's work, even if that person is much more experienced than them.
3, I make sure they see other people's mistakes before they start making their own; once they are out of the training period, their first tasks are to check other people's work, rather than do their own work. After that, they may be tasked with fixing other people's mistakes (which also helps them understand the sorts of mistakes to watch for in their own work later). Only then do they start their own work.
I want criticism about the designs. Tell me where you think the product is junk and why. There is not one user but many users you are designing for in a single product. Each has an unique take and requirements. Features to sell it, those that write the checks, and those that use it daily must both be met.
Or vice versa, depending on what side of the fence you are on. Acknowledging incompetence seems to be taboo everywhere, managers don't want to acknowledge that managers are often incompetent, and neither do workers want to acknowledge workers are often incompetent.
And I say that as someone who thinks this forum tends to dunk on management a bit too much. My point is that workers do want to acknowledge that others workers are incompetent, and likewise for managers and their colleagues, but they are structurally and culturally disinclined to do so primarily from an information gap problem.
We have that with one of the teams internally, I don't know what the technical leadership on that team is actually doing but whatever it is, it's not working and hasn't been for a while now.
I'm talking 6+ months of code not working right that I myself could have implemented better in a single day because it's not hard. I'm talking API 1 calling into API 2, API 2 reports a problem with detailed information (per our standards) and API 1 logs it as "see API 2 logs". Then you go look at the API 2 logs and _it's not there_. I've legitimately had this experience.
multiple of our offshore development teams run _circles_ around this team. The developers are not good so they can't be successful despite the poor leadership and the leadership is not good so they can't fix the problems with the development team.
Bad programmers are an organizational failure. You cannot fix that with tools.
You can make it easier for devs to fall into a pit of success, however. But, it’s fine line between facilitating that versus foisting things on users under the guise of being “opinionated.” The reality is it is often taken to be patronizing, such as views of nextauth on storing local usernames and passwords.
I recently learned this because I was asked this precise question and basically had to drudge up all my two-quarters-ago research that was the answer to this question. My answer to their question was "yes we could do the easy thing, but..." and everything trailing the "but" is a very long string of small points that add up to something that tipped the scale (at least in my and several other folks opinions). But without that laid clearly out they thought I was just over-engineering for the sake of job security or something like that.
Letting people know why is two fold. Not only does it keep them from relearning the 1000 edge cases you discovered in the school of hard knocks, sometimes technology changes and something that was a hard limit no longer is.
This form on "collective design" usually uses a confrontational form of rhetoric, but the exercise is very much collaborative.
"Could you do the easy and obvious thing?" means the same thing, I don't see how it makes a difference.
This way proposing xyz as a solution is positive not a negative.
Ideally, if as others have suggested, you've already worked through that question and documented it, you can just refer to that documentation amd move along.
If you haven't documented it, it's a good reminder others may have the same question and answering it will either lead the to the same conclusion or other questions you did not think of.
fast forward 6 months and suddenly they have a lot of problems due to that shared library being a larger risk than they ever anticipated.
sometimes "I've seen this before" is a legitimate concern.
The example I gave above, I definitely did spent months explaining to them how the risk to a library like that grows unexpectedly over time. How it's a small risk at first but if you don't consider the use of that library over the next few years you don't see where the risk profile ends up.
What's interesting is that I had a similar conversation with a VP recently. What I told him is that sometimes people really just flat out can't see it and in that case you have to "rule by fiat" as it were and issue an edict. If you wait for compromise with someone who just can't see it you'll get nothing done, especially if nothing can ever be agreed upon.
and I say this as someone who is very particular about the battles I'll fight, I'm a fan of compromise but only if everyone in that conversation truly understands all sides of the issue or I think it ultimately doesn't matter (yak shaving).
Socializing the design is good advice.
Seeking out contrarians is not.
It costs you much more to defend particular engineering tradeoffs than it does to raise questions about them. So unless you have a good relationship with your "contrarian" and they will operate in good faith, you'll quickly end up exhausted and dispirited after the anklebiters attack.
Architecture astronauts and other armchair engineers will suck up all your energy with half-baked ideas they aren't even invested in, if you let them.
There are people who somehow manage to ruin even the simplest code reviews with their precious input that ultimately goes nowhere. Such people will absolutely destroy your spirit when you invite them to consider your something substantial. Those guys so everything in their power to get themselves into such position.
I had a boss like that once. He could literally turn everything into shit. You had a good plan for an event room, he strikes everything useful out for "minimalism" and aesthetics reasons. Then they ended up with a room that was both expensive and unusable. No wall sockets pure concrete ceiling ("to show the carrying structure"), a reverb time worse than in a church.
For him it was always looks above literally everything else, no matter if it was about architecture, furniture, tools or graphic design.
It's important to make sure that folks who are doing the work, agree upon the work. Building a bridge only works if the engineers are building a bridge, not a suspended walkway of dubious quality because they didn't like the design so some wood and rope is what you got.
Happy to see this mentioned! By involving everyone, the experienced engineers will usually ask the harder questions and test the assumption of your design and the juniors to learn and re-evaluate assumptions they have about building software. Almost a win-win for everyone.
Even though in these discussions there may be a social aspect where certain individuals are trying that much harder to find disadvantages of a proposed design (many reasons which readers are probably familiar with). However, I think this becomes a net positive to the overall engineering as everyone tries to bring their A-game to these discussions.
Anyhow, my experience has been that collectively reasoning about a design (assuming the team feels comfortable with criticism) will always get results quicker.