[Tutor] Pair 'o dimes wuz: Volunteer teacher

[Leam Hall]

On 7/23/22 20:01, dn wrote:
> On 24/07/2022 12.53, Leam Hall wrote:
> ...
> 
>> I feel one of Python's strengths is that it can do OOP, as well as other
>> styles of programming. That lets people create actual working "stuff",
>> and then evaluate how to improve the system as new environmental data
>> and requirements come in. What people call themselves, and what
>> paradigms they use is irrelevant; working code wins.
> 
> Agree: at one level.
> 
> However, consider the statement saying "code is read more often than it
> is written". Thereafter, the meaning of "working"...
> 
> Yes, it is likely that if we both tackled the same requirement, our
> delivered-code would be different. We may have used different paradigms
> or structures to 'get there'. This is not particularly at-issue if, as
> you say, they are 'working code'.
> 
> However, software is subject to change.
> 
> At which time, the ability with which we could read each-other's code,
> or code from our 6-months-ago self; becomes a major contributor to the
> success of the new project! Thus, my code *works* on the computer, but
> does it *work* for you - will you be able to take it and *win*?


Totally agree, on two levels.

First, Python is a lot easier to read than many languages. My first Python task, years ago, was to try and do something with Twisted. I was successful, and I didn't even know Python at the time. The language was just that clear.

Secondly, you could argue that the Twisted code was particularly well written and that's an argument for good design. I would take you at your word, I don't know the quality of Twisted code. I would very much agree with you that a good design, implemented well, beats a lot of the code I have seen. It beats a lot of code I have written, too.

I chuckled as I read your earlier response. Imagine the dev team trying to work through a spaghetti of undesigned codebase, and the design person saying "Now do you believe me that design is important?" I'm all for good design, and if you or Alan look at my code, swear under your breath, and then ask me if I'd consider fixing things with a good design, I'm going to listen.

Unfortunately, we can't just open our skulls up, drop in the GoF or Booch's OOAD, and magically do good design. To learn how to implement good design, our brains need to play. First with the language itself, and Python is becoming the language of choice for many on-line college courses (Coursera, EdX). This play will be just like learning a human language; we'll sound awful and not make a lot of sense, but learning takes time. In both computer and human language, a lot of people can't get past the early learning failures, never realizing that failure is implicit in play, and play is mandatory for learning. Too often we burden them with rules and expectations that kill the joy of play.

Once we have the basics, hopefully a mentor shows up that can take us to the next level. Either a strong base in verb declensions or an introduction to design concepts. Then we have to play with those new toys. Play will integrate the concepts into our skills, but it takes lots of time and lots of play. Having the toys to play "design this" with engages our brains and gives us a chance to deeply learn.

We agree that good design is good. My opinion, even if it's mine alone, is that design is not the first thing to learn.

Leam


-- 
Automation Engineer        (reuel.net/resume)
Scribe: The Domici War     (domiciwar.net)
General Ne'er-do-well      (github.com/LeamHall)