September 16, 2014
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).
September 16, 2014
Samer just pointed me at vis.js and it’s shockingly easy to use. In about 15 minutes I had it plugged in to the PagerDuty API and graphing incidents.
Play with this on JSFiddle. Or you can probably scroll around it here:
September 15, 2014
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 scheduled. 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 mark 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:
August 28, 2014
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:
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:
Then stick them in this HTML (and probably tweak the CSS). The text in the DIVs
August 25, 2014
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
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:
- Find a product that you like with an API. Some ideas: Twilio, Firebase, Meteor, Temboo, or PagerDuty.
- 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.
- Post the code to Github & make a live demo (if possible, a video or something if a demo isn’t possible)
- 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.
- 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.
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
- 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.
July 13, 2014
If you want to bookmark it, you can link http://euri.ca/files/pdjs/examples/userCSV.html#subdomain,APIKey
June 8, 2014
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
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 . 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.