Holy shit that’s completely wrong.

It’s for sure AI generated articles. Time to block softonic.

This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.

Pretending those don’t exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).

Replace functions replace files and rewrite modules, that’s expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment…?

This thread is a great example to why despite sharing knowledge we continually fail to write software effectively.

The person you’re arguing with just doesn’t get it. They have their own reality.

I have a weird knack for reverse engineering, and reverse engineering stuff I’ve written 7-10 years ago is even easier!

I tend to be able to find w/e snippet I’m looking for fast enough that I can’t be assed to do it right yet 😆

That’s one of the selling points, yep

To be fair Microsoft has been working on Garnet for something like 4+ years and have already adopted it internally to reduce infrastructure costs.

Which has been their MO for the last few years. Improve .Net baseline performance, build high performance tools on top of it, dog food them, and then release them under open source licenses.

Great timing that Microsoft just released a drop-in replacement that’s in order of magnitude faster: https://github.com/microsoft/garnet

Written in C# too, so it’s incredibly easy to extend and write performant functions for.

It needs to be a bit more deployable though but they only just opened the repo, so I’ll wait.

.Net 8 will work on Linux just fine. But winforms will not, it’s specifically a legacy windows-only UI framework.

You’re going to have to jump through some incredible hoops to get it to work on Linux. Which are definitely not part of your normal curriculum.

C# on non-Windows is not impossible, but it’s going to require effort infeasible for school projects like that one.

You mean winforms (The windows specific UI) on non-Windows? Otherwise this is incredibly misleading, and plain wrong.

C# in non windows is the norm, the default even, these days. I build, compile, and run, my C# applications in linux , and have been for the last 5+ years.

I go full chaos and look up where I last used it when I need a snippet…

Someone who shares their experiences gained from writing real world software, with introspection into the dynamics & struggles involved?

Your age (or mostly career progression, which is correlated) may actually be a reason you have no interest in this.

And what does it imply?

That an AI might be better at writing documentation than the average dev, who is largely inept at writing good documentation?

Understandably, as technical writing isn’t exactly a focus point or career growing thing for most devs. If it was, we would be writing much better code as well.

I’ve seen my peers work, they could use something like this. I’d welcome it.

Yessss.

C#/.Net backends are the best. The long term stability, DevX, and the “it just works” nature of all the tooling makes it a great choice. It’s also fast, which makes scaling for most applications a non-issue.

I’ve switched to postgres for DB from SQL server, have never looked back, would recommend.

.Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.

I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.

You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.

Would recommend.

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 😒)

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.

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?

Hard agree.

Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.

Not all one-liners are bad ofc, that’s not the argument I’m making. It’s about the mentality that less code is more good, where poor decisions are made on a flawed premise.