Caveat: This is a long term bug bear of mine and I spent
many, many hours over the last 20 years in discussion with
our local universities discussing how software-engineering
training could be made more relevant to the real world.
I'll try to keep it focused :-)

On 25/06/2019 21:00, David L Neil wrote:

> This illustrates an interesting (at least to me?us) side-effect: in 
> order to reduce "cognitive load" we often introduce training by using 
> the most straight-forward or 'simple' tools. In this case Jupyter (which 
> I think a most marvellous invention).

Indeed, and for those with a use for it, extremely valuable and not
really very simple!

> However, such illustrative devices are often not what is used in the 
> 'average' development department (assuming there is such a thing). 

Maybe not, but then Python covers a wide gamut and some researchers for
example never get beyond Jupyter, matplotlib etc etc. Those tools
deliver all they need.

You have to remember that software development is only one sphere in
which Python is used. It is also a research tool, a prototyping tool,
a personal productivity tool, a devops production scripting tool in
addition to an application development language. Many Python users
have no need to distribute their software. And for others Python is
likely to be just one small component in a much bigger project
involving Java, C++, SQL, etc.

Professional devs may well need to build distributable apps. And they
will use different tools. But there is little point in teaching
students about them because there are few standards and different
toolsets for just about every combination of app type and OS.
In fact just about every web server framework has its own solution.
And what you do for Python is different to Java or C++ or Smalltalk or
Lisp... And if the project has multiple languages - and most do nowadays
then you need a hybrid solution.

There is no point in trying to do more than demonstrate some arbitrary
example of what it takes to build a distributable package. Then
make it clear that this is not a general solution, just one example.

> the training meets the knowledge-need (we hope) but not the requirements 
> of practical application in the work-place.

Frankly the biggest problem with most training regimes is that
they put way too much focus on coding and programming languages.
Professional devs spend much more of their time analysing,
designing and testing than they do coding. In my experience
very few trainees have any real experience of analysis,
at best some rudimentary theoretical knowledge.
In the real world the bigger the project the greater the
proportion of time spent analyzing to understand exactly
what you need to do. Often up to 25% of the total project
time-scale. (Of course, those early activities have lower
team sizes so the proportion of budget is more like 10%)
Fred Brooks made the same point in his classic essay
"No Silver Bullet". He talked about the inherent and
intrinsic difficulty of software and understanding the
essence of the solution as the major challenges.
And no toolset (or training course) can shield you
from that. At best they can free you to concentrate on it.

Design is only covered at a shallow depth - usually restricted
to some UML class diagrams and maybe a message sequence chart.

Testing is covered at unit test level but rarely at integration
or system test levels. And virtually never at UX or performance
level.

> On the other hand, should training in Python, and more specifically, the 
> likes of matplotlib, involve any forlorn attempt at universal coverage 
> of 'the programmer's tool-set'?

My personal thought is that the key word there is 'forlorn'
You could teach them to be experts in one toolset and in their
very first job they discover they have to learn a complete
new toolset. The principles will be similar but the practice
very different.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


_______________________________________________
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Reply via email to