[frostmatthew]

I like the rotation idea, but I can't say I see much logic in the desire to have new engineers deploy to production on their first day mentioned/linked in the opening. At VMware (or at least on my team) we try to have new engineers commit code their first week (this doesn't always work out, and when it does it's usually the 4th or 5th day) and I almost feel that's too soon...first day just seems nuts.

You don't see this in other professions, e.g. I doubt doctors are performing surgery or lawyers are going to court on their first day at a new hospital or firm. I'm just not seeing the value in having someone commit code before they're possibly familiar with the codebase and [unless it's a product they used before getting hired] may be equally unfamiliar with what the product even does.

[mcfunley]

You're not performing surgery and you're not arguing in court. You're making many mostly-trivial changes to a website, and that process should be trivial enough that it can be learned in a day.

Having people deploy on their first day is a check on the complexity of the process as much as it is intended to educate new employees.

(n.b. I don't work for Etsy anymore, but I still feel compelled to go to the mat on this thing.)

[rahij]

In my experience, I think it has more to do with getting an engineer acquainted with the pipeline from writing code to getting it live on production. Once he/she is familiar with this, it takes a huge barrier out of the way for the person to be productive whenever they are ready to write some non trivial code in the codebase.

[enjo]

That's exactly right. It's not about pushing meaningful or complex code to production, it's about pushing a small change so that a new engineer can see the whole process from end-to-end.

We do have people push on their first day here at Gridium and I think it's really beneficial. The new engineer sees how we work, and the rest of the team sees that new name in the git logs, on chat, and everywhere else. It sends a strong message that there is a new member of the team who is going to be contributing from now on. It helps to establish cultural norms (everyone makes a big deal out of that first commit which is fun).

I really like the effect it has on our team. Even changing two characters in a string feels like a big deal and that's awesome.

[frostmatthew]

> it's about pushing a small change so that a new engineer can see the whole process from end-to-end

Is that really an accurate portrayal of the process though? Most changes aren't small and take days of development, not minutes or hours. Not to mention code reviews and QA.

[mcfunley]

Yes, it really is an accurate portrayal of the process. Etsy isn't pushing days of development out in a deploy. That would be considered poor practice at Etsy.

To make a sizable feature live, you use a bunch of methods in cooperation:

* Only mutate a bare minimum number of executed lines as code deploys.

* Turn features on and off quickly with (much faster) config deploys.

* Release and test features for internal users first (in production).

* Ramp features up to small amounts of production traffic at a time.

* Deploy new code paths and queries so that they're executed, but aren't visible to end users. (You can use this to detect performance problems early.)

But what you never do is sit on days of sizable code changes that you don't deploy. If you try to deploy a massive diff people in your push will generally suggest that you not do it.

[frostmatthew]

> But what you never do is sit on days of sizable code changes that you don't deploy.

That's certainly sensible but I wasn't suggesting sitting on "days of sizable code changes" - just that it takes days to make the code changes (particularly once you factor in code review and QA).

[ulisesrmzroche]

That's super Byzantine. Do you guys have a decent test structure? Probably wouldn't have to tip-toe around so much.

[enjo]

Most isn't all tho! At any time I can come up with a dozen really small fixes. Changing the timing of a task, updating a string, or any other small things that are always hanging around.

[lotyrin]

Are the projects you work on business glue written in a high-level language and accompanied by tests?

At the places/projects that have these policies, (and whenever possible) software won't (or shouldn't) be rocket surgery.

[jbkkd]

Having an engineer deploy a trivial change is like having a doctor taking blood from a patient. Simple, needs to be learned and done often.