My name is Sam Stagg and I work for Pusher as VP of Engineering. My responsibilities are to grow the engineering team, and to coach project teams and individuals to do the best work of their careers in a fast-paced and highly technical environment. My background is in software engineering in the video games and data industries.
Pusher provides hosted building blocks to help productive app developers move faster and write less code. Our core product enables developers to easily create interactive features for their applications, such as in-app notifications, activity streams, real-time dashboards, live trackers and more.
We just released Pusher Chatkit in public beta. It is a specialised Chat API solution that makes it easy for developers to add cloud-hosted messaging services to their mobile and web apps.
My AMA will start at 1PM EDT today. Ask me anything from scaling engineering teams to building real-time messaging applications!
Latest comments (40)
Do you have any opening for young engineers?
Do you log all channel events on your end? Can I (programatically) access them?
No. There's just too many for this to make sense for us.
What does VP mean? What responsibilites do you have as a VP?
where can i software engineering on the web?
What's your current favorite game and what's your favorite game that you have personally worked on?
Awesome question. As a busy dad, nowadays I like games I can pick up and play a bit more quickly! I love Planet Coaster though.
I'm most proud of working on ToCA Race Driver (and especially the sequel) which was a great introduction to the world of high-latency network gaming from the other side of the fence 😁
Have you found that Pusher's core product works equally well with a seasoned developer as it does with someone who has less experience? What are the learning curves, if any?
It works equally well. We strive to make our APIs and SDKs a delight for any level of developer. And the scalability of Pusher means even the most experienced engineers get a lot of value from the product.
Not really. I'm informed about architecture reviews, and it's ultimately one of my responsibilities to make sure they happen, but I don't do it myself. We try to make architecture reviews one of the competencies regularly practiced by senior engineers and above.
Do you do any coding these days?
If yes, how often?
If no, do you miss it?
Yes, a lot less but I still love it. It's mainly personal stuff now. I'm not sure the engineers would let me near the Pusher codebase 😉
ha! What sort of personal stuff are you working on? Exploring any new technologies?
What do you think is the best way to select tech. Leads? Where I work we are trying to do better at this. In the past, it was kind of up to supervisors, and they just asked people if they wanted to be a lead. Recently, we tried doing an internal job announcement and treated it kind of like a promotional opportunity, with in person interviews (even though it is not a promotion here). In the end, both stratgies have pros and cons, and the general consensus is that the interviews were the better option. I'm curious to know what you think, and what some of your experiences are in this area.
Great question. I think we are at a similar stage. The most important thing IMO is to make sure the possibility of being a lead is clearly open to everyone. We also like to run short projects that let people try on the tech lead hat without committing to being a team lead forever.
Internal job adverts sounds interesting - is that working out?
The internal job announcements were a mixed bag for selecting new tech. Leads for us. Everyone involved told me that they liked the process better than what we had done in the past. It seemed more fair, and it was easier for people to make their intentions clear (i.e. in the past, if a supervisor didn't know someone wanted to be a lead, they'd get passed over; now they could apply for it, because it was pretty clearly announced to all). The big problem for us, was that we had 4 positions, and 3 people applied, and none of them were selected. 2 of the applicants weren't really qualified, and the third was already a lead on a different project. We are about to go through this again, and I want to avoid the situation of not selecting anyone again.
I'm not sure if we can set it up to have tech leads hold the position for shorter durations, with the way we are currently structured, but it is something worth thinking about. I like the idea of people not being tied to being a lead long term, especially if they find they don't like that role.
As VP of engineering, are you involved in project direction and goals as well or are more of the coach and guide for the engineering team?
Terrific question. I'm definitely involved, but as with many things my primary responsibility is to make sure these kinds of things actually happen. It's surprising how easy it is to kick off a project without goals or direction so I suppose I'm auditing that more than actually contributing.
Coaching and guiding are a big part of the role in my experience.
What's the Pusher stack and why were the various technologies chosen?
The core of the main Pusher platform is written in Ruby using the EventMachine framework. We also use Redis extensively for the internal messaging part. We picked this in 2010 because we spun out of a Ruby on Rails agency, and we never had capacity to change it 😁
In the last year we've been building a new platform built in Go to support our new products, which we're finding much more suited to building scalable distributed systems. We use Kubernetes for infrastructure management and React on our front-end.
I'm surprised Pusher is written in Ruby. What are Pusher's main performance bottlenecks and how do you deal with them?
It is quite surprising, but EventMachine is actually pretty good for letting us handle a large connection load on a single threaded Ruby process.
We try to handle all performance bottlenecks with horizontally scalability. And Redis is awesome for handling the internal heavy lifting.
Thanks, I'm definitely going to check out EventMachine.
I have to say (as a lead developer at Pusher) that I wouldn't recommend EM for new projects. It was a leader in the evented-code-in-dynamic-languages revolution and inspiration for node.js, but it did not take off in the same way. Nowadays it feels quite archaic and unloved. The abstractions have not kept up with the other ecosystems in the space.
If I were to start a concurrent ruby project today, I'd try Celluloid (github.com/celluloid/celluloid), but as Sam mentions, we've mostly moved on to Golang for high-performance work.