douglasg14b

Nevermind PC games, think about how this would impact mobile games. Where you get TONS of transient installs, and very few consistent players.

You could actually go into debt by using unity, and accidentally being successful if you aren't abusively monitizing your game.

Rider is great, it's 100% worth the money.

Switched over to it this year from VS, it's so good in comparison. There's some things that aren't as nice (the CPU/memory graphs in VS are actually nice and handy). But overall, an upgrade.

VS Code honestly kind of sucks for it, there's just so many small things missing or lacking.

Check out Rider, I was honestly surprised and switched over to it after 8 years of visual studio.

Yeah but the ecosystem drags it about as far down as you can go.

Backend development for large applications relies on stability, the JS ecosystem has anything except stability.This is okay for FE development where you naturally have a lot of churn.

It's a reasonable expectation that a backend built today should be maintenance free and stable over the next 5-10 years if no more features or bugfixes are required. And is buildable, as is, anywhere in that timeframe with minimal or zero additional work.

Additionally, strong backends in the same ecosystem are similar, they use similar technologies, similar configs, similar patterns, and similar conventions. This is not the case for JS/TS backends, there is incredible churn that hurts their long term stability and the low-maintenance requirements of strong enterprise, and even more importantly small businesses backends.

Mature ecosystems provide this by default this is why C#/Java is so popular for these long-standing, massive, enterprise systems. Because they are stable, they have well established conventions, and are consistent across codebases and enterprises.

This is a perspective most devs in the ecosystem lack, given that half of all developers have < 5 years of experience and the vast majority of that is weighted into the JS ecosystem. It takes working with systems written in python, TS, JS, C#, Java....etc to gain the critical insight necessary to evaluate what is actually important in backend development.

Edit: to be clear this isn't just shitting on JavaScript because that's what people do, I work with it everyday, TS is by far my favorite language. 2/3 of my career is with JS/TS. This is recognizing actual problems that are not singularly solvable with the ecosystem that pulls down its liability for backend development. There are languages and ecosystems are much better for your back end it's not that scary to learn a new language (many of my co-workers would disagree it's not scary 😒)

If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.

Your frontend will always churn, that's the nature of the job.

Libraries and frameworks specifically based around their stability, longevity, and level of support. The standard library plays a huge part in this as well.

Fantastic 1st party libraries > 3rd party libraries.

If devs are able to jump from project to project and the structure, constructs, operation, and style are largely the same as as foundation that facilities a high level of productivity. Stable 1st party frameworks also promote long term project stability and portability.

Not to start a holy war, this is simply a boring truth, .Net vs the JS ecosystem is a great example of contrasting framework & library stability and standardization.

It's not game changing because someone else tried to do this and failed

Kind of a weird point to try and make no?

I think you can have a well tended garden without giving up creativity.

You're not sacrificing creativity by practicing structures, considerations, and methodologies that maintain or improve the developer experience with whatever creative endeavor you're on.

The structure of your garden doesn't prevent you from playing around with new plants, it just outlines a set of patterns and expectations known to drive better outcomes.

I'm not saying that your extension of the analogy is bad I'm just disagreeing with some of the premise.

Pretty much.

For instance focusing on PR size. PR size may be a side effect of the maturity of the product, the type of work being performed, the complexity or lack thereof of the real world space their problems touch, and in the methodologies habits and practices of the team.

Just looking at PR size or really any other single dimensional KPI lead you to lose the nuance that was driving the productivity in the first place.

Honestly in my experience high productivity comes from a high level of unity in how the team thinks, approaches problems, and how diligent they are about their decisions. And isn't necessarily something that's strictly learned, it can be about getting the right people together.

That's not a licence thing, it's a privacy & security thing. Whos APIs are they using? What are their agreements with them? What leaks, what doesn't? Where is our code & context being sent to....etc

There is a lot more there that should be announced with it. Otherwise it's a hard no from security focused orgs unless they have this posted, in detail, somewhere, and it's favorable.

Edit: Looks like they just post who the providers are, and it's OpenAI. So that's gonna be a no unless we can bring our own APIs, since we have Azure GPT-3.5 & 4 access that meets opsec standards.

This is the kinda stuff I expect to find in this kind of community! ADRs are a good topic that can help teams act more mature.

And less general career questions and low-level "what technology should I learn" 🤔

How difficult would you expect it to be to go back and produce ADRs for significant decisions in the past that resulted in the current architecture and structure of a small-medium sized project?