SARON YITBAREK: So, hello. My name is Saron.
Thank you guys so much for coming to my talk.
I'm really, really excited to be here.
And as you can tell from the title of this talk,
grammar is very important to me.
So, before we begin, I want to start off
by telling you a story. A year ago today,
I was not a programmer. This is a, a
really big confession that I'm sharing with you. A
year ago today, I was this chick. I worked
at tech startups. I did business development, sales, marketing.
All of those non-technical roles. And I loved it.
If you've ever worked at a tech start up,
the best part is telling other people that you
work at a tech start up, because they instantly
think you're awesome and cool because you are.
But I realized, over time, after that honeymoon phase
was over, that my biggest skill, the best thing
I had to offer my company, was being able
to talk. And that didn't seem very valuable. And
I was always surrounded by programmers. By these tech
people who could build beautiful, powerful things. And so
I found myself always creeping on them and looking
at what they did and feeling like what they
did was so much cooler and so much more
interesting than anything I could ever do.
So, I quit my job, I started learning how
to code. I applied and got accepted to the
Flat Iron school, which is a three month programming
boot camp. And when we graduated, I was so
excited. I could finally build stuff. I could make
stuff. I was valuable. I could be a contributing
member to society, as my mother tells me.
And this is actually very important. One thing they
don't tell you when you graduate from a programming
boot camp is that you have to click your
heels and hold up a keyboard, otherwise it's not
official.
So I was so proud. I was so excited.
I learned all this stuff. I worked really, really
hard. I'm apparently standing on a rock of code
stuff that I conquered. But I was also painfully
aware of all the other stuff left to learn.
So there's the stuff I didn't know. There's the
stuff I didn't know I didn't know. There was
the stuff that I thought I knew, but I
forgot, but I didn't know I'd forgotten it yet.
So that's gonna be a nice surprise in the
future. And then, by the way, all the stuff
changes all the time. So welcome to programming.
And I was painfully aware of how much of
a novice I was. And this is the novice
track, so hopefully this applies to you too. And
this actually describes Dreyfus, or Dreyfus's Model of Skill
Acquisition, that says that when you start at zero,
when you start a new skill, you start at
the novice level. You move up over time to
an advanced beginner. Then you go on to confident,
proficient, and hopefully an expert.
And so, I don't want to be a novice.
I don't think anyone here wants to be a
novice. That's not fun. I want to be an
expert. And I want that cape. That's who I
want to be. So I started asking people and
did some research on, how can I become an
expert? How can I go from this poor novice
person who kind of sort of thinks she knows
what she's doing to, like, that cape-wearing expert. How
do I do that?
And the most popular answer I got was reading
code. Which is both really helpful but also not
very helpful. Because that leads to all these other
questions, like, what code do I read? How often
do I read it? And the best way to
start an adventure is to start it with friends.
So these are my friends. I think I drew
them very flatteringly. And so these are some of
my programming buddies from the Flat Iron school, and
I got them together and I said, yo. If
you get programming people together to start a code
reading club, you have to start the conversation with
yo. Otherwise it just won't work.
So I said, yo, we should read code together.
And so we decided that we were gonna dedicate
one hour every single Sunday at 11 AM. By
the way, this is a huge deal for me.
I don't wake up before two on a weekend.
So I'm, I'm already winning just by declaring that
this might happen.
And so we decided that we're gonna make this
a regular thing. And we decided to call it
Code Club. Because we are creative geniuses.
So the first question was what code should we
read? And we did some research. We asked, you
know, the mentors and senior developers that we knew.
We said, what would be a great starting point
for a novice to start reading code? And they
said, you should read anything.
This is not helpful. Please do not answer in
this way if someone asks you, where do you
start? And so we came up with our own
rules. We decided that the point of reading code
was to find code that we thought was inspirational
and would be great examples. So we decided that
whatever we read, it was gonna be exemplary code.
And we defined exemplary as having four attributes. We
said that one, it had to be somewhat popular.
Something that was well-used. Something that was endorsed by
the, the developer community. Something that hopefully was well-documented,
so that if we got stuck we wanted somewhere
to go to.
Third, it should be well-written, and four it should
be well-maintained. So knowing that it had, you know,
recent commits and people were still keeping, you know,
maintaining it was really important to us.
And we thought that if we did this, we
studied our exemplary code and read every Sunday, we
were gonna go from novice programmers to bad ass
experts. So, the one suggestion that I actually did
get from a much more senior person than I,
said, why don't you start with Sinatra? You've done
Sinatra. You know it. You're kind of familiar with
it. So we said, great. We'll start with the
get method, which is something that I never really
understood.
And so we gathered on the Google, and we
got together and we said, we're gonna get through
the get method. The get method in one hour?
Totally doable. If you've seen the get method in
Sinatra, I think it's like seven lines of code,
which sounds perfectly doable. No. This is a trick.
This is a huge lie.
Because every single line is completely abstracted code, and
you have to go through all these other files
to find out what they're doing, and then they
have more abstracted code. Then you go to other
files, and it became just one rabbit hole after
another. And we found that we really got nowhere
with it. And so we went from being really
excited to completely overwhelmed.
So, I'm a really, really big believer in retros.
I like taking the opportunity to reflect on what
I just did, especially if it's something that I'm
doing for the very first time. So, at the
end of the very first Code Club session, we
paused and we said, how was this experience, on
an individual level? How did each person feel?
What did we learn? And most importantly, how can
we improve? The idea was to keep this going
every week, so what can we do to make
sure that the next time we do this, we
learn a ton?
And the first and most important part about the
code-reading experience, is to pick a manageable code base.
It was very, very disappointing, and a huge hit
to our ego, to know that we couldn't even
figure out a get method, that started out looking
like just seven lines of code.
And so, picking something that is manageable, that is
digestible, that you can actually get through and understand
is really, really important. This is the first guideline
of having your own code club, and definitely the
most important.
So we decided that, for us, one hundred lines
of code was the great limit. And it was
a pretty arbitrary number, but it ended up being
perfect. Because what happened was, in that hundred lines
of code, you have just enough that you can
complete a full gem or library. And that's a
great accomplishment. Being able to say, hey, I read
through this whole thing and I finished it? Even
if you didn't understand it, you feel really good
about yourself.
Second, it gives you the amount of time and
flexibility to stop and comfortably ask questions. So if
there's something you haven't seen before, you can say,
hey, can we slow down? Cause I, I don't
really get this. Can someone explain it to me?
And you don't feel like you're slowing anyone else
down.
Second, you have the opportunity to try things. One
of my favorite parts about reading code is finding
new methods that I haven't seen before, or maybe
finding methods that I haven't seen in a long
time. And so being able to stop the session
and say, can we open up IRB and just
play with this and see how this works is
really, really valuable.
And the third thing was research topics. So there
were always patterns that we've seen that look kind
of familiar, that we've seen in other places. Being
able to stop and look things up on StackOverflow
or just Google was a really great opportunity. And
so with that limit, limited code base, we're able
to do these things while also getting through code.
Which brings me to the second really, really important
part about reading code. It's not really about reading
the code. Reading the code is just the starting
point. All these other things that I mentioned, the
parts where you kind of get off track and
you kind of digress and you have conversations. Those
are the things that matter. That's the real value
in reading code.
So, the learning happens in these digressions. In these
conversations. I am very, very sensitive to getting off
track and making sure that everything I do is
very focused, so this is a little bit difficult
for me. But over time, I got to see
a lot of value in it.
The third thing is that it's a team effort.
Do not go at this alone. It will be
very painful and you will not have a good
time. So knowing that I had other people that
were about my same level and that, you know,
we knew what we knew and we knew what
we didn't know, made it really, really easy to
start on this journey and to keep going.
It's really important to make sure that everyone you
do this with feels comfortable enough to raise their
hand and say, can we stop here? I don't
quite get that. Or, I know you just said
that, but can you say it a different way,
because it didn't make sense to me the first
time.
So it's really important that everyone is comfortable, that
everyone is engaged, and in order to do that,
we find it very helpful to have a tour
guide. So every week we trade off, and we
have one person lead the conversation. This is just
one person to say, hey, we're gonna start on
line two. We're gonna keep going. Stephanie do you
have a question? Dan, what do you think about
this? Ian, have you seen this before? And having
someone stop at all the right places, make sure
everyone is engaged and excited is a really important
part of this journey.
So we found, very quickly, that finding exemplary code
that's only a hundred lines is very, very difficult.
I think we ran out after a couple of
weeks. And so, out of necessity, we had to
kind of lower our standards. We had to say,
the most important part is really that we finish
getting through the code base, so we're gonna, you
know, not worry about whether it's well-maintained or well-written.
We're just gonna find code that's a hundred lines.
And this ended up being a really great thing.
So one day, the very first week that we
decided to lower our standards, we were looking at
a method that we didn't really think was very
well-written. And Dan said, this method sucks. How would
we write it?
And he gave us our very first point of
interaction. And that's the fifth guide line, is to
find these opportunities to interact with the code. Because
in him asking that one question, it lead to
a very interesting conversation. One, about what the intent
was. What was the point of that method? What
was it doing?
Two, why was it written that way? Was it
because the developer had a certain style? Was it
because it was a fork from a different gem
and they were just kind of, you know, maintaining
that, that writing style stylistically? And how does it
fit in to the overall design and architecture of
the entire code base? Did this one stand out
as being worse than the other ones? Or did
it just kind of follow the general pattern?
And so, these questions were awesome, because now it's
not just about reading code, it's about going on
a little adventure. We got to pretend that we
were the developer, and we were the ones that,
that were building this code and connecting what we
knew, in our world and in our workplace, to
this specific situation. So having that moment of interaction
really changed the game for us.
So, this leads to the sixth point, which is,
it doesn't have to be exemplary. Actually, reading bad
code is awesome. Because the fact that you get
to say, as a novice, that this is bad
code, and you get to, like, you know, have
an opinion on someone else's work, you feel really
good about that. It makes you feel fairly adequate.
And so it doesn't have to be exemplary. It
can be really bad, and you can learn a
lot from that as well.
So, everything was going swimmingly. It was going awesome.
And then one day, we encountered a gem that
talked about rack middleware. And in that conversation, Dan,
who comes up with awesome things to say, says,
guys, I don't think I really understand how rack
middleware works. And we said, Dan, it's, it's obvious.
This is how it works. And then we realized
that none of us really knew how it worked.
And in that conversation, we found a knowledge gap.
We found this, this thing that we thought we
understood, that at one point we did understand, but
we'd just forgotten about. So the following week, instead
of doing our regular code review session where we
just read through the code, we, instead, took a
break. We did some research on what rack middleware
was, how it worked, when you'd modify it, what
you do with it. We watched a few RailsCast
videos, did some, you know, looked at some blog
posts. And the following week, we shared that knowledge
together.
So we had a much higher-level conversation, but it
just emphasizes the fact that it's not really about
reading code. It's about reading code that's a launching
point for more interesting conversation.
The eighth thing is you gotta keep at it.
So, I've never told my code club this, and
they're gonna find out, which is awesome. But I
thought it was kind of a chore. It really
wasn't fun at first. It wasn't that exciting. It
was something that I felt like I had to
do. I don't like waking up in the morning
on a Sunday. So it was really something that
I had to force myself to do. But over
time is when I saw the value. I was
really looking forward to that first code reading session,
when it ended and I said, yeah, I'm now,
like, ten steps closer to being an expert.
But that's not how it works. It really takes
time to get the value from it. So keep
at it long enough and hopefully you'll see the
value as well.
So everything was going swimmingly again, and then we
read the omniauth-meetup gem. So right now I'm a
developer for the New York tech meetup. Yes, it's
a meetup group. Yes. This is a real job.
And there we use the omniauth-meetup gem to authenticate
our members. And this is something that was very
interesting, because it was very unexpected for me.
For me, I read code because I felt like
that's what I had to do to be a
better programmer. That's what everyone told me to do.
But when I looked at a gem that I
found personally interesting and personally relevant, it made the
whole thing so much more exciting. Cause I use
that gem. I used it all the time. I
knew what it was supposed to do. I knew
it wasn't, what it wasn't supposed to do, and
having the opportunity to look under the hood and
see how it did it got me really, really
excited.
And so the ninth guideline is to find interesting
code bases. Things on topics or problems that maybe
you've had. Things that you've worked on before. That
makes it a whole lot more interesting.
And then there are the unexpected benefits. Things that
I really didn't consider at all. The first is
that, you get to explore the organization of the
code base. So we really focused on reading, literally,
the lines of code. But just as interesting was
the file structure, was, what are the folders called?
And what are the files named? And how do
we work together?
And we got the opportunity to see that and
get exposed to that from all different types of
gems and libraries. The second was, you get to
really see how collaborative code is. When you start
as a programmer, people tell you that open source
is amazing and this beautiful thing, where people from
all over the world collaborate and build great things
together. But when you actually see it for yourself
and you see that that gem that you love
is really just a fork from this other gem
and really this gem is dependent on all these
other things that you didn't think would ever have
a connection, that's really powerful. And it makes the
whole thing so much more beautiful.
And the third, and honestly the most important one,
especially as a novice, is it's a great opportunity
to build your confidence. I didn't fully appreciate how
intimidating it was to open up source code until
I had to do it for Code Club. Cause
that first day, when I said, guys we're really
gonna open up this gem and try to understand
what's going on. And I think it was maybe
a month and a half into doing this, so
it's been about, like, six code clubs at this
point, or at that point, when I was at
work and I wanted to know how this gem
worked, I just opened it up. I didn't even
think twice about it. Because by that point, it'd
become such a habit. It had become so normal
to look into how things worked. And having that
frame of mind and that mindset is really, really
important. It really makes you feel a lot more
competent.
So, obviously by now, I have fully convinced you
that you do want to start your own code
club. But you can't call it code club cause
I called that. So you have to find out
your own name. But I wanted to review the
guidelines.
So the first is, manageable code base. For us,
it was a hundred lines of code. If you
feel like that's too low for you, definitely raise
the stakes, but I think having a limit is
very important.
Two. Understanding that the learning really does happen in
the digressions and in the conversations.
Three, that it's a team effort. Make sure you
go at it with other people, and make sure
that you check in and see that everyone is
engaged and just as excited and hopefully you are.
Four, to pick a tour guide, to take turns
and have someone lead the conversations. It's also a
great opportunity for people to lead and kind of
feel like they're, they're taking charge as well. It's
a different type of confidence booster.
Five, to find those moments when you can interact
with the code, where you can say, how would
I do that? How do I feel about that?
Even asking that question of, what do you think
of this code and having an opinion is very,
very powerful.
Six, it doesn't have to be good. You can
learn just as much from bad code as you
can from good code.
Seven, find those knowledge gaps and find a way
to fill them. And hopefully fill them together.
Finally, to, to keep at it and make sure
that this is a habit, it's something you do
on a weekly basis or a monthly basis.
And finally to find interesting code bases. You're gonna
find the experience much more enjoyable.
So, the question that I had, every single week,
was, how does this get me to an expert?
I wanted to feel that moment where I said,
yes, now I am so much closer, and I
can feel myself growing and getting that cape, finally.
And it didn't really happen quite that way. That
transformation wasn't quite as visible and as tangible as
I would have liked it to be. And so,
I thought a lot about why. I thought a
lot about, if I can't feel the change in
a very tangible, physical way, how do I know
that I'm becoming an expert?
And I found this really great infographic on Twitter
a couple months ago that I repurposed for my
own agenda, that I think really explains the process
and the result.
So this is what information looks like. It looks
like Skittles. And information is just all these little
data points that are separate and isolated, that happen
to kind of relate and, just by being in
the same bucket.
And then eventually, you're able to connect these little
dots, and you're able to have knowledge. And knowledge
is being able to tell a story. Being able
to say, I can start from that yellow skittle
in the corner, and if I go right, I
can get to that green one, and then I
go, shoom, go all the way down to orange,
and then if I make a left, or, a
right I'm at green. And then if I make
a right again, I'm at red. And that's how
I get from yellow to red.
It's understanding that, that path.
And then wisdom is saying, you know what, I
don't need to go through all those skittles. I
can just go straight from yellow to red if
I make my own path. And you know, I
don't even need that path to be straight. It's
gonna be all straight, cause I'm a rebel.
And so, this was kind of the journey of
reading code together. The information and all those little
data points come from all the code bases that
you get to read, from all the things that
you're exposed to that you've never seen before.
Those points where things connect and you have knowledge
and you have these stories and these paths, that
comes from having really good code reading sessions. That
comes from working with other people who give you
their input, from asking those questions that you're gonna
ask that are very insightful, and it also comes
from leveraging everyone else's experiences. So when I go
to work and I use a gem, I can
say, hey, I've seen this before.
When Dan goes to work and, and uses a
specific method, he can say, I've done that before.
And, in doing that, we're finding all these connections
that would have been way harder to find on
our own.
And then, finally, we'll be able to see that,
of all that noise, of all those patterns and
designs and concepts and all those lines of code,
the ones that we really care about are just
yellow and red. And those are the ones that
keep popping out, over and over again, over time.
And eventually we have wisdom and we're much closer
to being experts.
So, these are just a handful of the code
bases that we've read. If you're interested in looking
at them. I think most of them are about
a hundred lines. I think one or two may
be a little bit bigger. But take a look,
and I'd love to hear kind of your stories
and see what you get from that.
That is my website, bloggytoons dot com slash code-club.
There's a page that has links to all of
these gems and a few other ones as well.
That's the end. That's my handle. I pretty much
Tweet, like, mostly about programming and, like, cake. So
you've been warned. But, and that's the website again.
So I think that's pretty much it. Any questions?