Why lemmy.zip?

The whole programming.dev site was severely broken in the last release last month, and so far hasn’t been fixed.

https://programming.dev/post/20515601

You’ve never met an average ASP.NET developer?

OP is right. For web development with JavaScript frameworks (React, Angular, etc) with Node and even Typescript, you either use vscode or you haven’t discovered vscode yet.

They’re really not. As much as I hate commercial licensing for any dev tools, if you want to talk about superior there’s nothing quite as good as Visual Studio (not code) on Windows.

It really depends on what kind of project you’re working on. For .NET projects that might be true, but for other languages such as anything involving C++ then Visual Studio lags way behind CLion, which is multiplatform to boot.

Your comment feels half-baked at best. You start to talk about “best editors” but you proceed to present your two best examples and neither has anything remotely related to editors.

CLion is undoubtedly the absolute best IDE for C++ projects, and it’s multiplatform on top of it. It’s not even a competition, specially if you’re using CMake. Using Git integration as your best and single example to refute this is extremely puzzling by how silly it is.

I just checked the status of communities such as [email protected].

They are still fucked.

I understand not everyone can be a pro or spare time from their personal life to fix problems they barely had time to create to begin with.

But the truth of the matter is that programming.dev is proving itself to be unusable.

Just to think that not so long ago Lemmy was being portrayed as a Reddit alternative.

And Gallup claims that 29% of Americans have been diagnosed with depression at one point:

That really doesn’t mean anything. The only requirement for succumbing to a depression is being alive, because all it takes is something bad happening in your life (loss lf friend, loved one, even pet, etc) to fall into a pit of despair.

Every job lately seems to have been infected by Meta/google “data driven” leadership. Its so painful and wasteful sometimes.

It’s cargo cult mentality. They look at FANGs and see them as success stories, and thus they try to be successful by mimicking visible aspects of FANG’s way of doing things, regardless of having the same context or even making sense.

I once interviewed for a big name non-FANG web-scale service provider whose recruiter bragged about their 7-round interview process. When I asked why on earth they need 7 rounds of interviews, the recruiter said they optimized the process down from the 12 rounds of interviews they did in the past, and they do it because that’s what FANGs do. Except FANGs do typically 4, with the last being an on-site.

But they did 7, because FANGs. Disregard “why”.

In the 2010s, the mindset at tech giants seemed to be that they had to hire the best developers and do everything they could to keep them.

Not really. The mindset was actually to hire skilled developers just to dry up the market, so that their competitors would not have skilled labour to develop their own competing products and services.

Then the economy started to take a turn for the worse, and these same companies noted that not only they could not afford blocking their competitors from hiring people but also neither did their competitors. Twice the reasons to shed headcount.

It was not a coincidence that we saw all FANGs shed people at around the same time.

It looks like many communities are still down following the last update.

Does anyone have any update on this issue? I’d love to continue using Lemmy but I won’t be able to do so if it’s unusable.

(…) rust, since js is much higher level. you should be comparing it with c, c++, zig, maybe nim, etc

Obvious troll.

I develop professionally in C and C++. No they aren’t. At all. C and C++ are so loaded with footguns it’s a surprise people can get anything done in them without triggering UB.

The way you parrot undefined behavior is a telltale sign you do not work with either C or C++. If you had any cursory first-hand professional experience with either one of those languages, you’d understand what UB is, why writing your code by laying unfounded expectations on UB is actually either a bug or design error on your behalf, you’d know that for a decade or so there are tooling that throws warnings and errors if you inadvertently use it, and above all UB only means frameworks are ultimately responsible to specify the behavior that is left purposely undefined.

If your primary exposure to programming is only typescript or JavaScript maybe you shouldn’t be jumping straight into something like rust.

That completely contradicts any claim that Rust is user-friendly and provides a decent user experience.

Probably was closed

What do you mean “probably was closed”?

A comment on the YouTube video makes a good point that we already have a better word for the concept of dealing with multiple things at once: multitasking.

I don’t think that’s a good comment at all. In fact, it ignores fundamental traits that separate both concepts. For example, the concept of multitasking is tied to single-threaded task switching whereas concurrency has a much broader meaning, which covers multi threaded and multiprocess execution of many tasks that may or may not yield or be assigned to different cores, processors, or even nodes.

Meaning, concurrency has a much broader meaning that goes well beyond “doing many things at once”. Such as parallelism and asynchronous programming.

Do we really need a video about this in 2024? Shouldn’t this be already a core part of our education as software engineers?

I’m not sure what point you tried to make.

Even if you believe some concept should be a core part of the education of every single software engineer who ever lived, I’m yet to meet a single engineer who had an encyclopedic knowledge of each and every single topic covered as a core part of their education. In fact, every single engineer I ever met only retained a small subset of their whole curriculum.

So exactly what is your expectation?

You do actually understand that languages that aren’t JavaScript don’t have built in async runtimes and they need to be provided by a library, right?

How do you explain C#?

good: Add foo interface.

Another commit style is summarizing what a commit does. In this case it would be someting like:

Adds foo interface.

I think this style is more in line with auditing code.

Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?

Documentation in software projecte, more often than not, is a huge waste of time and resources.

If you expect your docs to go too much into detail, they will quickly become obsolete and dissociated from the actual project. You will need to waste a lot of work keeping them in sync with the project, with little to no benefit at all.

If you expect your docs to stick with high-level descriptions and overviews, they quickly lose relevance and become useless after you onboard to a project.

If you expect your docs to document usecases, you’re doing it wrong. That’s the job of automated test suites.

The hard truth is that the only people who think they benefit from documentation are junior devs just starting out their career. Their need for docs is a proxy for the challenges they face reading the source code and understanding how the technology is being used and how things work and are expected to work. Once they go through onboarding, documentation quickly vanishes from their concerns.

Nowadays software is self-documenting with combination of three tools: the software projects themselves, version control systems, and ticketing systems. A PR shows you what code changes were involved in implementing a feature/fixing a bug, the commit logs touching some component tells you how that component can and does change, and ticketing shows you the motivation and the context for some changes. Automated test suites track the conditions the software must meet and which the development team feels must be ensured in order for the software to work. The higher you are in the testing pyramid, the closer you are to document usecases.

If you care about improving your team’s ability to document their work, you focus on ticketing, commit etiquette, automated tests, and writing clean code.

Custom methods won’t have the benefit of being dealt with as if they shared specific semantics, such as being treated as safe methods or idempotent, but ultimately that’s just an expected trait that anyone can work with.

In the end, specifying a new standard HTTP method like QUERY extends some very specific assurances regarding semantics, such as whether frameworks should enforce CRSF tokens based on whether a QUERY has the semantics of a safe method or not.