Improve demonstration of use in modularity

[pshriwise]

@kkiesling

While I think we both know it makes sense to calculate the flux in its own function, I don't think the example we're providing drives home a couple of the key points which motivate that for new programmers. In particular we don't really demonstrate:

• saving lines of code
• correcting an implementation in one place vs in 20 different places in the code

we can certainly talk about these things, but I feel from a learner's perspective that experiencing those things would be more powerful.

I'm going to think about this a bit and try to figure out how we might modify the demo to incorporate those points. Any thoughts?

[pshriwise]

thought: maybe we drop the negative sign when creating the function the first time? And demonstrate that the fix will apply to all subsequent calls of the function. That could be done during the lesson. No changes to the checkpoints necessary I don't think.

[kkiesling]

To the point about knowing why we put the calculation of flux into its own function: that action does really cover two points that I often think of when I make funcitons:

1. modularity (taking some discrete action that can be named and separated and taking it out to make it its own thing to use later if needed)
2. repetition (repeated similar actions)

I think that # 2 shown through the lesson and is probably the reason most new developers will recognize first. For # 1, this may be more difficult to show, but I think it certainly something we can talk about with them even pertaining to this situation despite the motivation being presented as repetition.

Regarding saving lines of code - I am not sure exactly what you mean by that and how we want to demonstrate it.

I like your proposed idea of intentionally making the mistake in the code and only needing to change it one time. I think when we do that with the function it will help motivate the use of functions.