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
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
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
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
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.
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
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
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
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
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
If you want to learn to code, it’s important to start building a conceptual framework so you can effectively communicate with developers. The book I recommended in that blog post, Simple Program Design, is a great start and will give you the basic tools you need to get going. You can go through the entire book and all the exercises relatively quickly. Most people that are interested in learning to code want to dive in and make something work, and the goal of building a conceptual framework is to make sure you know how to swim first. But Simple Program Design isn’t very heavy on computer science. You don’t need to be a computer scientist to learn to code but
Everybody, especially developers, loves working on documentation. They understand the importance of docs and its impact on customer adoption and customer experience, and they always consider docs when planning and releasing code. Wait, why are you laughing?
Many companies have some kind of trouble with documentation. Lots of common problems make docs difficult to wrangle; information gets out of date or lacks completeness, the content is poorly organized or inconsistent, readers can’t find what they’re looking for, and code samples might be broken. If you walk through most engineering departments and ask for volunteers to help update docs, you’ll be met with silence if not outright derision.
The truth is that there are no cheat codes for creating a culture that values documentation or for creating quality content, but I’d like to share some practical things I’ve learned while trying to do just that at SendGrid, and hopefully give you a few extra lives (or at least some extra quarters) for your game.