Comment by eru
2 days ago
> It is a technical solution for a people problem. It is better to guide and to mentor people in designing the right abstractions. What we should learn from this experiment is that this is the wrong approach.
Nah, it was just the wrong solution.
People problems are basically intractable in the grand scheme of things. Whenever you can turn a people problem into a technical problem, that's an opportunity for progress.
Imagine telling everyone to be a professional and being careful not to break our program when they edit the code? Sounds like a big people problem!
Instead, we give everyone their own copy to muck around with (instead of a shared folder), and we only allow changes to be integrated into the 'master copy', if they pass automated tests.
A good manager and really motivated and professional workers can help cope with people problems. But there's a limit to their ability. So the more we can offload to technological solutions, the more 'professionalism' (for lack of a better word) we can spare for other task that aren't feasible to be solved via technology, yet.
And I agree that not all technical solutions work! You need to experiment, and make judgement calls.
I agree it was the wrong solution. The problem is that Go is quite popular and lots of code has been written in a language that cannot be fixed. And that is also a people problem, because living daily with a programming language feels like a marriage.
People keep fixing the unfix-able rather than moving on. I see the same happening with Python.