eurica

numbers for people.

September 16, 2014
by dave
Comments Off

Reporting time spent on PagerDuty incidents with notes (code sample)

I was talking with a PagerDuty customer, and they track how much time they spend responding to an incident with a simple string like “30m” or “2h” in a note on the incident.

That makes it fairly easy with our API (and PDJS) to pull and sum all the time spent on incidents. Here’s a script that pulls out all the notes mentioning times from incidents on my “webdemo” account for September 15th, 2014. (All the data is fake, of course).

http://jsfiddle.net/eurica/oj4c7p2z/8/

September 15, 2014
by dave
Comments Off

2 reasons software usually takes longer than estimated

Like many people whose jobs involve getting software out the door, I think a lot about why we usually ship late (and never early). Unfortunately my theory is pretty mundane — the less accurate the estimate, the more likely it is to be late rather than early.

1. Errors don’t cancel out. A simple example: If a half of the tasks in a project take twice as long as you expect, and the other half take half as long — rather than being on time, your project took 25% longer than scheduled1. Unfortunately, to compensate for 1 task taking twice as long as you thought, you need to come in 50% under for 2 other similar sized tasks. The numbers are correspondingly worse if you’re off by a larger multiple.

2. The winners curse is very hard to avoid. Generally the same team working with the same tools in the same problem space is going to have very similar cost benefit ratios for the top items on their backlog. The top projects on your backlog have costs of X1…XN and values of Y1…YN. Assuming that you’ve done your homework, you’ve ordered them so that X1/Y1 > X2/Y2 > … > XN/YN — in reality it’s likely closer to the truth that X1/Y1 = X2/Y2 = … = XN/YN. In words: you’re most likely to do the projects, or parts of a project that you’re the most optimistic about — so half the time, you’re picking a project because you’re overly optimistic about how long it will take.

What can we do instead?

One of my favourite aspects of Agile is the frequent demos with a process for re-prioritizing tasks, but even on a waterfall project there’s a simple rule of thumb that I like:

By the halfway mark2 on a schedule:

  • Someone not working on the project/feature must’ve successfully used the feature
  • You have a finite, prioritized and shrinking list of remaining features and bugs
  • You have a line that separates blockers from non-blockers and most of your effort is going towards blockers

The goal is to control as much as you can — if you can’t predict when a project will be done, you can at least put yourself in a position to decide between launching on time or launching with all the bells and whistles (or somewhere in between).

Some better answers:

  1. 50% x 2 + 50% x 1/2 = 125%
  2. I remember once being asked to bid on a project that was “90% finished” and dutifully (and I strongly suspect, correctly) estimated that we’d have to basically start over and do 100% of the project.

August 28, 2014
by dave
Comments Off

Making a survey for tablets with Google Spreadsheets/forms

Google forms are a great tool to throw together quick feedback forms – we use an iPad with a form in the lunchroom to rate our caterer.

Great idea, poor execution. Most of them end up looking like this:

ugly google forms

We can do better. Take this form for instance. We can convince just about anyone to click on a form optimized for an iPad: Live demo

The great news, is that the form is just HTML that you can muck around with that goes straight into a Google spreadsheet. Open up your form and view the source. You only need 2 values: the form’s action URL and what the input’s name is:

where to find values

Then stick them in this HTML (and probably tweak the CSS). The text in the DIVs

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.