I would like to amplify Avi's comment below.
I have noticed something when programmers try to practise TDD: they don't seem to learn how to refactor. I don't mean to state this so harshly, but it seems that they struggle a lot more with refactoring than I did when I started. I have this feeling that "we" learned relatively quickly compared to what I see, even comparing myself programming in Java in 1999-2002 to today's programmer also working with Java. And today's Java programmers have better libraries and better tools! They use IDEA and Vavr, but I had Eclipse and plain Java. :)
I'd like to know your impressions. Which kinds of problems do people have when they try to learn how to refactor? When they learn how to guide a design to evolve? Why does it seem like they have more difficulty learning this than "we" had?
I admit that I probably have some strong cognitive distortion. That's why I'm asking this question.
Cheers,
--
J. B. (Joe) Rainsberger :: :: ::
---------- Forwarded message ---------
From: *Avi Kessner* <akessner@... <mailto:akessner@...>>
Date: Thu, Nov 14, 2019 at 5:05 AM
Subject: Re: [testdrivendevelopment] We are back on the air!
To: <[email protected] <mailto:[email protected]>>
Is this the diagram you wanted to share?

I would recommend making a box which is part of the flow rather than some external dotted lines. For example, maybe the box should read, " Apply SOLID principles" as part of the refactoring, and then before the next failing test have something like, "design the contract"
I think the community needs more explicit direction on the design being done in those phases.
On Wed, Nov 13, 2019, 16:44 J. B. Rainsberger <jbrains762@... <mailto:jbrains762@...>> wrote:
On Tue, Nov 12, 2019 at 11:27 AM Roy Osherove <roy@...
<mailto:roy@...>> wrote:
Awesome.? I sent a new thread to the group about tdd diagrams. Was it received?
Maybe.
If you sent it to the Yahoo! group, then no.
Please try again--at least until we figure out the transition. :) I
want to see it!
--
J. B. (Joe) Rainsberger :: ::
::

On Nov 24, 2019, at 4:00 PM, Samuel ]slund <samuel@...> wrote:

?Hi all,

Spontaneously I would guess there is a difference in experience between us trying to learn TDD with 5-10 years or more of programming experience and loads of examples of why it was necessary, compared to people learning it today that (I hope) learn it earlier since TDD is not really new any more. I would also guess/hope that TDD now reach a broader range of people than those actively searching for ways to improve.

Regards,
//Samuel

On Nov 24, 2019, at 17:14, Hassan Schroeder <hassan.schroeder@...> wrote:

?On Sun, Nov 24, 2019 at 1:40 PM Charles Gallo <Charlie@...> wrote:

Place after place I’ve been in has a small to mid sized collection of tests, that are either not maintained, not run, or not added to, and when you do start adding, management complains.
I’ve never been to a place that does more than pay lip service

Ouch, that sucks. I'm part of a smallish team, but we deploy via CI/CD
and if any of the test suite, code coverage minimum, linter, or typespec
checker fails, it doesn't go out.

We reject PRs for not having adequate tests, and recognize people
for expanding coverage of existing code.

My condolences on your past employment situations :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@...
twitter: @hassan
Consulting Availability : Silicon Valley or remote

On Nov 24, 2019, at 19:48, Steven Smith via Groups.Io <ssmith.lists@...> wrote:

?I yeah refactoring a lot, and I think practice helps (shocking, I know). I include it in my workshops as well as in free resources on my github (). I also have three different Pluralsight courses on refactoring, including the monster 8 hour course Refactoring Fundamentals. Anyone can access these with a trial account and most enterprise shops I talk to have subscriptions for their folks.

But to JB’s point, I do think it’s a part of TDD that newer devs lack confidence and probably skill to perform, at least until they gain experience with it.

Steve

On Nov 24, 2019, at 17:14, Hassan Schroeder <hassan.schroeder@...> wrote:

?On Sun, Nov 24, 2019 at 1:40 PM Charles Gallo <Charlie@...> wrote:

Place after place I’ve been in has a small to mid sized collection of tests, that are either not maintained, not run, or not added to, and when you do start adding, management complains.
I’ve never been to a place that does more than pay lip service

Ouch, that sucks. I'm part of a smallish team, but we deploy via CI/CD
and if any of the test suite, code coverage minimum, linter, or typespec
checker fails, it doesn't go out.

We reject PRs for not having adequate tests, and recognize people
for expanding coverage of existing code.

My condolences on your past employment situations :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@...
twitter: @hassan
Consulting Availability : Silicon Valley or remote

On Nov 24, 2019, at 7:49 PM, Steven Smith <ssmith.lists@...> wrote:

?I yeah refactoring a lot, and I think practice helps (shocking, I know). I include it in my workshops as well as in free resources on my github (). I also have three different Pluralsight courses on refactoring, including the monster 8 hour course Refactoring Fundamentals. Anyone can access these with a trial account and most enterprise shops I talk to have subscriptions for their folks.

But to JB’s point, I do think it’s a part of TDD that newer devs lack confidence and probably skill to perform, at least until they gain experience with it.

Steve

On Nov 24, 2019, at 17:14, Hassan Schroeder <hassan.schroeder@...> wrote:

?On Sun, Nov 24, 2019 at 1:40 PM Charles Gallo <Charlie@...> wrote:

Place after place I’ve been in has a small to mid sized collection of tests, that are either not maintained, not run, or not added to, and when you do start adding, management complains.
I’ve never been to a place that does more than pay lip service

Ouch, that sucks. I'm part of a smallish team, but we deploy via CI/CD
and if any of the test suite, code coverage minimum, linter, or typespec
checker fails, it doesn't go out.

We reject PRs for not having adequate tests, and recognize people
for expanding coverage of existing code.

My condolences on your past employment situations :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@...
twitter: @hassan
Consulting Availability : Silicon Valley or remote

Autocorrect: yeah->teach

On Nov 24, 2019, at 19:48, Steven Smith via Groups.Io <ssmith.lists@...> wrote:
?I yeah refactoring a lot, and I think practice helps (shocking, I know). I include it in my workshops as well as in free resources on my github (). I also have three different Pluralsight courses on refactoring, including the monster 8 hour course Refactoring Fundamentals. Anyone can access these with a trial account and most enterprise shops I talk to have subscriptions for their folks.
But to JB’s point, I do think it’s a part of TDD that newer devs lack confidence and probably skill to perform, at least until they gain experience with it.
Steve

On Nov 25, 2019, at 8:06 AM, Jeanne Petrangelo <jeanne@...> wrote:

?

“How do you mentor 20 somethings when they won't READ, even short stuff”

I have a 19yo son going to college for software engineering, and he doesn’t like to read. He prefers videos. It is frustrating. We tried pointing out that vast swaths of information in the world is written down and if he doesn’t learn to ingest information that way, then he’s cutting himself off from that info. Reasoning hadn’t motivated him enough; it’s too abstract. But you have a specific case. Do you get the sense these 20 somethings want to learn, or are they happy enough with the way things are? Maybe starting with goal setting so they understand “why” and what’s in it for them, first?

On Mon, Nov 25, 2019 at 1:03 AM Charles Gallo <Charlie@...> wrote:

Steve (et al)
So here is the real question I have
I've gotten older, and it seems out of touch with a lot of the younger
developers

I was brought in to mentor them on this stuff, refactoring, TDD etc (and
of course get out code, setup CD/CI etc etc - of course all at the same
time ASAP)

How do you mentor 20 somethings when they won't READ, even short stuff

I tried to get them interested in "Brownfield Development" - Or
Feathers, etc - and even when you hand them something as small as a
partial chapter, or a simple write-up, you get blown off that they don't
read (and this is management, as well as the Jr developers)

I've noticed at the last couple of places.? One place - Give them the
basic instructions for GIT/TortoiseGIT, no one can be bothered to read
it, and one culprit (the CEO no less) would cowboy code, have it on his
PC, not in any source control, and yell when you can't get things to
work (the only semi working copy of the web site source was on his
laptop)

I don't understand how to get through to these folks anymore

Trying to get them to understand WHY you TDD - Why you can't get CI/CD
setup on a legacy project in a week (all manual builds off a developers
PC, with no tests run, even though there were tests)



On 2019-11-24 19:49, Steven Smith wrote:
> Autocorrect: yeah->teach
>
>
>> On Nov 24, 2019, at 19:48, Steven Smith via Groups.Io
>> <ssmith.lists=[email protected]> wrote:
>>
>> ?I yeah refactoring a lot, and I think practice helps (shocking, I
>> know). I include it in my workshops as well as in free resources on my
>> github (). I also have three
>> different Pluralsight courses on refactoring, including the monster 8
>> hour course Refactoring Fundamentals. Anyone can access these with a
>> trial account and most enterprise shops I talk to have subscriptions
>> for their folks.
>>
>> But to JB’s point, I do think it’s a part of TDD that newer devs lack
>> confidence and probably skill to perform, at least until they gain
>> experience with it.
>>
>> Steve

On Nov 25, 2019, at 11:11 AM, Charlie Poole <charliepoole@...> wrote:

?Hi Frank,

Interesting thoughts. I have noticed the problem but thought it might
just be my own attitudes as I get older!

As I think about it, folks of my generation had to climb a very steep
learning curve just to write our first programs. I learned about
refactoring back in the 90s, by which time it seemed like a way to
make my work easier, not harder. The same was true for all the XP
practices at the time... but times have changed.

One thought on teaching this stuff... use at least some commonly
reversible refactorings. For example... convert to method vs convert
call to inline code. I talk about "forces" in this context, in the
same way I teach architectural patterns. In different contexts, the
forces want to resolve in different ways. When I make __choosing__ the
refactoring seem more intellectually challenging than doing it ('cause
it is!) I find that at least some folks start paying attention.

Another think I believe strongly is that folks should learn
refactoring first __without__ tooling to do it for them. Once they do
a few of them by hand, particularly if they are wide-ranging in the
code, they end up with a better understanding about what the tool
needs to do. This also gives the opportunity to talk about how the
presence of tooling changes the balance of the above forces. They also
need to learn about the danger of limiting oneself to only those
refactorings supported by the IDE.

Charlie

On Mon, Nov 25, 2019 at 1:59 AM Frank Carver via Groups.Io
<frank.carver@...> wrote:

I teach programming at the local university and have found that one of the biggest mental blocks which students need to overcome is the assumption that there is only one way to solve any problem, and that the job of a programmer is to find that way.

This mindset makes it really hard to teach refactoring, particularly in the context of eager new practitioners of TDD who want to rush on to the next test as soon as the first one passes.

I'm not sure where this attitude comes from. Perhaps the way that programming and/or software development has been reframed as "coding", and the implications of the name, or maybe that first experiences in the field often come from poking at HTML and CSS with a stick to get something that looks right, and then copy/pasting a bit of Javascript or PHP to make something happen, or perhaps the prevalence of fill-in-the blanks frameworks, or perhaps that so many students prefer to learn by following a linear set of steps from YouTube, Who knows

I'd love to investigate this in more detail, as I too, can see how much new developers struggle with the concept and skills of refactoring.

If it helps, I have found that I get slightly better traction if I lead with the idea of "code smells."

Frank Carver