Cloudberry provides simple, intuitive digital experiences. Our challenge was to communicate the idea of delivering a “good” experience. We sought to create an identity built upon this unmistakable emotional response and strike that same emotional chord through the design. The solution isn’t overly adorned or complicated. We’d like to say it’s, well, “good.” An unmistakable monogram that when rotated communicates the universal symbol for satisfaction.

The materials feature hardy letterpressed stationery, foil stamped wireframing journals and fun, elementary-like illustrations.

Bitmaker Labs Exclusive – HackerNest: Women in Tech

On November 25th, the HackerNest social opened doors to three of their speakers and many guests to discuss Women in Technology. Each of the speakers were generous with sharing with us their insight into the challenges they face everyday and the highlights of their work in the tech industry.



Pearl Chen, founder of Karma Laboratory, started coding at the age of 13 and emphasized how important it is for women especially to take risks. As an educator herself teaching children to code, she finds that girls at a young age are already hesitant and fearful of trying new things. She recently worked on a redesign of TELUS’s website in an effort that included changing their corporate culture to a startup one of agile, lean practices. She advises novice programmers to never give up and work through those error messages.



Leila Boujnane, is the CEO of TinEye, an image recognition search engine. She views mentorship as the opportunity to pass along her knowledge and expertise onto someone in need of the skills. She says that in Canada’s education environment, there is less exposure for the tech industry and the opportunities available. Leila believes coding should be taught at an age as early as four. Her advice is as simple and concise as “Start.”

Originally posted here on December 16, 2013.

Code Collaboration Jungle: Working In a Fearsome Four-Some

The October 2014 cohort is about to begin their final projects. The last assignment is Crowdfunder, a copy of Kickstarter, for which possible user stories total up to about 40. On this week’s fateful Monday afternoon, when the assignment was introduced, we were explicitly instructed to work in groups. Most of my cohort opted to work with one other person in a pair. I decided to work in a group of four people. If you listen to the previous cohort’s podcast here (https://soundcloud.com/bit_by_bit/bitmaker-labs-podcast-episode), they will let you know that this probably won’t be a good idea for the final project. But for experience’s sake, I wanted to try it out on Crowdfunder, because it’s the last assignment meant to prepare you for the project. And moreover, in today’s work environments, especially in modern-day devshops, working in a team is near inevitable.

That being said, the challenges in working in a group of more than two aren’t as monumental as I first expected. Today’s the last day of the assignment. Throughout the days, it required clear communication, patience, and strategy. Sound GitHub practices will save your sanity, and keep the momentum going. I’d like to outline the most important difficulties and offer some words of encouragement.



  1. Working in a group of four means that you will be splitting up the work between two pairs of programmers. Hopefully you’ve already been working in pairs throughout the weeks Bitmaker. But regardless, work on a single computer together. Two brains are stronger than one! You will make less minor mistakes that bog down the coding process, such as typos and faulty syntax. You will be able to break down the logical steps needed to tackle a program’s feature together. And explaining things the other person doesn’t understand helps you process the information yourself, creating deeper associations in your mind.
  2. Use Github well. Be a friend and describe (thoroughly!) what exactly you’ve just committed. We’ve been given lots of advice on this at Bitmaker, but essentially, you want other people to know what you’re doing. The more information you offer, the more likely your group members will like you.
  3. Do standups. Standups are like a pow-wow, where everyone regroups and goes over what he/she has been working on, what issues came up, and decide who should do what next. It’s also useful if you’re merging branches back into the master. If both pairs have branches to merge, and the two features are for similar areas of the app, there will be conflicts to deal with. Merging conflicts will work more fluidly if everyone in the group is present and ready to discuss the changes required to maintain your master branch in a deployment-ready state.
  4. Do not be afraid of conflicts (in your code, specifically). The prospect of merge conflicts may be daunting at first. As long as you’re in your own feature branch, and the master branch is in working order, there’s no reason to hold back on foraying into unknown territory. If both pairs know which features are being worked on, you’ll be able to communicate what changes need to take place later. Just tackle the next feature, and get your group members to sit with you and pull through the conflicts later.
All in all, it’s been a rewarding week. I was initially very intimidated by merging conflicts, but when everyone’s aware of each other’s progress, it can go swimmingly. Because it’s more difficult than having one workflow of your own, once it’s all merged into the master again, it feels like a bigger win. And really, with all the communication and planning challenges that come with working in a bigger group, you should celebrate every one of these wins. So why not try out working in a bigger group? It’ll prepare you for a future job in a devshop, and you’ll find people who you can work well with. Wins all around.

Originally posted here on December 9th, 2013.

Who’s the App For? Paring Down to the Right Idea at ProductTO



ProductTO is a casual tech meetup of about 50 guests who get to participate in a small group discussion about Product Management. If you’re wondering what exactly Product Managers do, see the slide at the end with some quotes from Jack Dorsey of Twitter, David Kelley of IDEO, among other notables. Last Tuesday at Shopify’s Toronto headquarters, Elizabeth Caley (VP of Product at Firmex), Daniel Patricio (Product Manager at Shopify), and Tarun Sachdeva (Head of Product at Wattpad) each brought up an issue or challenge to discuss. The discussion encompassed a topic of interest for us Bitmakers: before the launch of a product, how can we ensure that we understand the user to implement the right features and design? In a way, we are all going to be playing the role of a PM for our final projects. We’ll be making decisions on what our minimum viable product entails, keep track of our progress, and design the “final” product.

During the group discussion with Tarun from Wattpad, he said that it’s important as a product manager to fundamentally understand and “get” who his users are. For his team at Wattpad, a self-publishing platform for anyone and everyone to write stories and share them, knowing who the users are is not at all self-evident. The team at Wattpad strives to conduct extensive research beyond what their users do with their product, but to find out what they do on the internet as a whole. They found that these storytellers, mostly in their teens and well connected with their peers on social media, have launched off of Wattpad to extended their reach into YouTube videos, blogs, etc. They tell stories in all kinds of mediums, and their goals, wants, and habits are informed by this single drive. It helps Tarun’s team understand and foresee what these users want from their product (one for each platform). It helps them also to adapt to changes or shifts in user desires in the future.



When you’re whittling down to a single project idea, try to see if it has one single purpose for a specific user. This week, I’ve received the advice from some of our instructors to “build something that solves a problem in your life.” Another advice I heard was to “make it simple.” After attending the ProductTO meetup, I have a better grasp of what exactly they had meant by that.

The advice “build something to solve your own problem” is to help you identify who the user is. It’s an easier question to answer if that user is essentially yourself. Because you’re able to fully identify and empathize with that “user,” you’ll be able to create a more intuitive solution. And more importantly, your product will stay within a specific scope without trying to do too many things at once. (It really shouldn’t be trying to please everybody, so to speak.) That’s why Tarun wants to know what Wattpad users do outside of his app.



And “make it simple” is something to keep in mind even after the Minimum Viable Product. Every time you suggest a new feature, you have to ensure it’s not only feasible (budget, time, technical constraints), but also that it meets user expectations.

I’d highly recommend attending a ProductTO event. It’s a casual, and less intimidating event where you get to have in-person discussions with professionals in the field. See how they respond to your ideas! They deal with the problem of viable products every day, and had years of experience in wrestling with their user stories. Getting to hangout at Shopify’s shiny Toronto office sure didn’t hurt either.


Originally posted here on November 29, 2013.

#BLOctober2013 Cohort – Week 5 – Life As A Bitmaker

Exactly a week ago I had my first hackathon. The process of drafting user stories, drawing out model associations, then writing the code itself with another person was great experience to have sooner than later. And we achieved an MVP, a walking skeleton. But throughout the twenty-or-so hours, I wished I could contribute a lot more than I did. I found that I was providing ideas for solutions, and took the backseat when executing those ideas.

I mention this because at the Open House Alumni event last night, the main advice every alum agreed upon was to focus your learning. Find out exactly what you’re good at and build something. Zero in on one skill, be it Rails, D3, or JavaScript & UI design. In fact, even at the Rails Pub Night on Monday, I received advice from hiring partners to make sure I can clearly communicate my achievements in interviews during Hiring Week.

The applications that Bitmaker alumni created for their final project gave me a fresh sense of urgency and inspiration. The October cohort is well into the second half of our training period. It’s time to set a clear goal and work day by day to get closer to that end point.

Lots of keyboard button mashing.

It’s a coincidence that I’ve recently finished reading The One Thing by Gary Keller and Jay Papasan. His book is a compilation of research that supports his advice: find and stick to one thing; aim for mastery. He hedges that with several chapters of practical guidance (ex. Aim for the Big Goal that’s just within possibility, but outline exactly what small steps to take to get there).

I think it’s easy to get overwhelmed at Bitmaker. There’s a lot to learn over the nine weeks, and we jump from Ruby to Rails, to Javascript and jQuery. The past five weeks went by and I’m realizing that you definitely need to orient yourself towards your own goal. As the alumni members also said, not everyone is a great Ruby on Rails dev, and you will find you’re good at something else. You might just want to focus on front-end development, design, or you may really just “get” Rails. Remain open to ideas for your project, but make sure you’ve found your “one thing.”

Another great advice that a former Bitmaker told me was to find a good pairing partner. The difference in skill level may not be as significant as how willing the two of you are willing to work together. Explaining your own though processes out loud, and making sure you’re on the same page is not as easy as it sounds. I definitely wasn’t used to it at first, and had to consciously make myself verbalize what I’m thinking.

In the next week, I’ll be working on my front-end dev skills in preparation for the final project. I’m also going to try building a Rails app from scratch on my own to be able to work through the back-end process with more ease. Bit by bit, as we say here, I hope to become a full-stack dev!

Originally posted here on November 22, 2013.