Dustin Collins


Read this first

From Zero to Hero, or There and Back Again

You just landed your first software job. You’re excited, this is a great opportunity! You’ll be able to apply that expensive Computer Science degree to something useful and start paying back those students loans. (If you’re self-taught, good on ya). You know a lot of stuff and now you have the chance to use that knowledge to solve some interesting problems.


Your first day of work goes pretty well. You get set up with HR, someone gives you dev accounts to various tooling and you start poking around at the projects on GitHub. “Hey”, you think, “this is going to be easier then I thought”. A few days in, you are assigned a task to do. You check out the project and follow the README to run it locally. You start running into problems.

  • You need RVM, but the README doesn’t say what version of Ruby to use.
  • There’s a Vagrantfile in the project root, but you can’t tell what it’s used for.

Continue reading →

DevOps on OSX

If you work at a DevOps organization, you use a lot of tools. Communication, architecture, planning, programming, testing. I always like reading what tools other people use to do their job. It helps me stay current. My development machine at Conjur is a Macbook Pro. This post is a list of the tools I use day-to-day, and how I use them.


  • Slack - Internal chat; external chat; Github, Jenkins and Pingdom notifications.
  • Google Drive - Sharing design docs/spreadsheets/presentations (inline commenting is great).
  • Google Hangouts - Video chat for standups and other meetings.
  • Screenhero - Pair programming tool. Both people can control mouse/keyboard and it’s the most reliable experience I’ve found with spotty connections.
  • asciinema - Record and share terminal screencasts. Especially useful for sharing CLI workflows and creating tutorials. Check out the -w flag on the rec

Continue reading →

Three Practices for Winning Communications


When the Gotham City police summon the Dark Knight, they broadcast an unmistakable signal. Everyone knows what it means, the immediacy, and the intended audience. While effective communications is seldom so easily implemented, the Bat Signal demonstrates foundational concepts. Effective communications deliver the right message to the right people at the right time and convey the meaning you intended. Seems straightforward enough.

Until DevOps. Until continuous delivery. Until you have to communicate up, down and sideways. Deadlines. Multiple departments, tools. Third parties. Competing interests, competing demands. Now the only straightforward thing is you in an organization prone to reactive management, islands of self-interest, distrust and blame.

How can you possibly win?

Decades of experience reveal the following three practices of those who put themselves in the

Continue reading →

DevOps: The skills that matter

What skill set is desirable for an engineer in a DevOps organization? Let’s take a look. Surveying DevOps job posts, you need to be intimately familiar with dozens of technologies you’d never use in a non-production setting. Reading articles on devops.com, you need to be able to write 1,500 words without really saying anything at all. Attending DevOpsDays conferences or DevOps meetups, you need to have a finely-tuned sense of empathy. So many things, what should you focus on?

In this post I’m going to talk about the top three DevOps skills I’ve seen to be most important for engineers, in no particular order.


There was some controversy over this when DevOps first became a #TrendingTopic, but I think we’ve settled it now: If you’re an engineer in a DevOps organization you need to be able to deliver solutions as code. It doesn’t matter if you’re dev, ops, QA, DBA, security, data

Continue reading →

How to kill your DevOps initiative

DevOps is hot. Everyone wants it. Continuous delivery is not just for the cool kids in the loft office anymore. Enterprises that have a long history of ‘hardware’, like Target, ING and Cengage Learning, are transforming into software companies. They need to be able to experiment in the market with shorter lead times. A potent brew of collaboration and automation is required.

A quick note. Startups, you are not doing DevOps by default. Just because you sit together does not mean you don’t also have to put in the difficult work of creating and maintaining lean delivery cycles. I’ve worked for large and small organizations, and the notion that “X only works in startups”, or increasingly common, “X only works in enterprises”, is disingenuous. This is the definition of a red herring.

import random

X = random.choice([
    'continuous delivery',
    'feature flags',

Continue reading →

boot2docker vs docker-machine: who cares?

We’re using Docker a lot now at Conjur. Jenkins integration tests - Docker, dev environments - Docker, shipping a virtual appliance - Docker. You get the picture. A lot of our scripts have lines like this in them:

chef-runner --ssh Port=2200 -H root@$(boot2docker ip) mycookbook

I develop on OSX, so I have been using boot2docker for a while now. But I really liked the feature set of docker-machine when it was announced. It allows deployments to more than just VirtualBox and folds together nicely with the other Docker tools. For the last couple months, I have used docker-machine exclusively.

But now we have a problem.

The dev team is split: some of us are using boot2docker and some docker-machine. Our automation code assumes a boot2docker VM is up and running. When this sort of issue comes up, we have three choices.

  1. Write code. Update our automation code to be smarter and switch

Continue reading →

Debugging code for the Particle Core/Photon

I’ve been spoiled as a software engineer. When I write Python, Ruby or Javascript I have a REPL to try different ideas out. I can set breakpoints in PyCharm, RubyMine or the Chrome Devtools to inspect my stack at any point. The feedback cycle is short. I can TDD, even with infrastructure code. Developing code for hardware is not so straightforward. In this post I’ll share my current workflow for writing code for devices.

Hardware is messy; that’s part of the fun of it. In my free time I tinker with hardware: microcontrollers, sensors and robots. Writing code for Arduino and Particle devices can be frustrating. It can be difficult to tell why something isn’t working. Your code is perfect, but you have a broken connection somewhere or that new sensor you’re trying out was damaged in shipping. Or your code has a bug, but it’s hard to tell in the tangle of interrupts what your path of

Continue reading →

Our Role in an Automated World

There is a recurring story about automation told by those looking at tech from the outside. It is a popular anecdote, and goes something like this:

Lisa is a developer at Initrode. She spent most of her day in databases and spreadsheets, cross-referencing them to create weekly reports the higher-ups needed. After some months doing this, she thought to herself “There has to be a better way!”. So she wrote a program to collate all data sources, perform the analysis needed, generate a PDF and email it on a schedule. Now she spends her time on her passion, rock climbing, and stills gets a paycheck every two weeks!

We’re doing DevOps now. It works. The Kool-Aid is drunk. We talk to robots with cheeky names in chatrooms to deploy new releases of our software. Servers confer with each other to promote leaders and cull low performers. Our task management software learns the cadence of our team

Continue reading →

Lessons learned running a DevOps meetup

I’ve been organizing the Boston DevOps meetup for almost two years now. When the organizer spot opened up I jumped at the chance. My experience DevOps-ing along in smaller organizations gave me a pretty narrow view of the movement and I wanted to educate myself. I also wanted to become better at public speaking (still working on that).

I’ve talked with a lot of people learning about, struggling with, and eventually getting somewhere with DevOps at different organizations. We’ve hosted presentations, panels and open spaces at several venues throughout Boston and Cambridge. Partnering with other local meetups, we’ve held discussions on everything from recruiting to wearables.

As always, YMMV, but here are some things I’ve learned organizing events for our community that weren’t obvious when I started.

 1. Being welcoming takes consistent effort

This really applies to any community, but

Continue reading →

DevOps: A House Divided

What is DevOps? DevOps is not about tools. It is about culture, enabling cross-functional teams to quickly deliver value in a sustained matter. It is hard to define DevOps, but blah blah alignment blah success blah blah joy. Three paragraphs later, no takeaways. How many posts have you read about DevOps that follow this format? Promoting this vague clickbait as guidance is only doing ourselves a disservice. We’re patting ourselves on the back so hard we fall over.

How did we end up here? I think it’s because we’re still not having real conversations between business units. We find ourselves now with two camps in the DevOps community: technical and non-technical. Either side shifts the conversation to where they feel most comfortable: the domain they work in and understand. Technical folks talk about tooling. Non-technical folks talk about culture. The divide here is artificial, but it’s

Continue reading →