learning and teaching

day 49

spent the morning with my group. actually, started with responding to an important email, and gavin came over and told me he understood why i was not participating and contributing, but that he was hurt that i hadn’t brought it up. i wrapped up what i was doing, joined my group, and apologized.

spent the rest of the morning working on styling. got things looking pretty nice. awesome pairing session with ivan. it was like each of us was able to pick up whenever the other one was at our wits’ end.

afternoon had demo day. HOLY SHIT people built some impressive stuff. i was pretty proud of what we did, and still am, but quite a few groups went really above and built some crazy stuff. wow.

my brother and two of his friends dropped by for a few minutes. that was fun.

then there was some interview prep stuff. didn’t pay a huge amount of attention.

day 48

spent the morning on impact dialing. lots of business stuff coming up. started working on the first bit of the feature i am building. mainly just refactoring to get ready to build an api. the api will be trivial once the refactoring is done. ran into a lot of problems, but the fun part is that i knew how to solve them. going was very slow, but very steady. awesome.

afternoon worked with my group. lots of distractions. but got to spend a lot of time on styling. got things looking pretty good. feeling better and better about css.

day 47

started the day with shereef talking about hiring and answering questions. notes:

you will have a range of experiences
some will hate you and want to show you you suck
some will think you're awesome just because of going to dbc

you will have a lot of rejection

learning should be number 1 thing you look for
humility and confidence
i am a beginner
i can figure things out

be comfortable saying "i don't know"

if you think you need to know everything, you will be stressed
if you approach it like the last ten weeks - learning - you will have fun

be kind to yourself
the first few interviews will suck

be honest about how excited you are about a company

last person interviewed was first person hired
twitter and change disappeared and then got in touch after everybody was hired

your knowledge is not useful
you will be hired for who you are, not what you know
you know next to nothing
you are a 3-4 month investment, before you contribute useful code

3 spring graduates aren't even using ruby

you will get cs questions you will have no idea about
if the employer thinks you're stupid for not knowing, they're stupid

big companies don't know what to do with dbc grads
their interviews are for cs grads
small companies tend to get this more

be humble about what you can do and then surprise them

spent the morning working on impact dialing. a couple times almost gave up and put in a ticket with twilio support or an email to my developer. but each time, i then thought ‘this is just a computer. all i’m telling it to do something wrong, and i need to tell it to do something different. i just need to figure out what.’ and i did. rock!

in the afternoon worked with my group. was not a great team member. got distracted a lot, had to take a call with my investors, took a nap.

had a nice session with a designer who dropped in for the day. he gave us some good feedback on our app. really liked his approach of putting together a scenario of someone using the app and walking through the usage in their shoes.

did a bit of css and realized how muddled my understanding is. robert cleared me up and now i have a better understanding of what i’m doing, specifically around inheritance.

day 46

yesterday started getting things set up to hack impact dialing locally on my dev machine. took a lot of time; realized i needed to make some changes for ruby 1.9.3. at first got frustrated and then just went to problem solving mode and got things figured. took a lot of time, but really satisfying to be able to do it.

started the morning with exercises, so i just worked on impact dialing. loving it so much.

in the afternoon back on group project. had a standup (in the morning, actually), and planned out the week and divided up the work. was really tired and felt unproductive. got some jquery stuff working. not liking how i’m learning javascript and jquery - just hitting my head and solving one problem at a time, instead of getting the big picture. but then again, this is how i started learning ruby: before i made a concerted effort, i tried to just learn little things to get by, and then realized i needed to learn the big picture. here i am again.

once we got jquery working, starting working on form submission to get the data back. again, a tough problem. looked at how impact dialing does it, and didn’t understand at all. so much for understanding impact dialing.

but all i want to do now is hack on impact dialing. can’t wait until i can work on it full time.

days 41-45

group projects this week. came in and pitched our ideas. i pitched building an api for impact dialing, but didn’t get enough bites. wasn’t excited about much of anything but signed up for my favorite, a tool to help groups make decisions. spent the afternoon whiteboarding the product. really glad we did - so many different ways to approach it. trouble was, we didn’t really have a good grasp of how people would use it, and under what situations. so we just made some assumptions about who our users were. one frustrating part was that i wanted to make decisions lean-startup style, by putting out an mvp and getting feedback, but obviously we don’t have that ability, so we just have to decide to do things one way. oh well.

started building and realized it was really difficult to coordinate between two pairs when we didn’t have an existing codebase. the other pair started setting things up with a rails template while we did i don’t remember what. once we had the code we tried to start building, but again it was tough when we didn’t yet have the core pieces we wanted to be building on. in hindsight, we could have built some static views with placeholders for the dynamic pieces.

next day we were supposed to do curriculum in the morning. i wasn’t too interested, and we didn’t really like all of the stuff the rails template threw at us, so i rebuilt the app by hand. took a bit longer than i expected but easily completed it by lunch. but when i was moving the actual functionality the other pair had built over, realized they hadn’t test-driven it and that they had generated a controller that left a bunch of extra stuff. started to test drive it to see how long it would take to get to that spot and then gavin came over and paired with me. later apologized to the other two for throwing out their work and brought up the issue of testing. i’m definitely the most into testing in the group. pushed everybody else to get on the tdd train.

pretty hard to work in a group and get everybody on the same page. there are a lot of things i don’t like to compromise on, like tdd and clean code.

finally got the pieces together for the base of the app. the other pair worked on another piece of the user flow. by the end of the day they were very frustrated with tdd and felt like they hadn’t gotten much done.

at some point in here wednesday rolled around. the morning workshop was on conflict and frustration. unfortunately i don’t remember all of it, but here are the two big parts. first, we got in our groups and said on a scale of 1-10 how we were feeling about the project. our lowest was 3 and highest was 8. then we went around and said why. nobody really liked the problem we were working on. that was a bit of surprise to me. we came back to the big group and shared a bit about what happened. steve had our group come up in front and talk about our issues. he also had one person come up who was having conflict with his group and talked with him. the other piece was that we paired up and talked stream of consciousness about how we were feeling, and also commentated on that stream of consciousness. it was very steve. my pair and i both had some similar feelings about not being super into some of the steve stuff but trying to keep an open mind and finding some of it interesting at least. then we paired up with someone else and told them what we really thought of them. that was pretty interesting. my pair and i beelined for each other and had some slightly surprising things for each other. there’s something to be said for this radical honesty, just say what’s on your mind approach. but there’s also something to be said for feeling things out with people, for non-verbal communication, for letting things evolve organically. there’s a reason we do things the way we do. it’s not perfect, but don’t throw the baby out with the bathwater, etc etc.

that afternoon my group spent a couple hours trying to figure out something better to work on. we couldn’t agree on anything, and the best choice was to continue doing what we were doing.

the next day i switched to the code they were working on. some pieces were really broken. there was a lot of weirdness around things being saved that shouldn’t have been, tests not running correctly, helper methods not acting right… finally we got a TA to come help us. he removed spork, which he says can cause weirdness, and it started working, then put spork back and moved a few things around until it worked. these are the kinds of things you can never learn online. but i wasn’t satisfied because i didn’t actually know what the issue was and why some things needed to be in certain places in spec_helper.rb, and he didn’t either.

kept moving through and getting things working and in the right places. hit another issue with using a devise helper and robert walked us through that, eventually deducing that it must just only work for controller tests, not integration tests.

the next day i got a chance to work on my own for a bit to wrap up the loose ends. created my own helper method to replace the devise one, cleaned the code up, rearranged and deleted things in spec_helper.rb until they were working properly, had no duplication, and had no unnecessary requires, and got all tests passing. thank god.

the rest of the week was just working bit by bit through the different pieces of the app. really slow going. realllly slow. i often feel like my teammates are moving really slowly. i think they feel that way, too, which is why they don’t want to test. but i think testing is such an important skill. it’s not testing that slows us down; it’s not knowing how to test, and learning that as we go, that’s slowing us down. and even when i’m frustrated by pairing because i know i could go much faster on my own, i still really appreciate it for helping me think through things i wouldn’t have otherwise, and catching my syntax errors and other dumb mistakes.

it’s the end of the week and we have very little to show for it.

days 38-40

paired with austin on a new project, a basecamp clone. felt great about starting something fresh, with the chance to tdd it the whole way. austin was a great pair; really knows his stuff, and we had a good rapport moving back and forth and solving problems together. was really good to be pairing again. really blows my mind how many super solid students there are in this class.

we did some reading on tdd and then dove into the project. decided to only tdd the models. shereef said no point in testing controllers since they should be super thin and do almost nothing. we thought it seemed silly to test our views, since they are just dumb rendering of the models.

we struggled a bit with what to test; you don’t want to test what rails does, but most of what we do is just rails methods, right, so what do we test if we aren’t writing our own methods in the model? we looked at the ‘awesome foundation’ example and saw that they had tests for the rails-y things they were implementing, which made sense. they also used some fancy matchers through shoulda, which made testing seem even more magical, but made a lot of sense when i thought about how writing the validation and relationship tests would really be almost the exact same thing in every situation.

finally got underway and it all seemed so simple, it felt like we were missing something. but after a bit i got more comfortable. and talked to shereef and we were on the right path.

we blazed through the first parts of the project, got everything working without too much trouble. at the end of the day i had an awesome experience. austin had been driving on the model, we got everything in place, and then i took over to write the controller and view. i blazed through the code. i was moving so fast. it felt amazing; i knew exactly what i was doing, just flew through the files and put everything in place exactly right. well, except that i hit a small bug just as 6pm rolled around. but damn. felt really good to know what i was doing and be able to do it crazy quick.

next day kept going. things got a bit more complicated and we had some nice breakthroughs. also ran into a funky error that we only fixed because robert came over, had seen it before, and showed us what to do. we replied to an unanswered stack overflow question on the same issue to pass the knowledge on.

funny how different testing rails models is than testing pure ruby. there’s so much rails magic, and then shoulda gives you so much testing magic, there’s often almost nothing to do. when we actually wrote a couple of our own methods it felt great to be back writing the rspec i was familiar with, where i had to do the heavy lifting. funny how that works.

by the end of the day we were spending most of our time in the browser testing the flow. it was horrible. we agreed that we would do capybara the next day. really gained an appreciation for view testing. not as straightforward as i thought!

did a retrospective in the morning and then moved to ajax. our new assignment was to change various parts of our app to be ajax-y. went through some reading that i didn’t think much of, finally got down in some code. phil and i had done some ajax; i was comfortable with the concept and how to make requests, but the javascript responses intimidated me. fortunately, austin was somewhat familiar with jquery, so our skills really complemented each other. yay pairing.

both of us were a bit low energy, so we spent a good amount of time making silly syntax errors. but we also learned some great stuff from robert about how helper methods for forms and links work.

we got the ajax to work and felt pretty awesome about it. also jquery is great. makes this stuff way easier to understand.

ended the day with shereef live coding tdd for the pollster app. was cool to see him using capybara. looks really straightforward. other students were struggling with how and when to tdd the model, and shereef’s explanation made me feel like i understand it pretty well.

day 37

started with a talk on testing. mostly review. took a group picture.

started out with exercises on testing, ran into a curriculum bug, and switched to trying to build the pollster app again. blazed crazy fast using scaffolding ;)

switched back to testing exercises, went through them with some annoying problems that were mostly my fault (in the wrong directory for a while), read some stuff.

went back to the pollster app, got some help with tricky business on creating multiple instances of a class with one form, and finished up the app without too much trouble.

got everything set up to start actually writing tests on pollster, felt tired, didn’t get anything done, it was almost 6, and i called it quits.

can’t wait to work on something new tomorrow. AND PAIR

day 36

spent the day soloing on an app for polling. it seemed really simple and took way longer than i wanted it to. some really annoying stuff about authorizing without user accounts, just using a random string in the url. spent way too much time figuring out the best way to create the random string.

got 3 vaccines in the morning and in the afternoon i totally crashed and got nothing done. it sucked.

a variation on my first post

1. teach one thing at a time.
2. teach by example first, explanation second.
3. teach through doing, not showing.
4. teach with practice.
5. break these rules as needed.

• teach one thing at a time.

when it comes to difficult problems, most people only have the mental capacity to learn one thing at a time well. so don’t try to teach more than one difficult thing at a time. only move to the next thing when students have a reasonably solid understanding of the first.

• teach by example first, explanation second.

human minds work most effectively by creating patterns. our logical abilities are far inferior to our pattern-making abilities. so favor examples heavily to show a concept before diving into an explanation. if the examples are good, you won’t need much explanation.

• teach through doing, not showing.

people learn more by doing than by watching others do. so give students a lot to do and little to watch.

• teach with practice.

people learn through repetition, so doing once isn’t enough. do a couple times. then do something else, and then go back to the first thing again. repetition, and spaced repetition, will help with the pattern-making process.

• break these rules as needed.

all the time you’ll find that it’s more effective to teach two things at once, or to give a bit of explanation before an example, or to do more showing than doing. so do it. but only if you have a good reason.

day 35

last day of hacker news clone. worked on exercises in the morning (per shereef’s orders) and learned a bit. spent the afternoon not as productive as i would have liked, but finished up some good stuff on the the hn clone. phil and i paired most of the time, which i liked. we spent some quality time with twitter bootstrap getting the styling better, and refactored some of the polymorphism phil implemented for comments. it was funny - once i got into his code, i realized that his implementation was actually pretty similar to mine on votes. there was some duplicate code i factored out, and started to remove some of the custom redirecting phil had done in favor of rails built-in methods, and then phil accidentally turned the computer off and we called it quits.

i spent some time thinking about how different what i’m doing now is from what i was doing in week 2. very hard to remember how i was coding then. i really want to go back and put together a couple of those apps again to see the differences.