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

Getting started... Tools to begin with

The first tutorial is always the most difficult. As you're getting involved in the community, one of the most frustrating places to be is when you are so basic that you don't know anything and that you don't even really know how everything connects. But, that being said, these are the basics, and some of the more mind-numbing stuff at the beginning builds the foundations moving forward.

My recommendation is to learn the ruby basics before adding in rails. I didn't do it this way… I did ruby on rails tutorials and then went back and did some more ruby stuff. Doing it this way, I think, helps solidify the basics.

Start with tryruby.org. Try ruby probably won't take you very long but try to take your time on it. When I started learning, I was so anxious about knowing stuff, that I rushed through the early stage things like try ruby when I should have been taking notes, really comprehending everything, and doing some additional googling on each term. If you finish try ruby quickly, I'd move on to reading why's (poignant) guide to ruby, and then finally the Jumpstart Labs Ruby in 100 minutes.

If you've never used terminal, the command line, or a text editor (which I hadn't before I started learning), then before moving on to Ruby in 100 minutes, do a little googling on what is the command line and how to use it, what is the terminal, and what is a text editor. One last note, don't let those last things scare you! The first time I opened the terminal and typed something on the command line, I thought I was going to break my computer and erase my whole hard drive accidentally (I still think that sometimes, mostly when I'm doing stuff related to git). All I knew from the command line was that it was for people who actually knew computer stuff. This is not the case. You will not totally destroy anything. So do some research and jump in there without fear.

Happy Learning!

Halfway there. Euler 5.

Euler 5! Phew, so, this marked my halfway point through the 10 problems I decided to do in Project Euler.

So, here is the problem:

2520 is the smallest number that can be divided by each of the numbers 
 from 1 to 10 without any remainder.
 What is the smallest positive number that is evenly divisible by 
 all of the numbers from 1 to 20?

For this problem, I actually solved it in a really ugly, awful way and then went back to refactor . I can't remember exactly but I think the ugly way involved taking a range of numbers, multiplying all of them and then seeing which was the smallest that had a remainder of 0 for each of the numbers... whatever it was, it was super complicated. Anyway, so first, the tests:

require 'problem5/problem5'
describe 'lowest common multiple' do 
  it "find the smallest number that can be divided by 1 through 10 with no remainder" do 
    expect(Problem5.divided_by(1...10)).to eq 2520
  end

  it "finds the smallest number that can be divided by 1 through 20 with no remainder" do 
    expect(Problem5.divided_by(1...20)).to eq 232792560
  end
end

At this point, if you've been reading the Euler series of this blog, you'll notice a pattern to all of the tests. This may not be the most sophisticated way to execute the tests since rspec can do a lot of cool things, but using the same format worked for and was a way I became comfortable with seeing tests formats, running the tests, etc.

Now for the answer:

module Problem5

def self.divided_by(number_range)
  list = (number_range).inject(:lcm)
  return list
end

puts Problem5.divided_by(1..20)

end

so, once I started reading the ruby docs, I noticed there was a greatest common denominator and a least common multiple method with an integer. Looking into those, the least common multiple method was a perfect, simple way to solve this problem. The inject plus LCM method on an integer basically takes a list and finds the lowest common multiple of that range of numbers.

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.

Euler 4! Onwards and upwards!

As I talk about doing these Project Euler problems, I increasingly realize how much they helped me crystalize certain concepts in the last few weeks. I knew they were helping me solidify some coding skills, but honestly, I wasn't sure if spending time on these was a waste of time and if I should have just continued to build things instead. One originally unseen benefit of having these problems done is being able to use them as a template to identify other things. For example, I solved my eulers by testing in rsepc and writing in ruby. The past few weeks, I've had more conversations about other testing languages including cucumber and minitest. I read about them first, but then I've searched for other people who have solved eulers and tested first using these different test suites. Because I'm familiar with the problem, I'm more easily able to identify with the example and look at how they wrote their tests.
Now, onto Problem 4.

A palindromic number reads the same both ways. The largest palindrome 
made from the product of two 2-digit numbers is 9009 = 91 × 99.

Find the largest palindrome made from the product of two 3-digit numbers.

First the tests:

require 'problem4/problem4'


describe "largest palindrome" do        

 it "finds the largest palindrome of 2 digit numbers" do
   expect(Problem4.answer(10...100)).to eq 9009
 end

 it "finds the largest palendrome of 3 digit numbers" do
   expect(Problem4.answer(100...1000)).to eq 906609
 end
end

Now for the solution code:

module Problem4

def self.answer(largest_palindrome_range)
  max = 0
  (largest_palindrome_range).each do |a|
    (a...largest_palindrome_range.end).each do |b|
       product = a*b
    max = [max, product].max if product.to_s == product.to_s.reverse
    end
  end
  return max
end

puts Problem4.answer(100...1000)
end

So, first, I thought about a palindrome. A palindrome is the reverse of itself. So, I took the range we were testing and took each number to get a and then did the same from a to the end of the range to get b. Then I multiplied all of the resulting 2 number possibilities. Finally, in order to find the maximum, you take the product, convert it to a string and then see if it equals the reverse of the string.

This one was really tough for me. I knew about how to find the max and I knew how to check if it was a palindrome and reversing the string, but the middle section of finding the products via the range given was pretty challenging for me to wrap my head around.

Learning to Code: 3 Pieces of Advice

Getting started is tough. There are loads of resources out there to learn how to code but the most difficult part is figuring out what to do, when. I'll be periodically posting my advice on the best path... this isn't the path that I took necessarily, but the one I wish I had looking back on all the tutorials I accomplished, things I did, and meetups I went to. First, a few pieces of advice.

1. If you really want to learn to code, you need to do something almost every day.
I started to learn to code not because I thought I would want to do it as a career, but because I was founding a startup and knew I could make better business decisions if I had a basic understanding of the technology being used. As a founder, I had to weigh what I spent my time on and simply couldn't be coding every day. As a result, I set aside Rails Girls Tuesdays and Thursdays to code and make all tech-related decisions. My progress was very very slow during this time. I would lose momentum, forget where I was at in a tutorial, and it just took longer for things to sink in. For the last few months, I have been coding every day and every night. I've tripled my amount of knowledge in a very short period of time.

2. Set goals.
Setting goals is important in anything.... learning how to cook, changing careers, advancing in a current career, etc. Setting goals keeps you accountable and motivated because you are constantly checking in on if you're accomplishing what you set out to do. I'm a list-maker and a goal setter so I'm very comfortable with this. My advice is to set small goals. For example, if I was using Thursdays to code, I would sit down on Wednesday and say tomorrow, these are the things I want to accomplish. Now that I am coding full-time, I set new goals every 4 weeks and have them written in a place I look often so that I am always reminded about what I set for myself.

3. Get involved in the community.
No one can learn to code completely on their own. There are points when you'll get stuck. There will be times where you need someone to explain something in a way a book or tutorial can't quite get you to understand. If you're not careful, you'll go through the motions of a tutorial "do this. Next do that." without fully understanding what is going on. When I first started attending meetups, I hardly understood anything. I was lucky if I wasn't lost after the first five minutes of whatever 45 minute presentation was going on. Sometimes I was fascinated, sometimes I was really bored, but I was there. I was listening to words and phrases. I wrote down phrases or names of things that seemed important to look up later, and I got to know people who would help me out a lot as I learned more. Going to meetups can be intimidating... people make jokes you pretend to understand, there are usually very few women in attendance, and most of the time is spent with you thinking silently "geez, I really wish I knew what the heck they are talking about!" but the best thing to do is to keep going because gradually, I started to understand more and more, was less shy about asking questions, and understood the jokes being made.

Now, for step 1. I LOVED the way I started... I started by attending a Rails Girls workshop in DC. If you can, start by attending longer workshop (a day if possible). There are a lot of different opportunities and they are all great. Check out Rails Girls, Rails Bridge, and if one of those isn't happening in your area, try to find a women's tech meetup... they might know the resources available. There was a lot I didn't understand, but I think attending a workshop makes other steps a lot less scary.

Eulers Continued: Problems 2 and 3

Continuing with the Project Euler problems, here's my solution for numbers 2 and 3.

Problem 2

Each new term in the Fibonacci sequence is generated by adding 
the previous two terms. 
By starting with 1 and 2, the first 10 terms will be:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
By considering the terms in the Fibonacci sequence whose 
values do not exceed four million, find the sum of the even-valued terms.

First, here are the tests that I wrote:

require 'problem2/problem2'

describe 'solution' do 

  it "sums the first two terms to generate the third term" do
   expect(Problem2.fib(2)).to eq 1
  end

  it "sums the even-valued terms up to the limit" do
    expect(Problem2.fib(4000000)).to eq 4613732
  end
end

Similar to the tests written for the first problem, we want to check the answer and put the actual numbers in the test and then write the code so that it doesn't need a number, it just needs the argument to be noted and the argument in the code pulls the fixed number arguments from the test in order to run and pass. The Problem2 is the module and fib is the method.

So, onto the code:

module Problem2

  def self.fib(limit)
    arr = [] 
    a,b = 0,1 
  
   while a < limit 
      arr << a 
      a, b = b, a + b 
    end

    sum = arr.select { |i| i.even? }.reduce(:+) 
   
  end

  fib(4000000) #sets the limit
end

To solve this problem, first, I decided to create an empty array, then I needed to put stuff in the array (that's the second line). The question gives a certain number as the limit (4000000) so while the number is under the limit, we want to push the new number onto the end of the array (arr << a). So that create the action of what will happen. Then we need to create the formula that will produce the number (the recursion formula). And that's that part of the problem. Next, once we have the Fibonacci sequence in the array, we need to solve the second part of the problem where we find the sum of the even-valued terms. In order to find the sum, we take the array and use the select method, passing the array through a block that looks for which numbers are even, selecting those numbers and then using the reduce :+ method to add those numbers together. Finally, fib(4000000) sets the limit of what we are looking for to put the result. One note about solving these problems. I've started outlining each step at the top of the problem to give myself a short roadmap to work from and then once I have the problem clarified in my mind and a roadmap worked out, I can work through each part until I find the solution and get working code.  

Problem 3

I include both problems in this entry because my solution to problem 3 is a bit of a cheat. But before we go there, here's the problem:

The prime factors of 13195 are 5, 7, 13 and 29.
What is the largest prime factor of the number 600851475143 ?

Here are the tests I wrote:

require 'problem3/problem3'

describe 'answer' do 

  it 'will have the largest prime factor for 13195' do
    expect(Problem3.prime(13195)).to eq 29
  end

  it 'will have a largest prime factor for 600851475143' do
    expect(Problem3.prime(600851475143)).to eq 6857
  end
end

And here's the code:

require 'prime'

module Problem3

  def self.prime(num)
    primes = Prime.prime_division(num)
    primes.last[0]
  end
end

So, there's a Ruby library called Prime which makes doing anything with prime numbers really simple. First, I required that library. The I just defined primes and used prime_division which divides the number to determine which the prime numbers are. Finally, I took the last number in the list which would be the largest number. Really simple and straight forward.

Project Euler all DAY

This week I took a break from building things to go back to the basics a bit. I've been having trouble getting a good handle on the different parts of Ruby (ie- blocks, hashes, etc.) and also struggled at the code retreat last weekend when I had to write code for tests in order to make them pass. Recognizing this as we significant weakness, I decided to spend the week tackling Project Euler problems.

Project Euler problems are math problems that you then solve using code. First, I found that they help me take an issue and think about different approaches. Second, they are great for practicing test-driven development. Third, they create additional challenges. For example, you can solve the problem and then go back and refactor to make your code even better OR I've had a few amazing friends/mentors this week look at my solutions and give me additional constraints or challenges to make my code even cleaner and better or explore a different method to solve the problem. There isn't one solution to these problems and if you google "euler ruby" you'll find dozens of responses.

I'll walk through the setup and first problem.

For me, the setup was actually pretty confusing, although really simply once I received some direction. It may seem basic, but I couldn't find these instructions anywhere so I'm writing them to hopefully help others get set up.

I wanted one euler folder with each problem in it's folder. I originally put both the problem1.rb and problem1_spec.rb files in the same folder but then rspec wouldn't run! It turns out that rspec looks for a lib folder in order to run it. The simplest way around this was to create a lib folder and a spec folder in my euler folder. The lib folder contains all the problem files and the spec folder contains all the spec files. To run the tests, I typed into the command line: $rspec spec/problem1_spec.rb and to run the actual file I had to type $ruby lib/problem1/problem1.rb. Finally, in order to test my code, I have been running the answer through IRB. To get to IRB, you simply type irb into the terminal and then you can write each line of code to see if you get the correct answer. Finally, at the top of the spec, we need to require the problem so that the tests finds the code file.

Euler Problem 1:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

First, I'll start with the tests that I wrote. I use rspec:

require 'problem1/problem1'

describe 'solution' do

it "sums the multiples of 3 and 5 under 10" do
    expect(Problem1.multiples(10)).to eq 23
end

it "sums the multiples of 3 and 5 under 1000" do
    expect(Problem1.multiples(1000)).to eq 233168
end

end

This test format is pretty much what I have been using for all of the Euler problems and I have found it pretty useful. To start the test, you have to describe something and then describe it's characteristics. So, since we are given the answer, we are able to hard code (put in the actual numbers) the test. The test says that for the sum of the multiples of 3 and 5 under to, we should expect that problem1(module)'s multiples(method) of 10(parameters/argument) to equal 23 (because that's what the problem tells us. I did a similar format for the next test and plugged in the final number 233168 once I got the code working.

Now for the code:

module Problem1

  def self.multiples(stop_counting)
    (1...stop_counting).find_all { |i| i%3 == 0 || i%5 == 0 }.reduce(:+)
  end

end

So, first we defined what the module was. Then, we were trying to find the multiples of two numbers (3 and 5) up to a certain number. I put self on the method definition because we are calling the method on the module. I put stop_counting as the argument which helps the tests pass, because in the tests we put at what number I stop counting (10 in the first example and 1000 in the second example). By defining the argument as stop_counting, we have more flexibility on the tests to plug the numbers into the tests and not the code (I think of this like an excel document where you have you assumptions worksheet. When you have an assumptions worksheet, you can change the number there as your assumptions change and since the rest of the spreadsheet is built on those assumptions, the numbers used in the formulas on other worksheets will automatically change as opposed to having to go through each worksheet and redo all the math manually). So, the code says to look at all the numbers from 1 until stop_counting and then find all the numbers (I think you can also use .select here) that have a remainder of 0 when using the modulus
(or modulo) which is the operation used to find the remainder of dividing one number by another, in this case either 3 or 5. Then the reduce method takes all the remaining numbers and using the :+ operator, adds those numbers together to get the sum.

Also, while going through this process, I paused in the middle to complete Ruby Monk. While initially I was like, "OMG, I CANNOT do another tutorial", Ruby Monk was really helpful and I wish it had been recommended to me two months ago. As opposed to the traditional ruby tutorial that builds a site of some sort, Ruby Monk really explains the terms and parts that make up Ruby and I feel much more confident in the definitions and grammar of it all now that I've completed it.

I'll be posting more problems in the next few days.

That Home-y Feeling

Growing up, I was a part of Young Judaea, a Zionist youth movement that became an integral part of my life. My years in Young Judaea helped me develop leadership skills, community building skills and fostered an appreciation for well-run, interesting, interactive programs/conferences. In Young Judaea, we periodically had conventions (both regional and national), which were weekend-long retreats to bring people together, learn about Zionism and Israel and make governing decisions about the movement. This may sound a little nerdy because it was a little nerdy but it was also awesome! There is nothing like being in a remote-ish place with little cell reception and no internet that promotes togetherness, understanding, and community. I haven’t felt that good about a conference I’ve attended since high school (and I’ve been to a lot of conferences), until this weekend.

This past weekend, I had the opportunity to be a Ruby DCamp participant. Ruby DCamp is an invitation-only weekend-long retreat for Ruby developers. The weekend is broken up into 2 parts. Part 1 is a code retreat and part 2 in an open space conference. Both parts were incredibly interesting. During the code retreat, we played Conway’s Game of Life. The point of the exercise was to practice test-driven development and really take each piece of code step by step. Particiants pair programmed with a different person every 45 minutes and the afternoon sessions introduced additional constraints like no speaking or not being able to use certain code approaches. For me, this was the first time I had ever pair programmed and the first time I had worked on a problem like this. While a little overwhelming, it was also really amazing and fun. I recognized things I need to work on as a new developer but also realized that I can contribute to conversations and determining approaches to solving the problem. Going into this code retreat, I was completely terrified… of failing, of feeling stupid, of having my pair be annoyed that I didn’t know anything. What I discovered was that all my fears were unfounded and I can’t wait to do another code retreat in the future.

The second part of the weekend was an open space conference. Each morning the group brainstormed possible session topics with the strict requirement that these sessions be discussions and not lectures or talks. We then had about 10 minutes to write all ideas on paper and hang them on a wall and another ten minutes to vote via putting dots on the topic papers we wanted to have sessions on. Each person was allotted five dots. The topics were varied, everything from contributing to open source, to an intro to small talk, to technical interviews and what you look for when you hire (which was particularly helpful for me). There was a newbie session designed specifically to answer questions of the newer coders there. One of the more impactful topics was about imposter syndrome, how and when we feel it, what we do to try to keep it at bay, and ways in which we can help each other. I also loved the session on good code reviews that offered different people’s approaches to reviewing and commenting on other’s code both inside and outside of the workplace. All in all, every conversation was super interesting and there was a rare ability to be vulnerable and honest since the group of people there operated within this unspoken web of trust.

For me, the most important thing I got out of the weekend was a reassurance that my career path transition is a good choice. I love learning to code, but anytime you try to move to a completely different industry, there are always doubts. I knew my local community was supportive, but what about others? The larger community? Well, it turns out they’re amazing too. Encouraging and nice in every possible way, I feel like every ruby-related meetup or conference I have been to just continues to make me more and more excited about this transition. Thanks to everyone who made the weekend amazing and to Evan Light for organizing. Watch out world, I’m going to be a developer!