Leaving PatientsLikeMe for AppCloud!
Leaving PatientsLikeMe
I’m sad to announce I’m leaving PatientsLikeMe for a new opportunity. I joined PatientsLikeMe to work with great people, grow the team/architecture, and help some very sick people. Like any startup, it’s been a roller coaster of joy and despair.
Two and half years later, it’s hard to believe we’ve crossed all the ambitious projects off the list we sketched out when I first started:
- Establish Minimal Scrum/Kanban and Grow the Team
- Rebuild the Production Stack for Speed/Reliability
- Overhaul the Medical Data Architecture
- Embrace Devops with Monitoring
- Ship Features as Efficiently as Possible
Why Leave?
It’s time to pass the different torches to engineers on my team and start something new. There’s still more work to do, but I’m excited to let my team step up and take my roles. It’s hard to leave a comfortable job, but you have to challenge yourself if you want to grow.
Joining AppCloud
I’ve taken a role as a Principal Engineer on the AppCloud product within BrightCove. They’re building a distributed, large scale system delivering mobile applications as a service. I’m excited to work with Ashley Streb, Scott Tamosunas, and everyone on a great team. I hope to bring Rails, Resque, and engineering experience to bear on day 1 while learning Mongo, Mobile, and BackboneJS among other new technologies.
The Future
It’s always sad to leave great people behind, but I hope I’ll see everyone from PatientsLikeMe on a regular basis – it’s a small town. I’m very excited to get my hands dirty and help launch AppCloud!
Mapping Rails 3.0 Commands
Rails 3.0 introduces ./script/rails
When Rails 3.0 was released, all of the individual command utilities (the Rails console, Rails generator, etc) were all consolidated into a single script:
./script/rails
That’s Annoying
Being used to typing “./script/console” for the last 4 years of my life, this is annoying. It’s a lot easier to tab complete within the ./script directory to the exact command you want and then fill in the arguments.
My Answer: rails_command_stubs
To solve this, I built a wrapper script you can drop in your Rails ./script directory. You can then symlink in commonly used commands and reference them directly and they pass through to the ./script/rails equivalent.
./script/console production # Calls ./script/rails console production
Resque Queue Priority
Resque Queue Priority
Resque allows each worker process to work a prioritized list of work queues. When jobs are added, they end up in one particular queue. Each worker scans the queues in that priority order to determine the next job to process. This allows you to ensure that higher priority work is processed before lower priority work.
TL;DR: Resque workers process work in the priority order specified.
A Year of WOW (20% time) at PatientsLikeMe
What is WOW Week?
PatientsLikeMe has built our own version of Google’s “20% Time” that we call “WOW Week”. WOW Week is a week of unstructured development time for engineers, where they can work on anything they choose to improve our products. This lets people focus on their personal passions or explore riskier ideas. See my more detailed post about what WOW Week is and how it works for PatientsLikeMe.
2011 WOW Week Projects in Review
It’s easy to pay lip-service to the idea of 20% time, but PatientsLikeMe actually dedicates entire weeks at a time. This post showcases what a year of WOW produced in 2011. Each of these projects was initiated by an engineer in their own time and most made it into production.
Clinical Trials (In Production)
Credit: James Kebinger and Jeff Dwyer
Provide a friendly search interface to National Clinical Trial registry and automatically match patients within PatientsLikeMe to relavant trials they qualify for.
WOW Week at PatientsLikeMe
What is WOW Week?
PatientsLikeMe has built our own version of Google’s “20% Time” that we call “WOW Week”. WOW Week is a week of unstructured development time for engineers, where they can work on anything to improve our products as long as they demo their progress in front of the company at the end of the week.
The engineering team works in 2-week long development sprints. After three development sprints in a row, we have a “Technical Debt” week and a WOW Week.
Why a Week at a time versus 20% Time?
It’s easy to pay lip-service to the concept of 20% time for engineers while scheduling a full load of work. I’ve seen this happen many times at other companies. PatientsLikeMe avoids this pitfall by creating a public block of time for the entire company. See the 2011 WOW showcase to see how much we build.
Scheduling a complete week allows a single context-switch into innovation mode for everyone. This maximizes the value of this time, instead of dividing it into smaller chunks that are diluted by context switching and deadlines.
How PatientsLikeMe.com Monitors Ops w/ PagerDuty
Summary (TL;DR)
We have a network of production monitoring tools at patientslikeme.com, where monit, NewRelic, and Pingdom feed alerts through PagerDuty to produce e-mail, SMS, and Pager alerts for production issues. PagerDuty has a ticketing system to assign a given problem to a single person. It’s awesome.
Life Before PagerDuty
Whenever a background worker was automatically restarted, we deployed a fix, or any minor system event occurred a handful of e-mails would be generated to our whole Ops team and most of them would get SMS messages for each. We mostly ignored all of this noise. When a genuine emergency occurred, we often didn’t react immediately. Because we were all getting alerted, often 2-3 of us would respond in a piling-on effect. This sucks.
Principles of Proper Ops Monitoring
- People only get alerts for serious issues requiring human intervention
- Only One Person Alerted at a Time
- Serious Issues Should Wake You Up at 4AM
Guerilla Scrum: Minimum Viable Process
TL;DR
You can start with the minimum viable process right now (Standups, a Backlog, and Demo/Retro). You can use this foundation to build a customized process framework that works for your team.
Frustrations with Heavy Process
The Software world seems split between process dogmatists and pragmatists. Dogmatists believe that the entire canon of Scrum practices must be enacted as a whole, or “you’re doing it wrong.”
I couldn’t disagree more – every process was designed to solve a problem in a particular context. This attitude runs rampant, and many teams chafe under the weight of heavy process. This post aims to enumerate the minimum viable scrum process.
Think Critically: A Process Should Solve a Problem
Any process or rule should solve a specific, measurable problem. Processes should exist to make your life better. You should know the problem(s) each process is intended to solve and answer:
- Is it working?
- Do you still need it?
Guerilla Scrum: Core Processes
I call these core Scrum processes Guerilla Scrum, the minimum viable process to get started and generate what you need:
- Daily Standups
- Single, Prioritized Backlog
- Fixed Iterations
- Demo & Retrospective
