6 ms·

This is timely, as I’ve just gone through the worst onboarding I've ever experienced. It took two very long days to install an OS on a machine and get it to boo

by luu 11y ago

This is timely, as I’ve just gone through the worst onboarding I've ever experienced. It took two very long days to install an OS on a machine and get it to boot (I had to assembly my computer and then use the corporate installer, which failed multiple times with errors like “an unknown error occurred”). It then took me about a week to run the local project’s “hello world” (I was initially pointed to documentation that had been deprecated for months, and then when I found the right documentation it was incomplete and out of date). The actual process to get there was hilariously baroque; for example (if my email records are correct and I didn’t get duplicate emails from the system), I must have clicked through 18 EULAs to get a subset of the permissions I need. I promise, that’s worse than it sounds since the form to do so took more time to click through than you can imagine. It was a month before I could effectively do any work at all. I originally thought that I was just unlucky, but when I asked around I found that I had an above average experience, at least among people near me who started recently. Unlike many other folks, I was actually able to get a username/alias, a computer, and an office. I don’t know what folks without a username do since they can’t even start clicking through the necessary EULAs to get permissions to do stuff, let alone do any actual work. I’m not sure how it is in other parts of the company, but if you imagine that it’s similar and do some back of the envelope math on how many people get onboarded and how much losing a month (or more) of time costs, it comes out to N million dollars for a non-trivial N. And that’s just the direct cost of the really trivial stuff. It’s hard to calculate the cost of the higher level stuff that’s mentioned in the article, but I suspect that’s even more expensive.

walshemj 11y ago
So your all individualy developing locally on your machine instead of on a server that you all use? - I think that's your problem right there
- marssaxman 11y ago
  I'm curious, what subset of the software development world are you working in? "Developing locally on your machine" is and has always been standard practice in every part of the industry I have encountered.
  - walshemj 11y ago
    Every project I worked on at BT (15 years) and all the webdev work it makes no sense to have 20 different pcs all developing and trying to merge the code at the end. You remove the risk of subtle differences between developers pc's if your only developing standalone apps I could see it but Microsoft doesn't develop windows or office that way.
    - marssaxman 11y ago
      Perhaps I just don't understand what you're describing, because in my experience it is completely normal to have developers working on 20 different PCs and all merging code as they go - that's what version control systems are for! I can't really imagine how else you would do it. Do all the devs really mount a shared filesystem with a single copy of the code!? Or do you mean that the devs all still have individual copies of the source tree, but they do all their work by remoting in to some big monster server and building/testing there? That sounds.... um.... ungodly slow. Though I suppose if you are talking about webdev, perhaps there is no build step, so it might not suck quite as much...? It sounds like a very different world, and I'm struggling to understand what you mean. I never worked on Windows or Office, but I did work in devdiv for a while, and at that time Microsoft certainly did develop Visual Studio in the traditional way. There were build farms, to be sure, but they were used for occasional checkpoint builds and for testing. For daily work, we ran the ol' edit/compile/link/run/crash cycle locally, on our own dev machines.
      - walshemj 11y ago
        You can have your own source control at the server level and every one logs into that server just run an X Server on your PC. And yes you should be developing on exactly the same hardware its going to run on. All you need to set up a new user is a bog standard pc and a new account set up on the server. Its a lot easier to keep dev test and live identical than 20 or so developers pc's And even when we did local development (oracle forms) all the code was checked in to a central server which was used to produce a daily build. How do you think IBM mainframe development is done?
- cheapsteak 11y ago
  What do you mean when you say develop on a server? Do you actually remote in and do development via commandline? Do you edit the files locally and upload it back? Do you run a remote desktop with gui? If one person accidentally saves a file that has a syntax error or something, does it crash the server for everyone? What tools do you use for development?
  - walshemj 11y ago
    sccs or pvcs normaly

by luu 11y ago

walshemj 11y ago

So your all individualy developing locally on your machine instead of on a server that you all use? - I think that's your problem right there

marssaxman 11y ago
I'm curious, what subset of the software development world are you working in? "Developing locally on your machine" is and has always been standard practice in every part of the industry I have encountered.
- walshemj 11y ago
  Every project I worked on at BT (15 years) and all the webdev work it makes no sense to have 20 different pcs all developing and trying to merge the code at the end. You remove the risk of subtle differences between developers pc's if your only developing standalone apps I could see it but Microsoft doesn't develop windows or office that way.
  - marssaxman 11y ago
    Perhaps I just don't understand what you're describing, because in my experience it is completely normal to have developers working on 20 different PCs and all merging code as they go - that's what version control systems are for! I can't really imagine how else you would do it. Do all the devs really mount a shared filesystem with a single copy of the code!? Or do you mean that the devs all still have individual copies of the source tree, but they do all their work by remoting in to some big monster server and building/testing there? That sounds.... um.... ungodly slow. Though I suppose if you are talking about webdev, perhaps there is no build step, so it might not suck quite as much...? It sounds like a very different world, and I'm struggling to understand what you mean. I never worked on Windows or Office, but I did work in devdiv for a while, and at that time Microsoft certainly did develop Visual Studio in the traditional way. There were build farms, to be sure, but they were used for occasional checkpoint builds and for testing. For daily work, we ran the ol' edit/compile/link/run/crash cycle locally, on our own dev machines.
    - walshemj 11y ago
      You can have your own source control at the server level and every one logs into that server just run an X Server on your PC. And yes you should be developing on exactly the same hardware its going to run on. All you need to set up a new user is a bog standard pc and a new account set up on the server. Its a lot easier to keep dev test and live identical than 20 or so developers pc's And even when we did local development (oracle forms) all the code was checked in to a central server which was used to produce a daily build. How do you think IBM mainframe development is done?
cheapsteak 11y ago
What do you mean when you say develop on a server? Do you actually remote in and do development via commandline? Do you edit the files locally and upload it back? Do you run a remote desktop with gui? If one person accidentally saves a file that has a syntax error or something, does it crash the server for everyone? What tools do you use for development?
- walshemj 11y ago
  sccs or pvcs normaly