Not a language, not a framework, not a design pattern; we have more than enough of these already, and they cover all of the use cases -- they've become fashions and a means for coralling developers and creating markets rather than actually delivering value.
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.
As an additional thought: it would be useful if such a service could be applied retroactively to historical software concerns as well.
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.
I agree with this. My partner is a dev and I am not, he needs some people like this to have those conversations with but feels the standard communities/slacks etc have too much noise. I don’t know what the answer is, but you’re not alone.
Thanks. StackOverflow has aspects of a solution (asking questions and tracking reputation), GitHub has aspects of it (pull requests and in-context discussion), but they just don't quite seem to fit somehow.
Without wanting to prescribe solutions, I do think that elements reminiscent of StackOverflow, Twitch and GitHub could be relevant.
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?)
One thing I struggle with is, like jka says, to communicate trade-offs and to gather requirements. In other words, solving the underlying problem; not the symptom without causing bigger problems in the future.
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.
Get a consensus from Engineers if they need another person (any role - Engineer, PM, Architect, Mgr) added to the team. Do not open the position until all Engineers vote a Yes.
Better test environments with "replay" of production traffic that I can easily hack on locally. Right now, we have some very robust tests. But getting all the containers into the right state can sometimes be a pain. Every now and then, you nuke the entire setup from orbit and re-spin everything back up. But this is still all artificial data in the tests. We spend too much time making a robust test environment when, if we could just say "make this like prod but with my binary in place of this other one and let me replay traffic to simulate a bug or load or whatnot" and to allow this to have a very, very tight loop. In the order of seconds between saving a change (maybe an added log line) and hitting the change with simulated traffic.
13 comments
[ 3.7 ms ] story [ 39.6 ms ] threadWhat 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.