How do you support the ecosystem that supports you? By giving away your expertise.
This is the story of our Scala Study Group: an experiment in training and community building.
Tests vs. Types
Scala is our go-to language for our back-end services because it’s proven, reliable, and performant (and it’s really fun to work with). It’s a young language that is still gathering traction in universities, colleges, and industry so our interest was in trying to grow our local community of Scala enthusiasts through experiential education: free hands-on mentorship and social learning.
We ran the free Study Group using the “flipped classroom” model popularized by Khan Academy: students watch the videos at home and do the assignment in preparation for coming to our office once a week. To keep it simple, we opted to piggyback on existing course material and parallel Coursera’s Functional Programming Principles in Scala.
At each session, participants took part in group code reviews and worked through their challenges or the assignments in a group setting. They drove the questions and the agenda, and received guidance from their fellow students and their mentors: Hootsuite Scala software engineers who are actively writing code.
“Nice! I was signed up for the Coursera already. But now I am glad to find a bunch of folks to sync with!” – Johnny H.
“An error occurred, please try again.” Hmm. PC Load Letter? This perfectly nondescript error message came up only in Production and only in a specific scenario. What do you when faced with limited information and a bug you can’t reproduce locally?
This was my first significant challenge as a co-op student. Fixing it involved equal parts debugging tools, intuition, and continuous delivery. Today, I’m sharing how I reached the root of the problem and resolved it.
Let’s say your company starts each year with a kickoff to bring people together, review past performance, and communicate new direction and priorities. A great deal of important information will be shared by those at the top, but how do you keep every attendee engaged and participating? With your entire team in one place at the same time, you’ve got a rare opportunity for everyone to share their innovation, ideas, and challenges. How do you set up that kind of cross-pollination so everyone can learn about one another and from one another?
On Monday January 26th, Hootsuite had its first internal unconference for about 150 people from across all our technical groups: Product, Engineering, Design, IT, Operations, Security, New Product Growth, and Labs (R&D).
My take away from that afternoon?
Look to the people building your company to surface ideas and subject matter expertise – their depth of knowledge and passion about what they do and love can be truly inspiring.
What is an Unconference?
It is an exhilarating whirlwind of spontaneity in which participants pitch, select, organize, and deliver sessions all in the same day. A lack of a planned conference agenda keeps audience anticipation high – and organizers a little uncomfortable – right up until the moment it gets published.
Material designed apps are all the rage these days. Gone are the days of Gingerbread design, and if your app is Holo, you’re already behind. Everyone (including your project manager) will want a shiny new Material App – but what about the people still using older Android devices? You can’t leave them behind, so that’s where the Material Support Library comes in.
Who doesn’t love hackathons? Hootsuite Engineer Alex Palcuie participated in December’s 2014 EU Hackathon in Brussels, Belgium. Alex shares his experiences below (originally posted on Blogspot) about making a difference, new friends, and 2nd place.
This month I participated in the EUHackathon 2014 in Brussels. Our challenge was to build tools that increased transparency and participation in the European Union.
My team built a site that helps the public understand the meeting timetable – with who, at what time, and where – of EU commissioners. We won second place, and had lots of fun.
A codebase with many active contributors grows and evolves like an organism. File systems that store code are shaped like trees, and all of the changes that happen over time are akin to organic growth and decay.
On the sixth anniversary of the Hootsuite’s codebase, Specialist Engineer Bill Monkman spent a weekend building a beautiful visual artifact that conveys those organic qualities and much more. Using Gource, Andrew Caudwell’s amazing code repository visualization tool, Bill has given us a macroscopic, time-lapsed view of every change, big or small, that has gone into making our product what it is today.
For those of us who have been fortunate enough to be a part of the team that builds Hootsuite products, being able to see our codebase grow up from its humble beginnings is a moving experience. Now with over 10m users, Hootsuite engineers get to work under the hood of a codebase that runs on hundreds of Amazon instances, and processes millions of social messages every day.
In this video, we are able to see not only how our code has changed but also the evolution of our team. We see some of the major technology decisions we’ve made along the way (and their consequences). We see big wins, and even a few things we might have done sooner or a bit differently.
When we showed this video to people outside of our team they also saw something of the beauty in a large codebase evolving over time. So, we decided to share it more broadly with our technical community and spark some conversation.
What we hope is evident is that software engineering is not just about putting headphones on and going into the zone for protracted periods of time. While there is some of that to be sure, we believe that building software is a team sport and a creative endeavour, the output of which has a life of its own.
About the Author: Geordie Henderson is the VP of Engineering at Hootsuite. Follow Geordie on Twitter @geordie_h.
Collective action is a wonderful thing. Meetups and open source projects are two examples of people getting together to have a conversation about the things they care about, with the aim to do something positive for themselves and their community. How can this collective action happen inside your organization? At Hootsuite, the answer is Guilds.
Guilds are a self-organizing group of people with common interests. It is a natural forum for social interactions that build relationships that, in turn, promote cooperation, cohesion, and productivity. 
Guilds provide a horizontal communication layer across our Product Engineering teams. Our engineers, testers, and other staff use them to set their own missions, to establish technical roadmaps, to take on joint tasks for their grassroots initiatives, and to promote education through experiential learning. This collective action benefits their members, their craft, and our organization.
Sometimes a wonderful tool comes along that makes a kludgy process radically better. Packer (thanks again Hashicorp!) and ServerSpec are great examples. The 1-2 punch of Packer + ServerSpec combined with the automation abilities of Jenkins made a significant impact on our automated server image creation. This combination reduced our time-to-deploy, took our visibility from ‘translucent’ to ‘transparent’, improved our traceability, and generally made our Ops Engineers much, much happier. Read on to find out how these tools can make you happy too.
When writing Android code, there are many situations in where you’ll need to make network calls. There are several different ways of performing these network calls, and after reviewing them all, we’ve determined some are good, some are bad, and one in particular is just plain ugly. We’ve compared and contrasted several methods, and along with some code examples, will provide some basic insight into using what we think is the best method of making network calls in an Android application.
Ow.ly is our URL shortening and click analytics service, and a critical part of Hootsuite because it handles several billion clicks a month. We love Ow.ly, and we’re delighted that our customers feel the same way – but the booming popularity of Ow.ly introduced scaling issues for our Engineering Team. We could have mitigated these issues by keeping with our current infrastructure and code framework, but it turns out that’s a lot of effort and not cost-effective. Instead, we searched for a solution that would allow us to scale Ow.ly, keep our AWS costs in check, and allow us to build new functionality … all while maintaining 100% uptime. Easy, right? Kinda :).
We turned to Typesafe’s Play Framework to refactor and scale Ow.ly’s services. Today, 100% of Ow.ly’s API, the web UI, and the URL redirect services are all running off the Scala-based framework.
After our successful relaunch, our friends at Typesafe produced a case study on our work, our research, and how we decided the Play Framework was the best solution to our scaling issues. Check out the case study to learn more, and visit the Typesafe blog for more innovative technology solutions.