douglasg14b

joined 2 years ago
[–] douglasg14b@programming.dev 3 points 2 years ago* (last edited 2 years ago)

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.

[–] douglasg14b@programming.dev 3 points 2 years ago* (last edited 2 years ago) (1 children)

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.

[–] douglasg14b@programming.dev 5 points 2 years ago* (last edited 2 years ago) (1 children)

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.

[–] douglasg14b@programming.dev 7 points 2 years ago (5 children)

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?🤔

[–] douglasg14b@programming.dev 2 points 2 years ago (1 children)

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

[–] douglasg14b@programming.dev 2 points 2 years ago* (last edited 2 years ago) (1 children)

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.

[–] douglasg14b@programming.dev 8 points 2 years ago* (last edited 2 years ago) (2 children)

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.

[–] douglasg14b@programming.dev 5 points 2 years ago* (last edited 2 years ago)

Kind of sucks that the source is locked away...

Would be a lot more convenient to read it when I don't have the whereabouts to watch a video about it(env, data...etc).

Edit: Finally was able to get the whole thing to load, commented on my thoughts.

[–] douglasg14b@programming.dev 2 points 2 years ago* (last edited 2 years ago)

Well I'm evil, so System.Text.Json.

Maybe after the whole world dunks on it feature champions devs will change their asinine stances on keeping it terrible...

[–] douglasg14b@programming.dev 4 points 2 years ago* (last edited 2 years ago)

If it helps, I've been a visual studio user for the last 9 years.

In order to better support non-C# devs onboarding to C# (who where mostly on Mac, and vs for Mac is terrible) I switched to Rider 6 months ago, so we are using the same IDE and I can help them out.

Holy crap, it's good. There are a few things that aren't quite as nice (no more intellicode, stack traces are kinda shitty), but after fixing some garbage default settings, it's turned into a pretty good IDE.

The visual studio debugger is still better though.

[–] douglasg14b@programming.dev 2 points 2 years ago (1 children)

A codebase is different than the language itself enabling many ways to do the thing.

You may not think it's likely to cause problems, but have you actually onboarded non c# devs onto new C# projects?

I have been for the last 6 months and let me tell you it really opened my eyes to new problems. One of those is that there are many ways to do the same thing, which has been a consistent pain point for non-c# devs, and has been hurting adoption and general sentiment.

Honestly I didn't think much of it till now, and didn't think it would be that big of a deal. Turns out it is.

view more: ‹ prev next ›