This script might be more harmful than useful

[nviennot]

I am not in favor of having a giant script that does everything for you:

1) It setup your ssh keys, vim, tmux, rvm, etc... IMHO if a developer joins the team without rvm installed, or his ssh keys in github, then you probably don't want to hire him anyway because that person was probably born yesterday.

2) This script will never work in all the different configuration (zsh vs bash ? already installed .vimrc ? nginx vs apache ? ).

3) It will eventually get outdated. Maintaining it over time will surely be costly, and maybe nobody will want to do it.

4) The cost of this script will be probably 50 hours in the next year (creating that whole thing + maintenance + all the verbal discussions around it). The apparent benefit will be 30 mins (this is what it takes on average to setup your stack I guess) times the number of developer that installs it. Assuming you hire 20 developers, you still don't break even.

5) Even if you could squeeze the cost from 50 hours to 1 hour, I still think it's harmful. I believe it's extremely important as a developer to setup the stack yourself so that you know exactly what's going on. When shit hits the fan, you need to know what you did. You need to own your configuration.

[jonstorer]

Nico, you're the only person on this team that's bringing your own laptop, keep that in mind.

[jonstorer]

Also, that's a lot of hate without any solutions... I'd love to collaborate on this, but if you're just going to shoot it down, i'm not really interested

[nviennot]

I'm not going to argue more than that, but just because I'm curious / understand what I missed, what points in my list become irrelevant after your comment ?

[nviennot]

There is no hate in my argument list. If you felt that I was being sentimental then I apologize, it wasn't what I was trying to do.

I won't be able to collaborate much since I am using a Linux system.

Also I cannot really bring any solutions on the table since it appears that I don't understand the problem to begin with.

[yodarjun]

@nviennot some of the statements you've made make sense. This script, as I understand it, is to make someone new coming into Crowdtap get up and running with the new laptop that they get from Crowdtap. If you can suggest some ways to improve the onboarding process for new hires(our current process is to ask them to follow instructions written in our wiki), we will welcome it gladly. I personally think that this is pretty decent effort to minimize the onboarding process of setting up one's laptop.

[jonstorer]

Nico,

1) you're the only dev that's bringing their own machine. So, yes, we will hire people that won't have rvm install or their the ssh keys for their brand new machine on their github account

2) I understand that you're working with a very complex setup on your own machine. But here at crowdtap, where we started with new machines, we run on apache, most of us use zsh (which is why I suggested checking your shell) and you won't have a profile setup. I understand that lots of people have their own profile, but as you're aware we're working towards a single profile so everyone's machine is the same.

3) Fortunately, it's pretty easy to update. And when it's outdated, we'll deal with it then.

4) Maybe, but we have to document it somewhere, in a wiki or in a script, so if we have the option of making the documentation work for us, why not?

5) The script isn't that long, and of course we would want our developers to read what it's doing and understand what's going on. The script isn't cryptic and anyone we'd hire could be able to google all they needed to know while the script ran in the background.

The issues you raise don't become irrelevant. That's not what I'm saying. What I'm saying is: this script is looking to solve the problem of documentation AS WELL AS making the documentation "work" for us (it documents AND installs!!). While you may or may not have many good points, you're not offering any solutions of your own. You're just pointing out what you believe to be wrong. So back to my original statement; if you're going to point out holes in the script, please provide solutions as well.

[kareemk]

@nviennot there is definitely a benefit to maintain this script given that it would replace our "Getting Started" guide which every new developer has to run through manually. It's a very common best practices to have a process like this (some places use a disk image instead of scripting) and most places enforce developers working on common hardware to ensure its easy to add new people to the team and for team members to jump on each others machines. You are definitely the exception, and there is nothing wrong with that, but what we have here works for literally 90% of the team currently and will likely apply to 90%+ of the devs going forward.

[nviennot]

1) Ok 2) Ok 3) Ok 4) Ok 5) It might become cryptic when you deal with error handling.

From a personal taste, I really like the wiki. I feel empowered to copy/paste all these commands and read the documentation of whatever I'm installing at each steps. I feel like I'm building my setup and I like it. Furthermore, it's really straight forward (thanks to the lack of mongo/redis credentials as opposed to postgres or mysql). But taste cannot be debated.

Ideally, I would like the wiki to be executable, interactive and readable (pretty printed). My intuition is that it cannot be (markdown / textile are not bash scripts).

If I had to choose for a solution, I would make the wiki more copy/pasteable, and put a bunch of comments in the script snippet. Like this:

The current wiki may benefit from compacting all the "brew install" in one single copy paste. The apache proxy setup should be copy/pasteable ($HOME instead of /Users/KareemK). It's cool to have links to package that we are using to "educate" ourselves while installing the stack.

This way there is no need to do any sort of error handling by a script.

We have both of the two worlds in my opinion.

Again, that's a matter of personal taste. So I won't argue more on what should be done / not done.