I see a lot of "government shouldn't interfere with the free market", but this is par for the course for Germany. After the world wars, they were in a do-or-die economic situation. The government started to heavily regulate and direct the industry that made Germany the power-house it is today. It's not perfect, but it has been working well for them so far. Enough to make them world recognized in many areas.
In my experience, there is little disagreement with how to solve a problem as with the problem being solved.
I've found that within the high performing engineers, they tend to agree quite often with the solution once they agree upon the priorities of features and the problems being prevented.
Development practices are not difficult to comply with because you make them work for you, not the other way around.
The issue that I see in software engineering is the XOR approach. Top-down vs bottom up, abstraction vs implementation. This is the wrong thinking. One of the classic books on software architecture said paraphrased "The architecture drives the implementation and the implementation drives the architecture". A classic book on software development said paraphrased "You design for the implementation you need and implement for the design you want.
It's a yin and yang. But many software engineers completely fail at this. They get stuck at implementation or design. You need both at the same time. They're trying to represent a many dimensional problem one or more dimensions lower than required. They're flat-worlders trying to describe a cube or even a tesseract. Of course there's going to be misunderstandings and mistakes. Everyone has a difference view of the cube. They're technically talking about the same thing, yet fail spectacularly when the parts don't quire align when they come together. The problem is very simple in a higher dimension.
It's like everything in programming. The 1% of the elite can use almost any methodology with great success, but the other 99% constantly fail to perform.
The problem solving aspect of programming is hard for most people. Nearly all of the high performers that I know are on the high functioning autism spectrum. They spearhead the hard technical problems, and set the stage for everyone else to tag along wit the busy work.
It takes all kinds to make a team, but we still need to recognize everyone's strengths and weaknesses.
And not every problem in programming is a technical problem. There are more issues in communication and understanding the problem being solved. Doesn't do much good to have a technically correct product that doesn't quite solve the problem.
What software engineering needs is a methodology in management to identify and properly utilize everyone to their unique abilities.
Like everything in programming, the cultural part is more difficult than the technical part. I've seen more than one a fellow coworker comment all my tests. If you don't create the correct culture, and there isn't management buy in, it won't work.
Lots of talk about false positives. As a human, when dealing with fuzzy logic, I like to focus on recognizing when something is wrong to reduce false positives.
Maybe Google should put more effort in training AIs to recognize when they don't know instead of shoehorning an answer.
An analogy is I would expect a non-stupid human who has never seen a screw before, but trained to work with hammering nails to quickly recognize something is wrong the first time they're presented with a screw and not attempt to hammer it flush.
100% "The trick is to not come off combative or argumentative". But I've never had to worry about "Tricking people into thinking something was their idea". It is always their idea, I just refine it.
I'm 15 years in and my PM puts me on special high profile cases, be it a new project or a failing one. She will literally tell the customer "We've got 'insert name' on this. He will ask a lot of questions and it may take him some time to complete, but rest assured that when he's done, it will be exactly what you need."
No pressure, right? I need to communicate very clearly about everything. If I feel there's a risk, I call it out EARLY. My PM wants to get out ahead of any issues and have all the resources that I need ready to go when I need them.
The upside of all of this is I have a "get out of jail" card. Because my PM and leadership know that it's actually done when I say it's done, they encourage me to take my time and do it right. Overtime, what's that? They know the mind fogs when someone works too much. I'll get scolded if I work too much.
Even when only working 30 hours a week, I find myself quite spent. I have no idea how people work 40-60 hours a week and still have the energy to go out and do anything.
The company I work for has an interesting setup. Marketing drives what products we need via marketing research, Product Owners(PO) represent those products and further research the problem space, Product Managers(PM) are coupled with an engineering team and the PM negotiates with the team around estimations, priorities, and planning. But ultimately the team decides what it does, but they are held accountable for delivering business value.
As a team, we can't just go all vigilante, but we can push back and have at times gone over other people's heads to make sure the proper people understood the problem. Most of the time we got what we thought was best for the customer by going over people's heads, but there's been plenty of times that a middle ground was reached.
The main thing is to not just say "we can't". Our job is to deliver solutions, not products. If there is a problem with priorities, we find an acceptable way to make things "work". Maybe that's adjusting timelines, or features, or just asking the customer how important that timeline is to them. I can't tell you how many times I've been told about "deadlines" that the customer never actually said was a deadline.
Us: Yo cust, can we slide that project 2-4 weeks?
Them: Sure. Heck, move it back 2 months if you want, but we absolutely need to start testing on our end in 3 months.
The problem with any outsourced companies is they live and die by acceptance criteria. Many times it takes longer to write out all of the criteria to the level of detail that I need than to just do it myself because natural language is horrible for such technical details and trying to explain to someone "What" and "why" is too time consuming.
It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy.
On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use.
To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".
