Posts from November 2015

At first glance, technical conferences may seem like a waste of time and money. Why spend hundreds of dollars to fly somewhere to hear the same talks that can be later found on YouTube, or read about same topics that can be found on countless blogs?  If you’ve been to any good conferences, however, you’ll know that it’s about more than just the talks themselves. Where else can you:

  • Talk with the people who write the software you use every day?
  • Discuss the war stories behind the blog posts, and hear about the realities of how the work actually got done behind the scenes?
  • Have those random hallway conversations that introduces you to new technologies or processes that could revolutionize your entire way of working?
  • Make connections with other developers and invite them back to speak at your office?
Conferences are about more than just the talks. They’re about the ability to learn and make connections with fellow developers who are in the same trenches facing the same problems.

During my time at Hootsuite, I have had the privilege of both attending and speaking at conferences, in addition to being an active participant in the Tech Meetups in Vancouver. The number of connections and conversations I have had over the years have been invaluable for my own career development, including my experiences at technical conferences. Read More …

At Hootsuite, we’ve been working on restructuring our front-end architecture using React and Flux. This has given us the opportunity to explore the benefits we gains by structuring the data on the front-end as immutable collections. As part of the Engagement team, a group of us are working on Streams, the part of the product our users directly interact with when they use the Hootsuite dashboard. This is one of the major chunks of the product being migrated over from Backbone and jQuery.


For those who are new to React, it is a JavaScript library for building user interfaces, built by the folks over at Facebook and Instagram to enable them to build large web based application with data that changes over time. It is often valuable to think of React as the view part of the Model-View-Controller pattern. Flux is an architectural pattern that complements React by utilizing a uni-directional data flow. When a user interacts with a React view, the View fires an Action that goes through a Dispatcher to update a Store that holds the application’s data and state, which in turn updates the Views. Uni-directional data flow ensures that a change in application’s state is updated wherever the state is used without forcing the developer to update the code everywhere the state is used.

Source: Flux Overview (
Source: Flux Overview (

You can learn more about React and Flux by reading this in-depth post written by my teammate, Catherine Tan:

Making React Even Faster

As part of building out our new front-end, it was important that performance was a concern that we kept in mind. With customers relying on our product to be highly efficient and robust, this was going to be a primary concern as we moved over to React and Flux. A key improvement metric that can be looked into with regards to React is how often a component re-renders. That’s where immutable data comes into play and provides a better way to optimize the process of re-rendering.

The way React works is by maintaining its own fast implementation of the DOM tree called the virtual DOM. Whenever there is a change in the UI, React makes a new virtual DOM and compares it with the old one, and if they’re different, it updates the actual DOM, minimizing the number of mutations. To improve performance, we need to ensure that only the part affected by the changes in the data is re-rendered. To allow developers to do this, React provides a component lifecycle function called shouldComponentUpdate which runs every time a component is re-rendered. We can couple this function with immutable data structures to ensure that a re-render only happens when the data has actually changed. Read More …

I always enjoy meeting eager prospective candidates and representing my company in public. I love sharing what I do and hearing unfiltered perspectives from real people in my field. When I’m looking at a company, that’s what I want to hear about – not forced enthusiasm about foosball tables or similar perks by an executive or manager, but real stories about the work and the environment. With that in mind, when it was our turn to pitch at Techfest, we wanted the audience to hear directly from someone who’s in a position they’re aiming for.


To me, what always set Hootsuite apart and what makes me love coming to work everyday has always been trust – the trust that our team has in one another.

My Pitch Read More …

Everything changes and nothing stands still – Heraclitus

Someone emailed me recently to ask about “the good, the bad, and the ugly” of Guilds, because almost a year has passed since I first wrote about them. We set up Guilds to tap into our desire to learn and improve how we do things, as well as facilitate horizontal communication and collective action across our stable teams. Most times our Guilds aim affect change on something external, but this post focuses on changes within the Guilds themselves. Here are some insights from a recent retrospective on Guilds that we held in July. Guilds session at July Unconference

1. Do > Talk

Hands-on sessions have higher engagement and a high participant return-on-time-invested. Some examples from our technical Guilds include coding workshops, group code-reviews, and mini-hackathons.

2. Why Did People Show Up?

Are members looking for a support network? Do they want a place to learn? Why did you start it? What do people want to get out of this Guild? Kick off your first session with your perception of problem, and a vision how the guild will help address it.

Read More …

In one of my previous positions, my co-worker let it slip that my team called me the “diversity hire” during a team meeting. It was the first time I had heard someone refer to me like this. As a woman in technology, I always wonder whether I’m being hired because I’m the best candidate, or because the company has to meet a quota. So, when I heard the comment about being the ‘diversity hire’, I immediately thought that I was an inadequate engineer. It made me doubt myself. It made me think that I wasn’t good enough, or that I didn’t have what it takes to be a software engineer. To be honest, it made me want to leave engineering.

As time passed, I continued to be called the diversity hire; whether it was by co-workers, people I knew who were purposely trying to get me down, or friends who were making jokes. Over this time, I became desensitized to it, and I now embrace it – even if I was only hired to add diversity to the team, I’m being given the opportunity to grow and learn. If I hadn’t loved software engineering so much, I probably would have left to do something more “suited” to females after the first time I was called the diversity hire. Being the diversity hire has awful connotations, but company diversity is incredibly important.

Read More …