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?