NOEL RAPPIN: Hey everybody.
I think we'll get started.
We've got a lot of people on here who
are all gonna wanna talk and we don't have
that much time. So, I'm gonna quickly introduce,
this is, we're doing a panel here on teaching
the next great developers. I have a panel
of
experts here. We'll let them briefly introduce
themselves, and then we will get on with it.
So, I'm Noel Rappin. I'm a Table XI senior
developer, and to some extent I'll be representing
traditional
CS education, if that ever comes up at any
point over the next forty minutes, which I'm
sure
nobody would ever bash traditional CS education
in, in
this forum. So, OK. First up, we got Jeff.
We also only have two microphones so you guys
are gonna pass them around.
JEFF CASIMIR: Hi. My name is Jeff Casimir.
I
run a company called JumpstartLab, and most
recently started
up a training program called Turing, Turing
School of
Software and Design.
N.R.: I put 'labs' up there. I got it
wrong.
J.C.: It's all right. I'll just call it Table
X.
BREE THOMAS: Hi. I'm Bree Thomas, and I'm
a
developer with a company named, called iTriage.
And a
recent grad of this guy's school.
JEN MEYERS: Hi. My name is Jen Meyers, and
I am part of the team at Dev BootCamp
here in Chicago.
N.R.: Jen is filling in at the last minute
for Dave Hoover, who couldn't make it due
to
a family emergency.
LIZ ABENANTE: I'm Liz Abenante. I am a developer
at Instructure and I also co-lead the Girl
Develop
It chapter here in Chicago with this gal.
KATHRIN EXLINE: Hi, my name is. Is. Just kidding.
Is it ready? My name is Katie Exline. You
can call me Katie. I am the co-leader of
Girl Develop It, Chicago. Started in Girl
Develop It
with Girl Develop It, Columbus with that girl.
And
I'm currently a software engineer at a company
called
Fooda. 600 West.
BEN ORENSTEIN: Hi. I'm Ben. I work at ThoughtBot
in Boston. I run our program for training
developers
there called Learn. And I write code and talk
to people and do things like this.
N.R.: So, I'm gonna. So, I want to start
this off by, so, we have a couple of
different kinds of programs here represented.
We have two
different boot camps that are sim- somewhat
similar in
structure, but different in length. We have
the Girl
Develop It, which is more shorter interventions
aimed at
bringing novices into the, into the field,
and we
have online, online inter- somewhat more in-depth
online interventions.
And, I guess, maybe, what I want to start
with is, what is, what do you think is
the most important part that you, in your
program,
bring to teaching a novice developer, and
how do
you think that that fits towards bringing
in the
next generation of developers? To start with.
Anybody can
feel free. Jen's got the mic.
J.M.: I've got the mic. OK. I'll go for
that.
N.R.: So what's the most, what's the most
important
thing at Dev BootCamp. If, if you were to
say that a Dev BootCamp boot came out of
there knowing one or two things, like what,
what's
the most important thing that you try to impart?
J.M.: Honestly, I think the most important
thing that
we try to foster is just being able to
love and learning how to learn. And really
being
able to carry themselves on and our, our goal
is to really produce people who know enough
about
Ruby on Rails to get a job where they
can continue to learn, and that they have
the
tools and the, the muscles built up, that
they
know how to keep learning on their own, and
keep exploring and finding out new things.
So, it's a little bit meta, but I really
do feel like that's one of the things that
is our main goal, to make sure that people
can continue learning for the rest of their
careers
and lives.
J.C.: Kind of a similar vein, I would say
the most important outcome for students is
understanding really
how to take difficult technical problems and
turn them
into sets of small, still difficult but more
manageable
technical problems. And we happen to do that
with
Ruby on Rails, but I'm, it's really validating
when
we see students go into jobs where they do
JavaScript full time, or iOS full time, and
they're
still able to apply all those same patterns
to
a different language and framework and so
forth.
L.A.: And Girl Develop It comes from a slightly
different perspective, because we work with
complete novices in
a wide range of classes, and we're just now
starting to get into programming here in Chicago
with
our gals. But, I think the most important
thing
that I've found teaching these students is
how to
ask questions and where to ask them. Who to
ask, what kind of responses are good responses,
and
what kind of responses are terrible and you
should
ignore them because they're from terrible
people.
B.O.: So, this is actually something that
I think
that it's important for all levels that I'm
working
on myself, honestly, is a willingness to admit
you
don't understand something. There's, I, there's
this phenomenon I've
seen in developing, in particular, where,
because it's an
intellectual-based activity, we have this
really strong impulse to
always act like we know what's going on and
we understand what people are saying.
And I've tried really hard to develop in myself
the ability to be like, I did not follow
that. I don't understand what's going on.
And I
think more of that is really good for the
world. I think, I've seen people, I've seen
myself
do it, too, where you sort of fake it.
Where it's like, oh, are you familiar with
this?
Yeah. I mean, I know I should be, so
therefore I'm gonna say yes. And that definitely,
that
hurts you. Like, you cheat yourself out of
that
immediate learning, and you cheat, you know,
your, your
colleague or the person you're talking to
out of
being able to trust you when they find out
you weren't telling the truth. And there's
just all
this negative impacts from that.
N.R.: So, actually. Let's. I have a, I have
a sort of jumble. Do you guys have questions
in the audience? Like, I have a couple of
prepared questions that are gonna be kind
of vague,
but if you guys have questions in the audience,
yes, no, maybe? Then we, this would be, this
would be, I think, more fruitful if you guys
com- if we come from there.
AUDIENCE: I think everyone thinks they're
terrible at programming
when they start, so how do you help people
N.R.: So the question is, how do you help
people build confidence, given that everybody
thinks they're terrible
when they start, or possibly for several years
after
they've started?
B.O.: I love that question. Did, you repeated
it,
right? Yeah.
N.R.: Yes.
B.O.: Because I still struggle with believing
that I
am a good programmer, and I think this happens
to everybody, is, there's this impostor syndrome,
and I
think everybody has. Wow.
N.R.: Sorry. I'm just going back in the slides.
B.O.: There we go. That's OK. Shwoo. It still
kind of blows my mind when people think nice
things about me. And I think that impostor
syndrome
is, like, is very prevalent. And, again, we're
in
a intellectual based field, again, so I try
to
be, like, humility, I think, is my answer
to
that. Like, I try to be humble myself, because
I've had those own feelings of impostor syndrome,
of
like, not even believing that I know what
I'm
doing. And so, I know that's just amplified
a
thousand fold when you're brand new and everything's
super
confusing. So when I've done stuff, particularly
with like,
really new people, like a RailsBridge type
workshop, I
like to like, open by saying, like. Don't
worry.
The state of being confused and like, this
should
work but it doesn't work. That is the normal
state of the working programmer.
That's like, how it is. And so, it's not
you. It's never you. It's that this is hard
and it's always gonna be like that. So, hopefully
you like it.
R.N.: Despair is what we teach. Long term
despair.
J.M.: Yeah, I was gonna, to back-track a little
bit on what you were saying, you know, we,
as Liz mentioned, we deal with a lot of
people who are just starting out. So, actually,
a
lot of them aren't, they're not faking it,
and
what we're working with, they think they're
totally incapable
of learning it. You know, on the, on the
reverse side. So, there's a few things that
we
do in order to make sure that they feel
comfortable is, for one, we make sure to encourage
them to ask questions and do not scoff when
they ask any sort of question, because then
we're
validating them and saying, that is a totally
valid
question, and it's OK if you don't know that.
And we may not even have the answer. So,
that type of, like, open discussion, being
able to
ask questions is great.
And then also, just providing positive feedback.
Actually, constructive
feedback. Both positive and even if it's constructive,
providing
it in a positive way, I think really helps
build peoples' confidence.
J.C.: Smart. Cause that's what I was thinking.
Giving
a set up where you can give somebody a
small, a small, quick win, that they've done
something
that they could point to, I think is helpful
in my experience as a teacher.
B.T.: So I'll just add to that. As one
who spent six months in a course, I wasn't
getting it at all, for like, the first three
months. And it was brutal. And I consider
myself
someone who's actually, I never had any question
about
my ability to learn something new. And so,
I
think, I think in terms of what's important,
from
a student perspective, when you're, when you're
in a
course, is having instructors in an environment
where they
can adapt to your learning style, so they
can
understand, they can look at you and they
can
understand, OK, here's where you're having
problems.
And, change course if that's what's required.
Because I
can say that that was my experience. I kind
of went, oh my gosh. I still have no
idea what's going on and we're halfway through
the
course and it's not clicking. And I kept getting
the, it's gonna be OK. It's gonna be OK.
No. It's not OK. I'm half way through, and
I spent all this money and there's only three
months left. And essentially, the instructors,
you know, at
least with, with Jeff's group, they took a
step
back and said, OK, let's focus on the fundamentals.
And, let's do some smaller steps, and let's
do
that work with you, and that was extraordinarily
helpful
for me. And, by the time I graduated, I
can honestly say I finally felt like, oh,
I'm
a developer now. I may not be, you know,
a great one, but I like, feel comfortable
calling
myself a developer now.
L.A.: And in terms of not seeing yourself
as
terrible, you're not terrible if you do one
thing
right. Like, in programming. If you get that
image
to render on your ht- your very first html
page, but you cannot figure out freaking CSS
for
the life of you, it doesn't matter because
you
got that one thing, that tiny victory, reinforcing
those
tiny victories, celebrating those tiny victories,
and using those
as moments to break away from the frustrations
really
helps break students out of that pattern of,
I'm
terrible. I don't get this. It's really hard.
J.C.: I think the, the whole conversation
around, like,
impostor syndrome, I found really interesting.
I kind of
want to ban that phrase. Like, I will probably
stop saying it, because I, I think it's just
a part of programming. Thinking, or perhaps
knowing that
you're not good at programmer. And, for me,
when
I first started, our first program as Hungry
Academy
in D.C., and I, when I laid out the
course plan, there were pieces in there that
I
did not know how to do and had never
done in a project. And I was so nervous
and I was like, oh, we're gonna. I'm gonna
be exposed.
Right? But I had this co-teacher and I was
like, he'll know. He's a real consultant and,
like,
he knows how to do these things. It'll be
OK. And, I think what's happened to me over
that time is just realizing that, like, I
don't
give a shit. Like, if I'm not the best
programmer - I'm sure Ben's a much better
programmer
than I. So what? Like, it, it, it, probably,
you know. And so, I'm fortunate, you know,
through
things like RailsConf to talk with amazing
people and
people are like, oh, you know, Jose Valim,
like,
building Elixir. Poof. Like, no idea. I can't
even
understand Elixir, much less how to build
it.
And, he's a much better developer, or, much
better
programmer than I am. But, who cares? Is really,
I think, something that's valuable to your
career.
N.R.: One thing I feel- sorry.
J.C.: Like, you're not, you're not measured
on some,
like, benchmark against other, there's no
like, programming test,
like, program this thing in thirty-seven minutes.
It's like,
oh, Jen can do it in thirty-six minutes. She's
smarter than you. Like, it, it doesn't matter
to
me.
N.R.: I did it in thirty-five, but.
J.C.: It's that CD degree. You can do it
in one minute.
N.R.: I, one thing that I think is really
important, is try to keep- I saw. Is to
try to keep novices from comparing themselves
against, like,
the quote on quote heroes. Like, it's really
easy
for somebody to say, like, oh, I see Steve
Clapnick submit, you know, I see these people
who
submit to open source all day long, and a
lot of the people who do that, that's actually
one way or another their job. And to compare
their output, their very public, very voluminous
output to
yours, when it's not really your job to do
that, is unfair to yourself, and a little
bit
unfair to them. But mostly unfair to yourself.
And
to try, I've seen, like, novice developers
get kind
of locked in that, that idea that they're
not
doing everything they could be doing. And
that's dangerous
for them. Like, you want them to be celebrating
the victories that they are doing and not
comparing
themselves with the things that they're not.
Sorry, what's?
AUDIENCE: Yes. So, what that brings to mind,
for
me, is [indecipherable - 00:13:04], one of
the concerns
that was brought up was this idea that we
were missing a lot of developers who are perhaps
gonna even do some harm in their first, you
know, first few gigs, perhaps.
N.R.: All of us do a lot of harm
in our first few gigs, right. Like. Yes.
AUDIENCE: So this question's for all of you.
I
wonder if, if teaching the next 'great' developers
is
even the right question to be asking. And
if
N.R.: So, OK. So, the question is whether
teaching
the next great developers is the right question,
and
if so what is? Great developers was my fault.
Don't blame them for calling this great developers.
J.C.: That's link bait.
N.R.: Yeah.
B.O.: And you're here.
N.R.: If I had only said, if I had
only said good developers, half of you would
be
off learning- teaching the next half-assed
developers.
J.C.: Yeah. I, I think one of the privileges
of working with these programs and people
that come
into our program and, and programs like all
these
people participate in is that they might not
be
great developers. And, like, Bree wants to
be a
full-time developer. In ten years, will Bree
be a
full time developer? I'm not so sure. But
will
she be doing something amazing in technology,
and like
probably be running a company? Will I be working
for her? Like, above zero change, you know.
Like, and so the people that, mostly, I guess
one of the things that surprises people about
our
program, and I think it's probably similar
for Dev
BootCamp, is most of our students are career
changers.
It's not their first career. And so they've
got
these years of experience about how to be
a
professional. They've got years of experience
in some domain,
whether it's finance or health or restaurants
or whatever
it is. And that experience is gonna be amazing
for what they do next, after their first couple
jobs, right.
Noel and I, we have these CS degrees. We're
like, one day gonna get thrown out of a
Ruby Conference. Like, marked and thrown out.
N.R.: Re-education.
J.C.: But those people, I'm excited to see,
like,
yes, they're gonna really mess up some projects
in
the short term. But what they do when they
get to the point of leading teams and starting
companies I think is, well, it's gonna be
really
cool.
J.M.: Yeah. I think that the question really
is,
what does great mean? And my, my definition
of
it is similar to what Jeff is describing,
is
that people who bring a really great diversity
of
experience and backgrounds and to, to kind
of enrich
the products that we're making. That's exciting.
And he's
right. In Dev BootCamp, we do have a lot
of people who have really unique backgrounds,
and have
some really cool perspectives that they bring
into things,
and are just, like, great people.
And those are people you want to work with
on teams, and they, you know, they just help
you make better things together. So that,
I'd like
to have that definition of great, and kind
of
tease out the, the potential in those people
who
have other things that they can bring to it,
and help them contribute that for making the
developers
they are.
B.O.: I really like both those answers, because
I
think one of the, the best things about programming
is that it's an awesome force multiplier on
something
else that you want to do. So rather than
being like, I want to be really amazing at
writing code, if you can say, I want to
do, I want to change lives in this way
or make this sort of thing, and programming
is
the super power that lets you do it harder
and faster, I think that's like, the best
way
to think about that.
I have a friend who has just enough programming
background, that at, he works at a bank with
a bunch of finance people, and everyone he
works
with, basically they massage Excel spreadsheets
all day. And
he has just enough programming background
to write VB
to do some of this massaging automatically.
And he
is, you know, the one-eyed man in the land
of the blind. Like, he is, there is, he
is revered, and people are blown away, because
he
can do these things.
And I think that's the perfect way to say,
rather than saying I'm gonna be amazing at
code
for code's sake, if you think, you know, I'm
gonna get good at using code as this amplifier,
as a tool for the other things I want
to do.
N.R.: What they used to say about journalism
school
is don't do journalism school as an undergraduate.
Learn
something, and then learn how to apply journalism
to
it. I think programming is very similar. Like,
learn
how to do something and then learn how to
apply programming to it.
One thing I have seen from both the, I've
met a number of Dev BootCamp and GSchool,
Jumpstart
graduates, and they do seem very enthusiastic
as a
group, as people who have, like, chosen something
and
gone through and succeeded in this challenging
program. They
tend to come out being, being very enthusiastic.
K.E.: You have to.
N.R.: Yeah.
K.E.: I mean, you spend eighty to ninety hours
a week.
N.R.: So the question is, how do we make
sure that the next generation of developers
has the
interpersonal skills to be leaders and, and
mentors within
the community.
L.A.: I don't know if you've noticed this
about
me. I'm kind of a perky person. I'm kind
of, you know, friendly, I hug a lot. When
I introduce myself at Girl Develop It classes,
I
always say, I wasn't doing this a year ago.
I don't get to say that anymore because it's
now been a year. I'm so proud of myself.
But, I tell them, when I tell them my
story, I say, I made this career transition.
I
went to Dev BootCamp. I made this choice.
And
I would not have been able to do this
without the assistance of my mentors, of my
friends,
of the teachers at Dev BootCamp who, Jen talked
me down from a ledge a couple times. It
was not easy. It was really difficult. And
I
preach that to them, and I tell them, I'm
here for you. Katie's here for you. We have
meet ups. We're your friends. We're your mentors.
We
are here. You should be here for the people
that you need help with. And we encourage
them
to help each other during class. So it's not
just something we say, do this, maybe, you
know,
in a year or a month or however long,
x days, until you become a developer.
It's do this right now. Do this in class.
Help this person next to you when they're
struggling.
J.M.: And, and, at Dev BootCamp, we actually
kind
of take it a bit further and formalize it.
So we actually have a portion of our curriculum
that's called Engineering Empathy. The students
all go through
guided sessions in feedback and communication
and, you know,
understanding themselves as, as kind of touchy-feely
as that
sounds. The goal is exactly what you described,
is
to get people to know how to communicate better,
know themselves better, have better team dynamics,
and just
be well-rounded individuals that know how
to connect with
other people. Whether it's on their teams
or clients
or customers, any of those sort of things
that
you need to be able to, to build really
good software.
We formalize that, we have sessions for it,
and
then we try to support structure around it.
Like
Liz describes, of all of us being on board
and all the instructors are there to kind
of,
to reinforce it as they go all the way
through the program.
B.T.: I would just add to that, specifically
to
your question about how do we foster this?
I
would say that, in, I am a very extroverted
person, and aside from that, I think it's
really
important when you, when you work with new
developers,
be in their business. Like, don't let them,
you
know, OK, yeah, yeah, yeah, I got this. I'm
just gonna go work over here on this thing,
or I'm gonna do a couple hours of code
school till you give me a task to do.
Because I think as new developers, no matter
how
extroverted we are or, there, there is still
a
little bit, that fear of, oh gosh. We're gonna
break production. Oh shit.
Or whatever it is. Or you know, maybe we're
just, we're too nervous to ask questions because
you
guys look really busy doing the real work.
So,
I would, I just think it's important, at least
for me, I mean, I like it when mentors
and people that I look up to are, they're
like in my business. They're like, OK, what
are
you doing? Let's talk about that. Let me shoulder
hawk you for a few. Let's pair program. I
think all of that is really important in fostering
new developers.
J.C.: Anybody in the room been a mentor for
a program like one of ours? So, number one,
want to give you tremendous shout outs, that
those
relationships are incredibly valuable for
our students. People like
Shawn had a mentor, a mentee in our program,
and like, Shawn changed that young man's life.
Like,
without a doubt. So, tremendous shout outs.
Fostering the interpersonal communication
I think is the most
valuable piece we can add, right. Like, the
code
you can get from a book. And how to
work with a team and how a team goes
wrong and right, you only get through experience.
And
so, that's like, with our program, we're fortunate
to
have a very long time. And so, they work
primarily in three week projects with groups
of four
people. And you learn all the hard lessons
of,
hopefully, some of those first projects that
you would
otherwise screw up for money, you screw up
on
your own time and your own money.
You see the team that has all the all-stars
and they go in with all the confidence, and
they're like, yeah, we've been doing this
Rails thing
for six weeks, we're gonna build a Backbone
frontend.
And we're like, yeah, don't do it. And they're
like, no, we're gonna do it. OK. And then
it all burns down, right.
Or, you see the team that is honestly kind
of mediocre with their skills, but they get
along
and they pair well together, and they communicate
well,
and then they end up delivering better software
than
the all-star team, and the all-star team is
like,
hey, wait a second. Like, we should talk to
each other and, like, figure stuff out. Hmm.
This
works better.
And, just getting to iterate on those problems
and
learn them yourself, not just, like, hear
it in
a conference talk and try to follow through.
We
do little things like lightning talks. I know
you
guys do lightning talks also. So, I, I like
to think that that has like, lead to like,
Bree's giving a talk tomorrow and a couple
of
your grads are giving talks and so forth.
R.N.: Sorry, next. Yeah. Go ahead.
So, so the question is, is does it scare
us that we're bringing in a bunch of people
into an industry that's horrible at onboarding
people.
J.C.: I heard there's a talk about crafting
your
own onboarding experience that's really phenomenal.
J.M.: I mean, it's a little scary, especially
as
somebody who has been an instructor, you really
care
a lot about those students, and they go out
into the world and it's a little bit like,
yeah, you're, you're sending your kid off
to school
or something like that. You don't know what's
gonna
happen.
But, you know, I'm not really sure how to
solve that problem other than just attack
it. And
so I think that if we can bring people,
or produce people that do know how to own
their own learning and know how to communicate
well,
then those are some of the best weapons we
have to improve the overall process for other
people
coming in. And hopefully we can also, for
those
of us who know some these challenges, can
provide
more structure and, and, you know, we, we
have
a placements team who works with companies
to hire
our grads and things like that. So, we, we
can build a structure that maybe can help
provide
more resources or help for the companies that
are,
are taking our grads, and just make it smoother
for everybody. And hopefully the more we do
that,
the better it gets.
B.O.: I'm sort of the opposite of scared of
bringing more people in. I think we desperately
need
to do it. Right now, at, at least what
I see, demand is so much higher than supply,
and that works out pretty well for us as
developers that already know what we're doing,
right, because
we're, we're very much in demand. The power
is
on our side right now. But if that demand
are supply are mismatched for too long, the
demand
will drop. It'll have to drop. And I, I
know someone who is a CTO for hire. And
so he works a lot of companies. And so
he had a start up that just got funded
and was like, OK. Now we're ready. Let's go
hire a Rails developer. And they couldn't.
They couldn't
find someone. They said, OK, let's not write
it
in Rails. We're gonna go somewhere else.
So, if we have this mismatch for too long,
I think it will be bad for us. And
so I think, if we've got this crazy giant
demand up top, we've got to, got to satisfy
it.
N.R.: Speaking of-
B.O.: And it'll be better in the long run.
N.R.: Speaking from the side of this of somebody
who onboards novices, I think that, I mean,
this
is a problem that, to some extent, is outside
of all of their control, right, as Jen was
alluding to. What we need to do on that,
on the, on the incoming, on the incoming side,
is understand that in some cases, the, where,
understand
where these students are coming from, that
the experiences
that they have had and the experiences they
haven't
had, and ideally put them in a situation where
they can be successful, and where we're matching
them
to expectations that are reasonable.
You know, I think a lot of the students,
I think that you guys would agree that, that
there are better situations for your students
to go
to, and worse situations for your students
to go
to, and you want them to go to a
place where there are going to be other p-
you don't want them to go to a place
where they're going to be the entire straw
holding
up, you know, the one straw holding up this
huge weight of stuff. You want them to go
to a place where they're going to be more
senior people who can put them in a situation
where they're gonna be successful.
And I do think we have to get better
at doing that, generally.
Creating senior developers is a whole different
ball. Jeff,
did you have a point you wanted to make?
J.C.: As far as companies that do and do
not have apprenticeships, I think of it really
as
evolution. Like, there are so many companies
that sit
around waiting to hire a senior engineer and
look
for six months and don't find any and all
that. And meanwhile, the company who brought
in apprentices,
they now have six months experience, and they're
delivering
probably, like, somebody with two years of
experience, if
they're doing it well. And the reality is,
if
your company does, in my opinion, does not
work
on bringing in young people, young in their
career,
you're gonna die. Like, you're just gonna
lose. Because
the teams that build up their own people keep
those people. Those people are tremendously
valuable six months,
a year, eighteen months in. And they'll just
beat
you.
N.R.: Dave, Dave Hoover had a theory at Optiva
that the goal of a, a small company was
to have people at every level. You have the
best novices, you have the best intermediate
juniors, you
have the best people right after that. You
don't
just have a bunch of seniors and a bunch
of novices. You have people, to the extent
that
you can have people at every step in between.
What's great about that is, everybody has
somebody who's
about six months ahead of them to point what
their next six months are gonna be like, and
everybody has somebody who's six months behind
them, that
they are an obvious and immediate, like, partner
for.
So if you can build up a business like
that, if you can build up a team like
that, that's, that's fantastic.
B.O.: We've embraced that like crazy. Like,
bringing in
apprentice level people. We have an apprentice
program. And
it's been huge for us. We've been able to
hire so many more awesome people than we would
have if we had just said, we're looking for
senior only. We're not willing to invest in
these
people and train them.
N.R.: So the question is, how do we get,
how do we get the people coming in to
set reasonable goals for what they can accomplish,
technically?
B.T.: I'll start. Well, after being a student
of
this gentleman, he's actually, I would say,
over the,
over the six months that I was school, to
that point, he was actually really good in
that
learning time about, like, oh. You think you
can
do this thing? Go ahead. Knock yourself out.
Right?
So, much like with children, I have a seven
year old, it's kind of like, you're in charge
of your own fun. You learn a lot by
being crushed by some of those, oh, this was
a lot harder than I thought it was gonna
be. So I think there's something important
about that.
In terms of at the work place, I'd, at
least where I work, you know, they're very
good
about, and, and they have a, a focus on
kind of onboarding, right. And so they're
very good
about, hey, we're going to help define these
goals
with you. We're gonna help ease you into the
code base. And we're gonna do that with smaller
sets of problems to solve. And we're not going
to place this burden on you for, get this
feature done by this exact time.
And so I think all of that is, is
really, really helpful. And the other thing
that I
think's really helpful and goes a little bit
back
to what we were talking about just a second
ago is, in terms of students, you know, even
in being novices, there's different levels
of that. And,
and people are different. And so I think that
the programs that do exist right now, Dev
BootCamp
and the other ones, I think one thing that's
really important and that was beneficial for
me especially,
was as I went through the interview process,
my
instructors were there with me through the
whole thing.
And they were really, really honest with me,
as
well as having conversations with employers,
about my ability.
And so, that helped, that honesty about, you
know,
where I'm at in my learning and the type
of learner that I am and the things that
I'm interested in, is beneficial so that I
don't
find myself in a work place where, you know,
that's all I'm gonna be is, sort of buried
under these goals or things that I can't,
you
know, where I can't really prosper.
L.A.: On that note, it's also important to
teach
people to reassess their goals and to be able
to take note of where they are and where
they expected to be, and maybe think about
why
they're not. I think that's also a very important
piece.
J.M.: Yeah. I just want to kind of, I
like, really both of those, and I like what
you're saying, too. Maybe it's a parent thing.
I
have an eight-year-old. And I feel the same
way,
where, I feel very strongly it's important
for people
to make mistakes and be able to learn from
them. And I don't think it's so much about
preventing them from, you know, trying to
scale back
the goals to prevent them from making any
mistakes,
but, creating an environment where it's safe
to do
that, and them helping them in figuring out
what
they can learn from it when they do that.
So that's kind of, in general, the philosophy
that
I like to ascribe to, and I think, Dev
BootCamp is in a little bit of a different
situation, where we don't have people as long
as
some of the other schools. We only have people
for nine weeks. So we don't have as much
time to do that, but I think we do
that in general, and then also the way we
structure the program starts with the basic
building blocks,
and then builds on top of them.
We're a Ruby on Rails training program, but
you
don't even get to Rails until your seventh
week
of the program. So, we're teaching the fundamentals
before
then. So I think if you start out with
the, the basic blocks and build up from there,
and also at the same time kind of create
this environment where it's OK to screw things
up,
and somebody's gonna help you figure out,
you know,
how to learn from that, or, as the two
things together make it a lot easier to understand
what you can achieve and how to do it.
J.C.: No, hold on man. I'm going. Hold on.
N.R.: I'm sorry. You can have your question
after
Jeff says something.
J.C.: So, TDD I heard is over.
N.R.: Dead.
J.C.: But, we teach it anyway.
N.R.: Not, not, not, not just over. Dead.
Dead.
J.C.: So we're old fashion. It's dead. Well,
we're
old fashioned. And so we, we teach TDD, and
it starts on day two, and I think that
the approach behind TDD is the same approach
behind
lean start up. And, like, breaking off incredibly
small
problems, getting feedback right away and
iterating on that.
And so by starting with TDD, as the means
to build software, and then we try, through
these
three week projects they work on in their
teams,
really take, like, a lean approach to delivering
it
early, adding on incremental features.
Well, first we let them try and build all
the features and deliver it day of, and it
all burns down and we're like, see. That sucks.
Don't do that again.
And, but, like, by, by starting with the tests,
and then applying that to the product, I think
it teaches you how to take an idea and
figure out, what is the essential component
here? Like,
whether, whether it's an aspiration for a
company I'm
gonna build, or just the goal for, I'm gonna
learn something. Like, it's critically important
to figure out,
like, what's the first step. And I think that's
the hardest part of any good idea.
N.R.: OK. Now you can ask your question.
J.C.: So I'm very involved in the interview
process
and do a lot of like, coaching with the
students and so forth. And, your technical
interviews are
a hot mess. Like, people have cargo culted
their
process from, like, two companies ago, and
you'll see,
sometimes, it, it makes absolutely no sense.
There is
a company that'll put, like, students through
six rounds
of interviews, and then say no. And I'm like,
do you understand how much of your own time
you've wasted here? Like, it's insane.
Specifically with the technical questions,
you'll see such a
broad range. People will be like, I have an
array. How do I pull out an element? And
it's like, really? Come on. And then there's
others,
we, we did have a student get asked, like,
are you familiar with binary trees? And he
said,
like, yeah. I've built a binary tree. And
they're
like, do you know, like the, the lookup efficiency
of something? And he's like, oh, you mean
like,
n log(n)? And it's like boom. Bomb dropped
on
you. Like, you didn't see that coming from
somebody
who's been doing it for six months, right.
The reality is that, code, like, everyone,
I guess
not everyone. You should agree that coding
on a
white board is dumb, right. I tell students
that
if somebody asks you to code on a white
board, tell them how do I run the tests?
And, like, question over.
But the, the piece about, like, how do they
learn? How do they solve problems? That is
incredibly
valuable. So, yeah. I, I think we need to
have a lot more conversation around how, as
teams
and companies, do we want to build up interview
processes that actually achieve the goals
and, and like
find the people that we want?
Because, from what I've seen, there's like.
There's no
understanding. There's kind of like, fear
and uncertainty about
it. We had a student this time ask, get
asked to sign an MVA about the interview process.
There's, it's not that interesting, bros.
Like, whatever it
is, it's not that interesting. So, I think
there's
a lot of work to be done there.
K.E.: I can just talk on a personal level
of, I had a really, well, I don't want
to say I had a bad technical interview. But
I want to speak to the good technical interview
that I had at the current company that I'm
with, and part of the reason why I chose
to go to that company is because of the
technical interview.
And, the interview I had was a take home
assignment. And this is one of the different
formats
you can do. I had a take home assignment
for three days to build an API. It was
my first API, and it was just an amazing
experience, in that, not only did I get to
learn something, as part of the interview,
I got
to see how accessible my manager would be,
and
then he was also able to judge, how did
I attack something that I didn't know? And
also,
what kind of questions that, did I ask? And
I think we each got a really good understanding
of what this type of relationship would be
like.
So that's just personal experience.
B.O.: So the, the process that we do I
think is actually pretty good. So we do have
a, a technical screen, which is sort of a
discussion of, how might you build this? How
might
you build that? But the real meat of the
interview is, in person pairing in the office.
A
full day. And you work on real stuff. Real
client work. Real open source work. Whatever
people would
actually normally be doing. And you sit next
to
somebody. And I like that a lot.
You know, you can run the tests. It's not
a, a fake, contrived problem. You can see,
also,
what it's like to sit next to somebody, and
it's cause there's, there's that social fit,
which is
so important, too. And so that, the white
boarding
thing, I agree. That needs to die, for sure.
And, you know, let's move more towards pairing
and
seeing what people are actually like on real
stuff
that you're working on.
J.C.: I forgot to mention one of my favorite
interviews that I ever saw, that you reminded
me
of, was ThoughtWorks asks you to create a
code
sample, or, like, solve a sample assignment
and submit
it. You have, like, a week, or something along
those lines. And then when you get into the
in person interview, what you do is sit down
with an engineer and pair on refactoring your
submission
to the assignment.
And so they get to see a lot of
great things that way. Like, how do you understand
that you, that you wrote? Did you actually
write
it? You know. Like, and how do you think
about refactoring. Do you go, like, what it
works?
Why would I change it? You know. Or, do
you understand how to restructure, abstract
objects, abstract methods.
I thought it was awesome.
N.R.: We do something like that too, while
we're
sharing, we've done that before. I think we
have
time for one more question.
B.O.: That guy's had his hand up like the
whole time.
N.R.: OK. So I will, I will go with
you. I hope it's a good question. We actually,
we're last. I have no place to go, I
have no place to go after this. But they
may stop recording us.
After dark.
AUDIENCE: [indecipherable]
L.A.: We spent a lot of time getting women
familiar with technical concepts and comfortable
talking about technical
concepts so they can take on more technical
roles.
Not necessarily as an engineer, but perhaps
as a
product manager, instead of doing project
management. And, that's
a subtle difference to us, but it's a huge
difference to them. It's a world of difference.
It's
more technical responsibility. They're more
comfortable with their knowledge.
And so, my goal, teaching people, is not to
get them to be x, it's to get them
to whatever their x happiness will be. I love
what I do, but that may not be right
for them. I want to help them in any
way that I can to get to the technical
career that they want to have, that will work
for them. And whatever resources I have, I
will
just like waterfall at their face. So.
J.C.: It's one of the questions I really try
and watch out for in students, or applicants,
at
that stage, is do you want to be a
professional developer? And if the answer
is no, please
don't come. Because it's a tremendous waste
of time.
Like, spending twenty-seven weeks to prepare
for a job
you don't want makes no sense. And I redirect
them, like, you're a lot better off, like,
going
to Dev BootCamp, and you can come out and
like, you have some programming skills and
you can
reappropriate those into a management position,
in a project
position if you want to. It makes a lot
more sense.
J.M.: Yeah. I'll, I'll just add to that. That,
I think that, sometimes even Dev BootCamp
is a
little too intense for that, just because
most of
the people, like, it's still hard to like
quit
your job for nine weeks if you're just kind
of doing it to, to pivot. But it is,
it's less intense, or it might be a little
bit easier. And we do have people who go
through who want to apply it to, maybe, a,
a certain area that isn't just being a straight
up developer. But I think, like, Liz was talking
about, things like Girl Develop It and other
organizations
that are working on really reaching out to
people,
and there's lots of them. And they have lots
of different focuses. But I think that's where
they
really come into play, is that just opening
these
doors, and you get to choose where you go
after that.
You know, you kind of just go, maybe a
door is the wrong word, but more of a
gateway. And, so then you can go in many
directions after that. So, I think that these
are
compliments, not nec- they're not all necessarily
the same
thing. We kind of have a spectrum of different
organizations, and they compliment each other
really well.
The really nice thing about just being, reaching
out
and letting people choose where they want
to go,
maybe they don't know what they want and they
don't know what's out there. I know, you know,
as I was growing up, I didn't even have
the internet, you know. Web, being a web application
developer didn't even exist. So I had no idea
until I was probably like in my early twenties
that maybe this might exist and maybe I can
start working towards it.
And there are still, and that was kind of
a time thing for me. But there are many
people who don't have access to the opp- to
the kind of opportunities that we do, and
so
just being able to give them more accessible
ways
to see what is out there, might be able
to say, oh, well maybe I actually do want
to do that. And then they can take one
of these other programs.
N.R.: Yeah. Things like CodeSchool and Rails
for Zombies
and stuff also have a place in that, too.
You get, you get a certain amount, enough
knowledge
to understand. You have to have enough. There
are
some positions where all you need to know
is
you need to know when your technical person
is
totally bull shitting you. And that, that's,
those kinds
of things move to that, go to speak to
that.
I am obligated to tell you that we're at
time. I, I don't have any place to go.
I don't know about you guys. So, if people
have questions, I'm willing to, with whoever
wants, continue
to answer questions. If you have some place,
if
you guys have places to go, that's fine. But
first, just a round of applause for the panel.
Thank you guys all for showing up. And, thank
you for coming.