Permission to include Buffer work: Granted :D

And a quick intro to what I do at Buffer in the first place! :)

Today I shared this little project with my manager at Buffer. And with it, I finally asked for permission to post updates related to Buffer work, and I got it! :D . With a few exceptions I'll finally be able to do live logs of what I'm working on at Buffer almost on a daily basis. The exception being anything that could potentially be seen as a security threat for Buffer. That means:

  • No identifiable db structures or locations of internal projects.
  • Minimal discussion of specifics of security related updates.
  • Definitely no dumping of any secrets.

And from my perspective, I won't be talking a lot about anything operational at Buffer.

That said, there's still a lot that I can talk about thanks to the fact that Buffer is such an open and transparent company. We are even building our products out in the open now, allowing anyone to see the upcoming features and PR's being merged in. Like here, on our Buffer publish repo.

I want to keep this post short, but at the same time I want to do a quick dive into the work I do at Buffer. In short, a lot of my work centers around developer experience. I don't like the term dev ops all that much since whatever I do, I try to get out of the way and let developers take control of the work being done so they can sort of manage as much of the process themselves (no bottlenecks). But at the same time, I try to enhance that experience of self management to be happy and safe so people don't accidentally bork an entire cluster because of poor documentation or fail safes.

This means I work a lot on:

  • The local dev environment experience.
    At Buffer this means making our dev environment really easily accessible to anyone! Not just the engineers. And even for the engineers it shouldn't have to mean fighting a dev environment to get work done. Just run something like ./dev up using a little tool that we've built for internal use, and you should be up and running. Anytime, all the time.
  • The deployment pipeline.
    We use Kubernetes pretty heavily at Buffer. And the deployment pipelines is something I do a lot of work on. I've helped build a custom layer that sits on top of the Kubernetes API (I'll call it CIK8s on the blog) that handles the actual work of patching deployments, rolling back, getting status, etc. I try to ensure that the work I do here stays pretty darn stable while continuously evolving in terms of features and observability.
  • AWS infrastructure costs, security, and tooling around it.
    This kind of says a lot, but I spend a good chunk of time working on keeping track of AWS costs, and security policies, and helping to build tools to make sure that things are running smoothly and other developers can contribute to that as well.

There's a fair amount of stuff in there which could potentially be sensitive, so this means I won't be talking about everything! But I can still talk about a lot, and what can't be live logged can occasionally make its way into the blog. Which will be pretty fun hopefully!

Happy times are here to stay :) .

Permission to include Buffer work: Granted :D
Share this