learning and teaching

day 49

Mon, 01 Oct 2012 14:06:40 -0700

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

Mon, 01 Oct 2012 14:06:36 -0700

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

Thu, 16 Aug 2012 16:22:28 -0700

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

Tue, 14 Aug 2012 10:45:27 -0700

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

Sat, 11 Aug 2012 09:51:07 -0700

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

Fri, 03 Aug 2012 18:22:54 -0700

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

Tue, 31 Jul 2012 18:08:58 -0700

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

Tue, 31 Jul 2012 18:02:18 -0700

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

Fri, 27 Jul 2012 23:24:00 -0700

teach one thing at a time.
teach by example first, explanation second.
teach through doing, not showing.
teach with practice.
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

Fri, 27 Jul 2012 23:05:37 -0700

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.

days 32-34

Fri, 27 Jul 2012 10:13:10 -0700

i suck at blogging this week.

continued to work on hacker news clone with phil. really battled with rails and understanding all of the different moving pieces. there are a lot of them. on wednesday, shereef made us spend the morning doing exercises from the curriculum instead of working on the project. it was really frustrating to tear myself away from what i wanted to work on. a lot of the curriculum was stuff i already knew, but on the other hand, a lot of students didn’t know it (especially html/css/erb/front-end stuff). and there was lots of good stuff i didn’t know. but i really just wanted to skim the content and then come back to it when i needed it for the project.

interesting to think about how my learning style has changed over the course of becoming a (slightly) more experienced developer. at first i really wanted lots of practice on the fundamentals. now i want to dive into a project and then learn the pieces i need to complete the project. at first i wanted lots of explanation, and most of the online content didn’t do it for me; now that i have a basic understand, i like looking at the documentation 90% of the time. but there are often still big gaps between what’s available online and what i need to get a deep understanding.

one of the most difficult things about this week has been the sheer number of new things to learn - views, asset pipeline, controllers, routing, RESTful design, validations, relationships, migrations, and a lot more. i’m a big fan of breaking things down into digestible pieces, and i’ve been thinking a lot about how to break rails down. i’d like to play around with a sequence that goes like: oo, db, CRUD design, activerecord, RESTful API design with rails (no views), and finally a rails app with views. every iteration take a project from the previous iteration and move it to using the new architecture, and then add a new project or two that begins with the new architecture.

day 31

Tue, 24 Jul 2012 00:31:27 -0700

started in on our first big project - a hacker news clone. paired with phil, who i love working with. started out with a bunch of reading, most of it review, and some exercises. went through them side-by-side, working individually but discussing as we went, which i enjoyed more than i expected. after a bit we got bored, so we jumped into building.

the day flew by. it was a lot of fun. we’re both perfectionists and love learning new stuff, so we spent a lot of time researching and figuring things out. it took us until lunch just to get the basics of the app set up - creating an rvmrc file, installing postrgres on our dev (with the awesome new heroku app), setting the app up to use haml, and various other things. also, i came up with the name HackerJews which i thought was HILARIOUS and made phil slightly uncomfortable, but after a bit more unsuccessful brainstorming i took the keyboard and typed in the magic command, because i’m not good at compromising.

after lunch lunch we got basic posting implemented, with some awesome validations and a bunch of work to get bootstrap working just right. 6pm rolled around real fast and phil had to leave for a date (woot!). i stuck around because, tonight aside, phil sets a high bar for putting in long hours, and i wanted to pull my weight (also knowing i likely will not pull my weight later in the week ;).

i spent almost another 2 hours working insanely fast on getting user creation, authentication, and authorization set up. (very excited to try out devise one of these days.) i felt really nervous for some reason, maybe because i was trying to code so fast. but i got it, with less trouble than i expected. i started to build the relationship between users and links, but ran into trouble and decided it was late and i was hungry, so i went home.

fun times.

day 30

Fri, 20 Jul 2012 23:24:28 -0700

weirdly couldn’t let go of my url shortener last night and kept working at it before i went to bed. guess i got bitten.

kept on going with the shortener today. started to re-do it properly, without scaffolding. learned a lot and then got annoyed at having to remember everything. anne gave me permission to look at a scaffold while i was building my own, which for some reason i had been feeling would be cheating. got things working fairly quickly, couple bugs, and then built out new features.

day went pretty slow. not as productive as i would have hoped. helped out other people and learned a lot by explaining. funny how that works; hasn’t happened that way in a while. i really get the response cycle now.

through the afternoon got less and less focused, but kept hammering away at getting the features i wanted. some alums came by after class and did a little q & a. interesting to hear their post-graduation experience. got dinner with a few of them, came back, and there were still a LOT of people there. got some help sorting out my last bug, but couldn’t quite get it licked. gave up and went home.

day 29

Thu, 19 Jul 2012 22:22:52 -0700

rails started today. began with shereef’s tough mudder talk. then we had a longish lecture on mvc, rails directory structure, response cycle, and some other stuff. hit the books to learn more about routing. did some exercises on routing, redirecting, and rendering. paired with someone i haven’t worked with before to get through some of the difficult ones. needed lots of help from robert.

helped out a couple people, including someone who had already jumped into the project - a url shortener. as i was helping someone, got a brilliant idea for how to make the url shortener really quickly - just use the rails ids for the shortened links. went and implemented it using scaffolding so i could work fast. funny, it only took a couple lines of code to make it work. tightened things up in a few places, faced lachy’s wrath for implementing it in such a hack-y way, and felt VERY smug.

day 28

Thu, 19 Jul 2012 21:22:51 -0700

corey haines came in for a ‘code retreat’ today. started with some background about how he and other devs would talk at conferences and bitch about how much shitty code other people write, and how much they write. so they had the idea to just take a day and focus on writing amazing code. nifty.

told us to pair up and build conway’s game of life for 45 minutes. we wouldn’t be able to finish it, so we could just focus on the code, not on the product.

my pair and i spent almost the entire time whiteboarding, going through 3 design iterations before settling on a good approach. partway through, corey surprised me by encouraging everybody to stop whiteboarding and start coding. i thought we were being awesome by spending so much time thinking about design.

after the 45 minutes was up, he told us that the requirements had changed, and now it needed to be in 3 dimensions. don’t actually build it - just look at what you would have to change. felt pretty good that there were only a few places we’d have to adjust, although we weren’t super far into the problem.

talked about what good design is. nobody agrees on good design, but we can all strive for better design. his definition of better design is design that’s easier to change. change is the only constant in software.

gave us 4 rules of simple design, codified by kent beck (coined TDD):

tests pass. not unit tests - any kind of tests. that said, shorter the testing cycle, faster you can change.
reveals intent. good names.
no duplication. DRY isn’t just factoring out methods or classes; it’s about eliminating all duplicate sources of knowledge. for example, passing in two coordinates to every method. factor them into a class!
small. methods only a couple lines long. remove things that aren’t needed any more. you can always get them back with source control.

went to our next session but can’t remember our instructions this time. optional instructions were to keep methods under three lines, and not to use if statements. if statements mean your method does multiple things depending on the situation. in that case, you should have two methods. don’t totally have my head wrapped around this.

after the next one, came back for some more words of wisdom. law of demeter: you’re only allowed to talk to things that have been passed to you or things that you create. no method chaining. if you need to talk to something else, wrap it in a pass through method. that makes sense, i guess - if something underlying changes, it gets masked.

next pairing session was mute ping-pong. supposed to help you write really clear code for your future self. didn’t really inspire me.

the next breakout had some really inspiring advice, courtesy of ron jeffries. he says when he disagrees with his pair, he does whatever they want. if they are right, he learns something. if they are wrong, it’s pretty quickly obvious, and they’ll change courses. brilliant.

next pairing was about breaking problems down into small pieces - no more than 3 minutes to write a test or the code to make it pass. if you’re spending more, it’s probably needs to be broken down.

also, over time, these cycles should grow shorter, as you get into a rhythm.

started off good, and our cycles shortened. then we hit on the tough part of the problem, and it went to shit. couldn’t bang our heads on the problem in less than three minutes. part of that was we made the problems too big, sure enough. but part was we just needed more time to figure it out.

got the feeling this retreat was typically done with people with more experience than us.

last breakout talked a bit about tests and objects. don’t test if a method returns an array; test for what you’re looking for. comes back to my insight from ‘numbers in words’ - write code to do exactly what it should. i will figure out a better way to express this, but it’s a concept that i think is really important.

day 27

Tue, 17 Jul 2012 21:55:14 -0700

started the morning with shereef trying to decide what to do next - have a breakout on the issues we ran into yesterday, let us continue on those problems, or starting working on refactoring staff versions of apps from last week to use activerecord. quite a bit of back and forth, and decided to work on the apps. shereef joked that if he wasn’t exuding confidence it was all in our heads. bummer that things aren’t going more smoothly. ideally, i think the curriculum would be dogfooded more.

shereef strongly suggested we solo. i asked why. he said because he thinks we’ve been spending too much time pairing. it’s funny for me to hear that. i’m just getting to the point where i can’t get enough of pairing; before a few days ago, i would have loved to have spent more time soloing.

started on the craigslist scraper app, since it was what i had worked on, but the code didn’t feel good and i wasn’t sure where to start, so picked up the drive or bart. that one turned out to be a great place to start. took me a while to get my head wrapped around the code, and then a while to figure out where to start on replacing raw sql with activerecord. but once i got it, it was pretty easy, when i realized that jesse had just re-implemented activerecord methods. i just had to comment out all of his code and have his class inherit from activerecord. then tweak a couple tests and a little code and i was done. but the weird thing was, i didn’t feel like i really learned what i was supposed to, because i didn’t really know how jesse’s methods worked, and i didn’t have the energy to work my way through them.

started on the next one, ruby reflector, and ran into some weird errors that i had trouble with.

after lunch, jesse did a breakout with… his own code, which i had already worked through. but i learned a bit from it anyways. really wanted a nap.

paired up with kendra and worked on one of the exercises from yesterday. made some good headway and learned a lot. she got distracted with something else and i worked through another of yesterday’s exercises and got through the first part of the ruby reflector refactor.

went for a run after class and while showering afterwards thought a lot about how best to teach databases. it’s been on my mind a lot the past few days and i feel like it’s coming together for me. i think the dbc approach of building in-memory apps first, then backing them with plain text, then with sqlite, and then moving to activerecord is right on, even if the implementation hasn’t been perfect. all of the skills in each step are important for a web developer to have, and they give a deeper understanding of the problems that the next abstraction layer is solving. here’s how i would do it, to try to make things flow a bit better:

in-memory app, such as todo.
text-file-backed app, such as todo and flashcards. teach the pattern of using a parsing method (via a coding example for another app than the one students work on) rather than parsing within the method that reads in the file.
swap out the parsing method for CSV.
swap out CSV for sqlite. teach the pattern of having the db interactions in their own methods (via a coding example for another app).
show the pattern of factoring out the save and load and other common db methods into a class any other db-interacting class can inherit from. have students implement it in their own app.
then replace that class with activerecord.

i think this approach would teach important skills (interacting with text files, CSVs, SQL, and ActiveRecord); help students understand the “magic” and justification behind each subsequent layer; impart good design patterns in each phase; and avoid the frustration of not really knowing what we’re doing or seeing a reason for doing something.

i’ve also been thinking a lot about the flipped classroom model recently. i like the idea more and more.

day 26

Tue, 17 Jul 2012 21:27:30 -0700

started the day with our teams from last week, doing a feedback session. each person took turns saying the things they thought they did well and the things they think they could improve on. then the other three team members went around and gave them feedback. pretty great format. when it came to my turn i had a hard time thinking of positive things to say about myself. i had trouble pairing for the first part of the first day, because i was frustrated that my pair was so far behind me, but when she finally confronted the situation i was able to quickly change to a more productive way of working with her. some good, some bad. when we went around, my pair from that day gave me good feedback on my responsiveness and took a lot of responsibility for not telling me before we started. also, i took charge of our whiteboarding session on our app and db design; i wasn’t sure if i was too heavy-handed, so i asked for feedback on that. people said it was fine. my pair who was closest to on the same page with me said he really appreciated my attention to detail and perfection-mindedness, but cautioned i might be going too far. i hear that feedback, but deep down, i’m not taking it ;)

worked a bit trying to finish up the app to a usable state but didn’t get there.

two teams had their code reviewed in front of the class. we went second. the first team got a bit torn apart. shereef didn’t review all of our code, but fortunately focused on the class that everybody had contributed to. i had done a big refactor on it and felt pretty good. shereef was really positive; said he was scraping the bottom of the barrel for criticism. yay. but farther down, things got a bit worse. tests weren’t written as well - that was stuff i just didn’t have time to refactor; but also there was a big method that i had actually refactored out of a few confusing smaller ones. i wasn’t sure where shereef was going to go, but then he had the brilliant idea of turning it into a factory method since its point was to get data prepared for creating an object. awesome.

after lunch we started activerecord. it did not go as well as we hoped. in the beginning it was pretty straightforward, but then there were lots of really confusing things about how to construct queries and create relationships among objects. very frustrating in a not-good way. got burnt out and didn’t really try to finish the homework.

day 25

Sat, 14 Jul 2012 11:59:14 -0700

RAFTING

day 24

Thu, 12 Jul 2012 19:17:38 -0700

last day of our week-long projects (tomorrow is rafting!). jeremy was gone so i soloed while asad and orasa paired. we went over everything that was left and divided it up. turned out to not be that much… but funny enough, we didn’t finish. things take a long time.

writing my own code didn’t take too long to get everything working. but then i had to go in to make changes to our old team member’s code to add some stuff and it took a really long time to figure out. i spent a lot of time refactoring to make the code more understandable and usable. i wasn’t sure if i was spending too much time refactoring, because at some point i understood the code and could have stopped refactoring and started building. but i just couldn’t stand to leave it that way.

thinking about it now, i think it’s actually good that i kept refactoring. if a future developer had come into the code and i hadn’t finished, they would have had the same struggle as me. so by spending another 45 minutes on it, i probably saved a future dev 90 minutes.

but, i didn’t get to actually write the new things i needed to add to the code.

but, it probably would have only taken me an hour to finish now that the code is clean.

oh well.

day 23

Wed, 11 Jul 2012 19:24:00 -0700

meta skills wednesday. started off with group checkin. always nice. we have two minutes to give a checkin; everybody else seems to find it plenty of time, and i never feel like i have enough. what does that say about me. hm.

shereef’s brother came in to co-facilitate a workshop on the super ego. it was optional and about 6 students opted out. terms like super ego make me skeptical, but i decided to stick around. was glad i did.

shereef and his bro explained super ego as the voice in our head that tells us we aren’t good enough, that we’re too fat, that we aren’t smart, that nobody likes us, etc etc. it can sometimes give us praise in a bad way - “you lost weight, girls will like you now” - but it comes at the expense of our self-worth.

then we wrote down the couple things our super-ego tells us most. mine were “you’re too needy” and “s/he doesn’t like you”. came back to the group and people shared theirs.

a student came up and acted out his super ego, with shereef’s bro playing the part of his regular self. pretty amazing to hear those experiences, and how i could relate to a lot of them, and at least empathize with many others. then shereef’s bro talked about how it felt to be talked at that way.

repeated with another student and shereef.

then we paired up and did it ourselves. paired with tanner, who i quite like. i started out as super ego. was pretty nervous at first, but actually once i got into it, i realized that the words i was saying, while still resonating, didn’t go as deep as they used to. feels good seeing from another angle how all the therapy and whatnot i’ve done in the past year is paying off.

also interesting how what tanner described feeling was almost exactly how i often feel.

we switched. very surprising to hear about somebody else’s insecurities this way.

then shereef and his bro showed up a diagram of the “compass of shame”: attack other, attack self, withdrawal, avoidance. we broke out into groups based on our primary behavior and talked for 10 minutes about why our group was the best. kind of a weird approach, but i get it - i definitely have thought a lot and justified why i deal with problems this way. but it’s too bad we didn’t also discuss why our way is bad.

came back together and shared with the other groups why our way is best… and pretty surprised at other responses. attack others don’t want to let go of their relationships, so they want to engage you and work it out. our group didn’t want to hurt anybody. all groups seemed a bit surprised to hear about how much their responses hurt other groups. shereef and his bro said that our approaches are often different from our parents’ - we see our parents way, don’t like it, and do something different. i can relate, but i’m not sure that’s the whole story.

after lunch, our groups lost one member and gained a new one. i paired with jeremy, our new member. awesome pair - really great at switching, working through problems, talking about issues, coming up with new ideas, etc etc. one of my best pairing experiences. that said, most of our time was spent on some really minor bugs that were just super tough to work out. literally spent two hours on one line of code. but we got it sorted just as 6pm rolled around.

AND OUR CODE IS BEAUTIFUL

after class talked with felix about super ego and alternative models of that experience, social identity, taking the meta-skills to the workplace, and a bunch of other stuff. rock.