On Grit and Learning

This weekend, I was listening to the Ruby Rogues podcast from this week about how to learn. I’ve thought a lot over the past few years about how I learn, the importance of learning, and to be honest, how my upbringing and self-confidence has been affected by my learning. I am the middle child of three. I grew up in a single parent household but with a fairly traditional slant. I also grew up with a very very smart older brother. He was reading independently by the time he was three and often put himself to sleep by reading the dictionary...yes, the dictionary. He was the “smart one”. He was also the lazy one. Because he never had to work in school, he never did. He almost never turned in homework assignments but aced tests without ever opening a book. I was very different. For a long time, I was the “ditzy one”. I asked a lot of questions which were sometimes answered, sometimes laughed at, or sometimes explained by my brother using vocabulary I didn’t understand. I often had to think about concepts or reread things to understand and I had to study and work hard at school. As the most social of the three of us, I ended up being the outgoing, smart-ish enough child who was always expected to have a middle of the road career in something not super easy but also not too difficult.

Until I went to college, I believed that I was not so smart and would always have to work much harder than everyone else in order to learn something. When I encountered something challenging (especially math and science related things), my initial reaction would be that it is probably too difficult for me to understand as opposed to knowing I could understand it with a little bit of effort. A few months into school, I started raising my hand, answering questions and getting them right! Something that stumped my classmates, I would understand and when I couldn’t figure something out, I thought it through or discussed it with others to clarify. Turns out, I was smart, I just grew up convinced I wasn’t. Additionally, I realized that my ability to work hard was not due to the fact that I didn't understand something, it was because I strove to reach higher goals and wanted to understand something more fully than just “getting it”. This newfound “smartness” also came with self-confidence. Once I realized I had valid questions to ask and legitimate comments to make, I had no trouble speaking up.

This is where the Ruby Rogues podcast comes in… the first thing they spoke about was Grit and the importance of Grit. Grit is basically perseverance. It says that successfulness is not defined by innate talent or smartness but about GRIT and someone’s ability to stick with something and continue to push themselves to learn more. Sandi Metz did a phenomenal talk about this to the DC Rails Girls workshop in June as well which was the first time I had heard the GRIT theory. Other things discussed also resonated with me. I found myself alone, in my living room, often nodding at the conversation. For example, they discussed NOPS, which is a really interesting concept of recognizing when you are uncomfortable and going with it. I realized I did this when starting to learn. At the beginning, I was embarrassed to ask questions and they made me uncomfortable. One day I decided to just go with it and say I’m going to ask every question that comes to mind today. It was great. Everyone answered my questions and I learned so much more once I stripped myself of the feeling of embarrassment about needing to ask.

There were a few other good tips that relate to the lightning talk I gave at RubyConf (speaker notes coming soon! I promise). Things like knowing that everything is a rabbit hole and you need to give yourself license to not care about some things as you learn or explaining things as you learn them. This is actually mostly why I started this blog. I find that when I solve a problem I have and I want to blog about it, I understand the problem and solution much better because I want to explain it to other people and feel a responsibility to be able to explain it effectively and in a way others will understand (and now I understand pictures of rubber ducks I’ve seen related to debugging!! It’s called rubber ducking or teddy bear programming (same principle as rubber ducking but with a teddy bear) when you explain a solution or issue or definition to a stuffed animal or rubber duck in order to ensure you understand it). And a final great tip about constantly stopping to evaluate yourself, asking what did I do well this time and what wasn’t so good?

I know that at this point in my coding journey, someone is going to need to take a chance on me. In a recent interview, someone told me that no one would ever take a chance on me because I don't have a CS background or professional coding experience. I know enough but am still learning a lot and I just hope someone sees my perseverance, grit and passion for learning enough to know I’m a good bet as an employee. I also want to say to anyone who is currently learning, keep pushing yourself. Every day you know a little more, even if you don't always feel like you do.

Onto Session 2!

I fear I won’t be able to process everything and get it in a post before I start forgetting what my notes mean! Expect rapid postings in the near future.

Onto Session 2!

TL;DR: databases.

This session was about the Zombie apocolyse and data structures with Casey Rosenthal. I knew walking into this one that it would be a little over my head but after a post session debrief with Conrad (my guide) that helped frame database structures in general, everything clicked! I’m also just now starting to really get into database structures and understand more about how they work, how to work with them, and what are the ways you can structure different data types within databases so this ended up being a great session for me to be in. Also, it was about a zombie apocalypse so it had to be good. Let’s start from the basics. There are two types of databases, SQL databases and NoSQL databases. NoSQL databases are essentially anything that isn’t a SQL database. NoSQL databases can also be known as distributed key value databases. Examples of these databases include MongoDB and Riak. SQL databases include MySQL, SQLite, etc. There are a handful of differences but the main difference is that SQL databases are based in table modeling. SQL databases can be a bit more flexible if you have similar types of information coming in all the time, but they can also be harder to scale. SQL databases are also good as long as everything is on one machine because they are safe, have lots of features and have many other good aspects but features these same features are hard to implement once you are running on many machines. Why do you need to move to many machines instead of having just one machine? Because you can’t read the information quickly enough when there is a lot of it (essentially, the queries start taking too long and you need to split the information onto more than one machine). Finally, SQL databases enforce the structure. If you use a SQL database, all of the tables in the database require the same information. In a NoSQL database, this isn’t the case. NoSQL databases are designed to they can start as one thing but easily scale to become larger and hold different types of information. And because there isn’t the same table structure, it can be easier to store lots of different types of information. So, when using a NoSQL database, you don’t have to use commands like rake db:migrate because there are no data migrations (yeah, that kinda blew my mind and it was also where the whole rest of the talk suddenly clicked into place for me). AND there’s no schema file! A NoSQL database has tables but they aren’t specific so they’re called connections instead of tables. The downside, however, is that you can’t tell exactly what’s in the database unless you pull all the records

So, back to the actual talk…when thinking about what type of database to use, it’s important to think about how the information will need to be presented in the end. This was an idea that continued to surface throughout the talk.

Some important terms I learned when thinking about NoSQL databases (and databases in general) were high availability, strong consistency, and partition tolerance. High availability means you can connect to any part of the system and you can both read and write all the data. So, for example, if you have 3 different silos that each keep information, the databases are kept in sync with one another so that you can access all the same data from any of those silos. In other words, if a server crashes, the database still works (Casey has a great slide that shows this, so I definitely recommend looking up the talk on Confreaks when it’s up). Strong consistency means that parts of the database will remain in sync with one another. Finally, partition tolerance means that if the cable comes out of the wall, the database will remain running.

When you have a distributed system, there are a few data modeling options. You can do a document based inverted index or a term based inverted index. The document based inverted index means that you can write the information efficiently but that you’ll have an inefficient read process. The term based inverted index is the opposite. You have an efficient read but inefficient write system. So again, it comes down to really thinking about the data you have and what will be more important to your business processes.  Will you be reading a lot of data or writing a lot of data? The

He also talked about Highly Available systems (HA) of geohashes and one other type of HA system that I can’t remember. Lastly, I learned about some interesting components that are Riak-specific. Riak creates data siblings, which is also not possible in SQL but is possible in key value databases. Basically, when information is written into the system to the same key (so to the same data entry) from two different places (so two people are updating the same person’s file at the same time) the system will save both entries and connect them. In other systems, they just take the most recent timestamp as the most recent data but here, siblings are created and the two entries are both saved, become siblings and then the user is notified the next time that file is accessed being told “hey, you’ve got two entries here. Which one is correct?”

The rest of the talk went into some more detail on this information, how to locate zombies via zip code and other interesting components of the database but, for me, this is what I gleaned from the talk. For more examples, information, and the source code, you can check out zombies.samples.basho.com.

RubyConf: First session

My initial intention was to write up a post on what I learned at Ruby Conf this year and put everything in 1 big post, however, I've just finished writing up the first session and I'm already over a page, so I think it makes more sense to post as I complete write ups. Here's my first one about basically the first two hours of Ruby Conf 2013!

This past weekend I had the opportunity to attend Ruby Conf in Miami! It was fantastic. I learned a ton. Met a bunch of new people and really dove into some Ruby amazingness. I was also really excited because, while I have been to a few ruby conferences before, this one was the first where I really understood what was going on and could sit through sessions without being completely overwhelmed and feeling like I didn’t understand a majority of the session.

I was also a recipient of a RubyConf Opportunity Scholarship. This program paid for the conference registration and also connected me with a guide for the weekend. My amazing guide was Conrad Irwin who was able to answer any lingering questions I had from sessions I attended. Conrad was very helpful and really advanced the amount of learning I was able to do and amount of information I was able to process.

So, let’s begin… the day started with a keynote from Matz (Yukihiro Matsumoto). For some reason, I didn’t think Matz would actually be there but he was and it was great. His talk was more to set the tone of the conference than go into technical details but a few points he made were great. First, appreciate your garbage collectors. Garbage collection was actually talked about a handful of times over the weekend but this was the first. Second, appreciate and respect are key. I think this is one of the reasons why I love the Ruby community so much… because these ideals are held paramount and discussed throughout the conference, but especially at the beginning to set the tone. Finally, an interesting note about open source was made, that OSS is like a shark, it needs to keep moving or it will die. All great points to set the tone for the rest of the weekend.

Onto the track sessions.

The first session I attended was on “A Peek inside the Ruby Toolbox” with Loren Segal (who, by the way, is interested in mentoring a new developer who's learning to code. If you’re interested, you should tweet at him @lsegal). Loren spoke about the really good tools the Ruby community has like deployment/ops, documentation, and testing, but mostly focused on where we could improve. The talk started with Visualization. There are lots of great visualization tools out there but none for ruby. Some example given were visual studio, which is a diagnostic hub which shows CPUs, load times, etc. It also has a built in debugger. XCode was noted as a good visualization system. VisualVM which is JVM code. All of these tools really help with discoverability which was interesting to think about. Discoverability is basically being able to have a visual representation of what’s going on. The other tool mentioned was firebug which is considered a really awesome visualization tool and it is the inspect element function in FireFox. Right now, Ruby Mine is available for Ruby but it’s not awesome and fairly expensive. He also spoke about profilers like perf tools which results in a graphic diagram that runs through code and new languages like JRuby which have a JVM.

Next, he spoke about Linting… which is not picking lint out of your belly button or using a lint brush to make your clothing un-fuzzy. Linting tools are basic “check up” tools that help determine if your code is good or bad. Linting tools detect code smells and should find common errors. In Javascript, there is JShint. Currently in Ruby, a few tools exist… Reek, Flog, and Flay. The issue, however, is that these tools test the prettiness of code, not if it is good code (more on good code versus bad code in a later talk). These are some of the tools Code Climate uses to rate code there. There’s a new tool called Ruby-Lint but again, it’s new, and so Loren wasn’t sure how good it is. I’m excited to look into it more!

Next, he talked about Static Analysis. Static Analysis is bug checking/ defect finding. Here, I learned about Fuzz Testing (almost as cool of a name as linting but not quite). Fuzz testing is when you throw a bunch of crap into you application to see what breaks it. (I later learned the SQL is well known for its fuzz testing). It seems like there are lots of interesting things to look into further about fuzz testing but what currently exists are heckle, which fiddles with if statements to see If the tests fail and mutant. Finally, he also spoke about symbolic execution which runs code with no immediate values. I wasn’t able to really wrap my head around this… it’s something that has to do with math, testing values, and automatic test case generation. Right now there’s nothing in Ruby for symbolic execution.

In the category of random knowledge learned, In this talk, I also learned about what an IDE is! I hear people say it all the time, but never fully comprehended what it was exactly. Anyway, an IDE (integrated development environment) is having all the tools you need in one window so XCode is an IDE and so having an IDE would mean that instead of having a text editor, console, etc. all open, you’d have it all in one place.

Great session and lots of new stuff to look up. It will also be interesting to see what new tools are built based on these weaknesses in our toolbox.

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