zmagg

I consider myself reasonably OK at leaving projects without quitting, at Etsy. That's an important qualifier, as Etsy as an organization is very comfortable with diving deep to understand code and systems and co-debugging and generally what Julia would call, "becoming wizards together". Because of that, I've not found a lot of organizational pressure to stay on a project as the solo expert when you're ready to leave.

Some strategies I've used that have worked to wrap up work on a project and move onto a new one.

• Go on a vacation. One week is frequently sufficient. Create the bus factor for yourself. Observe the things you do leading up to being gone for a week: probably you're meeting with coworkers to sync knowledge, or writing more documentation, or possibly even presenting exceptionally gnarly part of the system that you worked on. You can preemptively do these things even if you don't go on vacation, but I find being entirely disconnected an important part of demonstrating your trust in other peo

aanand

Comment on this Gist with any present or potential concerns regarding the design and use of libswarm.

jphalip

------------------------------------------------------------------------
zip-test.py:

import zipfile
zf = zipfile.ZipFile('django-compressor-1.1.2.pybundle', 'r')
zf.debug=3

------------------------------------------------------------------------
$ python zip-test.py

jallspaw

Adrian -

I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.

You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,

jrauser

points_per_hour<-2000
layd_raw_transition<-
data.frame(timestamp=factor(c(rep(seq(0,11),points_per_hour),
                       rep(seq(12,23),points_per_hour))),
           latency=c(rgamma(12*points_per_hour,shape=3,scale=60),
                     rgamma(12*points_per_hour*0.9,shape=2,scale=60),
                     rgamma(12*points_per_hour*0.1,shape=8,scale=60)),
           type=(c(rep("before",12*points_per_hour),
                   rep("after",12*points_per_hour))))

jordansissel

#!/usr/bin/env ruby
#

require "rubygems"
require "puppet" # gem puppet
require "ap" # gem awesome_print

# Need to define a type for each type we want to have.
# Otherwise, unknown types are errors in puppet.
Puppet::Type.newtype(:input) do

garethr

#!/usr/bin/env ruby

require 'rubygems'
require 'grit'
require 'nokogiri'
require 'open-uri'

# This is a pre-receive git hook designed to be part of a continuous 
# deployment workflow using the Integrity continuous integration server