If the theme song were magically, retroactively changed to Archer’s Theme, the show would automatically be considered twice as good with no other changes.

Nothing is temporary. Every script, patch, application, and duct tape MacGyver/Scotty inspired fix I’ve ever written will run for eternity….

Yeah, I do all my development in WSL2 (Ubuntu) at work every day. I use VSCode on the Windows 11 host. It’s great!

Would I prefer to use Linux natively? Sure, but I also have to support some Windows-only legacy code and a D365 environment or two, so Windows makes sense.

I’m using 1080p at 144hz. It’s great!

I think that, in many cases, “what” and “why” are very similar to each other or are closely related.

I’ve had an experience like this on more than one occasion - I come into an established code base for the first time. I’m working on a new feature/refactor/bug fix. I am reading through a function that is relevant to me, scratching my head a bit, and thinking “I think I see what this function is doing, but why did they do it such a screwy way?” Often there are no comments to give me any clues.

In the past, I have foolishly changed the code, thinking that I knew better… But what often happens is that I soon discover why my predecessor did something that looked so weird to me. They weren’t stupid - there was a reason for it! And then I end up putting it back…

Point being, in a situation like that the “what” and the “why” are going to have a lot of overlap. So, personally, I try to write comments that highlight assumptions that won’t be obvious from reading the code, external constraints that matter but don’t actually show up in the code, and so on.

I am far from perfect at it and I probably don’t write enough comments. But when I do, I try to write comments that will be reminders to myself, or fill in gaps in context for some hypothetical new person. I try to avoid comments that literally explain the code unless it’s particularly (and unavoidably) complex.

Glory to you and your house!

“Why” comments make more sense as application complexity grows.

You also have to consider interaction of the code with other external systems - sometimes external APIs force you to write code in ways you might not otherwise and it’s good to leave a trail for others on your team (and your future self…) about what was going on there.

Whether you use Windows or Linux, the Windows key is the foundation of many useful keyboard shortcuts. You know, hold it down plus some other key.

Whatever your preferred OS, look them up! You may find a few you would like to start using.

But yeah, on my work computer which is a Windows machine, I often use it to open the start menu and start typing the name of the app I want to launch. It’s faster than clicking on an icon somewhere if your hands are already on the keyboard.

The product may have been useless, but they had some awesome art for their advertisement!

I know this may be an unpopular opinion on lemmy, which leans so heavily towards Linux and FOSS, and I’m a Linux user myself but….

I actually really like C# and .NET (the modern cross-platform version anyway).

That’s just what I was going to say - that will either be Arch or Debian…

And this is why mocks are bad…

Ah, the list of required skills on the last job posting I looked at…

Came here to upvote for the exact same reasons.

I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.

I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.

Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.

I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???

This is what I came into the comments section for…

Yeah, I was going to cheat and go with “the entire Star Trek franchise”

And… I pretty much already speak entirely in Star Trek quotes.

Yeah, ujust is pretty cool!

At work, we’re a Windows shop. So mostly Docker (desktop) via WSL2. But it depends on the project. Sometimes it’s just NodeJS in Windows itself!

At home, mostly tools like nvm and Python venvs to handle multiple projects with potentially overlapping/problematic dependencies that I want to isolate from the base system.

Either way, initial testing happens locally with Docker compose, sometimes minikube depending on the project.

With Bluefin-DX it’s a lot of the same concepts but the included tools get you there a different, and honestly easier and more convenient way. But I have learn how to use those tools!

Bluefin-DX is great! I’m still figuring out how everything works - there are a lot of tools included that are new to me, despite being a cloud-oriented developer.

It’s a very different way to use Linux, from how the OS is constructed, to the container-first nature of the default applications and intended workflow. But I’m really enjoying learning how to use it.