My thoughts on the lesson

[rkdarst]

I promised to give my thoughts, but may not be available in person. So here they are. I think #14 (functions, abstraction layers, packages) is still relevant and I'm surprised that there's still code there (I thought I hadn't done anything...)

My list of easiest things to do, that everyone should do (I'd empasize 3-4 to emphasize):

• [ ] Keep in mind: if you copy and paste something more than three times, try to find a way to avoid copying and pasting. Before that, maybe not worth it.
• [ ] If it's not a trivial script, at least separate your (input/data loading functions) from (analysis functions) from (output functions)
• [ ] Learn how to make (simple) modules/packages early on, put well-used common stuff there. (this could be replaced with a more important lesson)
• [ ] I wanted to add "make functions simple and without side-effects", but #21 is a good point.

Thoughts on slides:

• [ ] another initial question after slide 3: which is better: - slightly faster code - much more readable code with fewer bugs (quote: premature optimization is the root of all evil, or whatever the quote is).

• [ ] slide 4 could use caption and possibly even the same dark background as first slide, to emphasize it's also "food for thought". A slide title might help to make it immediately under stable. Maybe also pose a question like slide 3: which is better, properly implemented (slower right now), quick hacks (do it now). combined with above, first three slides are three main points.

• [ ] slide 5 sounds rather abstract but the message is important. can it relate more to researcher: "A does something fast because their advisor wants things right now. But then, they are never able to get ahead because they are constantly having to re-do what they did before. ..."

• [ ] before slide 6 or 7: quick mention that these are well known problems, but there are strategies to make the problems less bad. You learn them in theoretical software development classes, but the simplest lessons are easy and relevant to you too. Rest of talk is giving you some simple and not so simple ideas to try. Acknowledge that it's a tall order to fix them in research, because research is about the output, not the code.

• [ ] is the Zen of Python mentioned anywhere? They aren't all about modularity but it fits the theme.

• [ ] The times I force myself to design on paper before coding, I am much happier with my code.

• [ ] Use good libraries when they exist. Maybe this should be mentioned in social coding...

• [ ] do you build top-down or bottom-up? I do both, top-down gives you perspective. bottom-up lets you make small functions which can be tested independently.

These are the big ideas, I can have plenty of small ideas later.

[bast]

Thanks for the ideas! Another question I found useful and started with in Lille: "what does modular code development mean to you"? We answered the 4 questions together in the hackpad, without splitting into groups.

For me there are two central ideas:

• when I copy paste this code part, will it behave the same?
• implicit (hidden) time dependence of stateful code

This would also be a place to point to good examples for inspiration so I will try to add links.

[rkdarst]

This is a good point: "pure function" emphasis could be "reduce dependence on external state". Like the other issue pointed out, this may be more realistic to emphasize and has hit me a lot more often.

e.g reduce global variables, functions use only arguments for parameters, etc.

+1 to idea of using the hackpad.