The callback has been invoked, the Promise^☀ fulfilled. I’m super-excited to be rejoining Pusher to head up evangelism and developer experience.

This leaves a BladeRunnerJS Developer Evangelist role vacant so please get in touch if you’re interested.

^☀ This is a play on words. Rejoining wasn’t planned.

Rejoining Pusher

When I left Pusher back in June 2013 I said it was the best job I’d ever had. I’ve enjoyed my time back at Caplin, but I’d still say that the most enjoyment and best sense of achievement I’ve ever experienced was during my first stint at Pusher. So I’m extremely excited to be rejoining.

Some would say you should never go back. I disagree. My frequent returns to Caplin have proven there are benefits and both myself and Caplin have benefitted from this in the past. Time away can make you aware of what worked and what didn’t. You can make sure that you do the things that worked and find alternative solutions for those that didn’t. When you step away you see opportunities and benefits that you couldn’t see from the inside. I’m very pleased that my contribution to Pusher at the very beginning has legacy, I’ve maintained a good relationship with everyone there and that Max, Sylvain and the rest of the team will have me back! If you’re interested in joining me at Pusher, we are hiring.

Evangelism/Advocacy/Relations

My new job title will be “Head of Developer Evangelism”. I guess that’ll look good on LinkedIn. What I hope it reflects is that having “evangelised” for over four years that I have a good understanding of developer relations/advocacy/evangelism, why the role is required, and what needs to be done in order to fulfill the business needs in this department. I chose to go with the term “Evangelism” in my job title rather than the other options as I feel it better reflects my attitude about realtime web technologies. I still feel there is preaching to be done to convince others about how awesome realtime is! And, as before, this won’t just be about Pusher, it’ll be about realtime in general. Of course I will also advocate for, and build relations with, developers who use Pusher.

I’m going to again focus on talking about and demonstrating how beneficial - and cool to develop with - realtime web technologies are. Pusher are a leading name in the realtime web technology industry so it’s fantastic to be able to represent such a company when giving talks and when writing articles. There are still many developers and business decisions makers who aren’t aware of realtime web tech so I really want to reach out to them and convince them of the benefits and uses cases.

So, if you’d like me to write an article for your site or speak at an event on realtime web technologies please get in touch ([email protected]).

Developer Experience

As well as my love for realtime web technologies, I’m still passionate about developer tooling. Pusher is a hosted developer tool: it’s purpose isn’t just to make it easy to add realtime functionality to web and mobile apps. It also makes complex things simpler in order to make the lives of developers easier. So I’m really pleased that I’m going to be involved in maintaining and enhancing the Pusher developer experience including:

• the onboarding process - quickly showing what Pusher is capable of doing for you and in doing so making it easy to get started and reach a point of achievement as soon as possible
• documentation - ensuring that the information required to get the most out of Pusher is clear and accessible
• libraries - ensuring libraries offer common functionality on top of our raw WebSocket, HTTP fallback and REST APIs.
• gathering feedback - by attending hackathons, working on support and feeding that back into the product
• developer tools - the Pusher Debug Console and Event Creator are awesome. More stuff like this please!

I’ll offically start back at Pusher from 15th of December. But I’m already set up with my re-activiated [email protected] account and am raring to get started. So, don’t hesitate to get in touch with me now regarding events, articles or any questions at all you have about Pusher or realtime technology in general.

Did I mention I’m excited?!?!

What about BladeRunnerJS?

In addition to writing about rejoining Pusher I wanted to share a bit about BladeRunnerJS.

I joined Caplin (for the 4th time) to help them open source and evangelise BladeRunnerJS (BRJS). To help a company with the process of open sourcing, building a brand around an open source product, identifying the USPs and innovation of a product, giving talks and blogging about them has been a rewarding challenge.

One of the great things about Caplin is you get to work with a bunch of friendly and innovative people. So I’d like to thank Andy, Dan, Dominic, Ioana, James, Pre, Rich and everybody else I’ve worked with over the past year and a half.

One of the things I’ve particularly enjoyed about this time is that it’s allowed me to take on a product owner role as well as one of evangelist. Providing input into a product is one of the things I really enjoy about the evangelist role. The level of impact you have on a product as an evangelist really depends on the company. But I feel I’ve positively influenced the present and future BRJS.

A big challenge when open sourcing and evangelising BRJS is that it’s not a simple product. It does a lot of things “out of the box” that could be achieved gluing a number of other tools together. The belief is that Caplin’s customers want to be productive from day one - the first line of code you write should be feature code - and BRJS does make that possible. But what this means is that in order to evangelise BRJS you need to convince others about a large number of concepts and ideas. Don’t get me wrong, you can still evangelise smaller topics like the general issues that you’ll come across when building large complex front-end web apps, about testing strategies with large JS apps and about componentised web apps.

But, in order to appreciate BRJS you really need to think at scale. You need to understand that your application will be large; will have a very big codebase, will have a codebase that’s around for a long time, will be contributed to by multiple developers working across multiple teams and needs to have an architecture that supports complex component interactions and technological change. As I said, it’s a challenging task.

It became clear that the sweet spot for BladeRunnerJS is Enterprise scale organisations. The sweet spot for me isn’t just Enterprise; I do like to go to Enterprise-focused events, run workshops and hold lunch ‘n learn sessions, but I also like going to local meetups, going to hack days and thinking in the small. For BRJS to have the best chance of adoption it really needs to focus on Enterprise and those that think about programming in the large.

That alone isn’t the only reason I’m moving on. For me the draw of Pusher - and again focusing on Realtime Web Technologies - was just too strong.

If BladeRunnerJS sounds like the sort of challenge you’d like to take on, then Caplin may have a role for you. Please drop me an email if this interests you.