Ask HN: What would make your development 10 times or 100 times more productive? - mlejva
======
jka
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.

~~~
135792468
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.

~~~
jka
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.

------
haakonhr
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.

------
sethammons
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.

------
zpatel
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.

------
noir_lord
Clear instructions from above.

------
Adiguy
Speed or meth probablly

------
sgeorge96
if i wasn't dumb as a rock.

