What would genuinely enhance productivity would be some means to co-operatively share and discuss architecture, design and implementation decisions and trade-offs in realtime while maintaining creative control over code.
For example; I'm considering where to place the code for a new feature within my application stack - should I implement it as part of the frontend application, or do I handle it in a backend service?
Multiple tradeoffs and implications fork off from this type of seemingly simple question, and they'll have performance, deployment, security, operational and organizational impacts over the course of the lifetime of the application.
Those types of questions generally bounce around in a developer's own mind -- and potentially with their team over the course of a few meetings or chats.
To be able to share questions like these with a public audience -- perhaps similar to the way that coding session interview candidates are encouraged to explain their thinking throughout -- and then to gather and debate feedback on the merits of each decision, and develop trust with each participant (based on their overall contributions, or for specific areas-of-experience) could make for a valuable platform.
As hinted previously, this could apply at architecture and design (whiteboard, conversation) levels, and at implementation-level (shared IDE screen, conversation).
Delivered correctly this could also be a useful training and educational tool; observers could learn about the tradeoffs that are made for real applications, and participants should gain a sense of achievement (and attribution; ideally in writing although also through evidence of discussion) from helping steer the course of software.
Open-minded participants would learn from the situations in which their suggestions were declined, and ineffective actors on the platform (whether asking questions or attempting to mislead discussion) would become apparent over time.
Conversely though -- it could be time-consuming and potentially incredibly distracting for architects and developers to visit and share their problem statement in this kind of environment -- letalone interact with it subsequently -- so it would likely fail unless the signal-to-noise ratio was very high and clearly added value to their project.
This would provide the community with more of an ability to maintain and improve the existing software that we all rely on to be robust, effective and secure.
For example, if a software project had decided to introduce component X at some point in the past, a platform like this could identify that (and the historical reasons for the selection) as a blocker for necessary changes to support a subset of the current user community.
That could lead to a task list for the changes required to rectify the architecture, and discussions about the subsequent tradeoffs involved in those changes - and so the process could continue, iteratively.
As part of the developer experience, everyone hits design and implementation doubts or blockages from time to time.
The key feature to provide would be an unobtrusive way for the developer to 'surface' from the obstacle -- perhaps including a link to the relevant lines of code, issue, or project -- and to raise that question with a community that subscribes to the relevant topic(s).
Ideally people viewing and responding to that question could view and gather the project's context -- easy with open source projects, for example -- to help guide and improve their responses.
So as not to give the impression I think this is a risk-free idea: I do think a platform like this could raise questions about the authorship and ownership of code.
I believe it's reasonably well-accepted in startup culture that searching for snippets of code is OK, certainly with fair attribution; but is crowd-sourcing an answer based on your personal network value OK?
(addendum: also, ethically - how would a platform like this fairly remunerate participants and ensure that they're well-informed (and retain control over?) the use of their contributions?)
The main thing I miss is to be able to, as Fred Brooks says, "throw one away". It happens too often that, contrary to the second part of Brooks saying (i.e., that "you will anyhow"), something that should be a prototype ends up as the "finished" product, causing headaches down the road due to shortcuts that were made or because whatever was learned in developing the prototype is not taken into account due to time pressure. On the other hand, I work in a small company and the customers are happy enough, just too few so it might be the case that these headaches are a reasonable price to pay.