Ask HN: What big programming productivity gains you see happening in 5-10 yrs?

[0] https://visualstudio.microsoft.com/services/intellicode/

Hooray, it's just what I always wanted. A deep nested inheritance chain that not even the original implementer really knows well.

So we'll see a shift away from "developer specific boilerplate" in the same way libraries have abstracted a lot of basic setup boilerplate.

You'll say "initialize a web service with these models" and the IDE will build out the majority of the project.

To answer parent, I actually think better understanding of personality types and how manage people better will come with far better productivity.

The jungle of technology alternatives of how to solve business problems, causes a lot of unnecessary fights. It doesn't matter if you choose React, Angular or Vanilla JS. If your team is fighting each other, your team is not productive.

With this in mind, don't hire people that always agree with you, you always need someone to challenge you.

https://en.m.wikipedia.org/wiki/Constraint_Handling_Rules

If you care about the subject this much and you think that everything was better before the 80s, then why don't you link to or name some sources you value?

The industry oscillates. Each oscillation is a mirage that presents itself as a productivity gain but is in actuality an echo of the past.

Are the techniques we use today really more productive?

The OP mentions "backendless applications", and using Javascript and the browser as your platform feels like the same kind of trend.

Sure, all those layers are still there — OS, TCP/IP, raster — but we've settled on a standard simplified foundation that's good enough and that everybody implements, whether it's Safari-iOS-touchscreen-ARM-LTE or Edge-Windows-mouse-x86-Ethernet.

"Static web applications" likewise — maybe instead of your own backend you call a few SAAS's that you've configured in a GUI rather than written code for. The point is you've reduced the number of layers you have to maintain, while still targeting a huge number of users.

In general, the trick is settling on a foundation. The web has evolved rather than being handed down from on high. What consensus will the next 5-10 years of evolution bring? Or will new platforms appear? Will Fuchsia show up and look a lot like the web?

Maybe the quality of that foundation can be measured by programmer productivity. A web standard that's consistent from device to device is a boon to the whole world. Thank you MDN for telling me what works, and where! https://developer.mozilla.org/en-US/

I would argue that this should be "the minimization of unstructured/unguided/unclear meetings".

Tbh I've seen a non-trivial number of instances where engineers have wasted their own time or someone else's by not participating in organizational meetings - either by doing redundant work or having an unclear image of priorities/blockers/help needed.

Nobody want's to waste time in meetings, and most people who call meetings can't run them well. BUT having a well planned and executed meeting (30 mins tops) can save hours if not tens of hours of work time per week.

I also believe that the "just let the devs do dev work and avoid meetings" mantra is border-line meme status and (in my opinion) stems from toxic anti-social behavior, rather than efficiency. However, I also believe that meeting time per week should have an upper-bound (something like 4-6 hours, including a 15-min daily standup) to better enforce efficiency, rather than throwing 1-hour meetings all over the place and hoping they don't use all the time.

They surfed on the "everything must be Google-scalable..." trends. They built hundreds of interconnected micro/nano-services, upgraded networking infrastructure ($$), OAuth federation, ...

What they've got? Network latency/congestion/..., security and API versionning management nightmare, unresponsive applications (tooooo manyyyy APIs calls), performance issues, circuit-breaker, caching, ... Ok you see the big picture.

Now, the returned back to a more "monolith" design. They merged many services together in one application (services that wasn't called by anything else). Everything doesn't need to be exposed as a service. This simplified security management, reduce a lot the network usage and simplified bugs investigation/fix.

The difference is that now, their new monolith designs are more modularized than before. Everything is now in a clear module (call it jar file, lib, package, ...) with a clear contract/interface. This is what I like to call "intra-services" : clear services/features separation minus the networking/security moving parts (and all band-aid solutions to support it like circuit-breakers, distributed caches, ...).

If one day you are the size of Google, Netflix, Facebook, Spotify, ... you will probably have the money/manpower to implement it the "Google way". Until then, KISS!

Note: English is not my first language.

I also like the point that the "revolution" is in one aspect, not the whole thing, and it requires changing other aspects, and is therefore much less of a net win than it appears...

SASS/etc help manage the complexity of CSS, but they don't simplify anything at all. I think there's a scope problem here: the styling and layout of an application isn't just a bunch of selectors and styles in CSS. It's the class names and structure in the code, it's the implied connections between the expected rendered layout, it's a private language of expected elements and their semantics. You can't simplify that just using CSS. We're still waiting on someone to come up with a combined approach that actually works. I personally eagerly await someone's genius idea!

I agree with this point.

> React and JSX revolutionized the act of writing HTML

I see nothing revolutionary in React.

> GraphQL revolutionized the act of connecting front end and back end

OData existed before GraphQL and still does.

Also, what about Xamarin/C#? Going from Kotlin to C# should be pretty smooth and Xamarin is supposed to be pretty usable.

I use Kotlin mutli platform. Share the scss between react(KotlinJS) and Desktop(tornado).

The underlying trend here is toward more pragmatic language design, and I think this is definitely a trend that will continue in the near future (5-10 years).