WWicket

A little confused what you are asking, but if you are saying you want to get rid of the colon ( : ) from the prompt message, you cannot control the presentation of Read-Host, but you could use a different input method, like $ReadUserInput=$Host.UI.ReadLine()

Unclear if you are just bringing up Bash as another popular scripting option (and I suppose maybe a weird possibility with WSL) or if you misunderstood because batch and bash are similar words, but the OP is talking Windows batch scripting, which is unrelated to Bash. It has significantly better predictability (don't need to worry about interpreter versions) and backwards compatibility. Sometimes in enterprise environments you need to write a script that will work on computers that might not have PS or might have the wrong PS version etc. *cough DOS* Batch script can be lighter and the interpreter significantly lighter than PS. In most cases, PS is a much better choice, but that doesn't mean batch has nothing to offer/ is never the right choice. For your specific example, if you want to make your debloater be able to work on systems that have PS disabled, than PS is obviously the wrong choice (Or if you wanted to also support older versions of Windows [95/98/ME/2000]). Not much but something

At FAANG and I know 0 engineering managers that would care about this cert //

AWS offers a free-tier/trial on the vast majority of their products, including most storage solutions (5GB/12Mos S3, 5GB/12Mos EFS, 30GB/12Mos EBS, 100GB SGW, etc.). You can find details here (Not a differentiating feature from Azure; both offer tons of free training and trial versions of most services... just responding to the above. I don't think it makes any difference which you start on; skillset is almost entirely transferrable between them)

I feel like this really encompasses the moment you know there was a missed opportunity for some helpful comments : Small, simple projects don't often require much in the way of commenting and getting caught up in commenting too much can tend to be used as a crutch for unclear code with poorly chosen variable names. More than any specific habits around commenting, being able to clearly explain your code, especially why it is structured the way it is and choices of algorithms/data structures etc. is going to help moving into a professional setting (both during interviews and when actually working). Writing documentation for what you are doing can be help you get used to explaining and thinking through these sorts of choices, but code comments aren't the only or even usually most important documentation... overall, most new developers would probably get as much or more value focusing on versioning/defect logs/commit comments, req. (user story etc.)/arch. (functional interface/class diagrams) / end-user documents than code comments. Not a big fan of TFD in production, but think TFD approach is great for learning and tends to clarify what needs to be documented.

Agree with the above for needed info. Whether size matters, if there is a lot of dust where it will be run, how much you care about noise, and color preference (if it is at all a factor) also would be good to know. Decent quality cases with more than 1 fan included are going to start around $75. If you want to keep it on a tight budget and don't care about looks, you could just grab a couple passable budget fans (eg., Zalman or Kingwin or maybe craigslist... should be able to get them around $6s/per) and fan guards and cut some more vents on your current case ~ less than $20s.

These two were by far the biggest improvements for me - as someone with portrait displays that docks and undocks a lot with a lot of monitors and uses snap placements heavily, these two features were enough life improvement to be worth switching on their own.

Okay - here is information. Rust is hard. Rust has an extremely small marketshare. The combination means (good) Rust developers are relatively highly-paid and hard to find. Rust is great, but Rust isn't a language you use without knowing why you are using it. I have no issue with people not being experts. This is effectively: 'I am starting a 3PL business. We are going to be moving some things, some amount of distance, across some kind of terrain. Not sure yet or won't tell you. But I am planning on buying 50 vehicles and am wondering what kind I should get. I like hydrogen powered thing. I'm not really that up-to-speed on supply chain management or transport.'

Stuff and things, eh. That really gives so much more info. to know what kind of hardware would be appropriate. 10 devs. and no devops or sysops to be seen. No idea what sort of stacks you are going to be working in. No idea what your pipeline looks like. Rust because why not. Something - again with such specific workloads. And 2 24" screens ~ cause the size impacts the compute load ~ so lets assume you mean 2*1080p... like you couldn't find a modern desktop cpu+integrated graphics that couldn't handle that if all they are going to be doing is using vscode. Calling sus on this op. GLHF.

Robotics is less a programming domain than an application IMO. We have basically 4 categories of programmers that work with robots at my job: A) Control engineers/ automation engineers/ process engineers/ deployment engineers/ robotics operators/ etc. that will be SMEs for a specific robot-type and responsible for the configuration of finished/fully-developed robots. Sometimes this involves actual programming, sometimes it is just done through config. files or front-end utilities. Most of them are comfortable scripting but would not meet the technical bar to be hired as an SDE. Not really any expectation to know a language here, but most of them are at least comfortable with BASH, making minor edits to existing C++, SQL, XML/JSON/YAML, and some web automation tools like Selenium. B) Hardware development engineers, embedded programmers, robotics engineers that design and build prototypes of the robots. They do all the IC and PLC programming. We don't utilize a ton of FPGAs, but I'd probably throw the FPGA developers we have in this grouping. Most of them have an engineering degree (Electrical, mechanical, computer, control, signal, aerospace, robotics, mechatronics... see a pretty big range, but much more often a BE vs BS). Most of these teams use C/C++ as their primary languages. C) Computer Vision, Machine Learning Infrastructure Engineers, Applied Researchers - build the ML/AI and sensor/vision models. Most of these have PhDs. D) General SDE, Machine learning engineers - training models, connecting all the systems, motion logic, material handling logic, building control interfaces, etc. Most of total development staffing... no hard educational requirements, just need to meet the general hiring bar for SDEs. Mix of C++ and Java, primarily. The robotics teams also have the usual development support roles ~ QA/test engineers, appsec, devops, safety and compliance etc. that have varying degrees of involvement on the SWE side.

If you can find them anywhere, might be worth trying the CRBN... feel like Audeze did a good job of capturing the benefits of electrostatic headphones but still keeping it more towards their profile, which it sounds like you enjoy.

Oh, definitely. But like Avocado said, it isn't because the community doesn't suggest it

WTF. Cars are one of the absolute worst things to buy new.

But his testing prior to running through the ceiling, where he was getting near gigabit speeds, was with the switch in the path.