douglasg14b

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.

That single line of code may be using a slow abstraction, doesn't cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it's meant to solve.

More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages... Performance optimizations especially.

A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.

More lines of code = slower

It doesn't. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable...

each line of code is a millisecond round their neck

My man here thinking performance optimizations= fewer lines of code 😂😂😂

Yep, saw it one day before I had to have surgery, went into it and it gave me a couple day timer before it will vanish. So it timed out and I wasn't able to play around with it.

Oh definitely. I have some gripes with C# as a language that I wish for better. But it's extremely flexible.

Good up front understanding of your problem space goes a long way. You don't need to waterfall it, but you should at the minimum have a high level view of the problem and your proposed solution(s). With considerations of where the team/domain might go wrong, where we expect to find pain points, and what sort of mitigations should be considered for those.

Your planning will not survive reality, and that's okay. You are already further ahead as a result of some high level consideration than you might otherwise be, and hopefully you have built your software under the assumption that you will be learning and changing as you go.

Human to human interaction is a baseline necessity for any large work for any field TBF. It's also hard failing point full of nuance, and doesn't really have a panacea as humans are the more complex parts of any system.

Software is hard, not treating it as such means devs will build complex systems because they focused too much on "simplicity". Missing the forest for the trees.

You are conflating necessary complexity vs unnecessary complexity. And assuming that all things are the later, without acknowledging that yes there are many applications that must scale, and that most non-trivial applications must deal with real world complexity. Nevermind scaling being a simple example of a complex problem, not a statement about it's necessity...

I would expect devs here to be experienced enough to understand and differentiate those two, as such assuming the worst isn't a good fit and prevents fruitful discussion.

I would suggest you reconsider the premise you are using here, you appear to be here to complain, not to share and learn.

Practice practice practice, always challenge and improve on your foundational skills. Everything else gets easier. Write code and solve problems, struggle through it in whatever way works for you. There's not really a shortcut to getting more experience than to put in the work.

It's especially important to try and do things the "right way" as a learning/growth tool. It will take longer, and you'll rewrite your code multiple times, but the next time you encounter a similar problem you suddenly know exactly what to do and the constraints around the problem.

Do this often enough and you'll find yourself having a general idea of how to solve just about any problem you come across, and how to do it elegantly.

Software has to model the real world, and the real world is complex. Not to mention that software is not a perfect abstraction, you will have to solve hard problems such as scaling.

Software complexity is unavoidable, how you reduce and control the impacts of that complexity is how you build maintainable software.

Are you sure you should be answering questions here?🤔

Well, let's start with which ones you have looked at, and why they aren't to your liking.

If you're trying to build a company then stop using Blazor, and start using react/vue...etc for your frontend and make an Asp.Net API.

If you need a web app, then use well known technology to do it. Otherwise you're just playing in the sandbox, not building something that can be built quickly, and can be easily onboarded to.

So many C# devs are scared of FE tech, learning how to use it effectively will only make your work better, and speedier.

Essentially, use boring technologies and be pragmatic.

Isn't this an entire class of problems that's avoidable by using strict DDD-style entities?

You don't have the same "purists" OOP problems, you don't have extension methods to get lost in, you don't have publicly mutable state, and you have a clear surface area for state changes. And your ORM is happy.

Purists OOP has all sorts of issues, more procedural, pragmatic, approaches can alleviate that pain. And strict entities provide the same surface area as the functional approach, without concerns over breaking ORM tracking. With the added benefits of closely guarding local state.

Opinion time.

This is less "what you can't do in OOP" and more "what you can't do if you use OOP design as dogma" 🤔. Perhaps that's an important distinction to make, depending on your viewership, but to me this feels like a solution looking for a contrived problem.