On February 23rd I had just returned from Fiji, surviving Hurricane Winston. This was the worst hurricane in history to ever hit the southern hemisphere. On Feb 24th, another hurricane hit on Twitter when Mandrill announced they were shutting down their free service tier. Many of you took to Twitter to frantically seek advice and alternatives.
The next 68 days that followed, our goal was to reach as many of you as possible with answers and possible solutions. In fact, it was actually your feedback, which helped us move up our timeline on subaccounts. (Thanks for that feedback and please keep it coming.)
We have some of the most talented engineers working at SparkPost. Believe me, we are as passionate about coding as you are. But for me, on February 24th I wondered, do engineers make good Tweeters? As it turns out, they do.
Twitter Awards: Growing Our Community With Your Feedback
We empowered our employees to take to Twitter and answer your questions with their personal handles as best they could. We simply couldn’t handle the traffic and questions solely with our corporate handle. Additionally, we had to communicate internally via our Slack channels to get you answers quickly enough. (Since many of us on the social media team aren’t engineers!) This allowed us to aide in your decision. From this experience we decided to open up a public community Slack channel for all of you, managed by our Community Manager Mary, yet another great by-product to come out of all of this. We also created Twitter Ads advertising our 100K free for life tier, which many questioned. “Is this too good to be true?”- that is, until our CEO confirmed it was real in his blog post, “I Am All In. My Promise to Developers.”
Even though SparkPost has been a leader in the email industry space for a decade, many of you hadn’t heard of our SaaS platform product. Yet, you trusted SparkPost with your business – and I am grateful that you did. (In fact, if you haven’t received one of our limited edition client library laptop stickers, I’d like to send you one. Go to this page for details.)
Fast forward to last week where we won a Twitter Award in the ‘Twitter for Small Biz #Growth’ category. We certainly have grown a lot this year, in part, thanks to you. Although it’s nice to win an award, the real win for us is you. We’re so glad to have you as part of our SparkPost family. When we say #WeLoveDevelopers, we really do. Some of you have been vocal in letting us know how much you appreciate the ease of use of our SparkPost APIs and how seamless it is to make the switch.
As we continue to grow, we want to keep hearing from you, what cool projects you’re working on, and your suggestions to improve the SparkPost product. Stay tuned, because we’ll be rolling out our 2nd Annual Sparky Awards contest where you can submit your kick-ass projects.
Didn’t get a chance to follow this year’s Twitter Awards? You can follow the latest news through #twitterawards – And as always, if you need help, contact us on Twitter, Slack, or just follow the flame. 😉
Developer Productivity Tools You Might Like
Staying productive in a modern software firm can be a challenge. You might be physically remote, in a different timezone or maybe you just have an excitingly active user community. Whatever your situation, we each have productivity tools, techniques and coping mechanisms for maintaining momentum in the modern world. I often learn from others on this topic so here is very quick overview of my own thinking.
Slack is one of the most useful developer productivity tools available to me today. Slack’s modern grown-up take on IRC makes traditional corporate IM completely obsolete. I could not function without live group comms with all my colleagues and our user community. Our founder and CTO George Schlossnagle says this and more here.
I also can’t imagine, due to Slack, how many fewer hours of meetings, memos, dry papers and otherwise slow-boat conversations we now have, but it’s alot.
Image c/o: an alot
My home within SparkPost is the Developer Relations group. We’re spread over 8 time zone hours and some of us move around quite a bit. Slack’s backscroll, the body of messages sent while I was away, lets me catch up when travelling, eating, asleep or whatever else. There is no substitute for backscroll to stay connected and in sync with the team.
So much of the work we do is visible in backscroll and it’s searchable too! I sound a little like an advert but Slack is an unprecedented new capability for me. I can now answer a great many of my own questions with Slack search – thats huge win for group productivity. I’ll touch on that a little more in the anti-patterns section later.
Of course Slack is not a replacement for deliberate documentation but it certainly raises the knowledge floor, does it not?
Ok, yes of course we all have calendars. We use Google Apps at SparkPost and Google Calendar helps my productivity in a few specific ways. I like to put solo tasks in my calendar. This lets me block out my days and remind “future me” (read: confused and lazy me) to do things on time. For example, I have a calendar entry entitled “Draft blog post” for writing this article with a couple of hours allocated. I leave the calendar notification on screen while I work (I use Chrome) so I can see it right beside my clock.
I reschedule tasks as needed but I try to work as dictated by my calendar. “Past me” had a plan to make progress on multiple fronts and keep things rolling along. I can also reduce my cognitive load by separating the planning from the doing. In an convenient twist, Google Calendar’s “find a time” feature also meshes my tasks with actual meetings.
Alright. So far, so obvious. I have also identified a few productivity anti-patterns (behaviors that negatively affect my performance) which I try to avoid or at least manage. Here they are now.
I know. I just advertised Slack like I was getting paid for it but I also feel it’s possible to be too connected. In larger teams, Slack lets you watch the whole organization function in real-time. That can feel a little like staring directly up the Niagara Falls and it’s as alluring as it is unproductive.
In response, I have learned to limit my channel membership, to make liberal use of channel muting and to re-think things when I’m reading backscroll for longer than a few minutes at a time.
Have you ever heard: “Can you just quickly do X for me? It’ll only take a moment.”?
Our lives are made up of moments and they’re all precious. Technology can also exert unwanted pressure to be ever available and responsive throughout the working day. For tasks in engineering, education, research and writing, this “twitch culture” impacts our performance because interruptions affect our flow. They can be jarring and difficult to recover from.
As a coping mechanism, I tend to just be less available during intensive task periods (like now). It takes a little getting used to but it works. I also try to answer my own questions (Slack search, lmgtfy, …) before interrupting others. It’s a balance so I’m sure everyone’s is different.
We live in a time of explosive growth in information availability. With a little awareness and more of these excellent developer productivity tools, I hope we can all continue to have rich, productive, interesting and happy lives.
Productivity is an extremely important, ever changing and yet very personal topic. We’ve been writing about it throughout July and frankly we’re exhausted. Leave us a comment or tweet about your own developer productivity tools, tips and techniques.
Howdy there! You and I have talked before about how we build Slack bots at SparkPost, but I didn’t say much about how we use them. We use bots at SparkPost to do all sorts of things. We’ve learned a lot and I thought now would be a good time to share some of that with you. I love bots, you love bots, so let’s turn the lights down, light a few candles and have a nice glass of your favorite beverage over some bot talk.
How We’re Using Slack Bots to Maximize Productivity
Like I said, we use Slack bots for a lot of things. We run our standups with bots, we use them to get links to our docs, to post sample data from our endpoints, and to encourage each other. We do internal reporting and monitoring from bots. We track the status of our deploys along with any new PRs and issues on our Github repos all from Slack.
Why do we use bots for all these things? I mean, there are other tools that do almost each one of the things we use bots for. Well, that’s the thing: there’s at least one tool for each of those things. Our Slack bots consolidate everything into one place and one interface.
There are some advantages to using Slack as that central platform for us at SparkPost. First, since we’re a distributed team, Slack has become lingua franca – it’s our primary communication tool – so everyone is comfortable with it. Slack access doesn’t require any special VPN connections (though you should set up two-factor auth for safety). It’s accessible on mobile devices so we can make API calls from just about anywhere. We make our Slack bots easy to use for non-technical people so they don’t have to use developer tools like cURL or Postman.
Basically, since we’re already in Slack on a regular basis, it’s easier and faster to simply perform as many of our everyday tasks from there as possible. Not only does it mean fewer steps to complete something, but we also don’t have to leave the interface where we’re already spending a lot of time. Just repeat this over and over with me:
NEVER LEAVE SLACK. NEVER LEAVE SLACK. NEVERLEAVESLACK. NEVERLEAVESLACK. It’s probably fine.
Botify All the Things!
So how do you choose what to add to your bot? Be on the lookout for things that are inconvenient or painful. Start with the things you do a lot. For example, in our community Slack team we found we spent a lot of time tracking down links to our docs: we’d open a browser, go to the docs page, search for the right resource, copy the link, go back to Slack… It was just awkward. And in that time the conversation would often have moved on. Now we have a single command that will give us a link to the resource our users need when they need it.
Do you have something that only you can do because you’re the only one technical enough? Bam! Slack bot! Or do you want to empower your team to do things on their own? Botify it! Want to let new users know what’s up when they join your Slack team? Bot time! You get the picture. It’s open-ended, the only limits are your creativity and a few pesky natural laws.
How to Succeed at Bots Without Really Trying
Ok, you have this awesome idea for this bot that is going to save you time and frustration and probably the world. You set up a repo and a sweet continuous deployment pipeline for easy deployments. You’ve got 100% test coverage, the build is green. But nobody is using it. Nobody? Seriously? Yep, nobody.
Remember, bots are an interface, just like a web page. And just like any web site they can be hard to use or unintuitive or just plain off-putting. Bots have the extra challenge of being a pure text interface to your code and code is rigid and brittle. But human language is fluid and nuanced and weird. So when you build your bot be creative, funny, and offbeat. Find that unique voice inside of you and channel it into your bot. That helps offset your bot’s rigidity (and even make it endearing!).
Making your bot enjoyable goes a long way to getting users to engage with them. We’ve also found a lot of success by including help text for every command. The skellington library we use for our bots makes help text a first-class citizen and makes it easy to add help messages. The easier and more fun you make the bot to use, the more people will use it!
If you use Slack or some other chat program, bots are a great way to empower your team and make rote tasks easier. Make your bots useful, interesting, and entertaining (in that order) and before you know it your bots will take over the world! Ok, not the world but at least the hearts of your users.
We’d love to hear how you’re using bots! Either post a comment below, or come find us in our Community Slack channel.
We use Slack a lot at SparkPost. A lot. We use Slack so much we just made another public Slack team so we never have to be far from that beautiful brush-knock sound.
We love Slack because we are distributed (I work on a team that spans eight time zones) and being in touch so much helps us stay productive (usually). We also love Slack because it’s extensible. I’ve built a few bots here at SparkPost using the botkit library to help us run standups and to help out our developer advocacy team. I thought it would be fun to share our approach to building, testing, and deploying our Slack bots.
At SparkPost our mantra is “API first”, which is really another way of saying “humans first.” We work very hard to build clean, well-designed APIs that are consistent over time. And we do that because we know as developers that’s what makes our lives easier. So even for our internal tools, our guiding design principle is “what will make this the best tool for this person to use?”
For bots I am usually asking: What makes this command easy to remember? Is the phrasing/syntax similar to other commands or tools the user is used to? Will the users like something straightforward (@bot award a point to @user), or will they prefer something a little quirky (@bot pointify @user)? Maybe both!? Then I sketch out what all the interactions will be. Only after I know how the bot will behave and how people will interact with it will I start writing code.
Humans are great, the best really. If you’re a human, you’re A+ in my book. But robots are also awesome, and they are especially good at the boring repetitive tasks we humans don’t like and tend to mess up. That’s why we automate things like testing and linting to make sure our code quality stays high and unbroken.
For our bots, I set up a TravisCI continuous integration server that runs linting checks and tests on every pull request and every code push. I also add automated checks ensuring code coverage doesn’t drop (otherwise it’s just too tempting to not write your tests 😉 ). Pull requests aren’t merged in unless they pass CI. And once a PR is merged to master, we run it through CI again to make sure there are no regressions introduced by the merge. If the CI passes, the code is automatically deployed to a staging environment.
By automating so many rote tasks, we can have a lot of confidence that our code works and that new features aren’t going to cause regressions in our existing ones. But if I learned anything from Wall-E, it’s that robots can’t do everything by themselves.
Then Humans Again
Automated tests and linting are great, but they won’t notice things like inefficient code paths (I’m looking at you nested for loops). And 100% test coverage is an awesome goal, but that’s only one metric for test quality. Tests can cover 100% of your code without meaningfully testing anything or they can miss important edge cases (like error handling at the end of a promise chain). That’s why every line of code (including tests) is reviewed by another person. Our reviews are conversations, not just throwing code over a wall. Having another perspective can be invaluable. A lot of time, as a programmer I’m focused on the microscopic world of lines of code. A reviewer has a chance to step back and look more holistically, catching something that I might miss. Once the code review is done, we start our user acceptance testing to get more feedback from a non-technical point of view.
It’s important to get feedback as early as possible, this prevents churn later down the road. For our bots I ship one command at a time, complete with tests and docs, and review the changes with a few key users. I want to make sure that everything works for our users. At that point it’s easy to iterate quickly because we have focused feedback.
We have private channels dedicated to user testing staging bots, but you could easily set up a separate Slack team for testing if you don’t someone to stumble on your not-ready-for-primetime bot.
Back to Bots: Automate Shipping
We host our bots on Heroku. We create two apps: one for staging and one for prod. Once a bot passes user acceptance testing in staging, we promote the app to prod using Heroku Pipelines. One of the nice features of pipelines is the same slug we tested in staging is the one that gets deployed to production; there’s no recompilation or re-installation of dependencies. Shipping the same artifact we test keeps our confidence in our bot high, which is good because people are not happy when Slack doesn’t work. If you want to anger someone on the internet, just take away their ability to post cat GIFs.
The Long Way is the Short Way
It’s funny, you would think that all this process outside of coding would slow us down. Taking time to sketch the user interface, writing tests, reviewing code, building automation workflows and talking with people. But we’ve found the opposite to be true. Including people early on, and taking time to build automated tools help us ship more features faster. One of my mentors used to tell me “the long way is the short way.” By investing time and effort up front, we deliver a high quality product that is exactly what our users want: a bot that will show them GIFs of guacamole whenever they want.