@Pete-S said in Obtaining hardware from terminated remote employee:
@stacksofplates said in Obtaining hardware from terminated remote employee:
@Pete-S said in Obtaining hardware from terminated remote employee:
@StorageNinja said in Obtaining hardware from terminated remote employee:
@JaredBusch said in Obtaining hardware from terminated remote employee:
Hardware is not worth the fucking time to get back.
If the company thinks wasting man hours on that is a good idea the company is insane
While I largely agree, our R&D laptops are ~2-3K a pop. (fully max spec' MPB or XPS with onsite repair agreements).
I did hear we have started on the Mac's using DEP, so the device will auto-enroll in MDM even if the device is wiped.
https://support.apple.com/en-us/HT204142
Makes no sense developing on a laptop IMHO - unless you're talking about another kind of R&D in another field.
On our team we remote into development servers and all development and testing is run there. Which means the computer you're actually sitting in front of just needs to be able to run a browser, rdp, ssh etc. So any machine suitable for general office work would get the job done. So no 2-3K laptops needed for development, even if that is not the primary reason. I kind of assumed everyone worked that way but haven't actually given it much thought until now.
I haven't really seen anyone do this other than CAD work. Everywhere I've been it's local development, possibly using Eclipse Che or Coder or something for a remote IDE but still local.
VSCode and JetBrains tools allow you to include your development environment in a container. So when you open the project it will open inside of a container with all of the dependencies included. That's the best workflow ive seen so far.
I believe you and find it very interesting. Wov. If that's how most people work, I'm just blown away. I assumed everyone was remote and had full on development and test environments at their disposal.
They usually do have full dev/test environments but it's all containerized. So it's trivial to run that locally. Then when you are satisfied with local results push to your branch and have it auto build/deploy against the actual dev/test environments with something like Flux/Argo. This is still remote, GitOps is all about remote workflows.