Mentorship from a n00b's perspective

Here are the slides and notes from my lightening talk at RubyConf 2013 in Miami.



While at RubyConf, I did my first lightning talk!!! I have to give a shoutout thanks to Jim for suggesting it in the first place and a bunch of the other Arlington Ruby folks for helping to encourage me and make sure I went through with it. I literally felt more and more nauseous as I wrote each letter of my name to give the talk. I walked up on stage and the room was packed! I took pictures of the empty room and posted them below to get a sense of the space and when I walked up on stage the only thing I was thinking was “What was I thinking?! Oh well, I’m here now so let’s do this!)

Here’s some more info on the talk that expands on the slides a bit.

I chose to talk about mentoring from a n00b’s perspective. I’ve been learning how to code for a little over a year now. Since I started, there have been a lot of people who have been really incredibly helpful. They constantly gave up their time to help answer questions, provide guidance, and give encouragement… and I’m grateful for each of these people but some were easier to learn from than others and that’s ok. Mentoring is hard. It’s difficult for the mentee and it’s difficult for the mentor. Here are some of my tips to being a more effective mentor.

1. Understand that at the beginning, I don’t know what to ask and everything sounds like a foreign language.
When I first started learning and people would say “what questions do you have?” or “how can I help?” I would just tell them I was fine because I didn’t know what to ask. I just went through the tutorials and kinda understood what was going on. And then, when I sometimes did ask a question, the answer often included words or acronyms that I didn’t understand. And so I really appreciated when people encouraged me to be unabashedly curious and to ask any and all questions that popped into my mind and even interrupt them if I didn’t understand a word they used.

2. Don’t go down the rabbit hole
In groups of beginners, I often see someone ask a question and the person explaining wants to give a full explanation. Therefore, they will answer the question, explain how it relates to all of these other things, and give additional articles and books to read if they want to know more. This seems really helpful in terms of laying out the complete picture but at some point the person who asked the question is completely lost and generally feel like they’re never going to be able to understand all this coding stuff. So make sure you’re checking in, not going too far unless the person asks additional questions, and let them know that they’ll get to the point where they’ll be able to answer these questions for others.

3. Understand if you’re not understood.
This one is really challenging. There are times when I ask a question and someone tries to explain the answer to me. They could try explaining it in 15 different ways using all sorts of examples and I just won’t understand but then another person will walk up, give an explanation, and it will just click! Don’t take this personally. It’s okay to ask others how they would explain a concept if you see the person just isn’t understanding you and it’s important to recognize that people learn in different ways and understand different teachers.

4. The answer to the dreaded “what should I read?” question
In forums, groups and on IRC, I see this all the time. Someone asks “what should I read to learn more?” and they get a flood of responses… books, authors, titles, blogs, everything… but no direction. They leave with a long list of things to look up but without any guidance on why to read certain books or when. So, give direction. Suggest a title but also provide information on why they should read the book, where they should be in their learning process when they read it and what sorts of information they should be hoping to glean from that book.

5. Don’t put your fingers on my keyboard
This one may be the most challenging for experienced developers. I know that it is painful when you have to say each letter, symbol, and space that a person needs to enter into the terminal. It’s easy to say, “let me just type in a few commands to move us through this piece” or when you encounter an error to want to just grab the computer to quickly research what the solution might be but if you have the patience to tell the person learning what to type or what to search, they’ll learn a lot more.

6. Help celebrate the small stuff and motivate to do the big stuff
When I first started learning (and even still), everything that I did was so exciting!! But I assumed that my little celebrations would be silly and miniscule accomplishments compared to the more experienced developers. It was both exciting and eye-opening when they helped me celebrate the small things making sure I realized that those small things weren’t so small. I mean, how many times have you celebrated when you got different error message? If no one tells you that is worth celebration, a n00b would never think it’s worth celebrating. And then motivate to do larger things. My local group helped push and encourage me to do a talk at a local meetup and to do this lightning talk. I would have never even considered either thing if they hadn’t suggested it to me.

This is a talk that I intend to expand upon and present in the future again to the local Ruby groups here in DC. I’m not sure when exactly that will be, but I’ll be sure to post on the blog when it happens. Thanks #rubyconf for all the support when I was up there on stage!

6, I have 6 Eulers

Euler 6! This is getting a bit more difficult to post about the Euler problems because I've actually completed all 10 a few weeks ago now. When I go to post, I find that I'm trying to remember what I did, where I was at, and what my thought process was. So, a word of advice, if you're looking to blog about a bug or something you're working on, do it right after you finish figuring it out.

Now, onto the problem!

The sum of the squares of the first ten natural numbers is,
 12 + 22 + ... + 102 = 385

 The square of the sum of the first ten natural numbers is,
 (1 + 2 + ... + 10)2 = 552 = 3025

 Hence the difference between the sum of the squares of the first ten 
 natural numbers and the square of the sum is 3025 − 385 = 2640.

 Find the difference between the sum of the squares of the first one 
 hundred natural numbers and the square of the sum.

This one was a good one to roadmap out before I got started. Once I broke it down into a few pieces, it was also not super complicated to solve. So I know I had to find the sum of the squares. And then, the square of the sums. And finally, the difference between the two. Breaking it up into the three pieces also lent itself nicely to writing tests because I wrote tests for each of those three pieces and then a test set for the numbers up to 10 and a test set for the numbers up to 100. Here are the tests:

require 'problem6/problem6'

describe 'up to 10' do 
  it "finds the sum of the square of the first ten numbers" do     
    expect(Problem6.sum(1..10)).to eq 385
  end

  it "finds the square of the sum of the first ten numbers" do
    expect(Problem6.square(1..10)).to eq 3025
  end 

  it "finds the difference between the sum of the square and the square of the sums" do 
    expect(Problem6.difference(1..10)).to eq 2640
  end
end

describe 'up to 100' do 

  it "finds the sum of the square of the first one hundred numbers" do 
    expect(Problem6.sum(1..100)).to eq 338350 
  end

  it "finds the square of the sum of the first one hundred numbers" do 
    expect(Problem6.square(1..100)).to eq 25502500
  end 

  it "finds the difference between the sum of the square and the square of the sums" do 
    expect(Problem6.difference(1..100)).to eq 25164150 
  end 
end

And here's the code. You'll see each of the three pieces and how they work together. And you actually don't even need the three pieces. (Looking at it again now as I post, I'm seeing that the question only asks for the different so you don't even need to define the sum and the square separately.) For me, when I originally did this, it was easiest for me to define each to visualize it better but now I see that was unnecessary and the final piece is really the only thing I need.

module Problem6

def self.sum(number_set)
  sum = (number_set).map { |i| i*i }.reduce(:+)
    #put here the sum of squares of the numbers
  return sum
end

def self.square(number_set)
  square = (number_set).reduce(:+)**2
    # put the square of the sum of the numbers
  return square
end

def self.difference(number_set)
  difference = (number_set).reduce(:+)**2 - (number_set).map { |i| i*i }.reduce(:+)
  return difference
end

puts Problem6.difference(1..100)

end

If you wanted to keep each of the three parts, this is what the code would look like:

module Problem6

def self.sum(number_set)
  sum = (number_set).map { |i| i*i }.reduce(:+)
    #put here the sum of squares of the numbers
  return sum
end

def self.square(number_set)
  square = (number_set).reduce(:+)**2
    # put the square of the sum of the numbers
  return square
end

def self.difference(number_set)
  difference = square(number_set)-sum(number_set)
  return difference
end

puts Problem6.difference(1..100)

end

The primary difference is that, instead of taking the information for the difference and repeated all that code, you are taking the result of the sum method and the result of the square method to find the difference.

The One Where I Get a Mentor

I am excited to announce that I’ve been selected as one of the first mentees for the new Arlington Ruby mentorship program! There is a lot of informal mentoring that goes on in Ruby communities which is really amazing, but sometimes it’s really difficult to get a mentor. Sure, there are lots of people you can ask questions to but having a more formal mentor is different. Knowing that time and dedication are required also makes it more difficult to ask someone to commit to you in that way. It involves both the mentor and mentee developing goals for what they want to learn and both people are invested in the relationship and progress.

Arlington Ruby has recently formalized their mentorship program. The goal of the program is not just to connect new programmers with experienced ones and it is not to just benefit the two people involved. The program involves peer mentoring and a lot of thought into how the mentors and mentees will additionally contribute to the rest of the community. You can check out the official guidelines here. In the meantime, I’m super excited to have Chris Sexton as my mentor!! For the next six months, I’ll ask him hundreds and hundreds of questions (he may not know what he’s gotten himself into) and I’m looking forward to developing some goals and posting about my progress and what we work on here.

Thanks Arlington Ruby for putting some serious thought into how to continue to make the Ruby community even better. Hopefully other Ruby groups will copy this format and it’ll become a way to build stronger local communities for all of us.

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!!

On Accomplishing Goals

I've always been a listmaker. I use evernote to take ideas and things down. I make lists for everything and I keep a running weekly to do list for what needs to be done. I have it listed as Monday, Tuesday, Wednesday, etc. through weekend with an "other" underneath for things that should be scheduled in future weeks. On Sunday every week, I look at my upcoming week, my meetings, and my projects and try to balance my days. I've done this with every job and every project I've ever done. 

To do lists for coding and development are way more difficult. I LOVE crossing things off of my to do list, and when your to do list involves coding projects, you are just less likely to cross stuff off your list, let alone be able to cross a bunch of things off your list. So, to help with this, I've also been making 6-8-week goal chunks. For example, at the beginning of August, my first set of goals included finishing a few specific tutorials, "building something", and making a decision about if, after the 6 week, I would continue working on my former startup or continue doing just development and stop working on that site (the "former" suggests what I decided to do).

I was super excited this time around because I accomplished almost all of my 8 week goals in just 5 weeks! These goals included establish a blog, post on the blog often (at a minimum twice per week), build something that teaches me some javascript and jQuery, shadow at a few companies, learn how to and then build a technical resume, and speak at a ruby meetup. The only goal currently not accomplished is get a job... so, I'm still working on that one. But, it looks like it's time to set some new goals and maybe think bigger for the next set.

Getting started with jQuery and JavaScript

This week I started learning some jQuery and JavaScript. They're good skills to have and ones I can continue to expand upon once I know the basics. For me, the best way to learn is by doing. I decided I would design a memory game with cards that flipped over, related to the university of Michigan that we could potentially use to engage alumni at game-watchings. When you're new to something, I believe there is doing and doing. As I've mentioned before I'm still in my tutorial rage stage so I really didn't want to do another tutorial to build something in JavaScript.

I naively thought I could just build this memory game as I went. Well, I mapped out the game, figured out all the pieces and the different logic that needed to take place. Looking at all the parts, I realized that I had no idea where or how to start. So, I came up with a new plan. I started by watching some Treehouse videos. I actually kinda dislike watching tutorial videos but I’ve found that if I take notes at the same time, then I am able to absorb some of the information. So I watched a bunch of the Javascript series and a little bit of the jQuery series. I then searched for getting started with Javascript and same with getting started with jQuery and did some more reading. I also did some searching and reading on jQuery and Rails since I was building my game into a Rails application.

Once I felt like I understood some of the basics, I googled and searched in github for memory games using Javascript and jQuery. I did this when I started doing the Project Euler problems as well. For the first few, I really had no idea how to structure things or where to begin, so I would search the problems, find 4 or 5 different solutions, walk through each one to understand how different people solved it and take one of their approaches to move forward. I did the same thing with the memory game. Since it seem sot be a popular starter project for people learning Javascript, I looked over how 5 or 6 people put the game together, how many js files they built and how they structured the information. I walked through each thoroughly and then chose one to build my memory game off of and now I’m starting to customize it based on the foundation that I borrowed from someone else. If you’re curious about the foundation I used, check out this awesome memory game.

Ruby versus Rails

This last week, I did my first tech presentation! I presented to the Arlington ruby group on the difference between ruby and rails so I figured I'd do a post on it as well.

When I first started learning ruby on rails, I had no idea they were two separate things. I went to a workshop, built something cool, and continued looking at tutorials from there. I guess I knew some things were ruby tutorials and some were ruby on rails buck didn't fully comprehend the difference. It wasn't until one day, when someone asked me about my learning path, the I realized I had some research to do.

So I went home, and looked and everything I found talked about ruby on rails or just ruby. It was pretty difficult to figure out what was pure ruby versus what rails brought to the table. During the presentation, I compared ruby and rails to the Settlers of Catan game and expansion packs available (which is what you'll see in the slides which are attached). For those of you who are fans of the real housewives of new jersey, you can also think of it like the original cast/season versus newer seasons.




So, what's what....

Well, to start, ruby is the base. It is a programming language like python or php. And you can use different stuff on top of ruby. You can use rails, but you can also build an apication with ruby and node or ruby and backbone, etc.

Rails is built on ruby. It is an open source web application framework. Rails are like the other seasons of housewives... Where new characters are introduced and original character are enhanced by the new characters. Take Teresa and melissa for example. Teresa has been there from the beginning but when melissa joined the cast, it allowed for more flexibility, more storylines and a whole new set of drama. If you don't watch housewives, but play catan, Rails is like an expansion pack. Just like in all of these versions of settlers, most of them use all or some of the pieces of the original settlers to build new versions that are more flexible, give you more game options, etc.

So here are some of the basics... in settlers, the original, you’ve got some basics like the resource map, the resource cards, dice, houses, roads, settlements, etc. Housewives is the same way... Think of the original cast with Teresa, Caroline, and Jacqueline set in Jersey. In ruby, you have the base of an object-oriented programming language. It also uses gems and something called IRB.

To go a little more into each of those things, IRB is interative riby. It’s a way to try things out using the command line. you can get to irb by typing irb into your command line. The command line will change a bit. To see how this works try typing 2+2 and press enter. You'll see IRB does the math for you. Now do Teresa=3 and enter and then Teresa*3 then enter and you'll get nine. You just set the variable Teresa to the number three and then used it to do some math. There are lots of different things you can do and test in IRB. I’m still getting the hang of how to use it really effectively while coding.

The other thing I mentioned were gems. Gems are a packaged library or application. They are code grouped together to allow easy integration of certain functionality. There are lots of gems. And rails is a gem. Some gems I've used include Ransack which is an easy way to integrate search into a site and bootstrap which is a design gem that adds css and some prettiness.

Okay, so then what does rails add… Rails is like the pieces that come in the expansion pack or in new housewives seasons. So, for example, in seafarers, you get additional water pieces, ships, etc. that allow you to have different boards and built off of the original settlers. In housewives, we got the addition of joe, melissa, and kathy.

Rails follows the rules of MVC and DRY. It uses the Rails console, can query a database, and has commands like rails generate or scaffold which give you out of the box builds.

Okay, so there’s a lot there. To start, MVC is model, view, controller. This is a rails pattern.The model handles the logic. The controller handles the actions of requests and responses, clicking to navigate, form submissions, etc. and the v is the view or what you actually see. In ruby there’s no MVC pattern. This is a little confusing but Models and controller are just classes that make up the state and behavior but with the addition of view, it creates a pattern that rails follows.

DRY stands for don’t repeat yourself. Basically, that means if an element is being used over and over again, rails lets you group the code into something (like a module or helper) and continue to use it by including that item instead of rebuilding the element each time.

The other main thing is scaffolding. Scaffolding is a way to have an out of the box solution. Think of it like a house. Ruby is the housing materials and rails is the blueprint for the house. You can fill the house with different furniture, paint it different colors, etc. but if you want to build another house, you can use the same blueprint and go from there.

Finally, in thinking about the view part of rails, rails combines ruby with HTML, CSS, and javascript to create a web application. I think the best way to show this is with an example, so this is an example of form_for code. Put in the form code. form_for is basically a method that is view code to build a simple form on a website. This form is just asking for name, email, and password. It is view code which exists in rails, but doesn’t exist in ruby.

So, that’s a bunch of information on whats in rails and whats in ruby. I’m still learning about the differences, I know there are a lot of additional methods available with the addition of rails that aren’t available in just ruby. So, what to learn first? Personally, I think it is best to learn ruby first and then add rails. I think doing that makes it more clear what is ruby and then what is rails. However, the tutorials available for ruby on rails, I think, are much better because they are more interesting and you’re actually seeing something be built as you go through a tutorial. The ruby tutorials I’ve found cover lots of good basics, but I found them a little difficult to get through. And don't forget... if you get frustrated, just flip the table and you'll feel a little better.



You can find the slides here: http://www.slideshare.net/asheren/ruby-versus-rails