Learning to program doesn’t happen all at once. It’s a process full of happy highs and stubborn lows that takes a lot of trying and failing. You can struggle with something for days when suddenly it just clicks.
We think we’re pretty resourceful when it comes to helping students understand the stuff they’re learning. Instructors will assign more labs or hold 1:1 tutoring sessions—but sometimes getting the material is just a matter of hearing someone else’s perspective on it.
To make sure students in our Web and iOS course get as many of these perspectives we can give them, our alums volunteer to share theirs. Every Sunday, alumni hang out for a few hours (or more!) to hold office hours, help students out with labs, and go over any questions that pop up.
If alums have a new way of explaining a topic that really makes it stick, great! Students get a valuable perspective from their peers. And for those doing the teaching, they’re crystallizing their knowledge while learning how to teach—a skill they’ll be able use over and over again.
Hey look, there’s a picture of me tutoring from this past Sunday (if you click the “read more”)!
Peer tutoring was AWESOME. I wasn’t sure what to expect, but I really enjoyed it and I think I’ll be coming back to tutor even on the days I didn’t sign up for because I really learned so much (and I just really enjoy teaching). Plus, I just had a really good time “nerding out with code” (as Avi put it) and seeing some of my RUBY-005 buds who were also there to tutor.
I can’t wait to go back and tutor again!
The quote above is from Alan Turing’s essay, "Computing Machinery and Intelligence" (the one where he introduces the Turing Test). It might seem like an overarching statement about technology, but it’s actually about building a theoretical basis for artificial intelligence back when AI was just fantasy.
As the “father” of theoretical computer science, Olympic-quality long-distance runner, extraordinary genius, and tragic hero, Turing (1912-1954) packed a lot into his 42 years. Because so much of we do wouldn’t have been possible without him, he makes a regular appearance in programming lectures at Flatiron School. Here are three things you should know:
1. He helped make computer science a thing
He formalized concepts we use every day like, “algorithm” and “computation” with the Turing machine—a beautifully simple, totally hypothetical device that explores the possibilities of computation.
The Turing machine, or “universal computing machine,” held its program on an infinite piece of tape and was capable of solving any algorithm. This set the groundwork for him (and others) to make the conceptual leap from impossible tape to using the computer’s own memory to hold the program.
This is actually not stupid at all, I just wanted to reference David Letterman’s old “Stupid Pet Tricks” bit so I could have an excuse to post this hilarious image of a dog driving another dog in a little car:
ANYWAY. I’m going to talk about cherry-picking commits in Git, so you can merge only part of a branch into another branch without screwing everything up by merging everything at once and then melt your struggling brain trying to figure out where it all went wrong.
For an example of when this might be useful: this morning, I made a change to my ‘test’ branch that I also wanted in my ‘master’ branch, and had previously been copying and pasting from one branch into another in a very ungraceful way to avoid messing up certain precarious situations in one branch that would break the other. I knew there had to be a better way to pull those commits from ‘test’ into ‘master’ without breaking everything, and this is that way.
First, in your terminal, in the branch where the commit you want to merge lies (in this case, my ‘test’ branch), enter “git log.” It should look kinda like this:
I want to take that third commit down (28b4504) and merge that into my ‘master’ branch. The solution? CHERRY PICKING!
No, not that kind of cherry picking! DUH.
Git checkout to the branch you want to merge this commit into, and simply type:
git cherry-pick 28b4504
(Except, of course, you’d replace ‘28b4504’ with the commit of your choice from your own git log)
SHAZAM! Now that commit will be merged into that branch. So easy! Don’t you feel accomplished? Stephen Colbert dances with joy for you and your newfound cherry pickin’ skillz:
(ALSO: Big ups to Greg Lamp for showing me that cherry picking existed in the first place. Thanks Greg!)
Okay, so I have not yet learned to stop worrying (pretty sure that’s just a lifetime commitment), but anyone who knows me knows that I LOVE the Fibonacci sequence! One of my favorite pieces of jewelry is this Fibonacci spiral necklace:
Above: Fibonacci necklace by Agate and Elm on Etsy
I always know that I’ve met a kindred spirit/fellow math nerd when someone comments on it, and I wear it every chance I get (or at least, when it goes with my outfit). So why do I love the Fibonacci sequence so much?
First of all, some of you may be wondering - what is the Fibonacci sequence? And how does it turn into that cool spiral? Quite simply, the Fibonacci sequence starts with 0 and 1; every number that follows in the sequence is the sum of the two numbers before it, like so:
If you were to stack squares made up of these numbers on top of and next to each other to form a rectangle, it would look like this:
If you connect those corners with a curved line, you get this beautiful spiral:
(Okay, so those spirals don’t totally match, and one is slightly incorrect, but you get the idea)
The thing that really amazes me about the Fibonacci sequence, however, is not the manner in which it can be used to create a cool looking spiral, but the frequency with which one can see this spiral in action. Look around you, it’s everywhere! Check out any nautilus shell, for example:
Or even look as far out as the depths of space towards this spiral galaxy (which, according to the source, make up 77% of our universe’s observed galaxies):
BUT WAIT, THERE’S MORE!
Ever heard of the Golden Ratio? If you went to art school, as I did, then you should already know all about it. However, most people did not go to art school, so I’ll give you a quick primer.
If the ratio of two numbers is the same as the ratio of their sum to the larger of the two numbers, then they are in the golden ratio.
This ratio has been used in art for centuries! Leonardo da Vinci believed that the proportions of human bodies were in the golden ratio. Other artists, such as Salvador Dali and Piet Mondrian, were known to utilize the golden ratio in their work. Salvador Dali even modeled the shape of his famous painting, the Sacrament of the Last Supper, in dimensions that conform to the golden ratio.
But what does the Golden Ratio have to do with the Fibonacci Sequence?
If you divide any number in the Fibonacci sequence by the number immediately preceding it in the sequence, the result is pretty damn close to the Golden Ratio.
You can see pretty plainly that this geometric interpretation of the Golden Ratio looks a LOT like some of the shapes created by the Fibonacci Spiral:
There is just SO MUCH to love about the Fibonacci sequence; I’ve just barely scratched the surface here! If you’re interested, a quick Google search will yield a tremendous amount of information on the subject. I couldn’t possibly recommend one resource over another because there is just so much out there!
Isn’t math so cool?
Just started coding and thinking of working in tech? Amanda Peyton, founder of gadget marketplace Grand St and now a part of Etsy’s team, has some advice for brand new engineers looking to land their first job. She stopped by Flatiron School to talk through questions she always gets about how to start working in tech. Here’s what we learned:
Big company for structure, startup for speed
If you’re new to tech, and thinking about where to start looking for jobs, look to yourself first. What you want out of your next job should guide your decision—are you the artist who wants to construct something perfect or push features out of the door?
For structure and mentorship: try a bigger company. There will at least be other, more senior people to answer your questions and review your code. There’s also a lot more emphasis on building for the long-term and avoiding technical debt—which will allow you the time to spend learning more about their codebase and perfecting your own work.
Small startups, on the other hand, are more concerned with shipping fast and often, even if it involves duct tape and Band-Aids. If you choose to work at one, you might not have a mentor, but your daily routine will probably be more varied than it would be working on a small feature within a vast and established codebase. If you get into a startup early enough, there will be tons of hard problems to work through independently, and you’ll probably do a little of everything at some point.
Culture fit is really, really important.
Companies don’t expect junior engineers to know everything. They know they’re going to have to invest some time and resources in helping junior talent get better at their jobs. This means a couple things: (1) people interviewing for junior roles don’t have to be experts, but (2) they do have to be a good culture fit.
Culture fit is huge for new engineers, and companies will usually dedicate a lot of interviewing to it. Don’t get overwhelmed when scheduled to meet with 10 people on an interview—this usually means they’re excited about an applicant—but always remember that culture fit goes both ways. Applicants should also be assessing whether or not a company is a good cultural fit for them. It is super important for them to make sure they are going to love working with their potential employers.
Knowing how to learn new skills is even better than having in-demand ones.
It’s not as important as it seems to pick a programming skill based on market demand. Today, in September 2014, demand for developers of every variety is crazy. If you’re really good at something specific like Backbone.js, you can probably find a job doing just that.
But every so often a new technology comes out, and the slate is completely wiped clean. When something changes, everyone, regardless of how much experience they have, is forced to learn something new. New technologies are total equalizers. Perhaps the most valuable, in-demand skill you can have is to be flexible and excited about learning whatever’s next.
That said, demand for mobile developers is huge—so much so that even having smart opinions is valuable. So if you really want to focus on a skill that everyone needs, consider learning a programming language that you can use to build a mobile app.
Get out from behind that monitor and go do stuff.
Building a network means getting to know people in some informal way, so you’re not just that person who is coming in to interview. To get to know people, don’t hesitate to send emails or go to Meetups. Companies throw all kinds of events, so don’t be afraid to just show up and introduce yourself in a pressure-free environment.
It could also be worth it to go to conferences. If you pick one and explore, you’ll not only get a feel for the industry that you wouldn’t normally. You’ll also get to meet people. Who knows? Maybe the person you talk to for five minutes at JS Conf will help you get your next job.
Never miss an opportunity to show attention to detail.
Little details can be really important, and the best way for new engineers to show they care is through doing, not telling. Here’s a good place to start: read a potential workplace’s general or developer blog. Applicants rarely do this, but companies invest a lot of time and thought into their blogs. These can give applicants a sense of a company’s culture and help them show interest outside of an open position.
Not everyone reads cover letters, but new engineers can use projects to demonstrate who they are as people. If you’re showing projects to potential employers, pay attention to detail. Polish them—fix bugs and proofread UI copy. Even without a technical interview, if someone can show craft and effort in their projects, they’re showing they can do the same on the job.
Don’t wait for the technical interview to share what you can bring to a company
In a non-technical interview, be engaged, ask thoughtful questions, and don’t be ashamed of a lack of experience. Research potential employers before an interview and form informed opinions on their products.
Applicants with less experience are often afraid to say things like “here’s what your company needs…” and “here’s what I can do for you…”—but it’s what a lot of interviewers want to hear. Particularly in smaller companies with fewer than 100 people, talking about a problem and actually proposing a thoughtful solution shows initiative, regardless of how much experience someone has.
Right now, tech is filled with opportunities for new coders. No matter if you have three months or three years of experiences, it’s an incredibly dynamic field. It’s not only changing everything, but every new change in tech has the potential to totally level the playing field and get people at all levels of experience learning something new. Who wouldn’t want to be a part of that?
When I first started writing this blog, I had no idea how to format my code so that it looked decent, so I would just take screenshots of my code in Sublime, or even while it was still in irb. I had read a lot of other code blogs and noticed that other people’s code could be copied and pasted - obviously they were not screenshots! I had to figure this out.
There are many ways to pretty up your code snippets, but my favorite is to simply put my code in a GitHub Gist and copy-paste the code provided all the way on the right where it says “embed,” like so:
Then it looks all nice and pretty on your blog, like so:
If you’re using Tumblr (as I am, currently anyway) you can also just place your raw code between a couple of <pre class=”language-ruby”></pre> tags (obviously switch out “ruby” for the language of your choice if it’s not Ruby). It mostly looks fine, just black and white. However, if the code is wider than your blog it might just continue off the side of your post (unlike the GitHub Gist, which has a built-in scroll bar).
It looks like this:
class TriangleError < Exception end class Triangle attr_accessor :equilateral, :isosceles, :scalene def initialize(side1,side2,side3) @side1 = side1 @side2 = side2 @side3 = side3 end def kind if @side1 == 0 || @side2 == 0 || @side3 == 0 raise TriangleError elsif @side1 <= 0 || @side2 <= 0 || @side3 <= 0 raise TriangleError elsif (@side1 + @side2) <= @side3 raise TriangleError elsif (@side2 + @side3) <= @side1 raise TriangleError elsif (@side1 + @side3) <= @side2 raise TriangleError elsif @side1 == @side2 && @side2 == @side3 :equilateral elsif @side1 == @side2 || @side1 == @side3 || @side2 == @side3 :isosceles else :scalene end end end
Personally, I think the embedded Gist is much more aesthetically pleasing, so that’s my preferred method to post code. But, if you Google around you can find many different methods other than the ones I listed here, so feel free to do a little searching of your own and see what you can find!
Good news - I am now officially a graduate of the Flatiron School class of RUBY-005! Hurray!
Can you pick me out of the crowd?
Now that I have some free time, I can finally update you on the progress of my Hobo Name Generator, which is now live (and has been for several weeks but sssh, don’t tell anybody)! You can view the complete code on my GitHub account, but first I’d like to review some highlights of various technical aspects of the project that caused me some amount of confusion. (If you’d like to read my original blog post on this topic, you can do so right here)
First, I changed the structure of the model altogether. I now only want to add the user’s name to a random hobo-esque adjective, so this is the new/current structure of the model:
Next, in app.rb, I defined the routes, which was the hardest part for me to figure out:
The trickiest part for me was learning about exactly what “get” and “post” meant (this was about a month ago, so don’t worry, I know better now!). I had been looking at the code of a similar project done by a classmate, whose code was almost identical to mine in structure, but only had one “get” and one “post” request. No matter how I arranged my code, even seemingly copying it exactly, I could not get Sinatra to understand this ditty!
Finally, I rearranged my code in a way that made sense to me, and it worked! Three cheers, hurray! I knew it made sense that I would need another get request, and I was right!
It was definitely helpful to look at other people’s code in order to figure out how all the moving parts in Sinatra work together, but in the end, I learned that one person’s code is another person’s Sinatra error page, and it’s best to trust your instincts!
I know my Hobo Name Generator app is super simple, but I’d really like to utilize an AJAX request to have it all on one page (mostly so I can learn more about how AJAX requests work). I’d also like to pretty up the page a bit with some of my own original hobo-themed art, and figure out how I want to integrate the Hobo Name Generator into the Freewheel webcomic site.
When walking to and from class every day at the bottom of Manhattan, I’ve noticed plates of text on the ground with a date and name of a famous person. I didn’t realize what these signs were about until I was walking out of the southmost Bowling Green stop and saw the initial plaque on the ground:
After that, everything clicked! They are commemorating every ticker-tape parade held on Broadway, starting with the first to commemorate the dedication of the Statue of Liberty in 1886.
Before I came to the Flatiron School, I was working as a moving image archivist. I primarily worked with collections of newsreels from the 1920s and 1930s. My job was to catalog them and put them online for access. When I realized what the text on the ground stood for, I immediately ALSO realized that I recognized so many of the names because I had seen some of the actual parades happen (on film)! The text that struck me the most while walking up the street was this one:
I’ve definitely watched this footage. I ran to the (digital) archive and sure enough, there it was.
Footage identification can be difficult when you don’t have a lead, but this connection was pretty easy to make. I watched the footage, paying attention to the structures of the buildings, and then pulled up Flatiron School’s address on Google Streetview. Boom! It was a total match!
Here is a screencap of the Amelia Earheart ticker-tape parade superimposed on top of Google streetview.
Bonus: The building that the Flatiron School is located in used to be the office building for the White Star Line, which built the RMS Titanic (and many other, sturdier ships). Cool!