0:01

Hello everyone and welcome to another episode of Code

0:03

and the Code Encoders .

0:05

You're listening to the Ruby on Rails podcast . We're

0:07

here with Drew Braggs the special crossover

0:09

episode .

0:10

Where I'm talking to Elise Schaefer of the

0:13

Ruby on Rails podcast . So

0:15

some of you remember we've done a crossover

0:17

episode before , but that was with the old

0:19

host , brittany Martin . Brittany , we miss

0:21

you very much , but we're excited to have Elise here

0:23

. Elise , how's it going ?

0:25

It's going well . I just got back from

0:28

RubyConf yesterday , so kind

0:30

of adjusting to normal non-conference

0:33

life still , but things are going really well . How

0:35

about you ?

0:36

Going well , got the post-conference slump

0:38

where I just kind of miss all my friends , even

0:40

though I'm really tired from interacting

0:42

with so many people for multiple days

0:45

. So it's that weird . I'm so

0:47

happy to not be there anymore , but I'm also missing

0:49

it terribly .

0:52

So I think we've kind of met a few times

0:54

at this point . The first time I met you , I

0:56

think , was at RubyConf Mini

0:58

maybe . Yeah , like you have this wonderful game

1:00

show that you do , and I'm

1:03

just curious where the idea for that game show came

1:05

from , and because it's like a great

1:07

part of the conference . When it's there

1:09

, I always appreciate it . So

1:12

I'm just kind of curious , where did the idea come from ?

1:13

Yeah , I appreciate the kind words . I am

1:16

consistently surprised

1:18

and blown away by all the overwhelmingly

1:21

positive feedback I get about

1:23

the game show . It really was

1:25

an accident that it happened . In

1:27

a way , I had told a

1:29

friend of mine , jason Sweat , that it

1:31

was on my bucket list to one day speak

1:33

at a conference he was putting

1:35

on a conference called Sin City Ruby

1:38

, and he asked me to speak at it and

1:40

I was like sure , but I have no idea

1:43

what I'm going to talk about . So I racked my brain

1:45

for two or three weeks trying to come up with

1:47

what do I want to talk about ? Am I an expert

1:49

in something , or am I good enough at something

1:51

to talk to a room of

1:53

other Rubyists about something

1:56

I don't know ? I have very low self-esteem

1:59

and self-confidence so it's hard for me to say

2:02

I'm smart enough to talk about X

2:04

or I know enough about

2:06

Y to tell it to a room . The

2:09

one thing that I did have that I was really

2:11

interested in was a collection

2:14

of weird Ruby snippets . I

2:17

had a company with a 17-plus

2:19

year old code base . It was like Ruby

2:22

1.8 and Rails 2

2:25

when it started , so it's super

2:27

old and it's always been a really lean team

2:29

. It was a little outdated when I

2:32

got to it and it just

2:34

kind of meant that as I started doing the

2:36

upgrade , I was just touching files that hadn't

2:38

been touched in 17-plus years

2:40

. So there was really weird

2:42

Ruby and it was awesome . I learned so

2:44

much , but there was a lot of stuff that I noticed

2:47

. Hey , I don't even know how to

2:49

Google this syntax . I know nothing

2:51

about this syntax . I don't know what's called . I don't

2:53

know how to describe it . To Google

2:55

this was pre-chat GPT days

2:58

, so you had to do your own Googling

3:00

. Yeah , so I had that and I was like

3:02

I wonder if I could do a talk about that . Hey

3:05

, readability in Ruby is super

3:07

important . Ruby's a wonderful language for making

3:09

it readable , but you can still be weird

3:11

with it , which is also great . But it's sort

3:14

of important . You're leaving behind

3:16

this legacy of code . You kind of need other

3:18

people to be able to read it . So I

3:21

knew I had that , but I didn't know how

3:23

to make it a talk and I thought

3:25

maybe I would do it like a circus act , because

3:27

why not , we're in Vegas , I can be as weird

3:29

as I want . The talks also weren't being

3:31

recorded , which was a godsend

3:33

, because if they had been recorded , I probably would

3:35

have just bowed out and been like no , no one can

3:37

see me do this ever . But

3:39

it was like I wasn't sleeping one

3:42

night and I just , middle

3:44

of the night , was like and

3:46

I just was like I can do it like a game show

3:48

. I can do it like some , like just

3:50

pick a game show I can , doesn't matter

3:52

the format , I just I have this weird

3:54

Ruby and that's what I can do is like what

3:56

is this output ? Like what happens when

3:58

you run this Ruby or what is this shit called ? I

4:01

worked on it for a few weeks and gave it

4:03

a sin city and everyone was like it was fun . Brittany

4:05

, the old host , was my first contestant . She did

4:07

great . It was a lot of fun

4:09

. My friend , Chris Seaton was in the audience

4:11

and anyone who remembers him he's

4:14

prolific at knowing Ruby syntax

4:16

and he admitted afterwards that I stumped him

4:18

on one . So it was like life achievement

4:20

mode there . I got great feedback so I decided

4:22

to do it at many , which is where you saw and participated

4:25

I appreciate that in it and

4:28

it's been going strong . I've done it a

4:30

few times . I have a few more instances

4:33

of it scheduled , so I'm excited by

4:35

how many people have seen it and enjoyed

4:37

it . I'm excited by the fact that people tell

4:39

me they continually get something

4:41

out of it . But yeah , it's a great

4:43

. It's heavy audience participation . I

4:46

bring people up to the stage . So it's

4:48

not just some guy that you don't

4:50

know talking at you for a half hour , which is

4:52

that can be a great thing when it's like

4:54

Kevin Newton talking to you for a half

4:56

hour , but when it's me , it's , I don't want to do

4:58

much of the talking .

4:59

I like the audience participation

5:01

aspect of it and also it's typically

5:03

I don't know if this has been true every time , but it's

5:05

been true the couple of times that I've

5:08

seen it it's been at the end of the day and it's like

5:10

a nice little energy rejuvenation

5:12

thing right before everybody goes

5:14

to dinner or goes to karaoke or whatever

5:16

they're going to do . It's like it like brings the energy

5:18

of the conference up , or at least it did the two

5:20

times that I was there and I think that's like part

5:23

of it . It's also just really funny because some

5:25

of the questions are just wild

5:27

, like wild Ruby

5:29

questions . It's good

5:32

. I know a lot of people like the game

5:34

show , so I hope you keep getting to do it . I like

5:36

the idea that it was just like a midnight epiphany of like

5:38

it could be a game show .

5:40

Yeah , and I think it's a good . I think it's a good

5:42

message too to pass on to anyone who's

5:44

trying to come up with a talk and they're like I don't

5:46

know if I can do a technical talk

5:48

or if I don't know if I know enough about

5:50

this topic . You also don't have to stand up there

5:52

for a half hour and just talk at people . You can come

5:54

up with fun stuff . Nick Schwatterer gives

5:57

some of the best talks I've ever seen and he

5:59

just kind of mimics what Y used to do , which was really

6:02

weird . You sort of don't know what's going

6:04

to happen next . You're like fully engaged in this performing

6:07

arts act of Ruby

6:09

, and those end up being some of the best of

6:11

the conference because there's a ton of

6:13

really great technical talks and non-technical

6:16

talks and every time there's something that isn't

6:18

a traditional talk , it ends up being so

6:20

good and so fun . So I would

6:22

say to anybody who's thinking

6:25

about talking and don't

6:27

know how to come up with an idea

6:29

be weird , embrace the weirdness

6:31

.

6:32

Yeah , I mean , I like that Ruby is weird .

6:35

Absolutely .

6:35

That's a strength of the language and of the community

6:37

is that we're weird sometimes . So

6:40

let's talk about code and the code encoders who

6:42

code it . Because this show is really interesting

6:45

. You've got kind of a standard format . It

6:47

was the inspiration for the show .

6:51

I had tried blogging . That

6:53

didn't work out too well writing and writing

6:55

consistently , or not anything that I've been

6:57

terribly strong at in my life so

7:00

I didn't think that blogging was gonna

7:02

happen . I also didn't think

7:04

that there's a lot of time and effort that goes into

7:06

Chris's Go Rails videos , so I didn't think

7:09

I had the organizational skills

7:11

to do something like that . But I really wanted

7:13

a way to contribute , even

7:15

if it was in a not terribly meaningful

7:18

way , and this was just my own . I just wanted

7:20

something to give out , to give back

7:22

to the community , and I kind

7:25

of just thought about the idea of podcasting

7:27

because I had a ton of respect

7:29

for podcasters . Podcasts really

7:31

got me through the pandemic . I probably

7:34

would have lost my mind a lot more than I

7:36

did if I hadn't been able to go for a walk

7:38

and listen to other engineers talk . Like

7:40

I listened to a ton of the remote Ruby podcast

7:43

. I list a ton of the Ruby

7:45

on Rails podcast , jason Swett's podcast

7:47

. There were so many podcasts that really just kept

7:49

me from going a little stir crazy . Also

7:52

because no one in my family speaks code

7:54

, so just having someone saying it

7:56

just being a fly on the wall . So

7:59

I just was like well , maybe I'll give it a shot . I

8:01

like talking to people like I like

8:03

hearing their stories and hearing what they have to

8:05

say . So maybe if I just have a podcast

8:07

and I just ask a quick question and let them

8:09

talk for a half hour and then release

8:12

it , maybe other people will enjoy that as much

8:14

as I did . And yeah , that was

8:16

like how I decided to make

8:18

my contribution back to the community a

8:20

podcast .

8:21

Conversations are always so interesting because

8:23

you're asking the same three questions but

8:25

every episode is completely different because

8:28

the person you're talking to is like

8:30

working on something different or they've had a different blocker

8:32

or they share fun things . And sometimes

8:34

you have people who share things that are not even

8:36

the cool thing they share is not even code

8:38

related , and those are always really

8:40

fun too . So appreciate

8:42

kind of the standard format but like how

8:45

much variation there is from

8:47

guest to guest .

8:49

That's really for me in

8:51

a way and it ended up being like great for

8:53

the show . But that was really . I

8:55

need enough structure to not get lost

8:58

in my own show . I need enough structure to

9:00

offer something resembling a structure

9:02

to guests to set them at ease . But

9:04

I needed it to be open enough that we can have good

9:07

, meaningful conversations and I feel like unless

9:09

you're really type A , it's

9:11

hard to do that . It's hard to have a really

9:13

good , meaningful conversation when you've already planned

9:16

every single question out and every single answer

9:18

and things like that , Like some folks do

9:20

it incredibly well . I know that's not me

9:22

, so I was like I need structure

9:25

, but not so much of it . Let's do it

9:27

sort of stand up-y . And yeah , the last

9:29

question , the what's something new or interesting

9:31

doesn't have to be coding related is

9:34

my favorite question . I get such awesome

9:36

scope of responses to that .

9:38

I agree with you about structure , though , because what I try

9:40

to do since I've taken over the

9:42

show , what I've been trying to do is have a list of questions

9:45

that we're going to ask , but kind of follow

9:47

it but not follow it too closely and

9:49

piggyback off of stuff and sort of try

9:51

to find a casual sounding

9:53

conversation in the midst

9:56

of having a structure . So

9:58

I'm doing the same thing and I feel like it's worked

10:00

out pretty well so far and , yeah

10:02

, the conversation is always going in interesting directions

10:05

. Right , it's always fun to get to chat to people

10:07

. I think there's an element of it , too , where it's you know

10:09

, I resonated with what you said about having people

10:11

to talk to and having something in the community and

10:13

trying to find something in the community , because that's very much where

10:15

I was when Brittany asked me . But

10:18

there is like a selfishness to it too

10:20

. It's like I get to talk to really cool people

10:22

100% .

10:24

Yep , yeah , I've definitely had excuses to talk

10:26

to people that I don't think I would have gotten to

10:28

talk to otherwise , or at least talk

10:30

to them in the depth that I have

10:33

. So , yeah , there's definitely a selfishness

10:35

that comes along with the podcast

10:37

. It's like I want to talk to that person . Well , I have a

10:39

perfectly legitimate excuse to

10:41

talk to them now .

10:42

So , yeah , it kind

10:44

of gives you like legitimacy in a way

10:46

. You know , I'm walking up to like random people

10:48

at RubyConf last week just saying , hey , do you want

10:50

to do a quick three minute interview . It

10:53

kind of gives you legitimacy to sort of be like hey

10:55

, look , I don't want to just ask you one question after

10:57

your talk . I'd love to go really

10:59

deep on this for 30 minutes , and

11:01

having a podcast kind of gives

11:03

you a license to do that in a way .

11:06

Yeah , it's definitely one of the huge

11:08

benefits and the nice thing is

11:10

, I think a lot of podcasters

11:12

at least in this community , the

11:14

podcasters that I know we all recognize

11:17

that we're fortunate to have

11:19

that ability and then we use it mostly

11:21

for good . I don't think any of us has been like using

11:24

it for evil or anything , but we use

11:26

it to . A lot of the podcasts

11:28

have people who've never been on podcasts before

11:31

or who just gave a talk and was like

11:33

, hey , come on the show and let's talk about

11:35

more about this . I've never been on a podcast

11:37

before . Well , great , I have an avenue to

11:39

give you a voice . That's the

11:41

thing that I love the most about Ruby

11:44

for All Julie and Andrew's podcast . Like

11:46

they're super good at giving

11:48

people voices and Julie asks all

11:51

the questions that , like I've always

11:53

was too scared to ask and had to learn on

11:55

my own and it's a wonderful podcast

11:57

and I think that kind of it's

12:00

not that it's junior centric , it's just it's

12:02

great for early career devs

12:04

who have a lot of questions and might be feeling

12:06

like , oh , I can't ask them because I

12:08

listen to these podcasts and it's two senior engineers

12:11

talking about stuff that I don't even comprehend

12:13

the basics of . And then there's this podcast

12:16

where it's hey , let's talk about this , but

12:18

in a way that everyone , regardless

12:20

of where you are in your career journey , can

12:22

learn something from , and I love that podcast for

12:24

that .

12:25

Yeah , definitely . I also love that

12:27

podcast and I think it's very . It is an exceptionally

12:29

accessible show too , so

12:31

keep doing what you're doing , julie . We're

12:34

viewing Andrew shout out . Go subscribe to Ruby

12:36

for all .

12:37

Absolutely so . For those

12:39

who have you , who are unfamiliar with my

12:41

show maybe are coming from this , from

12:43

the Ruby on Rails podcast side , where

12:46

this is gonna work , cause I'm gonna ask at least three

12:48

questions . I'm gonna ask her what she's working on , what

12:50

kind of blockers she has . If she doesn't have

12:53

a current blocker , she can talk about a

12:55

recent blocker she had and how she

12:57

went about solving it . And then the last

12:59

question is what is something cool , new or interesting

13:01

that you've recently learned or discovered or

13:03

potentially even built ? It doesn't have

13:05

to be coding related , but , as the name

13:07

of the show gives away , it totally can

13:09

be coding related . It's kind of what we do

13:12

here . So let's get this party started

13:14

. Elise , what are you working on ?

13:17

Yes , that's a very good question . So obviously

13:19

I have the podcast and that's been

13:21

a big part of new things in my life . But

13:23

probably a more interesting thing to talk about

13:25

is that I've started putting together a

13:28

course on test driving rails

13:30

applications . So I've got the

13:32

first couple lessons done and I'm like working on

13:34

getting a few more episodes done before

13:36

I put that into

13:39

early access for folks to kind

13:41

of give early feedback on , and

13:43

yeah , so that's like the kind of big project that

13:45

I'm working on currently .

13:46

Very cool . So when you say test driving

13:49

a Rails app , do you mean TDDing

13:51

a Rails app , yeah , or getting okay cool .

13:54

Yeah . So the idea is that I get asked a

13:56

lot like I'm a big test driven development advocate

13:58

and I'm like big on testing and kind of testing

14:00

methodologies and how to think about testing . But

14:02

I often get a lot of questions from people

14:05

when I am talking to them about testing , about

14:07

sometimes I don't know how to start the test or

14:09

like how do you test this specific subset of things

14:11

that are complicated to test because it relies on

14:13

X , y and Z or whatever , and

14:16

I always have and like usually the answer

14:18

to those is like I have to talk about more

14:20

details of the situation to kind of help break

14:23

through it . But I've been consistently getting

14:25

series of the same types of questions

14:27

and the same types of topics came up over

14:29

and over again . There's clearly a gap

14:32

in education on this point because

14:34

like don't learn testing in school ? I mean , I didn't

14:36

learn it when I was in college . I didn't do

14:38

a boot camp but like most of the people that I've talked

14:41

to who've been in boot camps have said they covered

14:43

testing a little bit but they didn't really go deep

14:45

on what does test driven development look like . So

14:47

I kind of felt like there was a little bit of a gap here

14:50

for a course to be made to help

14:52

people walk through it . And then also

14:54

in testing a lot of the really interesting

14:56

test scenarios , like the

14:59

really interesting subject matter

15:01

where you want someone to like help

15:03

you learn , it is kind of difficult

15:05

unless you're working on something real Like

15:08

. A lot of test examples in conference

15:10

talks or in textbooks

15:12

even are kind of contrived

15:15

. So one thing that I've been trying to do

15:17

is picked a project to test drive

15:19

from beginning to end , so over the course of the whole

15:21

course . It's the same project

15:23

and the hope is that you

15:26

kind of started the beginning so you get an idea of like how do

15:28

you test drive when you have nothing ? But then I'm

15:30

hoping that by the end it's kind of more

15:32

like got X , y and Z feature

15:34

set and now I need to add feature A and

15:36

that interacts with features Y and Z and like

15:39

how do I test that and make sure I don't break anything ? So

15:41

that's kind of the goal . I've structured it sort of similar

15:44

to a lecture series . So I have the first

15:46

part of it is slides

15:49

about concepts , so we cover like the red

15:51

, green refactor cycle and then there's

15:53

like a demo and then there's like an exercise and

15:56

then I show you like potential solutions

15:58

to the exercise and then we move on to the

16:00

next lesson . So that's kind of the structure of it . But

16:02

yeah , it's been fun so far .

16:04

That is very cool and I agree

16:06

with you . I think there is a gap in that . I know

16:09

I did do a boot camp . I

16:11

did some programming in high school . There

16:13

was no TDD back in that . But

16:15

when I went to a boot camp to like actually

16:18

get into this as a career , we did

16:20

TDD in so far as like they would

16:22

give us tests and we would have to

16:24

write the code , the past tests , which is essentially

16:27

TDD . But like the biggest gap

16:29

that I had coming out of that was

16:31

like I didn't know how to write those tests

16:34

without code . Like I knew

16:36

what code would cause

16:38

these tests to pass and I knew what . If someone

16:40

gave me tests , I could write code to pass it . I couldn't

16:42

write a test unless there was code

16:44

and I would honestly kind of suspect

16:47

that I sort of can't do that . I can do

16:49

it better now , but I definitely

16:51

am . There's huge gaps in my knowledge

16:53

on doing proper TDD . So

16:56

that kind of course is interesting

16:58

to me , even at my level . I've been doing this for

17:00

years now and that stuff is

17:02

still good , so I think that's going to be

17:04

an awesome course and hugely beneficial to folks

17:07

.

17:07

Yeah , I think for me it's like interesting because

17:09

I have the opposite , where I kind

17:11

of get paralyzed if I don't write the test

17:13

first . At a previous job we had

17:15

these one-off scripts . This is funny . I told this , recorded

17:18

an episode with Julie for all while we were at RubyConf and

17:20

I told the same story about

17:22

how we'd run these one-off scripts , like

17:24

they would literally only ever run once

17:26

. But when I was

17:29

setting it up I was like I had to write tests

17:31

for it . And this is a situation where

17:33

, like I had multiple people ask me

17:35

like isn't it kind of a waste of time to TDD

17:37

this ? And I was like I don't even understand the problem

17:39

until I've written the test . Like I was like maybe

17:42

it is a waste of time , but like the tests

17:44

helped me understand the whole problem

17:46

and also give me like a checklist for solving

17:48

it . And so I have kind of the opposite , where

17:51

if I'm trying to do something without writing

17:53

the test first , I kind of get stuck

17:55

a little bit .

17:56

Right , right , and I can see that like

17:59

it's just a way to break down

18:01

the problem ahead of time . Right

18:03

, I think we all do that in whatever

18:05

our avenues are . We have to break

18:07

down a problem , and yours is . I

18:09

break it down via TDD , so in

18:12

a way , two birds with one stone you already have your tests now

18:14

. Eric Havillerson did a

18:16

lightning talk on a different methodology

18:18

of what it's called PDAC or something of

18:21

breaking down a problem , and it sounded

18:23

super similar to TDD . As

18:26

I'm sitting there , I'm just like this sounds like TDD

18:28

minus the actually physically writing

18:30

the tests . So I think it's maybe

18:33

confirmation of my suspicion that

18:35

like it's just an excellent way of

18:37

doing your problem breakdown

18:39

. But hey , this sounds like it and you're saying

18:41

, yeah , I have a blank canvas , I don't know . Tests

18:44

give me the structure to start doing

18:46

the work and that makes a lot of sense .

18:48

I feel it is kind of one of the real

18:51

big superpowers in coding

18:53

is like TDD , I think

18:55

. I look at the type of coding that I did before

18:57

and the type of coding that I do now and

18:59

I can move so much faster with tests At least

19:01

I can . I'm not super dogmatic about a

19:03

lot of things in code , but TDD

19:06

is one of the things where I just try as much

19:08

as possible to convince other people . I

19:11

think of it as a thinking tool more

19:13

than anything else . It helps me think through

19:15

the problem . Then , once I've

19:17

thought through the problem , it acts as a verification

19:19

that I haven't broken anything .

19:21

Right , absolutely .

19:24

Another argument that I usually make is that if you

19:26

have tests where you have a high

19:28

bar of confidence in them , you

19:30

don't really need to hold all

19:32

of your code in your head , because

19:34

the tests will do the verification for you . If

19:37

you have good tests and you trust them , you

19:39

can just wing it for most

19:41

of the development cycle , as

19:43

long as none of the other tests fail . You

19:46

can push to production at any time , right

19:48

, right , but getting to that confidence

19:51

is the key , or the tricky bit

19:53

.

19:53

Yeah , you said that doing TDD

19:56

speeds you up , do you

19:58

think it's sort of like that ? I'll just call

20:00

it the VIM paradox of when

20:02

you first start with VIM everything

20:04

is so much slower because you're learning

20:06

all these things . But once you know VIM

20:08

people who use VIM habitually are

20:11

super fast , moving through their

20:13

editor faster than I am with a mouse . Do

20:15

you think it's the same deal with TDD

20:18

, where it's like in the beginning you're

20:20

actually a little bit slower because you're still kind of thinking

20:22

through how to use the tools

20:25

at my disposal . And then , once I've got

20:27

those habits good habits in place , now

20:29

the speed up comes .

20:31

It's funny that you say that , because I am a VIM user

20:33

. So yeah

20:35

, I actually do think it . I think it's exactly like that

20:38

. I think Martin Fowler in

20:40

the Test Driven Development Book has like a graph

20:42

where he says like early on in a project

20:44

it is more expensive to start with tests , and

20:47

then later on in a project this

20:49

is going to be weird because it's an audio podcast , but the

20:51

line is like there's a crossover part and

20:53

then quickly they diverge

20:55

like very fast on the other side of that line and

20:58

he's like , until you get to the crossover point it

21:00

is faster to just write the code , but afterwards

21:02

it is unbelievably

21:04

slower . And I think that there's a part

21:06

of this where it's kind of the fastest thing for you

21:08

to be able to do is to do the

21:10

thing that you have a habit

21:12

of doing . So do you think in

21:15

a very similar way to VIM starting

21:17

out with TDD , if you're not used to testing

21:19

, if you don't have the skill level built

21:21

up and you haven't practiced it a lot , it can feel

21:24

like it's moving , like you're moving so slow

21:26

and you can kind of feel like I don't understand

21:28

why everyone wants to do this . It feels

21:31

like it's taking me forever . But at some

21:33

point you kind of get used to it . You've done it enough

21:35

, you are practiced enough at it . You've run into

21:37

enough awkward testing things

21:39

. Which I think is what really trips people up is that there's

21:42

not enough examples of weird testing

21:44

stuff when you're learning . So then you

21:46

reach a weird testing thing , but now you have to figure

21:48

out how to solve that thing . But once you've run into

21:50

a lot of those and you just have a lot of practice and you kind of

21:52

have internalized all that stuff , are

21:54

able to move faster , in the same way that

21:56

, like the day one you start using

21:59

VIM , nothing is gonna get done that

22:01

day , but by the end of the month you're

22:03

probably as proficient as

22:05

with your previous editor and another month

22:07

later you're so much faster than you

22:09

were before . So yeah , that was a good connection

22:11

.

22:12

I think that's a pretty big hurdle for a lot

22:14

of people is like telling them

22:16

hey , you have to go slow first

22:18

, you have to go slow to go fast . Slow is

22:20

for women's fast common saying . But there's

22:22

been more than a few times and I'm like I

22:25

should start using VIM . That's what all the cool kids

22:27

are using . I should use it . And I'm like

22:29

two days into learning VIM and I'm like

22:31

I just need to get shit done . So

22:33

what do you think if someone was to say

22:35

like , yeah , well , I just need to get stuff done . So

22:38

I can't stop and learn how to TDD

22:40

. I can't slow down to do TDD and

22:42

get used to it ? Like what would you say to someone

22:44

to convince them otherwise ?

22:47

So I think that there's a couple of things to consider

22:49

here . One of them is

22:51

you have to get stuff done and so you can't

22:53

slow down for TDD . Is that because

22:56

of a constraint that you are placing

22:58

on yourself , or is that an organizational constraint

23:00

? Or is that a code constraint ? And the way

23:02

that I like to think about this is like

23:04

one . It is gonna impact your

23:06

productivity in the beginning , and if that

23:08

is not a thing that your organization can afford

23:10

at the moment , if you're under a tight deadline

23:12

, if you're in the middle of an incident and you just need

23:15

to fix it and you can't , then clearly

23:17

do the thing you need to do to get done as quickly

23:20

as possible but hopefully you're not

23:22

in a situation where everything

23:24

is always get it done as fast as

23:26

possible and there is some room

23:28

and also just kind of understand

23:31

that like , yeah , it's gonna take a while , like anything that you do

23:33

, right , I love to cook and I

23:35

learn new cooking techniques , and the first couple

23:37

of times I make something new it's

23:39

awful , it's not good

23:41

, but then you get used to it

23:43

. Learn not to burn the rice

23:46

while I'm trying to whatever . But

23:48

it takes time and it takes practice and that is

23:50

part of the journey . And so I

23:52

would say one if you're really under the gun and you really

23:54

have a tight deadline and you're under a lot of pressure , maybe

23:57

don't worry about the test right now , but

23:59

then , when you have a little bit more breathing room , start

24:02

with a small area of something

24:04

that you're working on where , like , it's kind of bounded

24:06

and you can kind of feel

24:09

out the edges of it and it's

24:11

like gonna be not super expensive

24:13

to test , and then worry about the big

24:15

things . And then , if it's an organizational

24:17

thing , like your organization doesn't think there's time

24:19

for testing , the only thing

24:21

you can really do there is to lobby

24:24

leaders within the organization . The

24:26

thing that I've seen work most often in that

24:28

context is to tie

24:31

it to some quality metric

24:33

. So say , hey , we

24:35

have this area of code that's really hard to understand

24:37

and it's really complicated and there's no tests around

24:39

it and nobody wants to touch

24:41

it . Every time somebody touches it , that

24:44

feature takes twice as long as it should or

24:46

whatever right , twice as long as we expected

24:48

. And , especially if you've done the first part that

24:50

I just mentioned about , find a small area where

24:52

you can add some tests , if you can

24:54

show even the smallest amount

24:56

of quality or speed improvement as

24:58

a result of TDD , you

25:01

can usually get buy-in from

25:03

your leaders to do the more complicated one

25:05

, and then in that case , if there's something that is changing

25:07

a lot and it's super critical to the business

25:09

, you should be able to get leadership

25:12

buy-in on testing it . And if

25:14

you can't , then at some

25:16

point you kind of have to pick your battles , I guess .

25:17

But yeah , those are

25:19

good suggestions . I definitely

25:23

float on the man

25:25

. I wish I was better at TDD , because I

25:27

know a fair amount of people who TDD

25:29

and it makes a big difference . I

25:32

do write tests , like I

25:34

write the code and then I write the tests , and then

25:36

I run my test suite to make sure it and break anything , which

25:38

so I love having the tests . I'm 100%

25:41

with you , which is the writing the tests first

25:43

is not a skill that I have yet . So I

25:45

for one , will be checking out your course to try

25:48

and up those particular skills

25:50

that I feel like I'm lacking . So

25:52

what kind of blockers

25:55

do you have ? Now

25:57

, it doesn't have to be a blocker

25:59

on that course , it could just be blockers

26:02

in general , but I am also interested

26:04

in the idea of course

26:06

development . So if you do have

26:08

a blocker while building the course

26:10

or a recent one , that would be great to share , but any

26:12

blocker will do .

26:13

Yeah , I think a blocker that I'm running

26:16

into right now is there are

26:18

things that I know are awkward

26:20

to test and trying

26:22

to work those things into

26:24

the course and like finding good

26:26

ways to work them into the course . If you start

26:29

with TDD and you start the project , it's

26:31

kind of easy to have

26:33

the test just sort of evolve in the

26:35

correct way . But , like oftentimes

26:37

, the things that are tricky to test are

26:39

like oh , we designed this

26:41

thing and no one ever thought about using

26:43

it for this other thing . We designed

26:46

this billing thing but no one ever thought

26:48

that we might use it for single purchases

26:50

instead of just subscriptions , as an example or

26:52

whatever . And so what does that look

26:54

like and how do we make sure we don't break this other thing

26:56

? Those are the really interesting things . And

26:59

trying to shoehorn those

27:01

into the course and come up with

27:03

relevant examples . That's the thing that I struggle

27:06

through and I'm still struggling through . And then kind

27:09

of the way that I work through it is I just sort of stare

27:12

at the screen for a while and then

27:14

go for a run or a bike ride or whatever

27:16

I get on Zwift . But those are some

27:18

of the trickiest parts for me and this is the first

27:20

time I've ever put a course together too , so

27:23

there's like a part of me that's like trying

27:25

to balance . This is an interesting

27:27

testing scenario with . This is an accessible

27:30

thing for people who are not used

27:32

to testing or haven't learned a lot about testing

27:34

, like those are things that I'm like struggling with at

27:36

the moment , I think .

27:38

Have you reached out to anyone else

27:40

that does courses , or like just picked

27:42

brains of people who do those

27:45

types of content , whether it's video

27:47

or just lesson based ? Is

27:50

that a strategy that you're taking , or

27:52

?

27:52

Yeah . So our friend , you

27:55

actually work with Andrea . I've asked Andrea a

27:57

couple of questions about this , about , like , how

27:59

do you come up with a good example and how do you like

28:01

structure things ? Definitely talk to her

28:03

about it , manage to have a chat with Chris

28:05

a little bit at RubyConf , so I'm trying

28:07

to get advice from people who are kind

28:10

of doing content that's similar . That

28:12

actually has been pretty helpful , like I think that they've

28:14

given me a little bit of stuff to

28:16

think about in terms of how to structure it . I'm

28:18

working through it . It's good , and I take that advice and

28:20

I let it marinate in my brain a little

28:22

bit and then eventually I figured

28:25

out .

28:25

Usually , I think the course development

28:28

stuff is sounds like the end

28:30

result is so amazing . But the amount of

28:32

work that goes into it , I just feels

28:34

like it's so much work

28:36

because you're not just sitting there

28:38

and going hey , let me write a quick blog post

28:41

on X Not saying that blog posts don't

28:43

also take a ton of time and organization

28:45

and structure . But as we talked

28:47

about when we were like , hey , why do you ask the

28:49

three questions ? I do need that structure

28:51

, but I also perform better without it . Like

28:53

I like being able to free form things but

28:55

kind of can't do that with a course . So

28:58

it just sounds like a ton of work . And when you're

29:00

saying like I don't really know how to structure

29:02

this or how to shoehorn that , and I'm just like how do

29:04

you even solve that ? And that's why

29:06

I was asking like , is that something that you go to

29:08

other people for , or is

29:11

there a course on making courses ?

29:14

That's what I should do . I should make a

29:16

course about making you know what I should actually do . I

29:18

should blog about putting the course together . Yeah

29:21

, yeah , and that's what I should do . That's a good idea

29:23

. I want to go back to Vim . Yeah , yeah

29:25

.

29:25

Please do .

29:26

If you are interested in getting good at

29:28

Vim . The piece of advice that I typically give people

29:30

is are you using VS Code ? I'm

29:32

a okay , I tell people

29:34

, whatever editor you like , don't jump into

29:36

terminal Vim right away . Whatever editor you're

29:38

using , use the Vim plugin

29:41

for that editor . So VS Code has a very

29:43

decent Vim plugin . The benefit

29:45

of that is that if you do get into a time

29:48

crunch where you've got a ticket , that's you got to get it out the door

29:50

today , or it's a bug fix or in an incident or something

29:52

, you can turn it off and

29:54

you just have your normal environment and

29:56

it gives you a little bit of a safety net of you're

29:58

not stuck , so you

30:01

can turn it off and then you have your normal

30:03

environment and so if you have an emergency

30:05

you can get that stuff done and it gives

30:07

you kind of a safety net of like I don't

30:09

have to be perfect at Vim . Starting

30:11

out , which is like can be , it's very Vim is very intimidating

30:14

because , like you know , I've definitely been

30:16

in pairing sessions where I do

30:18

something and I don't even realize that , like the

30:20

person who's watching my screen , like

30:23

it just moves and people don't . They don't

30:25

know that I press four different keys to make

30:27

something happen , but a bunch of stuff changes on the screen

30:29

. And Try to get better at this , where

30:31

I try to explain Before

30:33

I do some operation . I'm gonna move this

30:35

down to here or I'm gonna change what's inside

30:37

these quotes , whatever . I try to get

30:39

better at explaining stuff , but it does

30:41

take a bit to get used to it . So if

30:44

you are interested in Vim , I highly recommend

30:46

use the plug-in for your editor

30:48

and then just turn it off when you

30:50

need to and then turn it back on when you're interested

30:52

.

30:53

I will have to give that a try . That sounds good . Yeah

30:55

, done that too , where I'm pairing with people who

30:58

work in Vim and I'm like we're using tuple

31:00

, it's great , you can go back and forth

31:02

really easily , and but if they're using

31:04

Vim I'm just like I know how to move back

31:06

and forth with a couple of keys , but

31:09

that's about . I can do a little bit of visual mode

31:11

stuff . I don't even know how to copy and

31:13

paste in it , so just I'm useless , you drive

31:15

. But it'd be nice to at the very least

31:18

be like have a baseline

31:20

with Vim where it's like cool , whatever editor

31:22

You're using , I can jump in and do

31:24

at least basic editing . I

31:26

feel like for most editors or most IDs

31:28

, I can do that . Vim is the one where it's just

31:30

like well , I know enough to get myself

31:32

into trouble . I know how to save an exit

31:35

, but that's the extent of my knowledge

31:37

.

31:38

It's so much different than

31:40

every other editor and I think that's the

31:42

thing . Like you don't have another example

31:44

of an editor or any , really any software

31:46

that works that way , and you really have to

31:48

Kind of train your brain a

31:50

little bit . And that's , you know , similar to TDD

31:53

. It takes , just takes practice .

31:54

Yeah , it was the original keyboard shortcuts , right

31:56

? Yep , for a while everything

31:59

was , there was no mouse , and then

32:01

we had a mouse and everyone used the mouse for everything

32:03

, including when the web was new . Like everyone

32:05

, it was just you use the mouse . You very rare

32:07

you touch the keyboard if you filled out a form . The

32:10

more and more we're seeing like websites

32:12

that are just like hey , here's your keyboard shortcuts

32:14

, keyboard commands to do this

32:17

stuff instead of having to touch your mouse , which is really

32:19

cool to see and it just makes me go man

32:21

, it does enhance my experience

32:24

on this website to be able to do all these keyboard commands

32:26

once I know them . In

32:28

my editor I do the same thing , but Vim

32:31

is like next level stuff . I don't even have

32:33

to take my hands off the keyboard . So

32:35

that could be cool . But , yeah

32:37

, learning curve . So the

32:39

last one , though , my favorite the

32:42

what is something cool , new or interesting

32:44

that you've learned , discovered , created , read

32:47

about . Anything doesn't have to be coding

32:49

related , it can be anything . What

32:51

do you got ?

32:53

One thing that I learned recently . I was

32:55

visiting some friends in Milwaukee and they

32:58

made this like rice dish

33:00

called kanji , and it's like

33:02

a Kind of like a rice oatmeal , so

33:05

it's like a breakfasty dish and I learned how to

33:07

make that and it's basically it's six parts

33:09

. Like normally when you're making rice it's like

33:12

two parts water to one part rice . This

33:14

is six parts water to one part rice gets

33:17

kind of creamy and it's kind of a savory

33:19

dish . You put like different things as

33:21

toppings on top of it , done like a poached

33:23

egg and shaved scallions and stuff . That's

33:26

kind of the newest sort of recipe that I've learned how to

33:28

make and I enjoy it because it's like kind

33:30

of easy and forgiving . It's kind of hard

33:32

to overcook it . If you're overcooking it , you just add

33:34

water and it'll get pretty good . So

33:37

that's kind of like the newest ish thing that

33:39

I've learned . That's like a big one .

33:41

This was a lot of fun . I like doing the

33:43

crossovers . It's a lot of fun , and I'm glad I

33:45

got you on my show at least a

33:47

condensed version because I wanted to

33:49

pick your brain a little bit .

33:51

So thanks for the invite and setting it all up

33:53

you've been listening to the

33:55

Ruby on Rails podcast and Code

33:57

and the coding coders who code it . Thanks to

34:00

Paul , our wonderful editor over at peach tree

34:02

sound , for making a sound like Professionals and

34:04

thank you for listening . You're a gem .

34:06

See you later .