Cosmin Vladutu

You should change your job. If you actually think there will be in your career a project in which you will catch all the bugs with automation testing, really, you need a career change If you want to catch a bigger percentage than what you have, then you should do/change probably the following things: 1. Your mindset. Aka, test cases and what, how and why you test. Maybe even think about the "good enough" concept. 2. The limitation of your automation tools (even check if you actually use the suitable tools for your project) 3. Check your tests. Are they creating false positives? Are they deterministic? Are they data-dependent, are they maintained? 4. Use more types of testing (performance, load maybe exploratory?)

Using DI you decouple the dependencies and you can mock them. The problem is that everyone is mocking ALL the dependencies without thinking about which is actually the business logic unit that they are trying to test, and they end up testing single methods and say that those are the logic units. It's a powerful tool for unit testing, but harmful for juniors.

It's funny that no one thought about the most important question when you build a project: WHY? You first need to understand why the project was built, what the end user needed, and how the project helped him. For some kinds of projects, you might need an event or message-based architecture, on others you might need CQRS with 2 databases, on others a simple n-Tier might be enough. You can't do an audit and give any kind of feedback without understanding the problem the project is trying to solve. Of course, security, scalability, performance, documentation, the common knowledge of the team and so on are important, but first of all, you need to understand if the project is actually solving the end user's needs, and start from there.

Based on decisions that are questioned we all evolve. The people asking questions will find out how you ended up to that conclusion and learn new perspectives. Based on conflicts you evolve as a leader. Now, this doesn't mean you need to fight all the fights to win the "war". If you are constantly getting questioned, then you need to ask yourself if you actually earned their trust. Ask for feedback, and try to involve the people who are questioning your decisions in the decision-making process. Do not forget: most of the time, if they are asking questions, they care! You should ask yourself if you're on the right path if you have only people that execute in the team, and never ask any questions.

The answer is simple. I wouldn't think of hexagonal architecture at all! Probably I will end up there, but I wouldn't think about it from the start. This is no silver bullet. Stop using this as one! Close the door after you get the domain expert in a room with you, understand the domain, design it WITH him and only after that start thinking about infrastructure, connections, and all other things. I've seen so many projects, that were in reality just adapters/mappers/api gateways and almost all of them had hexagonal architecture and DDD-ish style, even if they had only anemic models. Stop using patterns just because they are cool, and start solving the user's needs, and help the business to make money, not lose them!

From my experience, the leadership style you use should be based on the team or people you lead in general, not on the year or century we live in. The way you implement each style can change a little bit, based on some factors, like AI coming around, home-office and things like that, but styles remain the same. I still consider "The Art of War" to be a very leadership book and it was written ages ago!