30
Mar
12

DevBootCamp Reflection

Devbootcamp: an 8 week intensive program aimed toward taking neophytes to the web development space and turning them into hirable junior level developers.  I have just learned more in this program than I did in the entire year preceding and I want to investigate why.

 

First, I think the fact that we were a group seemed to make us all learn at a much faster pace.  We helped each other, we inspired each other, we made each other a little jealous, and we pushed each other.  I felt guilty leaving the office at 8 not because I was supposed to stay and work, but because I felt like I would be missing out on something really great.  Whenever I ran into a sticking point and felt a little dumb, I would inevitably find out that three other people had had the same problem either earlier in the day or at the same time that I did.  A lot of learning to program is about not letting yourself feel defeatist and stupid, and having other people in the battle with you helps a lot.  It was also a big factor that all the people in our cohort were just incredible.  I felt a bit out of my league in the company of most of the people at bootcamp, but just rubbing elbows with them is really useful and I found myself adopting the good habits of some of my peers almost without thinking.

 

Second, the structure was perfectly tuned for a beginner.  Many other programs jump right into rails because it speeds up the process of development by a lot, but it also does a bunch of magic that is really hard to understand as a beginner.  In bootcamp, we focused on getting a solid understanding of ruby first, which allowed us to understand when rails was doing magic and even be able to follow the magic a little further.  I felt like understanding ruby made me confident that I could build things, and once I got that mindset, rails made a lot of sense.  There are still some things rails does that I can’t for the life of me comprehend, and still some stack traces that I am afraid to follow, but I have a better feeling for what I’m getting into because I understand the building blocks.

 

Finally, and most importantly, the teachers at bootcamp really made the whole thing possible.  Where I used to spend a day or even two stuck on a bug and grinding in the past, during bootcamp I got unstuck within minutes or hours.  More importantly, I learned a lot about how to not get stuck in the first place.  I learned about how to get unstuck myself faster and how to ask for help when I need it.  Shereef, while being completely overwhelmed, made a strong effort to help us build ourselves and not only help us learn about programming, but also participate in some meta-learning.

 

Interestingly, as a result of finishing bootcamp, I now feel like I am further away from being a ‘real rails coder’ than when I started the program.  I learned about so many things that I didnt even know existed, and there were so many interesting technologies to study that I have a heap of information to ‘read and ingest later’.  I’m not sure I could maintain this pace for much longer than 8 weeks, but I really hope that I can keep the tenacity and energy that I absorbed from the bootcamp community going forward.

 

01
Mar
12

Model mishaps

Mon-Weds this week I really felt the stretch.  I had dealt with models and creating associations before, but I had never cemented my knowledge of them to the degree that we did in boot camp.  Among the difficult ones were:

Self referential associations:  

Problem:  A family with each member represented as an instance of the Person model.  Each person will have a relationship (Relationship model) with other members of the family.  This seems to be an obvious has_many relationship, but the strange thing is that it is a has_many relationship with another member of the same class.  So it is not as easy as just saying has_many :people, :through => :relationships, because it is ambiguous which ‘person_id’ you is the ‘from’ and which is the ‘to’.


Solution:  You need to create your own names for these relationships, for example instead of saying has_many :people… you need to say something like has_many :person_tos.  But then rails doesnt know how to find your foreign key!  So you need to explicitly tell it where to find it.  has_many :person_to, :through => :relationships, :class_name => ‘Person’, :foreign_key => ‘person_to_id’. Then do the same with the other side of the relationship. has_many :person_from, :through => :relationships, :class_name => ‘Person’, :foreign_key => ‘person_from_id’  .  Then you need a model for the relationship which acts as a has many table.

This took me hours to figure out.  Some meta that I learned from Doug (thanks man), was that the syntax for doing this has changed somewhat in rails, and so it helps to sort out old blog posts that might talk about how to do it.  So narrowing the search to within the time period of the latest version of rails (which we are using), helps to hone in on the right syntax.

Using the #delegate method to access information

Problem:  There is a Person model, and a Details model which holds lots of information about the people represented in the people table.  How do you set up the association and how do you delegate?  At first glance, one might try this:

class Person < ActiveRecord::Base

has_one :details, :dependent => :destroy

delegate :name, :to => :details

after_initialize do

self.details.build

end

end

but, I ran into a problem where every time I created a person, then added details about that person, then went to check that detail through something like Person.last.details, I would find a completely empty and new instantiation of the details Model. 

Solution: as it turned out, calling Person.last runs the initialize function.  This was confusing to me because I interpreted that the initialize function would only be run when creating an object.  So, in the end, the solution was simply to check in the after_initialize function if the record is a new record or not and only create an association with a new detail object if it is a new record.

Although it was pretty frustrating at the time, I feel like I have learned a lot in the process of figuring out why I was having this difficulty, and I think I’m a better coder for having had this experience.  I hope these explanations helps people who ran into the same problems that I did.

13
Feb
12

Feb 11, Saturday (day 11) – Programming as the new literacy?

We had a great speaker come and talk on Friday.  I think he had a lot of really useful things to say, but I disagree with one of his assertions, and I have been thinking about it enough that I think I’ll write about it.

 

Assertion

 

I think that there is a faction of programmers that believe that code should be taught in schools as a mandatory subject and that eventually everyone will know how to code and it will be a fundamental skill like writing and math are.  The argument goes that long ago, people though only special people could learn to write and that that turned out not to be true.  By extension, one could assume that people will learn to express themselves through code just as they have through writing.

 

Pushback

 

I think this assertion is a very positive thing to think and I really do like the idea of teaching it to everyone.  However, there are several factors that I think make coding dissimilar to writing.  I think that due to these differences, the people capable of coding as we think of it today will continue to be in the minority.

This is not to say that coding can not be brought to the masses.  I think that as coding becomes more human friendly, complexity will be stripped away and people will be able to create things using the extrapolated systems that our current system of coding evolves into.  In the same way that the complexity of writing has been stripped away and people express themselves through words.  However, I think to make complex things will still require a good understanding of how to manipulate complexity, and will leave many people unmotivated to learn to make a certain class of things.

 

Assumption 1

 

The first assumption is that people use writing now to express themselves and so will be able to express themselves through code in the future.  There are many people who, while capable of writing, have a large amount of difficulty expressing themselves clearly through words.  We take classes all the way through college on how to express ourselves well, but I don’t think anyone would claim they have mastered the art of expressing their thoughts through writing.  The difference I am trying to draw is this: writing is  a way to do two things:

1.  Translate verbal expression into symbols

2.  Translate ideas into symbols

I think that when we say that everyone is able to write, we are talking about accomplishment 1.  It would be difficult to claim that an overwhelming majority of people easily perform the feat in accomplishment 2.  Because the art of coding lives strictly in the perview of accomplishment 2, I think it would be difficult for most people to learn to the point that coding will not have the adoption rate that writing does.

 

Assumption 2

 

Given that we are past assumption one, people are likely to adopt coding as an intrinsic tool of communication in the future.  I think this is also a leap.  I think that because people can express themselves in writing effectively despite logical mistakes and and syntax errors.  It’s true that we can mold coding of the future to handle some of these, we can make parsers looser to handle syntax errors and we can correct some basic logical mistakes.  It’s also true that one could claim logical errors are part of expression and that people will enjoy expressing themselves slightly incorrectly through code as a form of communication.  However, some logical mistakes will make a program crash, but there is not a sentence that you can say that causes the sentence not to be heard.

 

Conclusion

 

I really do think that coding is a wonderful thing and that everyone should try to learn it.  I do think that the vast majority of people have the ability to learn to code to some useful level or another, but I think that the barrier to entry will keep the adoption rate much lower than the adoption rate of writing.  It’s not that we can’t or that only special people can do it, it’s just that it takes a huge investment and that until we strip out the computational load and leave only the primitives that people are dependably able to express themselves with despite errors in their construction, coding will be unappealing.

10
Feb
12

Feb 9th, Thursday

Today was a great day!

I think it’s an awesome idea to do yoga in the morning.  It helps me to do a kind of meditating and gets my body moving, preparing me for the day.  I got to go for the first time today, since I was sick previously, and it was fun.  I do wish it was less often though, as the cost per day in time is about 2 hours after transport and all, and I would rather do an activity that took 30 minutes and used the other 1.5 hours for some coding.  I think I’m going to try to get in the habit of spending at least 10 minutes after lunch meditating as well as I think the focus that I build in yoga has been frazzled by lunch.

Today I worked all day on creating an exercise and my pair and I got a ton done.  We really helped each other fill in the gaps and were able to catch each other’s small mistakes.  It was my first time writing a bunch of Rspec tests that didn’t come from the Michael Hartl tutorial.  I was surprise both by how initially difficult it was to set up the tests, and then how relatively easy it was to write tests after the first 5.  I also learned that it is really important to be super descriptive with one’s ‘describe’ methods.  Our error messages were just silly long and confusing, to the point that I couldnt figure out what test was not passing.

We also explored more about the difference between:

class Object

def self.method

end

 

and

def method

self.other_method

end

end

Very different things.  The top one means that the method will be available when you call Object.method.  The bottom one means that you can call that method on an instantiation of the class, like Object.new.method.  Also, I believe that in the example self.other_method, the self would refer to an instantiation of the class as well.

10
Feb
12

Feb 10th, Friday (day 5) – Is coding the new literacy?

Yoga

Yoga stressed me out, then chilled me out, then stressed me out again, then chilled me out again.  I woke up late and thought I was going to miss the bus, then the 71 limited showed up.  I felt pretty special, riding a limited bus and figured it would make fewer stops and I would get to yoga with time to spare.  I learned that limited means absolutely nothing.  It took longer, if anything, and I started to envision the locked door at the yoga studio and my accountability buddies crying while doing pushups and beseeching me to get up earlier.  As luck would have it, I got off the bus on 1st street with three minutes til 9:10, and ran to the studio, making it just before they locked the doors.

Needless to say, I wasn’t in the right frame of mind for yoga.  It’s pretty hard to switch gears from ‘my self worth is represented in being on time’ mode and all the stress that goes with it to ‘you are in the place and body that you are in, and you shouldn’t expect yourself to be anywhere or anyone else’ mode.  Then the stretch began to sink in.  I got in touch with my breath and started to relax.  I thought ‘this is great, I’m beginning to feel totally relaxed’.  Then we started getting into the hard stuff, the kind of poses that particular parts of my body tremble with complaint when I’m doing them, and I thought ‘I didn’t know this was going to be hard!  I don’t want to be all sweaty all day’.

I think though, like anything, the most important thing I can do in regards to yoga is to take what value I can out of it, and leave the rest.  I pushed myself and tried to follow the instructor, but when I felt myself thinking it wasn’t any fun, I just stopped and took it easy.  My main goal in going to yoga is to focus my mind and hone my attention before coding, and as I kept that in mind, I eased into a very comfortable state of relaxation and treated myself to a sort of mediation.  I think it left me in the perfect state of mind for the day.

 

Retrospective

We spent the morning talking and polling about how the program is going.  I think it’s really important for something like this to be a moving and changeable entity and I’m really glad that it feels like we are shaping the form of our education as we go.  One interesting stat that I noticed was that very few people felt like they were being dragged and that they were being overly challenged.  I do think that there must be some subtle learning going on though because although I was also one of the people who felt ‘less challenged’, I have the same feeling of fatigue when I get home as I have when I go to chess tournaments.

 

Coding

I spent the day pairing with Lachy, who is a great pair and a fun guy.  We wrote an exercise together and did a lot of good searching around ruby-doc.org.  I have learned that I should fine tune my search style depending on what kind of information I am looking for.  I looked for a long time how to round a FixNum, and found all sorts of information about it, but what I should probably do when I am looking for a thing that I assume is a method that exists is just look on ruby-doc.  I think that it would be wise to google only when I have a general problem that probably can be solved in several ways.

08
Feb
12

BOOT CAMP!

Three days ago, I started an amazing program called Devbootcamp.  I found out about it from my room mate who reads Hacker News religiously, and signed up.  The exciting thing about it to me is that it emphasizes a lot of practices which will be really important to working in a company – pair programming, test driven development, object oriented programming.  It’s awesome that I’m getting to practice these things before I even interview for a real job.

Yesterday, Wednesday the 8th, the exercises left the realm of total beginner and started forcing me to work on things that I had not put much time into before.  Specifically, object oriented programming seems both really intuitive to me in some ways and really unintuitive in others.  I think it makes sense the separate concerns by encapsulating things, but I have gotten so accustomed to the idea of manipulating properties in javascript, that it feels really weird not to write just ‘object.property = whatever’.

After the talk we worked on an app that implements a temperature conversion widget, but implements it in an object oriented way.  The trick is to think of the verb ‘convert’ not as an individual function, but as a suggestion to the temperature object.  I think it may have been easier to grasp if it were more directly mappable to a real life example.  For example, the idea of object oriented programming is pretty easy to think about when you are talking about nouns like ‘door’.  A door can have state such as open or closed and it can have state altering behavior, such as opening or closing.  creating a door object is rather intuitive, because you can just alter the state of a physical door being altered by it’s methods.  However, it’s pretty tough to imagine the state of a non-physical entity like ‘the construct of temperature’ and the state altering verbs aren’t as easy to grasp.  Regardless, my partner and I finally figured it out, and were pretty proud of ourselves.

Favorite quote from the day:

Tony – (on the benefits of emacs key-bindings) “I just…don’t want to move my hands”

Shereef – (confused) “but…that’s your job now”

looking forward to tomorrow.

23
Jan
12

Who is the audience?

I recently went the the Health Innovation Summit sponsored by Rock Health.  It was a marathon of a conference (3 days), and packed with info.  This makes probably the 3rd such conference that I have been to, and I have noticed a trend in talks that some of the speakers at the summit did a great job of avoiding.

 

The problem: It seems to be a common problem that speakers try to aim their talk toward the middle understanding level.  They don’t want to confuse people, and they don’t want to start from the very beginning, so they hit that ‘sweet spot’ in the middle.  Unfortunately, I think this spot isn’t so sweet, but rather bland.  There are basically two kinds of demographic for any particular talk. Either they have experience with the technology or idea that you are talking about or they don’t.  The problem comes in because by shooting for the middle, you are effectively losing all your audience.

 

For the beginners, the frequent acronyms that seem to creep in, and the subtle implicit knowledge that is not conveyed in the talk leaves the beginner thinking “this must be a talk for people with more experience, I’ll get some coffee.”

 

For people with experience, the speaker’s attempt not to lose the beginners leaves him/her only talking about very general concepts or very basic ideas that anyone who had spent a day or two thinking in the idea space would have come up with anyway.  This leaves the experiences listeners thinking “This is for noobs, I’ma get some coffee.”

 

Solution: So the reason I bring it up, is because several of the speakers at the summit did an amazing job of avoiding this pitfall.  I think there are two main solutions to this problem, and I think both are totally viable.

 

Solution 1: Choose one of the two audiences.  Yep, you are accepting that half of your audience is moving toward the snackbar, but at least the audience that you have targeted gets a real and meaningful interaction.  By focusing on either the newbies or the veterans, you can make sure that you have a focused conversation with no inefficiency in your presentation.  I think Michael Coates did a fantastic job of this.  He decided ahead of time that he was going to focus on people who had little to no experience in web safety.  The newbies I think had a great opportunity to learn a lot about security.  The veterans that I saw in the room kind of kicked their heels.  Amazingly, an emergent property of this talk was that the veterans actually engaged in answering questions that the newbie raised during the talk – so there is more than one way to get value from a talk.

Solution 2: Keep your topic so relatable and so general, that no one is left out.  Now, this is difficult I think because if you choose the wrong topic, then you end up losing the veterans because they have already spent time in the idea space.  However, if you choose a topic that you feel people have not put a lot of thought into, or is kind of philosophical in nature, you can probably provide value to people who have thought a lot about a subject.  I think Aza Raskin did an amazing job of this.  His talk did not speak to a topic where spending a day or two would acquaint you with most of the ideas that he was presenting.  Even if you spent a lot of time thinking about the subject, it would be easy to take value away from his talk.  Note: this is not the ‘sweet spot’ idea because I really don’t think this method can be applied to any topic.  It is not a matter of modulating the amount of depth to be in between your audience, it is a matter of finding the right topic where you can talk in a way that provides value to beginners in a contextual and concrete knowledge sense and to veterans in a more philosophical sense.

 

All in all, a great conference.  I was really impressed with how much work went into it and how much planning must have been necessary.  I hope Rock Health continues to spearhead these in the future.




Follow

Get every new post delivered to your Inbox.