Articles by Brandon West

Brandon West

As Director of Developer Relations for SendGrid, Brandon's focus is on empowering developers to build things, gathering feedback for new features and improvements, and fostering a cooperative developer community for anything that needs email integration.

Follow Brandon

Simple Webhook Testing Using Sinatra and ngrok

Brandon West Technical
Screen Shot 2015-02-13 at 1.04.34 PM

Webhooks allow for simple, deep integration between apps and services, but debugging them can be a little painful. We have a general guide to debugging webhooks, but you probably want to know what the quickest webhook test environment is for setting-up and using. It’s hard to beat Sinatra and ngrok for this purpose. Or, if you’d rather use node.js, you can check-out Martyn’s post on Testing Webhooks. Getting Started First, you need a ruby environment that has rubygems. If you are new to ruby, then check out rbenv for getting your environment going. Create a new directory and run gem install sinatra. Now let’s make a simple Sinatra app. Create a file called webhook.rb. We’re going to use the SendGrid Event Webhook in this example. The event webhook

Docs Antipatterns (Part 2)

Brandon West Technical

I previously wrote down a few documentation antipatterns, or descriptions of commonly seen bad solutions to problems. If you’re not quite sure what an antipattern is, it’s explained in that blog post. I’d like to present a couple more documentation antipatterns to avoid, both drawn from experiences that we’ve had in the past, but have solved along the way. Antipattern: Big Ball of Mud Definition The Big Ball of Mud is a well-known antipattern in software engineering. To quote the authors who coined the term: “A Big Ball of Mud is a a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of

The 4 S’s of a Good API Demo

Brandon West Community

Guy Kawasaki’s “The Macintosh Way,” is packed with good advice and is a quick read that you should absolutely check out. You can get The Macintosh Way as a free download. In it, there’s a chapter called “How to Give Good Demo,” where Kawasaki suggests that good demos should be short, simple, sweet, swift, and substantial, and that starting with a script that satisfies these requirements is the foundation for success. As sound as Guy’s advice is, we face different limitations than he faced in 1983. Our audiences have a way to tune out a bad demo instantly by grabbing their smartphone and giving their attention to the internet. They aren’t going to go crazy over animated icons like they

Open Source Documentation: One Year Later

Brandon West Community, Technical
SendGrid docs

A year ago, we open sourced our documentation, with the hypothesis that it would improve the docs by adding feedback loops and removing barriers that discourage contribution. We also wanted to share what we had learned during the process. I’m glad to say that so far the results have been good, and the decision to open source our documentation continues to help us improve it as a product. Where We Are Now We’ve had 59 different contributors to the docs repo since we open sourced it, with around 15 of those contributors being community members rather than SendGrid employees. Considering we had only a couple contributors before, that’s about 30x growth in the number of contributors. Makings things open and

The 3 C’s of Developer Relations

Brandon West Community

A lot of people ask what a Developer Evangelist does, and the answers can vary a bit depending on which company they work for, and how the team is placed within the organization. Regardless of the tactics in place, all of them are based on a few core principles of Developer Relations, which I call the 3 C’s: Community, Code, and Content. Community If you don’t have a way to reach developers, your Developer Relations program isn’t worth much. At SendGrid, our main strategy is “give first”–the more successful start-ups there are, the better off everyone is. As Tim has said before, a personal connection is worth more than a click. We don’t think in terms of leads. We’re thinking about

4 Common Antipatterns to Avoid in Your Documentation

Brandon West Technical
Apple iTunes RSS

Design patterns are powerful things. They help us short-circuit a lot of trial and error by relying on the past experience of others. They provide a common lexicon for communicating complex concepts. And, applied thoughtfully, design patterns improve our understanding of our craft as well as its effectiveness. And you’ll notice I haven’t mentioned software. Design patterns exist for many disciplines, and the core concept originated in architecture. One of my personal favorite pattern languages comes from the book Presentation Patterns, and it describes common solutions for problems encountered when preparing for and delivering technical presentations to audiences. Teachers also often use pedagogical patterns. What Is An Antipattern? Just as patterns are good solutions to common problems, antipatterns are bad

Technical Debt is Not a Bad Thing

Brandon West Technical

If you work around developers, you have probably heard the term “technical debt.” It’s a widely used metaphor that is useful when considering how to build and maintain software. The term was coined by Ward Cunningham, a computer scientist who created the idea of a wiki and contributed heavily to the development of object-oriented design patterns. But even though the metaphor is widely used in the world of software development, I meet a lot of people who don’t understand what technical debt is and why it matters, or people who are completely unfamiliar with the term. What Is Technical Debt? Our understanding of a software problem evolves over time, and our code should reflect our current understanding of the problem.

How I Evaluate A Developer Evangelist Candidate

Brandon West Community

Interviewing a developer evangelist is tricky because there’s a variety of hard and soft skills required. An evangelist has to be a strong developer, but also has to wear many other hats, work horizontally across departments, and be an engaging and helpful participant at events. If you’re wondering what the day-to-day duties of an evangelist might look like, check out the blog post I wrote after my first year as an evangelist. Standout Qualities I don’t give candidates an engineering test. I don’t care if they know which sorting algorithm is the fastest and I’m not going to ask someone to implement malloc or put any code on a whiteboard. What I will do is ask questions that provide an

Why Mind Maps are Awesomesauce

Brandon West Best Practices
Mind maps

About a year ago I started using mind maps to help me organize presentations, meeting topics and blog posts and I’ve found that it works really well for me. Mind maps help me take broad, abstract ideas and turn them into concrete, real world examples that I can use to help tell a story. What is a mind map? It’s basically a branching diagram. From wikipedia: A mind map is a diagram used to visually outline information. A mind map is often created around a single word or text, placed in the center, to which associated ideas, words and concepts are added. Major categories radiate from a central node, and lesser categories are sub-branches of larger branches. Categories can represent

Dirty Socks and Technical Debt

Brandon West Events
Socks drying

Last month I spent two weeks traveling to Mexico City, Bogotá, São Paulo, and Rio de Janeiro with Geeks on a Plane Latin America. This was my second GOAP trip; my first was last year’s trip to Eastern Europe. GOAP is an amazing professional and personal experience and I highly recommend it to everyone. Once our group of geeks arrived in Mexico City, I discovered I forgot to pack socks, so the only pair of socks I had with me were the ones I had on my feet when I left home. Not a big deal, as I figured I’d just buy a few more pairs when we had a few free moments. What I had forgotten to account for

Why We Open Sourced Our Documentation

Brandon West Product, Technical
SendGrid docs

I talk a lot about docs, because it’s important to me and important for the success of a product. You can read some of my thoughts on what makes good documentation and using Jekyll to create documentation. One of the goals I set last year when I was asked to take over the documentation was to eventually open source it. I’m happy to say that this week we flipped the switch and anyone can now view and contribute to the source for our documentation. Check out the SendGrid Docs repo on GitHub. Good documentation allows feedback from readers so they can point out inconsistencies or typos and have them addressed quickly. Even better is providing a feedback loop where those

Creating Sustainable Documentation with Jekyll

Brandon West Company, Technical
Dr. Jekyll and Mr. Hyde

I’ve spent a big part of the last year working on documentation for SendGrid. I’ve learned a lot of things. You can read about how we broke down the problem of documentation at a high level and why documentation is critical for success in Cheat Codes for Good Documentation. Below you’ll find the path we took, from the early days through last November’s switch to the current system, based on Jekyll. Most of what I’ll recommend applies to documenting an abstraction layer, e.g. an API. Scope of SendGrid’s Docs Just for context of what SendGrid’s docs look like, here is the output of a linklint check. 35 directories with files 6 default indexes 230 html files 1 image file 77