Well, I finished providing my first training session since 2000 (or so). As always, I learned a lot of things (hopefully not as much as the students). The course was a custom, "Upgrading to .NET with VB" that I wrote for the customer.
Right now, I'm a little conflicted about the session. Personally, I think it was awful, but they seemed to be more or less happy with it. Most of my conflict is around the act of training in general. Before I had joined
that company, training was the way I made most of my living: I travelled, teaching the wonders of Microsoft Mail, Exchange, VB and VC++. It really is a great way to both make a living, and sharpen your skills for your own programming needs. You never really learn a product until you either work with it for years, or try to explain it to someone. It was also the first time I've spoken in front of a group in months: and I think I've learned that I don't really like training very much. Perhaps it's just my normal personality, filtered through my new isolation. Ah, well. ever progress.
What were my main lessons during this session?
The main lesson learned was how much I hate my laptop. It was embarrassing just how much "umf" you need to have in a machine to toss around VS, SQL Express and PowerPoint (I switched to showing the slides as PDF midway through the week, and that helped. A bit). So, that's something I'll definitely have to keep in mind in the future (or replace my existing laptop if M lets me). Shut down every service you can find (that you don't need), and try to have apps and designers preloaded before you will need them.
As for the course and students, the next set of lessons I learned involved an ongoing topic of interest among developers: architecture. Particularly,
how much architecture is too much? After all, even an app whipped up over a sandwich has some architecture. For better repeatability, you could use some sort of framework (or even a Framework). However, ask 5 developers for an ideal framework, and you'll get at least seven answers. Stored procs or dynamic SQL? Aligned with a new database or designed to abstract out any database? Code gen or hand crafted? As always, these discussions really showcase some of the immaturities in our industry. Not in the developers per se, but in our methods. We really want to be
Engineers, but really we're
cabinet makers. There is no, "
Strength of materials" course that we can take that teaches us the relative merits and failings of possible choices, giving us the best practices to go on.
We're perfectly willing to have others use *our* methodology, but theirs "just doesn't fit", or it lacks one feature or another. Am I saying we can have one framework that everyone will use for all applications? Of course not (
I'm not a complete idiot, just a practiced one). What I am saying is that we frequently build our castles in the sky when they're not needed. Is another framework close enough? Would the existing features of your language+framework be enough? How importance is repeatability between developers or projects? No answers, just questions. I'm sure you can
find someone to tell you the answers.
Another semi-random thought: language wars. All I can say is, "Oh, please." Fortunately, many developers have finally realized that it's mostly about the syntax, and that a good developer can/should be capable, if not competent in a new language in a few days. The classes used by the language not included, of course. However, I still frequently hear language warfare from "Used to be Technical" (U2BT) managers. They still carry the baggage they had when they were coding, even if it is no longer relevant. So, the next time you hear from a single-language developer who insists that theirs is the perfect language for all situations, just make some sort of disparaging noise for me.