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
