Here at Workpop we get to work with MeteorJS everyday to accomplish our technical objectives. We’re a rapidly growing team and working within the Meteor framework provides us both with some awesome experiences and some difficulty in collaboration.
Today I’m going to give you 10 lessons learned from working with Meteor in a team like ours, but before we get to that let me give you some perspective into what we do…
What is Workpop?
Workpop is a Meteor application with a huge code base running in production. We’re trying to provide amazing experiences in the hourly and entry level job space by doing some neat things.
1. In the Small Business Space (SMB) there exists high turnover in hourly workers, most leaving within 6 months or sooner of their start date. For a small business owner who relies on people to generate revenue, one missed shift can hurt the efficiency of the business.
We want our employers to find candidates more efficiently. We provide them review tools common to most Applicant Tracking Systems (ATS) and also try to match candidates to them based on their own criteria
2. For the candidates, we want to disrupt a couple things. One we want our candidates to apply to jobs easier. Some businesses still use paper applications! To think, there used to be a time where people filled so many of those out. When I was in high school I remember the barrier of entry was all the paper applications to fill out. Our candidates put in the work for one job application and can use it across all the jobs on our site! Second, we want our users to receive feedback and encouragement on their job applications. We want our users to receive an answer back on their applications instead of being lost in someones inbox!
Now we’re far from perfection, but we have a great time and we’re passionate about getting there.
Our team — the squad
So our team is growing and if you think you’d fit right in, please email firstname.lastname@example.org!
So though it is not necessary in building a great team, I’m proud to say we have a team of brilliant people ranging from young to old and good school to no school. Most of us are computer scientists and we have some unicorns who studied visual arts and finance.
Something we learned about working in a team is… reactivity is a bitch. Hahah. Also dont fuck over your iOS developers by changing the data model :)
Things we learned by working with Meteor as a team
1. Have a code standard
Get everyone writing the code the same way. Pick a convention, write a style guide, and onboard new people to drink your koolaid.
2. Use an IDE that lets you format your code the way you want
We use WebStorm and we think its the ultimate IDE for a team. We can do git blames and find out who wrote janky stuff :). We can also set our spacing guidelines, do debugging on server code, and approach navigating the codebase in the same way!
3. Be mindful of the side effects
When you build reactive code, especially in Meteor, you got to watch the side effects. Make sure your publications don’t effect other pieces of code on your page. One time we had two publications referencing the same collection but one had different fields specifiers than the other. We noticed that one beat the other in priority and our users were seeing a blank page! So just be mindful of your teammates code and features.
4. You’re never too busy to help your team
Naturally as people get on boarded to the team they all learn Meteor differently. If you’re more senior it is so important to take time to help ramp others up. We are never too busy to help a teammate. Collaboration is a of a high value to us.
5. Don’t check in untested code
With Velocity slowly reaching maturity we won’t have to worry about this too much! But until to start bulletproofing your “golden path”, start writing out test cases you’d like to automate (GHERKIN SYNTAX FTW). Test those manually before checking in and submitting a pull request. Once you automate, life will be easier, but just because you don’t have tests doesn’t mean you can’t test.
6. Have stand ups and bug triages daily
We have standup every morning and bug triages after if we’re going to release new features to production. It gives everyone an expectation on what is going to be going out to the users.
7. Go to meetups
8. Explain why
Its not enough to get a spec and say “go”. At Workpop we focus on why. Why are we doing this, why cant we write code like this, why does the user want this. When we know why, everyone gets a little closer to the feature they’re working on.
9. Educate the non techs
Just because someone is nontechnical it doesn’t give you the right to act egotistical. At Workpop we first explain the technical reasons of why something was done a certain way. If they don’t understand we break it down into simpler steps. The nontechs need to have an insight on what we do. It is the only way to work together without killing each other. Programmers get a bad reputation for their egos, and we don’t condone that behavior at all.
10. Have fun
Programming is supposed to be fun. Writing code to solve interesting problems is awesome. I usually call it getting deep in the shit. And doing that as a team, seeing what is accomplished at the end of the day is a pleasure!
Thats it! Just some things we learned while working together in Meteor! I know some of these may not be Meteor specific so I will be writing about some technical difficulties we came across and learned from next! Please add any that you think is vital to working together in a big team!
Part 2: here