"If you're the smartest person in the room, you're in the wrong room. If you don't know who the dumbest person in the room is, it's probably you." (John Chawner)
I've spent quite a while looking through Pluralsight courses available by a subscription that I happened to get. To confess, I am not a real fan of any distance learning. Too often such a way of studying gives only an impression that you've got some knowledge, while you have not. There is even some psychological explanation to that phenomenon, which one can loosely articulate as a "lack of mass." The point is that any video course per se is not enough. A video course plus practicing are not enough either. What's necessary is all this together plus time, plus different views on the subject, seeing it from different standpoints and even touching some artifacts in-real-life. Only by passing this full journey, making all sorts of mistakes, you might end up with something looking like a real knowledge accompanied by intuition. Well, anyway, there are some video recordings that you might want to start that journey with. Here I'll list some of them. Bear in mind that my perception of these courses is subjective.
"Parallel Computing with CUDA" by Dmitri Nesteruk
If you never tried GPGPU computations, check out this course. It is full of non-trivial coding examples demonstrating different patterns of parallel processing on CUDA. Another good example is the integration of a CUDA-based dynamic library with a C#-based GUI. The practice is nicely balanced with technical notes. Exhaustive verbal explanations are given for everything that's being unfolded on the screen. Such topics as multi-GPU computation, different types of memory, synchronization of threads, atomics, and many others are touched. Although CUDA is something to do with computer graphics, there is nothing related to 3D rendering in this course. The contents are full of C-like coding that is not specific to any application. Hence you are not pinned to any particular niche.
At the same time, this course leaves the impression that it's not quite complete. When the author speaks about the Thrust library, the listeners like me might feel awkward. Should one start with that Thrust library instead of practicing the lower-level CUDA API? What is the best way to get into CUDA at the end of the day? To conclude, this course helps get started. Its practical examples are profound enough to return to them later on, once you gain a better understanding of the subject. Btw, in courses like that, it is essential to have a list of references. The lack of references is a big issue for almost all Pluralsight courses I've checked.
"Speaking Fundamentals" by Rob Conery
This one is to relax if you got tired of programming. A well-crafted course covering a bunch of "how-tos:"
- How to prepare for a conference talk;
- How to master a presentation that would save kittens from Edouard Tufte;
- How to get over demo faults, when everything goes wrong during your performance;
- How to keep the audience interested and ensure you're not remaining alone in the room by the end of your talk.
I could not recall any exceptional pieces of advice given in that course, though, in general, it was quite insightful. Unlike many other courses on Pluralsight, it is not just a screen capture prepared in Camtasia. It is more like a movie with its heroes, troubles, and accomplishments.
"Communications: How to Talk, Write, Present, and Get Ahead!" by Paul Randal
I was making some notes watching this course, and, amazingly enough, it did not feel like reiterating on obvious facts. Here are my notes:
- Use bullets.
- Be nice when communicating in whatever way. Pay attention to your body language, be attentive to the body language of your audience.
- People passing code review should not get out of it with a higher temperature. Do not use "that's incorrect" or, even worse, "you're incorrect" bullshit.
- Use spell-checkers (or my favorite Grammarly tool), do not misuse apostrophes (like "its" versus "it's"), ask for proofreading for somebody having equal or better writing skills (there's always something you did wrong).
- Stop and think what is the message you want to deliver. E.g., here I want to share the courses that excited me, which might excite you as well. Make sure that people get some value after communicating with you.
- An image worths a thousand words.
- Pay attention to the ESL issue (English as a Second Language). While P. Randal was speaking more on the issue when you're writing in a very complicated way (because your English is perfect), the situation is quite the opposite to me (I'm trying to write in English, while my first language and the only one I really feel is Russian).
- Be careful with "Reply All" button which may ruin your career ;)
- Be nice, be polite, use "please" and "thank you" magic.
- Always specify what result you're willing to get, when, and whom do you expect to deliver it. Be clear and concise.
- Avoid long emails.
- Ignorance ≠ stupidity.
- What you write is going to stay there forever.
- If you blog, do it regularly (that's something I'm struggling to achieve).
- People do not like dry language. Inject your personality in what you're writing. Btw, this piece of advice is often found in talks like "how to build your personal brand." The common cue is to attach people to your personality.
- Be careful with not disclosing any confidential information on your blog.
- Keep comments enabled, moderated, and answered. This way, you cultivate a community of professionals spinning around your blog.
- Presentation is always a two-ingredients thing: the information itself and the presenter. If any of these two is bad, the entire thing is as bad also.
- Only speak about topics you know really (really!) well. This one I vote for as I have a bad experience with not following that kind of advice.
- Understand the level of complexity you're delivering on. P. Randal uses five levels encoded as 100 (Beginner), 200 (Intermediate), 300 (Advanced), 400 (Expert), and 500 (Internal). Do not even try to present a deeper level than your actual understanding of the subject (see the previous bullet).
- Use simple slide deck templates (black text on a white background is just perfect).
- Tell a story. Say what you're going to present, do your presentation, and then recap (spin around your topic). A typical presentation consists of the following blocks: Title, Introduction, Content, Summary.
- Use agenda slides or any sort of progress indication throughout your slides.
- There are several "schools" of organizing slide contents: pictures only; brief bullets; lots of information on every slide. Use whatever works for you.
- Practice a lot to entirely eliminate all these "um" and "err" from your speech. Make it clean. Personally, I would recommend recording and listen to yourself. You will immediately feel the difference between a pure speech and the noisy one with "um" and "err" things. It's better to keep a gap of silence for a moment rather than using such a crappy glue.
Skimming over the library of courses at Pluralsight, I've noticed a lot on web-development, a bit on game development, and absolutely nothing on CAD development. Shouldn't we fix that? Which courses you'd love to see?