Well, for a C-based language that needs to keep compatibility, I'd say it's one of the best. I'd love to see a breaking change (under a pragma or something) in order to have public modifier as default, everything as expressions instead of statements and so on -- get closer to Kotlin.
I'm not against starting with a monolith and even keep evolving it if that makes sense but the problems with microservices I've seen were about poor design. They were mostly problems that could be avoided if people designed good DDD Bounded Contexts in the first place, regardless of being microservices or not.
I'm not sure about these comparisons because even with more and more people learning scripting and/or a few DSLs for their industries Software Engineering is still a career. Deeper knowledge and experience matters.
A simple set of dtos in the application layer, defined around their respective application services (use cases if you will) is ok. Required for most bounded contexts/microservices. You properly organize application and domain layers. It does not need to be verbose. The problem is when people define dtos on the http infrastructure, then similar dtos on the app layer, domain models (often with all attributes being public and behavior scattered elsewhere), then dtos for database schemas... AutoMapper looks useful in these scenarios, but it's the wrong solution for poor design.
While manual handling is required when you have proper domain models with controlled creation and change operations, these tools can be useful for other matters.
Most of the time I don't need automatic mappers, but it's nice to have good, fast tools available.
When I'm building something in a more domain-driven approach, which I usually strive for, tools for domain model<->dto mapping (assuming the separation between application and domain layers) does not make much sense. Because even when I have a domain model/dto pair with almost the same attributes I will be creating the model via a well named factory method in the domain layer, with notification style validation. And for changes, even for HTTP PUT, specially for HTTP PATCH, I'll be updating a subset of the attributes and for that I'll be using proper entity methods with, again, notification style validation. On both cases manual handling is the way to go.
If you're mapping lots of open fields to your domain models... it's not domain driven. Might be a choice, but should be conscious.
And if a) automatic mapping makes sense for a subset of the application, be it for api dtos or internal matters (you might be dealing with dtos internally for some integrations), and b) we'll really will have a one liner (including a one liner config) instead of mapping N attributes in multiple situations, ok, but I'll consider to define some sort of simpler Mapper interface and put the tool behind it without leaking its details for application and domain layers.
You can compare yourself to others to some extent as part of a [life long] learning process but make it productive: don't go too far and extract a few key points that are viable for your own improvement at this point in time and apply them. Do it again. You have lots of time at 23. You don't have to start coding at age five to be a descent software engineer, but it will take a few years, possibly a decade. Who knows, maybe the next Carmack started later too.
You can build a Ryzen or even a fairly powerful Xeon/x99 build in Brazil purchasing key parts (some used) from trusted sellers on AliExpress. I've done both. Not exactly the cheapest parts in my case, but I can say that I saved a good amount of money while building desktop hardware that exceeds my laptop to work on software development with modern IDEs, containers, VMs, being able to create useful and interesting test environments/scenarios for backend development. Anything less than that would cost me productivity and make me loose money.
I have been doing back-end development based on .net core/5/6 using Linux and Rider since ~2018. I had to switch to windows a few times due to corporate environment requirements. It happened again a few weeks ago. Fortunately Windows 11 + WSLg is stable and I'm running Rider inside it. Maybe I'll be running the IDE from Windows once Jetbrains release Rider's WSL support (or Jetbrains Gateway).
In São Paulo big names became remote friendly, smaller ones followed and, given the high demand for IT workers, non remote software engineering jobs became a joke. Note: Crowded and not a commute friendly city for most people.
Will be shared soon! If you registered, you'll get an email. Otherwise stay tuned to @vercel twitter. It will also be recorded and available afterward.
