0:05

It takes more than resolving deadlocked technical

0:08

disagreements by picking number three to be

0:10

a great software engineer. This is episode

0:12

four hundred and fifty two of the

0:14

soft skills engineering podcast where I am

0:17

your host James and Dance. I'm your

0:19

host Dave Smith. Soft scales engineering is

0:21

a weekly advice show about all the

0:24

non technical things that go into the

0:26

technical field of software development

0:28

like arbitrarily deciding to move

0:30

forward. I love it. It's like the Simpsons

0:33

movie. Yep. President Schwarzenegger.

0:35

Yeah. Optionsly. I

0:37

was elected to lead, not

0:39

to read. That's what you shout

0:41

as you arbitrarily decide.

0:44

Yes, that's leadership. Yeah,

0:46

yeah, it's not reading. That's true.

0:49

Dave, do you want to

0:51

thank our patrons? Yes, I

0:53

do. Big shout out to

0:56

those who contribute at the

0:58

just absolutely unhinged level that...

1:00

causes us to read whatever they

1:02

type in for their patron profile

1:05

name. They are Noah Labhart. It

1:07

takes more than a witty name

1:09

on Patreon to be a great

1:11

engineer. Do you really love us

1:14

or are we just means to

1:16

yacht? Can it be both? Alexander

1:18

Kuznitz of Chris Morton, Nick Molinu.

1:20

Attribute error non-type object has

1:23

no attribute to string, hobby or

1:25

consulus, chewy, Ted Timedrel. I quit

1:27

my job. It's 2025. Oh my

1:29

God, what have I done? Alexa,

1:32

Alexa, Alexa, Alexa, Alexa, Alexa, Turn

1:34

off all the lights. Become a

1:36

senior engineer.com is a newsletter. You

1:38

should read, Unsaulted French fries. You

1:41

should read, Unsulted French Fry's. I

1:43

turn off all the lights. Become

1:45

is a newsletter. Is a turn

1:48

off all the lights. Kyle Boss,

1:50

Kent, C. Dodds. Hold on a

1:52

second, I have to sneeze. Nevar is

1:54

not just a planet in the Vulcan

1:56

system, Jenny Kim. The stochastic parrot. Hellicone.i.

1:58

Best observability tool. for AI. Red Pandas,

2:01

Best Panda, Java is just discounted C-sharp

2:03

with worst documentation. Jonathan King's and I,

2:05

beautiful functional user documentation, Polish words that

2:08

are impossible to pronounce. Dang it, I

2:10

told myself I would learn to pronounce

2:12

these this week and I didn't. Skzbzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

2:14

Terskneen, I, that's probably wrong. Okay, williamangel.net

2:17

has cookies, please accept all cookies, we

2:19

process your data in the United States.

2:21

To opt out, go to ugla bugla,

2:24

not my chair, not my problem, that's

2:26

what I say. Braden Keynes, John Krant,

2:28

Brittany, Ellick, Joe Grossberg, wow, I really

2:31

botched the pronunciation of that one, sorry

2:33

about that, please write in and we'll

2:35

send you some stickers. Oh, I feel

2:37

called out. But also appreciate it. Simultaneously.

2:40

Are wonderful listeners. Yes. And we also

2:42

appreciate you. Thank you so much. Wow.

2:44

That was a great one. Great round.

2:47

Appreciate you. Dave. I want to tell

2:49

you about WorkOS, which is sponsoring this

2:51

episode. They have launched a ton of

2:53

new useful stuff that you should know

2:56

about, which we will tell you about

2:58

a bit later in the episode. Thank

3:00

you to WorkOS. Oh, sorry. Just randomly

3:03

inserting things here today. It's all good.

3:05

Randomly read our next question. I will.

3:07

This comes from an anonymous listener who

3:10

says, I've been a developer for about

3:12

1.5 years. I work for a large

3:14

consultancy. We provide services to big clients.

3:16

I'm working on a front-end code base

3:19

that has been through three consulting companies

3:21

already. Ugh. That sounds not fun. Okay.

3:23

Tired of just moving tickets and fixing

3:26

bugs, I decided to refactor the front

3:28

end of the entire application. Touching the

3:30

code base to add features gave me

3:33

a pit in my stomach. No integration

3:35

tests, no staging environment, huge functions with

3:37

tons of parameters, etc. The client provided

3:39

technical guidelines that were... pretty solid, but

3:42

the code just didn't follow them at

3:44

all. In the time left on the

3:46

contract, I refacted the code base to

3:49

fix the biggest problems to align with

3:51

the client's technical guidelines. I did all

3:53

this without my manager, product owner, product

3:55

manager asking me to. But now, how

3:58

do I communicate what I've done? Sounds

4:00

like, sounds vaguely guilty. Yeah, that's what

4:02

I was thinking. What have I done?

4:05

The next sentence is how do I

4:07

get recognition for it? And I was

4:09

thinking, oh, that's not where I thought

4:12

this was going. I have never worked

4:14

at a large consultancy. I have been

4:16

a consultant though. I don't think I

4:18

would have done this without some kind

4:21

of communication up front saying, look at

4:23

this awesome thing I'm going to do.

4:25

I have done, I mean, I've done

4:28

small refactors and just kind of the

4:30

normal cleanup that you do as you're

4:32

building stuff, but I haven't just said,

4:34

hey, I'm going to take these hours

4:37

that you're paying me for and use

4:39

them to completely overhaul the code base.

4:41

And I think it's hard to tell

4:44

them after the fact because what they

4:46

might think is, wait, what about all

4:48

the features that we wanted that we

4:51

didn't get because of all this time

4:53

that you took? I guess it depends

4:55

on the contract and... maybe you did

4:57

deliver all the things they asked for

5:00

and this was just sort of extra

5:02

that you added on, but if it

5:04

wasn't, if delivery of the stuff they

5:07

explicitly asked for slowed down, then you're

5:09

probably in trouble for getting credit for

5:11

this. Right. It's so tricky because there

5:14

are things that as a developer you

5:16

know are going to make the work

5:18

go faster and have fewer bugs in

5:20

the end. But sometimes it's really hard

5:23

to explain those things to the person

5:25

signing the check. And it's even harder

5:27

when it's a consulting relationship. I think,

5:30

yes, those incentives and that communication is

5:32

tricky when it's working for the same

5:34

business and you expect to have this

5:36

long relationship with the code base and

5:39

the people signing the checks. But often

5:41

consulting is like... explicitly like cowboy code

5:43

this thing out as fast as possible.

5:46

We just want you to crank out

5:48

these features and ship it and not

5:50

worry about tomorrow because tomorrow will be

5:53

another consultant. Right. Get in, get paid,

5:55

get out. Yeah. But I think what

5:57

you do have going for you is

5:59

these client technical guidelines. And I think

6:02

the way that you can pitch this

6:04

is if you have delivered all of

6:06

the features that they asked for. and

6:09

you're not behind on that, they're not

6:11

going to say, wait a minute, but

6:13

what about all this stuff you didn't

6:15

get to? Then I think you can

6:18

pitch it as I also kind of

6:20

went above and beyond to help follow

6:22

the technical guidelines to make sure that

6:25

the people who work on this code

6:27

base in the future will be better

6:29

off. So you should see benefits in

6:32

the future from this. That's kind of

6:34

like the classic pitch for it, but

6:36

I think you can say that and

6:38

explicitly point to the technical guidelines. There

6:41

is a risk you've been a a

6:43

year and a half, I feel like

6:45

that's still kind of the youthful exuberance

6:48

phase. And there's a risk that you've

6:50

been like blog post sniped into like,

6:52

I don't know, everything, you read a

6:54

blog post about reverse Polish notation and

6:57

just decided like, oh, that's good code.

6:59

That's what good code means. And you

7:01

just got really passionate about something that

7:04

doesn't actually make a huge difference in

7:06

the code base. So maybe get some

7:08

eyeballs from other more senior folks to

7:11

to kind of back you up on

7:13

this that you're not just like following

7:15

your preferred linting style or whatever, but

7:17

I think you can say basically I've

7:20

bought you future speed. You're welcome. Yeah,

7:22

like hey, I went above and beyond

7:24

and I got the project done on

7:27

time and in scope and under budget

7:29

and while I was in there, I

7:31

did a bunch of cleanup. So as

7:34

a result, we should see fewer bugs

7:36

in the deliverable. and long term our

7:38

next feature request will be able to

7:40

go faster. Yeah. Great. That's a good

7:43

internal message. Now, should you tell the

7:45

client? And I think there's a real

7:47

chance that you tell the client, hey,

7:50

we delivered everything and we made a

7:52

bunch of improvements as well, the client

7:54

might come back and say, I don't

7:56

want to pay for that part. Yeah.

7:59

I think that's what you, you, that's

8:01

what your manager gets paid for. You should tell

8:03

your manager this and leave it to them to

8:05

decide whether she communicated to the client. Or should

8:08

you give your manager the gift of plausible deniability?

8:10

Wait, what do you mean? Your manager is unaware

8:12

of this extra work that you did so they

8:14

can't be, they can't bring it up in a

8:16

meeting and it can never be a

8:18

question from the client of whether they

8:21

should pay for it. I will tell

8:23

you what you shouldn't do is you

8:25

shouldn't say, man, all these consultants that

8:27

touched this code base before were horrible.

8:29

They just made the dumbest decisions. They

8:31

totally screwed this thing up, but good

8:33

news, I have fixed it. Because they

8:36

have heard that so many times. The

8:38

developer who cried wolf. It is classic

8:40

to say, hey, everyone who touched this before

8:42

me was a moron. Yeah. But good

8:44

news. I, unlike everyone else that has

8:46

ever touched this code base. I am

8:48

not. And I did it right. And

8:50

the next person that touches code base

8:52

will surely not say, hey, everyone else

8:54

who touches is a morgue, but I

8:56

fixed it. I did it right. And

8:58

your client will say, you know, the

9:00

last two consultants said the same thing.

9:02

Yeah, exactly. Yeah, you kind of lose

9:04

credibility by saying that. Hmm. Well, have we

9:06

answered the question? I think so. And the

9:08

summary in my mind is that, yeah, it

9:10

would be great to take credit for this.

9:13

but only take the credit after you can show

9:15

the results. Like hey, remember those features we shipped

9:17

a few weeks ago? Well, that's thanks to a

9:19

little bit of cleanup work that I did while

9:21

I was in there. You know, hey, I was

9:23

already there, you know, I really don't think you

9:25

should pitch it as I spent a bunch of extra

9:27

hours. But rather, I did some cleanup, the codes

9:29

in a lot better shape now, notice how

9:31

there hasn't been bugs, and notice how we've

9:33

been able to deliver features faster, faster, well.

9:36

That was thanks to all that cleanup I

9:38

did. And it is it is a

9:40

good idea to take credit for that

9:42

and get recognition. And especially internally, but

9:44

probably not externally. I think

9:46

the client would just be like, what do

9:48

you mean you didn't clean it up? Like if

9:50

you, you know, it's like, would you say the

9:52

opposite? Like, hey, this code's a mess, but I

9:54

left it a mess. You know, probably not, right?

9:56

Yeah, so, yeah, I think that's what I think that's

9:58

what I would do. And they have added

10:01

some very useful stuff to their product.

10:03

Now, WorkOS is not just for adding

10:05

SSO to your app, it's so much

10:07

more. They've launched some cool stuff, and

10:10

we will tell you about it. WorkOS

10:12

lets you not reinvent permissioning with their

10:14

new fine-grained authorization system, which is based

10:16

on a Google system white paper thing

10:18

called Zanzibar. Very fun word to say.

10:21

I actually built some fine-grained off systems

10:23

myself and they had a way more

10:25

boring name. And also I had to

10:27

maintain all the code myself. Yes. Also

10:30

check out WorkOS's radar feature, which can

10:32

block bad signups from your app. So

10:34

things like bots, fraud, and impossible travel,

10:36

like someone using a VPN or proxy

10:38

to trick your sign-up system, they can

10:41

detect all of that for you and

10:43

help you avoid fraudulent sign-ups. They launched

10:45

an entitlements feature that integrates with stripes.

10:47

Your app can automatically give access to

10:50

accounts that have paid for new features.

10:52

I've also built one of these myself,

10:54

and it can be a huge pain

10:56

in the butt. So nice to put

10:58

that on someone else. Yes, totally. To

11:01

me, the coolest feature they launched is

11:03

a B2B app starter kit for NextJS.

11:05

WorkOS will actually help get your NextJS

11:07

app essentially from zero to one, super

11:10

fast. They provide authentication, billing, user management,

11:12

audit logs, and a ton more. And

11:14

I gotta say, if there's an easier

11:16

way to start a B2B SAS app

11:18

than WorkOS, I can't think of it.

11:21

Do not forget the passkey support. It's

11:23

effortless for you to add passkey support

11:25

and your users will love it. Check

11:27

out workos.com and try out all these

11:30

amazing new features. Shall I wish your

11:32

wit. Your command is my command. I

11:34

think that's how it goes. I think

11:36

that's right. A listener named Mike asks,

11:38

I've been in my role for about

11:41

a year and a half on a

11:43

dev team of seven. I really like

11:45

the job. It has a good culture

11:47

and I'm learning. Sometimes I channel my

11:50

desire to learn into improving our projects

11:52

with small self-directed changes on my own

11:54

time. These changes are useful. but aren't

11:56

high enough in priority to make it

11:59

into planned sprint work. I don't inundate

12:01

the team with these requests. It happens

12:03

maybe one to two times a month.

12:05

We make a point of working in

12:07

small steps, usually submitting several PRs per

12:10

day per person. I really like this

12:12

approach, and I also keep my occasional

12:14

self-directed bits of work small in scale.

12:16

However, I have noticed these PRs receive

12:19

more scrutiny and more whataboutism than our

12:21

regular on-the-books PRs. For example, for regular

12:23

sprint tickets, there's an understanding that we're

12:25

making progressive improvements or building small pieces

12:27

of features that exist within the constraints

12:30

of our systems. We might flag broader

12:32

improvements to consider, but there's no expectation

12:34

to re-boil the ocean every time we

12:36

want to merge code. When I'm submitting

12:39

a self-initiated piece of work, there can

12:41

be a long back and forth of

12:43

suggestions that can involve changing other dependent

12:45

code, changing internal APIs which may have

12:47

side effects and generally a level of

12:50

defensiveness in the code that we would

12:52

not normally expect. I understand that by

12:54

submitting off-the-books I'm requiring some work time

12:56

from reviewers, but there is still more

12:59

pushback than I'd expect. It feels like,

13:01

because I get the ball rolling on

13:03

my own time, the normal cost-benefit constraints

13:05

go out the window and the code

13:07

purists come out to play. Could I

13:10

be annoying the team with these submissions?

13:12

Have you experienced team members doing the

13:14

same thing? Is there a way I

13:16

can scratch my own itch by learning

13:19

against our systems without creating this resistance?

13:21

Hmm. I got distracted looking up, what

13:23

aboutism? You have a definition? Yeah, well

13:25

I have a Wikipedia page, that's authoritative,

13:27

right? Yeah. It's what aboutism or what

13:30

aboutery? Which I kind of like. I

13:32

have not heard that one. I kind

13:34

of like that one better. I like

13:36

that one better too. It sounds like

13:39

Tom Foolery. Yeah, exactly. So good. What

13:41

aboutism is the strategy of responding to

13:43

an accusation with a counter accusation instead

13:45

of a defense against the original accusation.

13:47

That's not how I've heard this term

13:50

used in argumentation in the past, which

13:52

leads me to believe that the people

13:54

I've been arguing with don't know. What

13:56

this means, or at least don't agree

13:59

with Wikipedia. Yeah, I thought that this

14:01

applied pretty well to this situation

14:03

and I guess it doesn't according

14:05

to the Wikipedia definition. Okay, so

14:07

what did you think it meant?

14:09

What I thought it meant in this

14:11

situation is you submit a PR, maybe

14:13

it moves a line of code, it

14:15

doesn't change the line of code, it

14:17

doesn't change any of the dependencies. Okay.

14:19

But because you touched it, all of

14:21

a sudden it's like, wait. This line of

14:24

code that you have touched is wrong and

14:26

needs to be changed. And you're like, it's

14:28

not the scope of what I'm working on.

14:30

Or doesn't follow some convention or something? Yeah,

14:33

like, yes, I changed the indentation because I

14:35

surrounded it in an if statement now,

14:37

but I don't want to rewrite all of

14:39

the code that is related. Yes. Because I

14:42

don't want to rewrite the whole code

14:44

base just to make this one change. But

14:46

maybe they mean it more literally and

14:48

it's like in these back and forth discussions

14:50

of feedback on the PR and then what

14:52

about is it? What about a battery? They

14:55

say, well, I think that's out of scope

14:57

and then they bring up the insults

14:59

that you made to their heritage

15:01

that one time or I don't know.

15:03

Interesting. So is that the situation you

15:06

think that's going on here is that

15:08

there's there are incidental code

15:10

changes that show up in the diff.

15:12

but aren't actually the substance of what

15:14

the author is submitting the change for?

15:16

Yeah, I think that's part of it.

15:18

I mean, the situation the author describes

15:20

is their off-the-books changes are

15:23

held to a much different standard

15:25

than the regular sprint work. Yeah,

15:27

and so there's an understanding in

15:29

the regular sprint work that this

15:31

is iterative and this will be

15:33

improved and tweaked in the future,

15:35

and it sounds like everything must

15:37

be perfect for these kind of

15:39

off-the-the-books changes. Yeah, why, have you

15:41

experienced this? I'm not sure that

15:43

I have. I have experienced it.

15:45

Not this same style of like,

15:47

well, I'm doing kind of side,

15:49

side work work, it's still work, but

15:51

I have experienced this vibe

15:53

of like, I am not going to

15:56

rewrite this giant abstraction just because I

15:58

added a line to it. it. Yeah.

16:00

But the person is asking me to.

16:02

Right. You're like, no. Yeah. I haven't

16:05

experienced it consistently from the same person

16:07

though. So my in my experience, this

16:09

has usually been someone who's doing a

16:11

distracted code review. They're not taking the

16:13

time to dive super deep into it.

16:16

And they see a line and it's

16:18

green and and and they just look

16:20

the line and say, ah, that line

16:22

looks wrong. It should actually look like

16:25

this, but they haven't. rocked the change

16:27

enough to understand wait that line is

16:29

just moved around. It's not like you

16:31

wrote that line. Yeah, and then I

16:33

guess the extra element here in this

16:36

question is because this stuff is submitted

16:38

outside the normal work process, I wonder

16:40

if there's a perception that they have

16:42

more time and they can do more

16:44

scrutiny. Whereas if it's part of a

16:47

sprint, it's like, oh look, we do

16:49

one week sprints and we all know

16:51

we're under the gun and no one

16:53

wants to be the reviewer that holds

16:56

up a sprint deliverable and then causes

16:58

the team to miss their commitment for

17:00

the week or something like that. Yeah,

17:02

maybe they're super intense about sprints and

17:04

you have a deadline every week, which

17:07

sounds not fun, but exists. I have

17:09

been on the other side of an

17:11

engineer who would regularly throw in. pretty

17:13

sizable extracurricular changes that were not related

17:16

to the business-facing work that the team

17:18

was doing. I actually told them, please

17:20

stop. And the reason I told them

17:22

to stop was explicitly because it took

17:24

time away from the team to review

17:27

this stuff. They had to context which

17:29

sometimes the changes were pretty broad to

17:31

like underlying tooling. It wasn't ever like

17:33

I added this feature or whatever that

17:35

the customer asked for it just out

17:38

of order. It was like... I'm changing

17:40

this underlying technical developer system that we

17:42

use. And I said, please do not

17:44

do that anymore. Exposedly for this reason

17:47

that it was distracting the team and

17:49

slowing down our normal work. Interestingly enough,

17:51

I am a hypocrite because sometimes I

17:53

do that to my team, but... But

17:55

by doing that I mean, sometimes I

17:58

submit PRs like that and distract them.

18:00

But it's okay because it's me doing

18:02

it now. So my point is, could

18:04

I be annoying the team with these

18:07

submissions? I think yes, it could be

18:09

that they are frustrated by trying to

18:11

get all their sprint stuff done and

18:13

also now they have this extra stuff

18:15

to review. And they are not clearly

18:18

communicating that and that frustration is coming

18:20

out in really very persnickety PR reviews.

18:22

You should ask them. You should say,

18:24

hey, I want to learn. I want

18:26

to do stuff. I feel like a

18:29

good way to do that is poke

18:31

around and make these improvements. I do

18:33

it on my own time outside of

18:35

work. I'm not missing work time. But

18:38

like, does this bother you? Are you

18:40

concerned with the way I'm doing this?

18:42

I think you could just directly ask

18:44

that question. Yeah, and I think that's

18:46

probably a very likely explanation for what's

18:49

happening here. Maybe even subconsciously people, people

18:51

are like, like, like, like, be with

18:53

us on the team and why can't

18:55

you carve out actual sprint time to

18:58

do these things if it's so important?

19:00

And now you're taking away from my

19:02

sprint time to do these reviews and

19:04

to subconsciously they're doing anything they can

19:06

to punt your PR. Yeah, they're just

19:09

a little grumpier when reviewing it. Yeah,

19:11

I think you also hit on a

19:13

good potential solution, which is if you

19:15

want to learn and you're passionate about

19:17

improving stuff, I don't know. But you

19:20

could advocate for either specific targeted improvements

19:22

to be made in the sprint or

19:24

just to say like, hey I want

19:26

a teeny bit of capacity also to

19:29

do some of these improvements to learn.

19:31

And the point of putting them in

19:33

the sprint is it prioritizes them against

19:35

other things that are typically more business

19:37

facing. And it's not that they don't

19:40

have value if they're not business facing.

19:42

but it's easier to articulate the value

19:44

of a new feature to the business

19:46

than the value of like I tweak

19:49

this underlying abstraction. Yeah. And so you

19:51

might have to do a little bit

19:53

more work to justify it up front.

19:55

Yeah, makes sense. Or you could just

19:57

go all. Right, they say change this

20:00

underlying abstraction. You say, okay, no problem.

20:02

And then you go off and, yep,

20:04

10,000 lines later. That feels like a

20:06

doom cycle though. It's like you come

20:08

back and they're like, okay, thanks. Now

20:11

do this other impossible task. Yeah. You

20:13

must cut down the largest tree in

20:15

the forest with a heading. Yeah. If

20:17

you like the team, it's got a

20:20

good culture. I feel like you should

20:22

be able to ask what's going on.

20:24

fairly openly and discuss it. And it

20:26

might lead to, I think I agree

20:28

with you, Dave, that it could be

20:31

subconscious on the part of your teammates,

20:33

that it might not be them directly

20:35

saying, aha, out of sprint work, I

20:37

will now put on my, my pendant

20:40

hat, my pendant pendant, pendant, pedantic pendant.

20:42

Yeah, the pendant, the pendant, the pendant

20:44

of pedantry. Yes, that one, that one.

20:46

That's a great one. We need to

20:48

get some of those. So maybe talking

20:51

about it helps them realize this and

20:53

then it brings it out in the

20:55

open. Yeah, that's probably better all around.

20:57

I had a developer on my team

20:59

last year who said, hey, I'm really

21:02

interested in getting more familiar with a

21:04

specific set of technologies and I've noticed

21:06

we have a big pile of tech

21:08

debt that we keep not getting to.

21:11

Can I volunteer to work overtime? and

21:13

for my own benefit and also for

21:15

extra pay to develop these skills and

21:17

burn down this tech debt list. And

21:19

I was like, yeah, that sounds awesome.

21:22

So we just created a really simple

21:24

tracking system, little document, you know, created

21:26

tickets in our normal sprint that this

21:28

person could work on and we communicated

21:31

it with the team. Everything was above

21:33

board and we got a ton of

21:35

value out of it and it was

21:37

really, really lovely and everyone is happy

21:39

with it. Now if that person had

21:42

just... like blindsided my team with like

21:44

hey I want to move this service

21:46

from EC2 over to a serverless architecture

21:48

and look I did it and here's

21:50

the PR I think everyone would be

21:53

frustrated, including me. Yeah. Because I would

21:55

have thought, you know, as the leader

21:57

of the team, it's one of my

21:59

jobs is resource allocation and time allocation.

22:02

Like, what are we going to spend

22:04

time on? And when you take that

22:06

opportunity away from me by just choosing

22:08

unilaterally to spend your time on something

22:10

that I didn't even think about, it's

22:13

not good. Like everyone's, everyone's frustrated with

22:15

that. And so it's like the same

22:17

actions with a little bit of preamble,

22:19

make for great outcomes, as opposed to

22:22

doing those actions without the preamble, and

22:24

then everyone's mad at you. Well said.

22:26

You just liked it because I said

22:28

the word preamble. Always a fun one.

22:30

I actually have a preamble pendant. Ah,

22:33

you've got all manner of pendants. Yes,

22:35

you might say I have a plethora.

22:37

All right, have we answered this question?

22:39

I think so. Good luck. Good luck,

22:41

Mike. It sounds like you are well-meaning

22:44

and you've got a good team. So

22:46

I think it'll turn out all right.

22:48

Yeah. And good luck with all the

22:50

refactoring. That's always fun. for you. Some

22:53

day you'll learn to hate refactoring. But

22:55

today is not that day. Yeah, other

22:57

people's refactors are your nightmares. Refactoring is

22:59

like when you want, there's that thing

23:01

you want to buy and you really

23:04

work it up in your mind and

23:06

then you save your money and you

23:08

plan and then you buy it and

23:10

you realize that wanting the thing felt

23:13

better than having the thing. You ever

23:15

had that experience? Yeah, the anticipation is

23:17

great. the hedonic treadmill is real for

23:19

code quality also I guess. I promise

23:21

I'm not going to say this spend

23:24

much more time on this but it

23:26

is the case for me that every

23:28

time I've embarked on a major refactor

23:30

I look at the code and I

23:32

just think this is going to be

23:35

so nice when it's all cleaned up

23:37

and then I do all the cleanup

23:39

and I'm like I feel the same.

23:41

Like it's just. Yes the code is

23:44

cleaned up. But I just don't get

23:46

this like amazing sense of accomplishment. I'm

23:48

like, ugh. I thought that by changing

23:50

the code I would change myself. Alas.

23:52

Unless I. just didn't

23:55

change the code the

23:57

right way. Surely

23:59

this next time I

24:01

will change myself

24:04

by changing the code.

24:07

But if you do the refactor together,

24:09

then at least you make friends

24:11

along the way. Yeah, fair enough. And

24:13

that's the real valuable thing. And

24:15

that does change you, making friends. You

24:17

know what else changes you? Asking

24:19

questions of the Soft Skills Engineering Podcast.

24:21

How can people do this? Go

24:24

to softskills .audio and click the ask

24:26

a question button where you can fill

24:28

out our form. Our form that faithfully

24:31

serves us and has for many years,

24:33

we thank you, one and all, who

24:35

have contributed questions to that lovely form

24:37

that have gone into our backlog, whose

24:39

depth is proportional to my self -worth.

24:41

So thank you for making it bigger.

24:45

I really appreciate it. I do

24:47

too. I appreciate you increasing Dave's

24:49

self -worth. My sense of self -worth

24:51

is proportional to Dave's sense of

24:53

self -worth, so. With like a 1

24:55

.3 multiplier on it. Yeah, yeah,

24:57

so I'm doing even better. Thank

24:59

you all. Thank you for listening.

25:01

We will catch you next week. Yeah.

25:08

Yeah. better.