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.
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.
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.
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.
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.
It took me two weeks to completely finish the image editor project that I have been really proud of, and I thought the following days would be the most enjoyable moment in the development process: writing some tests, watching those shiny green ticks telling me all the tests passed .. but they didn’t.
As a student going through the cooperative education system at the University of Waterloo, I have the opportunity to start at a new internship every 8 months. This means one thing — a ton of onboarding. I’m definitely not an HR expert, but as I’ve been onboarded four different times at three different companies in the last two years, I have some idea of what makes for a good start at a software company.
At the beginning of September, I started my co-op term as a software engineering intern at this startup going through hypergrowth. What’s hypergrowth? — think, learning to ride a bike by pushing yourself off at the top of a steep hill and figuring it out as you go.
This philosophy makes for a pretty unique first week, and provides a few lessons that I believe can be applied to the onboarding process at any company. Here’s a few things which I think stood out.
As our organization grows, we’ve discovered that it’s hard to scale mobile capabilities across the engineering group. As a scaling strategy, we decided to try embedding mobile developers within product teams. This is the story of our experiences with three experiments.
At the time of writing, we have north of 100 engineers organized into stable teams. Each team is responsible for some part of our product or infrastructure (e.g. Web Dashboard, Publishing, Billing, Analytics, etc).
Our Mobile team works on native iOS and Android apps that include features across several of these product teams. For example, features owned by the Publishing team on the Hootsuite web dashboard would be built and maintained on our iOS and Android apps by the Mobile team.
There is an expectation from our customers that (in most cases) we provide a comparable native mobile experience for the functionality that exists in our web products. An issue that we have run into is that the number of native mobile app developers is only about one sixth of the total number of engineers, thus the Mobile team’s backlog grows much faster and the team feels that it is constantly playing catchup. Because building native mobile apps is such a specialized skill, it’s also hard to hire mobile engineers at a pace that allows the team to keep up.
To alleviate this problem, we ran three experiments to grow native mobile expertise in our non-mobile feature teams. Training some of the engineers on these teams who are interested in native mobile app development is a good compromise to hiring, because existing engineers are already familiar with our products, our technical stack, and our culture.
If these experiments prove successful, we envision having native iOS and Android engineers working on teams that are responsible for a set of product features like message publishing or engagement streams. For example, the Publishing team is responsible for back-end as well as customer-facing functionality related to publishing messages on the Hootsuite web dashboard, it makes sense that the team would also own publishing-related functionality on native mobile apps. The core mobile team will maintain the platform that other product teams will build upon and stay responsible for the overall quality and architecture of the apps.
TDD comes from “Test Driven Development”. OK, but what does “doing TDD” mean? Doing TDD means letting the tests drive your design, hence the “Driven” part in the name. What that boils down to is writing your tests first, watching them fail and then making them pass by writing your code.
Yes, this can sound pretty confusing! But trust me, it’s worth it. Read on to rest of the post, where I present, a step by step process of writing code using TDD.
FYI: There is a derivative of TDD called BDD “Behavioural Driven Development”. Basically, it’s the same thing as TDD: you write tests for your code first, but the difference consists in how these tests are written. BDD describes the tests using the Gherkin language(a known tool for this is Cucumber).
When you write code you must know if it runs well. This means you must know if there are bugs or logic errors. You achieve this by executing the code against an input.
Sometimes when you’re developing a product and you are faced with a difficult problem, a clear view of your application structure can help you understand it and solve it faster. Also, having to read and understand poorly written code can make it harder to come up with a solution for the problem.
By using static code analysis we’ve managed to integrate and develop two tools that improve the overall experience of our developers, thus increasing overall code quality as well as general productivity. Read on to find out how we implemented these tools and how they work in our environment.
Static code analysis means analyzing code without executing it. This concept is most commonly used to check if the source code has any errors before runtime, and it’s most often seen in compilers which can find lexical, syntactic and even some semantic mistakes.
First, we need to understand how static analysis actually works. At its core we have the AST which stands for Abstract Syntax Tree. An AST is a tree representation of the structure of the source code where leaves represent constants or variables and inner nodes represent operators or statements.
Image from http://vinaytech.wordpress.com
Esprima takes the code and returns a JSON formatted, ESTree compatible, object which describes the program as a tree structure. Even though each generated node has its own properties, the “type” property is common to all nodes.