A Day in the Life of LivingSocial

On Wednesday, I had the opportunity to shadow at LivingSocial with Tony Pitale. Tony is awesome. He was a coach at the first RailsGirls workshop and really enjoys teaching (which is good for me because I enjoy asking a gazillion questions). LivingSocial is, by far, the largest company I have shadowed at so far. A lot of the initial part of our day just focused on looking at different tools that LivingSocial uses and how the company is structured.

There are over 100 developers that work for LivingSocial, which to me is interesting to think about in terms of culture. I’ve met with some smaller teams so far, teams that almost all work from one office, teams that work entirely remotely, and the in between but none with the sheer mass of developers that LivingSocial has. It was really informative for me, especially as I look at different company cultures as a job applicant, to learn about how tasks are determined, how teams communicate with one another, how standups work, and what sorts of professional development and peer learning opportunities exist at their size.

LivingSocial has a lot of different engineering teams. Each team is responsible for one to a few apps. That team is responsible for knowing all the logic of that application’s purpose and also helps different teams work on different code without stepping on toes, interfering with others, etc. There are a ton of different applications. In order for the applications to communicate with one another, a lot of synchronous API calls are utilized. This means, basically, that when an event happens, the event needs information from a different application in order to continue and make the process happen. There are also asynchronous API calls for other types of events and application communication.

Finally, LivingSocial uses a ton of different tools to measure and provide information about what’s happening. To just name a few we looked at were graphite, rearview, new relic, hive, and kibana. Each has it’s own purpose and tracks something different. The really cool thing about looking at all of these different tools was figuring out how they are used to see what’s happening. For example, when an alert, error, or bug report comes up, you can go into these tracking tools to get more information on what is happening and also to make improvements like site or transaction speed.

Other smaller things I learned:
*If you drag the icon of your sublime text file into the terminal, it’ll put the file path and you can run the file!
*Serializers. What interesting pieces of applications. Serializers say when you take a record out of a database, these are the attributes that we want back in JSON. They’re good to use when you’re building an API. You use something like serializers so that you don’t have to make a class with a method as_json which defines what would get returned as JSON. (Serializers relate to an interesting conversation I had with Jim Gay about presenters and what presenters are used for. As I learn more about rails, it’s also been really interesting to see how you can continue to break out these pieces of information to make cleaner, more organized code.
*when TDDing something, you can also use it to think as a design helper. If your test for a specific item is getting to large or crazy, it’s probably time to break it into different pieces and look at the code design a bit.
*A good way to organize TDD tests are by thinking through the logical order. So the test order should be setup, execution (thing you want to run), assertion (event did happen), teardown.


Overall, a really interesting day at a really interesting company with a really interesting setup and a really interesting teacher!!

A Day in the Life of Spree

A few weeks ago, I wrote about my awesome experience shadowing at Treater. This past week, I was able to shadow at Spree. Spree has a great space in Bethesda and does some really interesting things. Spree is an open source e-commerce platform. I was able to look over the shoulders of JD and Wes while there and ask LOTS of questions. Here are some highlights of what I learned…

A lot of the work Spree does (or at least was working on that day) is related to APIs. Having never had the chance to work with APIs (but conceptually knowing a bit about them), they explained to me the different parts of an API, how they have used them to help coordinate purchases and logistics. I also learned about things like query limits and some interesting facts about testing APIs.

A few other random tips I picked up included bundle console, which is an irb session with access to gems in a gemfile. This is most useful when you want to test something outside of a rails application, and therefore don’t have access to rails c. Also, a github tip, when you’re in github, if you press “t”, you can search the repo!

Finally, I didn’t get much into this but one thing I saw was a little bit of work being done in backbone.js. I don’t know much about backbone, but it was interesting to see it “in action” a bit.

Overall, my day at Spree was really interesting. They’ve got a great team and it looks like they’re doing some really interesting work.

A day in the life of Treater

One of the challenging things about entering the world of development was that I felt like I came from a completely different universe. I got a degree in political science and near east studies, always thought I was destined for a job in a government agency and then almost accidentally fell into the Jewish nonprofit world and loved it. For years, my job was about created experiences, building community, taking people to coffee… very different than the day-to-day of development. I saw a little bit more of a developer’s day-to-day in the startup world, but most of the people I work around are the only tech person on their team. One person responsible for all tech is different than how teams function and what a company culture looks like for startups that are just a tad bit larger.

I had the opportunity this past Monday to shadow the dev team at Treater for the day and it was great (Thanks JD for giving me the opportunity!). Treater seems like a great place to work and I learned a TON in just the day I was there (including my first look at someone using vim to code instead of sublime text and finally seeing what hipchat is all about). One thing I wanted to highlight was the idea of a scrum meeting to do sprint planning.

I had heard of scrum meetings and sprints/sprint planning before but had never had the opportunity to see first-hand what happens at these meetings, how development pieces are discussed and how the next few weeks are planned out. Additionally, I’ve run a lot of meetings in my life and have always been a part of a hierarchical structure but have always been curious about larger startups with flatter structures.

The scrum meeting starts with the scrum master (all this, by the way makes me think of rugby which is really not anything like one of these meetings). This meeting had three parts: review the last sprint, retrospective, and go through the next sprint, all utilizing the company’s Trello board. Each part is important and I was impressed by the fact that everything everyone said was acknowledged and considered. The review of the last sprint helped to set additional goals for the current sprint (sprints are two weeks long). After reviewing the last sprint, priorities, deployment dates, and phases were discussed. The retrospective was the most interesting I think. It gave each team member a chance to think about where they were at after the last sprint and address what they themselves or as a team could do better in the upcoming sprint. Finally, the next sprint was reviewed, discussed, and assigned to different people. It was really interesting during the future sprint discussion to see how each part of the team interacted (ie- front-end, back-end, testing, business, etc.). Being a part of the scrum meeting also gave me a really good understanding of what was going on so I could just jump into the code more effectively in the second half of the day.

So, if you’ve never been to a scrum meeting or done sprint planning, that’s what they’re all about (or at least based on my sample size of 1 company). Hopefully I’ll be shadowing at more companies in the future (if your company is metro accessible and willing to let me shadow for the day, please let me know!).

I just want to close by thanking the whole Treater team for being so welcoming and answering all of my questions. I really had a great time and learned a ton!