Dave Paola: Agency of Learning

Welcome to Build and Learn.

My name is cj.

And I'm Colin, and today we
are talking with Dave Paola

about the Agency of Learning.

Dave, welcome.

Hello?

Yeah, hi.

How's it going?

Good to be here.

Appreciate you.

It's going great.

Yeah, life is good.

Work is good.

we're in the beginnings of spring,
or I guess beginnings of summer here.

I'm calling in, calling
from rural Ohio today.

so there's a lot of
green, things are good.

Life is good.

Are you on starlink or what's
your internet out there?

funny enough, good question.

I investigated starlink and, I
haven't pulled the trigger yet.

Basically, I'm living in a family
cabin right now, that has been in my

family since I was born, basically.

and I was able to finally get internet
access here in, I think in late February.

For the first time in, it's 30
years of existing, and the internet

is faster here than it is at my
parents' house, in northeast Ohio.

It's faster than the internet I had
in San Francisco in the Mission, and

it's faster than the internet I had
in Tahoe and it's half the price.

it's fiber internet.

Yeah, it's great.

Kinda surprising.

I'm excited to try out starlink, but
I don't know, I'm not very optimistic

that it would work well for a Zoom
call or like a remote podcast recording

like this, just given the latency.

But, yeah.

I had to ask, given you're
out in some rural spots, I do

know that it's available here.

There's like a small lake here and
somebody acrossed the lake told

me that they had, star, Lincoln
had only recently gotten it, and

that they were raving fans of it.

So who knows?

Maybe it's in my future.

Nice.

Yeah, it's, it's big in the van life
community already, especially for nomads

and being able to still be connected.

Cause I think the joke has always
been that like, digital nomads

are probably gonna be like the
least dependable contractors.

You got a lot of like software developers
to try to travel and then you're just

like, they're never able to follow up on,
they're like, oh yeah, my internet's bad.

I'll sync up later.

And.

Push up your code when I'm do surfing.

Yeah.

Yes.

Let my people go surfing.

I got some friends who are, who are
van lifers and, it's interesting,

as part of that appeals to me, I've
heard their stories about, going

to Thailand for a year or whatever
and saving cash and surfing.

But I also remember hearing a story
of, I, I don't remember if it was them

or if it was somebody else about, they
would basically pull up to the beach.

They would work, off of a charged
car battery, and as soon as the car

battery died, they would go surfing
while the car battery charged.

And so the thing that would
dictate their hours, the flex,

the flexibility of their hours was
actually the car battery capacity.

Not, time zones or, their mental,
load or how much sleep they got

that day or anything like that.

I always thought that was
a, it was a funny story.

It's a forced break.

I think that's good.

But, yeah.

Yeah.

Yeah.

So I think today we're gonna be talking
a little bit about, helping early career

developers grow into more mid-level
senior level developers one day.

And, before we jump into that, we'd
love to hear a little bit about

your background, Dave, and just
how we got to where we're at today.

Sure.

I'll try to be brief.

Let's see.

So right now I'm founder of the
Agency of Learning, as you mentioned.

the Agency of Learning is basically
a community of early career

developers who, are either bootcamp
grads or self-taught, or otherwise.

I've described it in a variety of ways.

And the way that is most resonant with
developers is that it's a community to

help you get job ready for that first job.

being a junior developer is pretty lonely.

You're often working on.

Your own solo side projects, and you've
selected those side projects so that you

can potentially learn a new technology
because you think that's gonna make

you more attractive to employers.

the employer pitch is
a little bit different.

the employer pitches, we're essentially
a finishing school for bootcamp grads,

and I find that most employers nod
their heads at that description with

very little other detail required.

Right now we're pretty
focused on Ruby, on Rails.

I'm growing it very slowly and exclusively
so like I interview every single person

that joins before they're, before
they receive their link to Discord.

we run it like, like a real team.

It is a real team.

we contribute to open source projects.

We have daily standups.

We have a couple folks who are more
senior that help with all the code review

and, we do design documents for all
of our high level technical decisions.

We follow a pretty,
structured agile process.

And so forth.

My background comes from
the bootcamp industry.

I won't go into too much detail,
but, basically a buddy of mine back

in 2012, co-founded block with B
L O C, which was, to my knowledge,

the first online developer bootcamp.

I.

We were involved with Dev
Bootcamp extremely early on

during their first cohort or two.

and we worked with, the founder there,
for a short time and decided, Hey,

we should try to do this online.

It eventually evolved away from the
online classroom model, towards one

of a, towards more of a one-on-one
model where we would pair bootcamp,

attendees with experienced practitioners.

We pioneered a lot of the, a lot
of what you see now in the online

developer communities where you have
a developer boot camps where you have

the income sharing agreement and, we
have lots of thoughts and opinions

based on the experience there.

And eventually what we landed
on was, I was the C T O.

And so I was responsible towards
the end of my tenure there.

I was there for six years,
responsible for the longest and

most intense product, which was
the software engineering program.

Went to hiring managers and
basically heard from hiring

managers, Hey, 12 weeks isn't enough.

you have all these gaps
in all these students.

And so we put together a longer, more
intense program, to get them job ready.

and eventually we had this thing called
the tuition reimbursement guarantee, which

was basically like, you know, uh, get,
get a job where you get your money back.

a lot of my experience since then, and
certainly what I'm doing now is based

on my, my experience at Block and.

It was a really wonderful place and we
had some really great people working

there throughout the organization.

and I think we were like one of the
last programs that was based on Ruby

on Rails and I, can talk a lot about
that, when you're, when you're

talking about like this finishing
school for bootcamp grads, like what

are the main gaps that you're seeing?

is it how to work?

In an engineering organization
instead of independently?

Or is it more like computer
science fundamentals?

what is going into sort
of the finishing pieces?

Yeah, that's a great question.

the, it's, I am still iterating
and honing the way I describe this.

Probably every time I talk about it, I
talk about it a little bit differently

because we're learning so much, so fast.

But, Most, it's probably 50%
technical and 50% non-technical.

the technical stuff is, it's really just
like when you come out of a bootcamp.

you've learned the fundamentals,
in theory, and you've maybe worked

on some, some greenfield projects,
but here's what you have not done.

You have not been assigned a, a small task
and an existing code base that is running,

Ruby two seven and Rails, five oh that has
nine GitHub actions associated with it.

Two of them are flaky and, you have to
get this up and running on your machine,

and you have to do so in your first week.

And you have to manage the expectations
of your employer along the way.

You wanna be able to
communicate effectively.

So it's basically like a whole big
mess of okay, technical skills.

How do you get your environment set up?

How do you get unstuck when you
inevitably get stuck setting up

your environment like we all do.

how do you do so without
overburdening your employer?

How do you do so without being
overcome with imposter syndrome?

How do you, communicate?

What you need and when to your
colleagues, if you have colleagues

and a whole bunch of stuff.

it's hard to articulate like line by
line what it is, but what we've found

is that basically doing a simulated
team environment with open source,

like ticks most of the boxes, uh, it's
very obvious, you know, for example,

do you wait to be asked for an update
before you give an update on your work?

Or do you proactively provide
the update at a, a, a.

Same time every week to your employer.

how do you.

Infer tone from pull request feedback.

what does a nitpick mean?

Is a nitpick a nice to have or is it
a need to have, like all these things

that, that we know about as developers
every day, if you've never worked

on a real team, like you have to
learn all of this in your first job.

And so by providing what is essentially
a volunteer job experience upfront and

by, honestly like selecting the best
people I can find, like the idea is

that, the agency of learning becomes a
place where employers can go to find the

very best junior de developer talent.

Yeah, it's really interesting.

We, we, we did this at the collective,
so at the, our co-working space, we

worked with the university to hire
a software developer kind of intern.

So it was, this is really cool
program that the students voted on

where they're, they're, I forgot what
they're called, but they pay into

their tuition to create this program.

So the program then pays the students
so that we didn't have to pay them,

but it ended up being a really cool
program where we get the grant to

pay the student to work with us.

And we were building, you'll love
this, but we're building a co-working

software, management system.

Oh.

And the funny thing was like, you
could see as they were, this was

someone coming outta computer science
and they were, very good technically.

but there was that piece that you're
talking about, like working with a team.

In the real world.

And there were all these, very
senior Ruby on Rails developers who

just were too busy to be honest.

Like we were like, okay, we want,
they're gonna be here to help you.

And so when we started working
on the project with these

developers and our intern.

And at the beginning it was a lot of
them, you could tell they were looking

for permission to do a lot of stuff.

am I allowed to give feedback?

Can I ask for this?

To, by the end of their semester,
they were in GitHub being

like, Hey, where's your pr?

Hey, can we close this?

What's going on?

Like it was, I.

I, I don't care how many
lines of code were written.

I was like, you have
reached the next stage.

Like you have to get stuff done sometimes.

And it was just like, that is the one
thing I took away from that was so like,

I don't know, just filled up my cup kind
of thing, where it was like, I think we

succeeded here and I can, I reproduce
that with every individual person.

I don't know.

There's a little bit of, personality
and like you said, imposter syndrome

and all these different things, but
I didn't intend to teach that, but

she was like, my semester's ending.

We have to get this project done.

Where's your code?

Why is this still open?

I was like, you might have a future
in product and project management.

That's awesome.

you say it fills your cup like it does.

It does with mine too, and I dunno
if you remember this or if you

ever watched this talk, but what
you've just described reminds me

of way, way back, like maybe 2011.

Or so, Sal Khan, when he launched
the Khan Academy gave a talk, I think

it was a TED Talk where he talked, I
think it was about mastery learning,

and it was a TED talk about mastery
learning, where you don't let each

student proceed until they've mastered
the topic at hand, which is, I dunno

about either of you, but very different
than my public, school education.

and he talked, he had a graph that
he showed of each individual student.

It was like a scatter plot with
a vector attached to each point.

And you could visualize each line
was a student, and you could see as

time went on, So the x axis is time,
and the Y axis is like competency.

And most students were
roughly in the middle.

It was like this linear progression in the
middle somewhere, not perfectly linear.

but then there was this one at the
very bottom that for long, took a

long time, whatever the topic was,
algebra or something took a long time.

But as soon as they hit it, they
spiked and outperformed everybody else.

And his point was, in the traditional
education system, that person would've

been labeled learning disabled and.

Their whole life trajectory
would've been different.

And so that was, that's the whole
Khan Academy Mastery Learning thing.

And I find that very, fulfilling,
fascinating, intellectually interesting.

especially because education
is so important in society.

But, in a more micro level, maybe like
watching the less experienced developers.

If you give them a chance and you
give them the right environment, like

they can do amazing things, way better
things than at least 50% of the senior

people I've ever worked with, which is
uncomfortable to talk about sometimes

when you're talking to senior people.

But, but man, it's awesome.

I can give you three people right now that
come to mind, like very similar stories.

It's really cool.

So could you help explain a
little bit about the model?

Like how does the agency
of learning make money?

Are the junior devs paid?

Are they unpaid?

Is it all open source?

Is it like, are you taking
projects for clients?

Are you building your own stuff?

what does that look like?

it's been changing a lot.

In the recent past, and it will
probably change a lot, in the

immediate future as we learn more.

I'm definitely taking like the lean
startup approach to this, where I'm

like, try trying every different model
and seeing which one is a good fit.

And honestly, I'm not sure
we found the right model yet.

So I can tell you what we're doing now.

I have a very small for-profit
agency that is becoming more of a

side agency to be honest with you.

And the agency is like, the
naming is very confusing here.

My actual for-profit agency
is called Sierra Rails.

It's been around for a
year and a half or so.

the Agency of Learning is, as you
mentioned, it's totally volunteer based

right now, or I should say it is a freak.

It's free to join.

there's no compensation involved
today for, I, for myself or for the,

For the members and the way that one
business model I've been investigating

with, I would say it's very early.

the results seem promising, but I
don't know if it's where we'll land,

basically like I become a little bit
of like a staffing model where, on the

strength of the technical assessments
and the experience and the candidates,

we place these folks on a contract
a higher basis inside companies.

I have.

Three candidates right now.

they're not candidates anymore.

They've been placed.

So I have three eight junior devs
right now that are on that model.

And, it's I don't know the jargon cuz
I'm new to the staffing industry,

but, I have some friends that have
basically contracted through an

agency like this where the agency
takes a cut for placing them.

So that's one early experiment that I
would say is like modestly successful.

it could be that we evolve more towards
a model where employers pay to get

access to a profile system or something.

I think we're a long way off from that.

although who knows?

But basically like the model is,
Dave identifies like the best

people that apply, makes sure they
are good, and then gives 'em a

bunch of volunteer experience for.

Three months, six months.

And it's not just, it's not just Dave.

It's like I have a team of people
working with me, so I don't wanna

take all the credit, but essentially
it's, building a brand for employers

that employers can trust us to
give them really good candidates.

and trusting that at some point
we'll be able to make money off that.

I don't know when that will happen.

so I still have a day job,
but, yeah, that's how it works.

It'll be exciting to see.

I think we're seeing this in the rails
world with the Rails Foundation and

things too, where they're wanting
to focus on education, and how does

Rails show up to that conversation?

And you mentioned like having a
curriculum, in the boot camps that

you've worked with in the past.

And there's the gaps and there's no
replacement for real world experience.

Either.

So getting a blend of that, and it'll
be interesting to see how Agency of

Learning fits in with things that exist,
boot camps that exist, go Rails, rails,

foundation, whatever comes from that.

and yeah, I was going somewhere with
that, but We'll, I'll turn it over to cj.

Yeah, no, I was just reflecting on.

my experience too, teaching at a bootcamp
and then at the end having a group of

students that all knew the same stuff.

They all knew the same stack.

They all knew the same at the time.

We were using like rails in the back
end and backbone on the front end.

And so it was fun to see okay, they did
their final project and now like maybe

they're working on some extracurricular
stuff to polish up their resume

and get ready to go look for jobs.

But at that time, like right after
they came out, it was cool to see

many of, the students work together
because they could pair and build

stuff really quickly because they
all had this common language about.

Okay.

I know exactly what, my model's
gonna look like, my controller's

gonna look like, and you know what?

My front end is probably like the
conventions that I will likely follow.

so that was really exciting to see.

And then, I remember.

watching a lot of those students go
on to work at, at agencies and for

companies like Thoughtbot and Pivotal
Labs and, in those environments where they

continued the pair programming like, like
really immersive and like intentional.

Learning process, and many of those
engineers are now like the best

engineers that I know in industry.

And I think the pattern totally works
and, yeah, I'm, interested to watch

as you figure out the business model.

But I definitely have seen
and experienced, some juniors.

Being really effective.

And also the pair programming
model working really well.

is pairing something that's part of
your process or is it mostly solo,

you're gonna get a task and we expect
you to go execute on that or, yeah.

What is the, like the day-to-day
for one of the juniors look like?

Yeah.

so first off, I couldn't
agree with you more.

my, the experience I had lines up.

Perfectly with what you just described,
to the point where I now have, one

of the, one of the challenges we'll
say that I face an obstacle going

forward is in communicating to
employers the story that you just told.

This is a story that I tell all the
time, nearly verbatim to what you

just said, so I won't rehash it.

But the idea that you can hire
two developers instead of one.

It feels like educating the market kind
of a challenge, because over and over

again, the opposite story happens, right?

It's oh, yeah, I don't have the
budget to hire two juniors, so

I'm only gonna hire one junior.

it'll be fine, right?

And no, it's not fine.

it's so significantly different
and we all know how that goes too.

Like we know when you hire a junior and
you don't set expectations properly, you

don't communicate with them effectively.

They get imposter syndrome.

They feel guilty for asking
their colleagues for help.

I had a candidate recently who, was
told that they were not allowed to

ask their senior colleagues for help.

And if there's not a faster way to
destroy, the potential in a junior

engineer, I don't know what it is, that's
gotta be the one that does it the fastest.

you're not allowed to ask for
help from your, so nonetheless,

th that mindset is still pervasive
in the, in the market right now.

And I don't know how to fix it,
beyond just keep talking about it,

keep evangelizing and so forth.

but yeah, basically to answer
your question, Yes, pairing is a

significant part of the experience.

Basically, we follow what, used to be
a pretty normal agile process of you

go, get acquainted with a feature.

Either you pull it off of the work board
or you talk to your manager about it or

your product manager and, you spike on it.

Say, okay, let's go take a couple
hours and write some throwaway code.

And you write the throwaway code, and
then you come back and you talk about it.

You have a conversation.

You use the code as an artifact.

In that conversation, you say, this is the
part that's gonna be really easy and fast.

In fact, it's already done.

This is the part over here that.

We tried it this way and
this is not the right way.

We're gonna have to try a different way.

Or you say this way worked, but we
have to change 30% of it, or whatever.

And then you go on and build it again.

And when you build it again, it goes
four or five times faster because you've

already done the majority of the research.

And I don't know why maybe someone
more experienced can fill me in, but

this is way more effective at avoiding
the gigantic PR problem where you

have this huge PR at the very end and
people are just like throwing feedback

into that PR willy-nilly, senior
people, junior people, nice to have,

need to have nitpicks, style, choice,
who it is impossible as we know to

get like an architectural overview.

How does this thing work when you
have a 4,000 line pull request?

You have to review.

But we've all been on
teams like that I'm sure.

yeah.

Repairing is a big part of it.

Pair we pair on the spike aspect, and
sometimes they pair the whole time.

Sometimes they stop halfway through
and it becomes very obvious that the

seams, the seams are obvious and clear
and they can just, come together.

But it's very rare that there's
no pairing happening at all.

You didn't specifically mention it,
but , having two juniors, instead

of one, allows those two to pair
with each other as well, right?

So that they don't, they're working.

Someone might have a slightly different
background, they might be a little bit

ahead, a little bit behind, technically
and They hopefully will still get to talk

to their senior engineers, but having
the two means that it's not this lonely,

existence on the team where they're
like, okay, we were brought on, I've

been on many teams where they'll hire
a junior, but then they don't set the

expectations with the senior people that.

Or even giving the senior
people the right training.

I would say mentoring is not a
given, like most people have not been

taught how to teach or how to mentor.

And it's a chicken and egg there
too, where you do have to develop it.

Like in my roles, I do see,
helping my team as part of my job.

It's not just to produce my own
artifacts, to produce my own code.

I've also been a senior engineer who's
guilty of making the too big of a PR

that's got way too much stuff in it too.

Because we've just been jamming
on one idea or one concept, but

that makes it harder for juniors
to learn from as well because now

they, are they gonna emulate that?

Are they thinking this is what
being a senior engineer looks like,

that you have to have these huge,
massive, like too big to fail prs?

No, it's not.

So there's a little bit of
modeling that has to happen.

Role models.

a little bit of training.

I don't think, I don't know Sure.

If you've heard of anything.

Is there any formal programs for
teaching seniors on how to do

mentorship and things like that?

I'm sure there are, the only
one I am aware of that's top of

mind is one from Engineer Kit.

And I think it's pretty new.

I talked to Gavin, at Engineer
Kit a little while ago about this

that's the only one I'm familiar
with off the top of my head.

I do think you're right though.

And I think one of the, one of the
things that I've stumbled upon here is

that if you're already on an engineering
team, That has a great culture in

terms of, egoless leadership and people
are able to give candid feedback and

revisit decisions along the way and
you have a culture of helpfulness and

openness and, no such thing as a stupid
question, those kinds of cultures.

Then you can add juniors to that
environment and they'll do fine

even if you hire them one at a time.

It's the other cultures that you
need to send these squads of juniors

into to, in a sense, be a version of
it's like you're implanting a seed

of a new environment into a team and
you do it with these two juniors and

it can work really well actually.

It's very, it's harder, but
I think it can work well.

but I do think, basically
I agree with you like the.

The idea of being a good role model
is like half the battle, if not more.

Sandy Metz, I'm sure we all
love and admire Sandy Metz.

I certainly do.

she had a gr, I forget which talk it
was in, but she, hammered the point

home somewhere that when you have,
especially newer engineers, but all

engineers I think are guilty of this,
you go into a new code base and.

You're tasked with writing
some code or building a feature

or changing something, right?

Most code is not written new.

It's changed.

And when you need to make a
change, you try to adhere to

the patterns you see already.

And if the patterns that you see already
are, subpar, if you add juniors to them,

they're gonna copy subpar patterns.

It's not necessarily cause of stupid,
it's because that's what we all do.

And so I find a lot of my work at
the agency now has become, Try to

make sure the guardrails are good.

Try to make sure the
patterns that are there.

it's actually more, it's actually a
little bit like an architect role, but

it's not about the architect of the code.

It's about architect the code that
people are going to live in and habit.

So that like when you add more people
to them, they don't just duplicate bad

patterns, they duplicate good patterns
or arrange things in such a way that.

The patterns emerge or
there are no patterns.

Like you, you organize the mess first and
then you separate the messes first and

then it's kinda refactoring a little bit.

But anyway, yeah, being a good role
model and like making good technical

decisions, I find is half the battle.

and to your point about new engineers
joining a team and having those 2000

line PO requests, like everybody
is guilty of this, myself included.

And one of the meta lessons that
I've watched some of these folks

learn is, oh yeah, okay, this
is far messier than I expected.

Like we have a big project and it's not
this perfect harmony of beautiful code.

And the process rained perfectly.

It's like there's some stuff
that went in at the last

moment that is not good, right?

And we just have to suck
it up and deal with it.

And that's gonna be a reality too.

I think that's an important lesson to
learn, that you're not gonna learn on

your own, on your solo side projects.

you gotta learn that in a real team.

What I like about this too is most times
when someone comes from a bootcamp, they

have, a set of kind of personal portfolio
projects that they've worked on, but

they're solving a problem for themselves.

It might be a portfolio website.

It might be.

a to-do app, Pinterest
clone, things like that.

But they're not necessarily, they've
nev never talked to a customer.

They, and in some cases, I don't
think that's necessarily an

expectation of a junior either.

But like you, you're just coming up
with a thing on your own to do it.

And it's greenfield like you
mentioned, but you don't get

that world real world experience.

And I would actually say like open source.

Feels like jumping into the deep end.

what sorts of projects are we talking
about when we talk about open source

that folks are contributing to?

that's an excellent point.

we even had at Block, we had, as part
of our longer track, We had something

called the open source apprenticeship.

It was like that last
after the capstone project.

You would go, ostensibly
work on real code.

It didn't work very well.

it didn't work very well
because it wasn't real.

It, even though it was open source,
it wasn't a real simulated team.

It was like, go hunt and find issues that,
people need help with out on your favorite

library and try to contribute to them.

And it did a good job of instilling the
experience of getting acquainted with a

new code base, cloning the app, getting
it running, and like trying to understand

what's what and how it all works.

But that still wasn't real.

and so that's part of the, reason we're
doing it this way at the agency, but,

right now we have two projects and we're
about to have a third that I'm very

excited about that I can't talk about yet.

and maybe we'll have announced it by the
time this airs, but the two that we work

on right now and I'm very grateful for the
ability to contribute to Ruby for good.

so Ruby for Good.

If you're not, I'm sure the two of you
are, but for the listeners that aren't

familiar, it's it's this great group
of people that donates their time,

and energy to work, to basically build
out open source rails applications

for charitable organizations.

So the first one that we're working
on is called casa, which is Core

appointed Special Advocates.

It's a system that, nonprofit, pasa
organizations use to manage their.

Foster youth.

Not just the foster youth, but the
volunteers, the cases, they go to

court, they have to go report to
courts and give updates and so forth.

They have to keep track of their
volunteers and whether or not

their volunteers are commuting to
meet with their CASA youth or not.

And different organizations have
reimbursement schedules and it's a

real product in use by real people.

It just happens to be an open source.

It has all the warts and skeletons
and cobwebs that a real app

has because they've had to
make trade-offs over the years.

And so far that's the one that, I would
say has been the most realistic and given

people, I think, the best approximation
of what it's like to work on a real team.

in fact, I feel comfortable enough
with that fact that I encourage our

folks to add to LinkedIn the fact
that they have worked in a volunteer

capacity on this real product.

Because that's what it is.

Talk.

There's a stakeholder meeting every Friday
that we go talk to the users who use it

and hear the bug reports and that's the
kind of thing as another representative

example is if you're an engineer working
on this app, you get to go every Friday

to hear about this repeated bug report.

You have a disgruntled user sometimes that
says, Hey, this bug still isn't fixed.

Why isn't this bug fixed?

And if there isn't a more
representative example of what

it's like to be an engineer on a
real team, like that's it, right?

yep.

Now we're working on it, right?

so the second one is an app that
we're building for ourselves.

Actually, it's an open source as well.

It's the app that we're gonna
be using to basically manage

the experience of the agency.

Know, profiles, login, wait list,
onboarding, FAQ Pattern Library.

we have a lot, we have big plans for it.

We're starting very small with a feature
called pair requests where if you are

open to working and you want to pair
with somebody, then you send up a little

pair request and it'll notify people.

And a little bit like Calendly
actually, but specific for

developers who want a pair program.

so that's another
project we're working on.

And as I mentioned, we
have more on the way.

If anybody has ideas, if any, if either
of you or you, your listeners have

an open source project that you would
like some help on, that you think

would be a good fit, please email
me or text me or DM me or whatever

and I'll try to make it happen.

Cuz right now that is actually the
bottleneck is, getting ahead of the work,

making sure it's scoped, making sure it's
prioritized, just like a real organization

that's actually now the bottleneck.

We have plenty of developers trying
to get in, Thank you in advance.

Yeah.

How do you balance the demand?

Like how are you balancing supply
and demand, like the projects you're

working on versus how many devs
want to participate in the program

and I assume that once someone has
volunteered for six months or so,

they like spin off and go get a job.

and so you're constantly
trying through people or Yeah.

how does that look?

Yeah, I think one thing that's
very important to me is that once

you get a job, you don't leave.

I remember back in the bootcamp
days, there, there were some

call them optical challenges.

there was one big bootcamp that
we've all heard of that would

hire their own grads to teach.

And this got a very bad reputation.

And I, there's other things as
bootcamp did that were, not great.

but I do think there is a lot of merit,
and I think lots of educators would tell

you that there is a lot of merit to the
best person to explain something to you

as someone who just learned it themselves.

Because when you're really experienced
and I remember mentoring the first,

some of the first block students back
in 2012, and we made a mistake together,

pair programming, and they said, oh,
don't worry, but just get checkout.

And they're like, what's get oh
my God, we need to add version

control to our curriculum.

I.

And so those experiences of forgetting
you forget what you know already.

And I think it's very powerful to
have, somebody who, anyway, so to feed

this back in to the question is, we
care very much that the people who

get work through us, stick around and
help their fellow community members.

It's so at that point it kind of
transitions from, become job ready to

like, Newly employed mastermind group or
mastermind community where, you know, next

Wednesday, we're having a roll call, we
call it, where if you're on a contract,

then we just get together on Zoom and talk
about the challenges we face and, whether

or not it's like, how do I communicate
this tricky situation to my employer?

they said, I'm only allowed
to have X hours a week.

I wanna work more than that.

Do I build them?

How do I think about that?

Is it okay to go over
some of these questions?

you don't really encounter
until you get your first job.

so yeah, it becomes a little more like
a mastermind group in that regard.

I.

I imagine that some of those folks
are also then able to be more like

the quote unquote senior engineers
for the new juniors, right?

For pairing partners, stuff like that.

So they, I.

Their alumni of a sort that can contribute
in other ways, help, agency of learning

become a little bit more sustainable.

So it's not just Dave and
a few other people who are

keeping the lights on there.

Does that play into it at all?

Yeah, you nailed it.

it's like the value of the community.

It's one of the reasons when, you try
to pitch a, this is not a venture backed

thing, and I'm, I have no intention of
making it that, but if you pitch to a

vc, you go on Andrews and Horowitz's
website and read about the kind of

pitches that they fund, it's okay.

Network effects.

network effects.

There's a reason.

It's every time you add a new
great person to a network, it

increases the value of the network.

And that's true here.

That's true in every community I've
ever been a part of, is like the value

of the community is the other people.

And so if you have people that you
know, they come in, they work for

a little while, and open source,
they get some great experience.

They get their first job, they get their
second job, they come back and they

share that wealth with the community.

It makes everything better.

It makes everything more valuable.

It makes the community more valuable.

It gives them that experience of coaching
the juniors, which we just talked about

is really valuable, for their career.

Yeah.

I wouldn't call them senior right away,
but I would definitely say like we want

them around because more experience.

Imagine you're a bright isle, bushy
tail, bright eyed, bushy tail junior

developer looking for your first job.

If you're in a member of a community
where someone just like you, like just

got that first job and they're coming
back, you get to listen to all the

challenges that they're facing and the
challenges that you never would've.

Thought of.

It's just a really cool
experience, you know?

I think the brand that you're
talking about there is important.

Cause there's definitely some boot camps
where when we would get applications

from that bootcamp, we would take it.

They would go to the top, like we're
like, okay, of all the candidates,

like we really enjoy talking to and
know, we know the level of curriculum

and everything that comes outta that.

We've had people on the team
who've come from that bootcamp.

and then there's definitely been other
ones where, okay, we're gonna have

to go really like in the take home
tests or whatever, figure out what

might be missing, things like that.

And so having a strong brand with agency
of learning and keeping, I would say

Keeping that high is important there so
that when I see Agency of Learning, I

get excited that someone from Agency of
Learning is hoping to work at my company.

And I think you've talked about this on
other podcasts that kind of became similar

with Pivotal Labs was very much like this.

It's like someone would go from
a bootcamp, go work at Pivotal,

and suddenly everyone's oh.

I want a Pivotal alum on my team.

When they move on to their
next thing, usually they would

go on from agency to product.

And you end up with all these people
at Airbnb and all these companies

that came from Pivotal, which I
don't think is pivotal, still around.

I don't think it is.

Yeah.

So we've got today it's probably more
like the Planet Argon, the evil Martians,

sorry for all my agency friends.

Sierra Rails.

Not Bot.

Not bot.

There we go.

Not bot.

Yeah, you're right.

it is brand building.

There's a lot about this that's
not only is it not new or

innovative, it's actually very old.

we used to talk a lot about this.

At Block we had this problem where,
The whole industry decided on the

placement rate as a metric that
prospective students should use when

deciding which boot camp to attend.

And like on its face, if you're
looking at applying to in-person

boot camps, it makes sense.

It's not a crazy concept.

It's yeah.

How many people, went through the
program as the denominator, and how

many people got jobs as the numerator?

And when you're dealing in, 10, 20, 30
people in a cohort and you only have four

co, four cohorts a year, yeah, that's less
than 200 people, less than 300 people.

that's not crazy.

What it means is, first of all,
geolocation, depending on where

you're at, San Francisco, la, New
York, Houston, Dallas, whatever.

That bootcamp.

it's the same thing as college admissions.

It's literally the same thing.

you're identifying the best people and
you're bringing them in, and you're doing

it so you can get a good placement rate.

so that you can build that brand.

Block.

Block was different.

Man block was much harder.

we had an admissions process,
but it wasn't that competitive.

and the whole point of doing
it online was the scale.

We wanted the scale of
impact to be much larger.

And that's one of the reasons it
ended up looking very different

than an online classroom.

when I left we had 3,500
concurrently enrolled students and.

If all you're looking at is a placement
rate with numbers at that scale, you

have to have five asterisks after your
placement rate because you know a lot.

What about dropouts?

What about people that don't want a job?

We wanted to accommodate all of
those people, but in order to meet

the market, the optical market needs
anyway, it, it was a big challenge.

and I think, this model is simpler.

I remember.

hack Reactor.

I am, I'm unplugged in the boot camp world
now, but I remember Hack Reactor used to

call themselves the Harvard of boot camps.

I don't know if they still call
themselves that, but for a while

at least that was their brand and
I think they did a really good job.

I think that, I think they nailed that
branding because that's what this is.

it's about branding, it's about building
a brand that people trust and you

need to invest in that reputation.

And I'll say right away, I don't think
we did a great job of that at Block.

we did not appreciate
how important that was.

And then we also did not appreciate
how old of a problem this is.

anyway, so I agree with you.

When people are considering hiring
junior engineers, one thing that

often comes up is who is gonna manage
them or mentor them or lead them?

And I think.

In one of the posts on the Agency of
Learning site, you talk about like

wiggle room in management practices
and having a little bit more margin

to make mistakes in turn of management
when you hire a senior person.

And I'm curious what your take is on
maybe minimum level of experience for an

engineering manager or the other engineers
on the team to successfully integrate.

Junior or two to their team?

I think it's like there's more than
one dimension to mentorship, right?

there's like technical coaching, hey, You
shouldn't use loops, you should use map,

or you shouldn't use polymorphism here,
you should use composition or whatever.

this approach doesn't
follow solid principles.

Duplication is better than the wrong
abstraction, those types of things.

But then there's also hey, There's
also like pulling the, there's like

the managerial duties of pulling
aside the engineer and saying,

Hey, I get what you're going for in
that meeting, this kind of a thing.

Got in your way there.

Next time, maybe try this approach.

Or, Hey, uh, you know, I, I have a really
high bar for you and you didn't meet that.

Here.

Is everything okay?

so I think technically
obviously you need to have.

Significant experience to be able
to coach a junior from a technical

perspective, you want to definitely
avoid the blind leading the blind.

and I honestly, again, an unpopular
thing, like I see that a lot, I

see a lot of the blind leading the
blind and it doesn't keep me up at

night, but it makes me concerned for
specific organizations and teams.

I don't think you need a lot of technical
experience to do the other stuff at all.

in fact, I think very junior, technically
junior engineers can be significantly

superior managers and leaders.

I.

Because of their background, because
of their, maybe their communication

skills or their interpersonal skills.

Sometimes they're just like the
diamond in the rough and they turn

out to be really good leaders.

That's one person in particular at the
agency right now that I know of that's

like that, that I feel very fortunate.

Basically like Pluto and Saturn lined
up and beamed a good luck Ray into

us and we got this awesome person.

they're very junior technically.

So would they make a good mentor?

Like they make a good engineering leader?

they probably need some help
making technical decisions.

But, yeah, I don't know.

That's a very good question.

I don't have a totally
solid answer for Colin.

what is your sort of like experience
to being maybe like being managed or

managing other people or whatever?

Cuz I think, yeah, I've got,
My own takes about managing

people or like mentoring people.

And it's tough.

It's super tough to do it right and bring
them along and, yeah, I think, yeah.

I'm curious your experience too.

The wiggle room really resonates with
me is that you do have to have the

space for it, and you have to give
yourself, if you're the one mentoring

and helping, that is part of the job.

It may not feel like, oh,
I'm a software engineer.

My job is to write code.

as you get more senior, and I think we
haven't done an episode on this, but

we'll share a link to the engineering
ladders as you get more senior, your.

locus of control, if you will,
gets more from, goes from

more internal to externally.

You start working more on how as a
junior I have my tickets and I'm working

on my things and I'm learning myself.

You're not so much worried about
what other people are working on.

you might start to think about how your
ticket fits into the greater scope of

things, and then you get to the next level
and you start to work with other people.

I like the idea of pulling, pairing
down so that you are working with other

people on more earlier in your career.

But starting, you're not having
to worry about the business goals

as a junior engineer, Versus as
you get more and more senior and

you're getting towards that senior.

Level engineer, you're actually more
concerned about what the whole department

is working on or what your team is
working on and how it fits into the

greater goal and things like that.

And so I would say like all of that is
part of the work and I really enjoy for

developing like your own, whether or not
you're an IC or aspire to be a manager.

There's a really good podcast
called Developing Leadership

from Jason Warner and ISO Kent.

and then there's also a really good
book called Engineering Management

for the Rest of Us from Sarah Dresner.

And both of those are really good
at just if you don't want to be an

engineering manager, they're useful
to listen to, to learn how to work

with your managers to learn like
what is even engineering management.

sometimes that person was an engineer.

Sometimes they're not.

It really depends on the organization.

and.

It's also a very big decision people have
to make is a lot of people will stick to

the IC track and some people will choose
to go to the people management side.

and so I think if you're out there
and you're thinking about bringing

on a junior, like you gotta give
yourself the space and time to make

sure that you can do the mentorship
and that remember it's part of the job.

You might not feel like you did the
same amount of work as you did yesterday

because you had to do some work with your.

You're Junior and it's great,
that's part of the job.

that's going to, you're gonna
see that payoff in spade.

Like you could have done the work
yourself, but now they're gonna

learn how to do that work and they're
gonna be able to develop themselves,

which is, goes a lot farther.

Totally.

On one of the teams that I was on, we.

Worked really well as a
small engineering team.

And we had some, I would say like we were
pretty functional, like high functioning

in terms of using Jira really well.

We had our velocity was
like really locked in.

We could estimate really well,
and one of the things I remember.

When we brought on a junior to that
team was like, okay, everyone, we all

expect velocity to plummet for the
next six to nine months because we all

wanna bring this junior along with us.

And so like it is a fully understood
thing going into this that we're

gonna lose a little bit of speed.

And that's intentional because we want to
yeah, eventually get that back in spades.

I think, one interesting experience I
had was managing a couple of interns.

and that's when I started to recognize
there's so many different behaviors

as an engineering manager, that
can make it so that the junior is

more successful or less successful.

It's like you gotta, you do have to
be explicit about those communication

touchpoints and about holding certain
bars and being really clear about

the expectations and making sure
that they understand how to achieve

those and all the steps in between.

And the more and more that you
build that trust, the more you can

let go of the reins a little bit.

But I think, yeah, in my
experience holding those, I.

Controls really tightly with a
junior actually makes you move faster

because you can get to know what's
expected sooner and then the junior

kinda picks up and runs with it.

but yeah, I think, I don't know.

Engineering management is very hard.

So anyone who's out there who's doing
engineering management, I, yeah.

Kudos to you cuz it's, it is,
it's tricky to be both technical.

And be able to work with people.

And, yeah, bringing
juniors along is tough.

preach, that's all.

I'll, that's not all I will say
to that, cj, but I'll say preach.

I think the best environments that
I've ever seen or been a part of to

learn the craft of, of engineering
management have been, a weird mix of

both supportive and warm, but also,
The higher up you get, the more brutal

the consequences are when you fail.

and for me, just looking out my own
eyes, the experience of block for me was

fascinating and it, I feel very lucky
to have been a part of it because it

was, it's four of us at the beginning.

And then we started hiring
engineers and hiring a designer.

And then we had hired a second designer
and we hired an office manager.

We hired a director of marketing,
then we hired a SA salesperson,

then second salesperson and support.

Before you know it, I used to joke
my job changed every four to six

months and what I learned real fast
was that like, you gotta get your

ego out of the way because if the
ego's in your way, you're gonna fail.

And basic basically, cuz it's, for
me it was this like, Crazy recursive,

meta hyperdimensional experience of
like e every four months you'd have

a new mirror held up to you that
showed you all your flaws, right?

Yeah.

Because the team be beneath you
began to manifest those flaws.

It's okay, the next team, they
better be better at receiving

feedback than I was, installing that.

And the last thing, it's it's
a very humbling experience.

I couldn't agree with you more.

That goes both ways.

you don't want this culture of your
company to be that people who are new

to the team, whether they're junior
or not, to have this experience of

having to go visit the wizard on the
mountain to go ask a question, right?

It's like you gotta check
the ego at the door.

No matter what level you're at, you're on
the same team, you're on the same side.

Like the goal is not that I know
more, this is a very much a scarcity

mindset that sometimes happens.

And I'd be curious to end this,
this episode on this topic of

right now in the market, there are.

Quite a few engineering jobs.

There's also quite a few engineering
layoffs happening, but almost

all the jobs are senior and staff
engineers right now that I'm seeing.

And I'd be curious to get
your take on why that is.

Why when we see these little ripples in
the economy, do we see a retraction in.

Early career jobs, and we don't
have to solve this problem if we

don't know the answer to it, but
I'd just be curious to get your

take on why do we think we see that?

Like why wouldn't this be an opportunity
to invest in early career devs?

When you know, senior staff engineers,
they come with ego, they come

with really expensive salaries.

Why is that still being hired
for when we have other options?

I'm not gonna pretend to like.

be the oracle that knows why.

Cause I don't, my experience
is not at big companies.

I don't, I've, we did do a layoff at
Block in 2016, which was very tough.

so but I am of the opinion
that it is an opportunity.

I find myself in this weird.

This weird spot personally, where
it's I know, I feel like I now know,

especially after the last few months,
I know how to hire pairs of junior

devs with the right amount of senior
coaching, the right product management,

the right types of projects, and they
produce superior results to a team

of, three senior engineers and it's
cheaper and they have better retention

and they have better job satisfaction.

So what am I missing?

Like I do think that, And, I'm doing my
best to educate the market and manifest

it, but I think at the end of the day,
every team and culture is different.

to your point, CJ earlier about like
the balance of like holding that control

very tightly produces better results.

I'm a big fan of, David Marque, who wrote
this great book, turned the ship around.

I am not an affiliate or anything.

I've never met the guy, just,
I'm big fan of his work.

and he, there's this idea of in the
spirit of not ha not building a cult of

personality into your organization, he
has a line about every organization knows,

e everybody knows of an organization
where people will just follow the leader

off of the cliff, Instead, if you push
the authority down to the information

rather than the information up to some
decision making authority, then you

just get a healthier organization.

And if you think at it from a
systems perspective like that, tuning

the control that you give to the
competency level, and so you can

ratchet it up, is the key, right?

And so in this world of layoffs
where it seems like nobody's hiring

juniors like Zig, when everybody else
is zagging, turn everybody else's

deadly risk into your superpower.

that's what I would say.

find the playbook, execute the playbook.

It is not that hard.

What's hard is you, it's, it you,
it will feel unnatural to you.

it's the engineering management problem
that we've just been talking about is

it's much easier to hire the egotistical,
expensive senior engineer and deal

with their baggage, sorry to say.

Than it is to hire a pair of juniors
and go through that discomfort and

incur the management overhead and try
to figure out how to run an effective

organization when you've really been just
leaning on really experienced people.

Nothing wrong with that.

That's the kinda organization being it's
fine, but, I perceive this as a potential

superpower and I see it in my team.

I've seen it on other teams and I can't
figure out why more people don't do it.

So if you can crack that
code, you'd be in the top 1%.

All right.

I think that's a great
place to end, this episode.

Thank you so much for joining us, Dave.

And yeah, this is something, it's giving
me a lot of things to think about too.

In terms of like, how best I can think
of this in my own roles and how to

empower early career devs, and if you're
interested in getting involved, where can

people find all the things about agency of
learning, all things Dave Sierra Rails.

Where can, where should we send people?

Yeah, I should send people to agency of
learning.com or follow me on Twitter,

which I'm too, still trying to figure
out like the branding between myself and

the Agency of Learning Twitter account.

it's a weird hybrid, but yeah.

I appreciate you guys bringing me
on and it was fun chatting and,

yeah, let's catch up again soon.

Thanks a ton.

as always, you can head over to build
and learn.dev to check out all the

links and resources in the show notes.

That's all for this episode,
and we will, see you next time.

Bye folks.

Thanks again, Dave.

See ya.