eurica

numbers for people.

August 25, 2014
by dave
Comments Off

How much bad software development practices cost

I’m always jealous of other people’s datasets. Although Rally’s The Impact of Agile Quantified whitepaper is obviously targeted at getting people to adopt their product, it has some useful back of the envelope values taken from almost 10,000 projects:

  • A dedicated team (>95% focus) is roughly twice as productive on individual tasks as one that’s sparsely focused (>50% focused on one project) (page 5)
  • The median team has 25% of its members switch teams every 3 months (page 6)
  • Team stability can increase productivity by 50%: moving from 60% of the team staying each quarter to 90% staying increases average story count from 50 to 75 (page 7)
  • Small teams (1-3) move slightly faster (+17%) but ship more defects (17% again) making it a wash. (page 12)

Worth taking a look at. Credit: Chris Gagné

August 7, 2014
by dave
Comments Off

How to get a Programming Job in Silicon Valley

Because I am a very very important person, people often ask me how to get a job in programming in Silicon Valley. This is the advice that I’ve been giving them, it’s a work in progress and contributions are welcome.

One option is to get a computer science degree from a decent school, I don’t have very much experience with the wave of dev bootcamps. You’ll need to know enough programming to make a dent. I don’t have any great advice if you’re looking to start learning, since I learned to program on coal powered mechanical typewriters in the 18th century, long before the internet — but nowadays Codecademy looks pretty good.

If you want to teach yourself, here’s what I suggest:

  1. Find a product that you like with an API. Some ideas: Twilio, Firebase, Meteor, Temboo, or PagerDuty.
  2. Build something with it. Go ahead and play with the API first a little; but once you know what you want to build, sketch out a plan with some mockups. Planning projects is almost as valuable a skill as building them. Make sure to cover your use cases and who you’re building it for — even if they’re a little contrived for a toy project.
  3. Post the code to Github & make a live demo (if possible, a video or something if a demo isn’t possible)
  4. Write a blog post about what you learned & tweet it out CC’ing the company who made the API. This step is critical, people don’t read Github profiles — even if they did, it’s hard to tell your code from someone who just forked some existing projects.
  5. Repeat & get better every time. At some point you’ll want to move up to contributing to other open source projects, it’s rare you’ll be starting new projects from scratch — usually you’ll be improving or expanding existing code bases.

What next?
At some point you should start applying to programming jobs, you have a few options:

  • Someone from one of the companies you’ve been building on will reach out to you.
  • Find an internship
  • Find a programming-adjacent job (it’s always easier to get a job when you have a job)
  • Go with a recruiter — they’re a hive of scum and villainy, but they know which companies are willing to hire a super junior person

Stray observations:

  • internships in programming are paid, sometimes very well.
  • Google grows their developers in vats at Stanford, there are lots of other great places to work.
  • video game programming is not as much fun as playing video games — and there are too many people excited about joining it, so you’re going to be working harder, for less money on less interesting projects — if you don’t find solving real problems interesting, don’t become a programmer. The Appendix to Philip Greenspun’s Women in Science post is relevant — pick a working environment that you like, rather than a field. If you can genuinely find a happy 40 year old game programmer, go ahead and apply.
  • long term, don’t call yourself a programmer (a good rebuttal is Do call yourself a programmer)
  • It’s worth reading everything in the sidebar of Joel on Software, possibly starting with Getting your resume read.
  • Inspirational success story: Renee at Twilio

Thanks to Yaakov, Sonya and Cherie.

June 8, 2014
by dave
Comments Off

Using Pebble.js to hit PagerDuty

Pebble released a JavaScript-only API.

To try it out, I threw together a quick script that polls the PagerDuty API for the number of incidents assigned to a user and then vibrates & updates the screen when it changes.

  • I installed the SDK & forked this project.
  • Make the basic changes to appinfo.json
  • All of the interesting code went in app.js
  • Running pebble build rolls app.js and the PebbleJS library up into a 7-8000 line pebble-js-app.js
  • pebble install --phone 192.168.1.29 sends it over.

All told, it was pretty easy,

PebbleJS makes it really easy to throw up a basic UI:

Ordinarily I’d use PDJS, but PebbleJS exposes an ajax object that’s slightly different than jQuery’s 1. Either way the code to hit our API is pretty easy:

Still haven’t figured out configuration side of things, so I’ve just hard coded a read-only UI key for my webdemo account:

Giving the user feedback is pretty easy:

If this is the kind of thing that you want to be involved in, come work at PagerDuty.

  1. As always, I found Runscope invaluable in figuring out what was going on.

May 20, 2014
by dave
Comments Off

Typed Array performance in JavaScript

I was looking at a few JavaScript implementations of Conway’s Game of Life and I was a little underwhelmed by their performance, so I started wondering how much was related to Array performance in JavaScript.

There’s a better option for arrays of ints: Typed Arrays, the smallest object they can store is an 8 bit byte (I only need a boolean), but that’s still a lot less complicated than a full JS object.

Results:
I tested on Firefox and Chrome on a modern MacBook Pro and an old Windows 7 machine. In every case, typed arrays were faster than plain arrays.

Interestingly, Chrome was slightly faster operating on 32 bit words

On Chrome the typed arrays were ~3x faster, on Firefox they were 25% faster. Somehow Firefox managed to take over 12x as long on my old windows box.

Browser (Machine) Int8Array Int32Array Array
Chrome (MacBook Pro) 216.541ms 198.340ms 723.414ms
Firefox (MacBook Pro) 199.7ms 198.96ms 252.67ms
Chrome (Old Win7) 668.000ms 564.000ms 1878.000ms
Firefox (Old Win7) 7355.06ms 7163.35ms 9494.34ms

To test yourself, you can use this code (output goes to the browser console).
Continue Reading →

February 12, 2014
by dave
Comments Off

PagerDuty & Ruby with HTTParty

I’m trying to do more of my hackdays in Ruby, since it’s practically the lingua franca of San Francisco. Since we don’t have an official Ruby library, I used HTTParty.

You’re more then welcome to use it: https://gist.github.com/eurica/8951769

#This is a read-only API key:
webdemo = PagerDuty.new("webdemo","BcRghqyTqokgfx3ADXiq")
# Get incidents:
puts webdemo.get("incidents", :query => "limit=1")

Continue Reading →

January 9, 2014
by dave
Comments Off

Stop LinkedIn from showing candidates’ pictures

ghost_person_200x200_v1I spend a lot of time screening candidates for PagerDuty, and even if it doesn’t mesh with my gut the science says I might be subconsciously favouring mustaches, or be biased towards or against attractive people. So it’s counter-productive to my goals that LinkedIn keeps showing me photos of applicants — enough so that I decided to fix it.

Ideally I’d also swap names for initials since I don’t care about your gender or ethnicity, just what you can do. That’s a little harder since every tool and cultural convention along the way identifies people that way — and sooner or later I’m going to meet the stronger candidates anyway.

Blocking user images from LinkedIn:

User Styles with Stylish (the easy way)

I made a script available on userstyles.org that you can install with on click if you have Stylish

Custom.css in Chrome (the way I did it)

The fact that Stylish wants to “Access your data on all websites, Access your tabs and browsing activity” means that I only turn it on during development.

Chrome lets you specify a Custom.css (most browsers have some equivalent), so I added the following to mine1:

/* LinkedIn Main profile picture, specific enough to not trigger on other sites: .profile-card .profile-picture img */
.profile-card .profile-picture img {
content: url(https://www.gravatar.com/avatar/00000000000000000000000000000000?d=mm&f=y);
}

And there you go, hopefully it’s worth a minute or two to judge resumes on their content.

  1. Actually, the first thing I tried was to make a user script, GreaseMonkey a simple:

    // ==UserScript==
    // @match http://*.linkedin.com/*
    // ==/UserScript==
    $(".profile-picture a img").attr("src","about:blank")

    But it turned out that the picture was often displayed before jQuery was loaded (which is solvable with old timey raw DOM code) but GreaseMonkey tended to run after the image was displayed, so that’s a non-starter.