Background: I've done corporate #Python and data-science training for 20 years. Even before the pandemic, I taught live, online courses (via WebEx and Zoom) at least 1 week/month. I also offer many video (recorded) courses.
My work slowed down in April-May, when companies didn't know what was happening.
Training is now about where it was before. Except it's 100% online.
I teach everything from "Python for non-programmers" to "intro to data science." 5 days/week, 4-8 hours/day. All online.
I've learned a lot in this time, and want to share these thoughts with others — learners (no pun intended), teachers, and training managers.
Also: I teach adults at companies. I have huge respect and sympathy for schoolteachers who have been thrust into this world.
Live video, for all participants, matters. I know, it's a bandwidth hog. People don't want others to see their kitchen/children/dog/bad hair/PJs. But everyone on camera means more attention, seriousness, and questions. It makes a big difference to the learning.
Company culture matters. Some companies have done online courses for years. For many others, it's completely new. The difference is clear. At some companies, my students obviously don't pay attention, putting my window in a corner while they do "real" work. It's frustrating.
Keeping people engaged matters. An instructor who reads a slide deck is bad in general, and absolutely horrible when teaching online. Find ways to keep them interested, attentive, and participating. Fill the (virtual) room with your enthusiasm. Encourage tons of interactions.
For example: I haven't used slides in many years. Instead, I live-code into #Jupyter while teaching. If they ask a question, I can answer it, live-coding as part of the course.
(As a geeky aside: I use "gitautopush" to make my notebooks available in almost real time to my students, which allows them to review what I've done without asking me to scroll up and down.)
Also: When I review an exercise, I invite people to send me (privately) non-working code for public review. The fixes are usually small. And the odds are good that others made similar mistakes, and can learn from the discussion.
Which reminds me: Encourage people to keep the chat public, not private between the student and the instructor. Lots of people chatting privately doesn't make for a group learning experience.
Even before the pandemic, companies were trying to figure out how to incorporate technology and the Internet into training. But even the companies that are most interested in using technology have recognized
that there's no substitute for live interactions with an instructor.
With the pandemic, and with lots of people working from home (and often dealing with children), my clients are experimenting. I'm experimenting along with them.
For example: I used to only give full-day courses. Many clients now request half-day sessions. This has been surprisingly successful, especially in an era when I don't have to worry about travel time.
(Of course, it means I need to plan and budget my time more carefully. I don't have a full day to adjust my timing, if something goes over or under.)
Some clients have asked for 90-minute courses on specific topics. It's hard, in that time frame, to balance content, lecture, and practice. But these allow people to take courses even when juggling home issues, which is good. And they fit more easily into my schedule, too.
I've also had growing interest in mixed-mode courses: Companies are buying my recorded classes, supplementing them with live office hours for Q&A or in-depth discussions. These give everyone lots of flexibility.
That said, many employees don't have the discipline, time, or interest to watch an 8-hour video course. (And some of mine are even longer than that.) Which brings us back to square one.
The technologies that I use, Zoom and WebEx, are good but need to be better. Zoom is trying hard to improve; I've recently seen numerous small-but-important changes. I certainly prefer it as a solution. WebEx is clunky and stiff, and has more screen-share delays.
The training industry isn't going away, but it is changing. We all need to be willing to experiment -- teachers, employees, and employers -- and to shed things that aren't working.
I'm curious to hear what others are experiencing and saying. I'm sure that my experiences aren't unique.
And hey, if your company wants some Python training... hit me up! I'd be delighted to chat.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Lots of people ask me how they can translate their knowledge of Python into a new career path. The thing is, no one is looking for people who know Python. Rather, they're looking for people who know how to solve problems using Python.
Consider this: No one will hire you to speak a foreign language. But they will hire you to:
• translate to/from a foreign language
• conduct business negotiations in a foreign language
• be a tour guide in a foreign language
• edit advertising copy in a foreign language
The foreign language skills are necessary, but not sufficient, to put your career on a new trajectory.
Similarly, knowing Python is necessary, but not sufficient, for improving your career.
Did you know that #Python only supports two kinds of arguments?
I don't mean data types. Python functions (if we ignore type hints) don't care about those. Rather, there are only two ways that Python can take arguments and assign them to parameters.
Let's back up a moment.
When we call a function, we can pass it one or more arguments. These can be:
1. Positional arguments, assigned to parameters based on their positions and 2. Keyword arguments, assigned to parameters based on explicit name-value pairs.
That's it! There are no other types.
For example, consider:
def add(first, second):
return first + second
It has two parameters, first and second. We can call it with two positional arguments:
add(10, 20)
We can tell that they're positional arguments, because they are just values.
Do x and y have the same values? Are they interchangeable?
The answer, as always, is: Yes and no.
x is a list. We know this because we assigned it the result of running a list comprehension — that's what the [] indicate.
y, by contrast, is a generator. We know this because we used a generator expression — which looks the same as a list comprehension, but uses () instead.
So no, x and y aren't the same type.
But lists and generators are both iterable. So if we're planning to put x in a position where we'll iterate over it, you can use y instead.