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.