Subscribe: Interoperability Happens
Added By: Feedage Forager Feedage Grade B rated
Language: English
audience  don  funny  ldquo  mdash  much  put  rdquo ldquo  rdquo  speaking  talk  thing  things  time  work  years 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Interoperability Happens

Ted Neward's Blog

Recent content on Ted Neward's Blog

Last Build Date: Sat, 28 Jan 2017 23:12:31 -0800


Speaking Tips: Don't Be Funny

Sat, 28 Jan 2017 23:12:31 -0800

For many years, I’ve quietly mentored a few speakers in the industry. Nothing big, nothing formal, just periodically I’d find somebody that wanted to get in front of audiences and speak, and either they’d ask me some questions or I’d get the feeling that they were open to some suggestions, and things would sort of go from there. Now, as I start to wind down my speaking career (some), I thought I’d post some ideas and suggestions I’ve had over the years. This time, it’s about humor. Or the lack thereof. Recently, I watched a presentation by a speaker (nobody I will name, to protect the guilty) who tried—oh, so very hard, he tried—to be funny. But his jokes just weren’t landing with his audience, and he grew visibly more and more nervous with every bombing joke, until finally he either ran out of material or ran out of courage, finished his talk, and bolted for the door as soon as he could. It was really a painful process for everybody. Which leads me to my next speaking tip: Don’t be funny. Or, rather: Don’t be funny, unless you know how to be funny, and by that I mean you have actually studied how to be funny. Don’t quit your day job It’s a hidden desire we all (or many, anyway) have: to be standing in a group of laughing people, tossing off quip after quip, telling story after story, to peals of laughter and amusement. To be funny, it seems, is so easy—just find the right jokes, toss off the right comments at the right time, and lo-and-behold, everybody laughs, and who doesn’t love somebody that makes you laugh? (Matter of fact, remember, we learned that lesson in Aladdin? Genie tried to tell Aladdin to reveal his true identity to Princess Jasmine because “A woman loves a man who can make her laugh!” He refused, of course, and ended up having to out-trick the Vizier/sorceror/evil-genie at the end of the movie instead. Shoulda run with the Genie’s advice, Al!) Unfortunately, when the would-be comedian tries to be funny, it often backfires horribly, with what seemed so funny when you told that joke among your friends last week instead just draws blank stares from the room. Yikes! Maybe they just didn’t hear it, so you try the punchline again. Nothing. Hmm. OK, let’s try one more…. That gurgling sound you hear in the background is the sound of a talk, going down, for the final time. Or, in some cases, it’s drowned out by the “whooshing” sound of flames erupting in the back from somebody who really did not care for the supposed joke, because it wasn’t really all that funny, and in fact it was downright offensive. I know: You want to be funny. You really, really want to entertain the audience as much as educate them, and that’s a good thing, generally. (Actually, it’s almost always a good thing—if it can be done well.) But, like many things speaking-related, it’s never as easy as it seems on the surface, and if you’re committed to a speaker persona of one who will make the room laugh, then you need to commit to learning the “science” of being funny. Being funny is no joking matter No, seriously—you think standup comedians are funny by accident? Or that they’re just somehow more talented? No way. They practice, and I don’t mean with their friends. The funny people actually go out and practice their jokes on strangers. Many of the world’s funniest comedians continue to do stand-up in small, out-of-the-way clubs, where they can try their newest material, judge the results, and tweak it (the material, the delivery, the pacing, whatever) in time for the next show. In fact, some of them will even play around with the material during their “big” shows (in Vegas, for example), because nobody ever goes to the same stand-up comedian’s show twice in a row, right? Let me be entirely transparent with you—a few years ago, I had a small accident while I was in Riga to do the keynot[...]

Speaking Tips: Managing T&E

Wed, 18 Jan 2017 21:27:31 -0800

For many years, I’ve quietly mentored a few speakers in the industry. Nothing big, nothing formal, just periodically I’d find somebody that wanted to get in front of audiences and speak, and either they’d ask me some questions or I’d get the feeling that they were open to some suggestions, and things would sort of go from there. Now, as I start to wind down my speaking career (some), I thought I’d post some ideas and suggestions I’ve had over the years. Recently I got an email from a blog reader, Krzysztof, asking me a question specific to speaking, so I figured I’d just use his question as the spine of the next Speaking Tips. Quoting him, he wrote: I have also been presenting recently at several conferences and these were quite successful performances (very highly voted). I would like to continue that and I have beed invited already to several places. The concern I have are the cost of travel and accomodation. I feel strange asking my boss again and again to pay that for me. He has agreed every time up to now but I dont feel this is how it should work, especially if I plan to do it much more. If it is not a secrect, could you share some thoughts about it? In some ways, there’s two questions here—one is the question of whether it’s acceptable to speak on your employers’ time, and the second is how to get conferences to cover your T&E (travel and expenses). When work speaks Whether a company should cover an employee’s T&E for a conference really has no universal answer, and frankly, I don’t think there should be one, either. On the one hand, certainly the company derives some direct and indirect benefits from an employee going out into the world and speaking at conferences; namely Increased visibility. When you speak, if your title slide has your company name and website, you are implicitly saying “Hey, these folks are cool and if you want to work with cool kids like me, put in an application.” That’s definitely a good thing for them. Unfortunately, it’s also damnably hard to track the success factor here in any sort of reasonable quantitative way—so don’t expect that your company is going to even realize that they’re getting that additional mojo unless something really unusual (like your talk going viral) happens. This is doubly hard for companies that aren’t in the developer tools space. Increased technical skills. The old adage states, “You never know a thing half as well until you try to teach it.” Even if you think you know a subject pretty well, trying to teach it—and trying to anticipate the questions you’ll get, not to mention the questions you never thought to anticipate and find yourself stumped by—will give you a much deeper skillset around that thing than you would ever have had just using it. This is sometimes directly obvious, but often management at work will attribute it to causes that may or may not be actual. (Let’s face it, it’s a hard sell to suggest that the only reason you got smarter on the subject is because you spoke on it, since you’re doing things every day that all could—and probably would—contribute to your comprehension of the subject, too.) Increased communication. In addition to sharpening your technical skills, giving presentations also increases your communication skills, and that can have direct benefits to the company as well. Having a technical individual who can stand in front of customers and/or their IT staff can be the difference between closing the million-dollar deal and the Sales staff blaming the crappy documentation again and demanding better leads from Marketing. But again, this is hard to quantify, and if the rest of the company doesn’t know you’re giving these talks and utilizes you in these situations, again, there’s no direct way for them to see the benefit of your talks. If you’re starting to get the impression tha[...]

2017 Tech Predictions

Mon, 02 Jan 2017 20:54:34 -0800

It’s that time of the year again, when I make predictions for the upcoming year. As has become my tradition now for nigh-on a decade, I will first go back over last years’ predictions, to see how well I called it (and keep me honest), then wax prophetic on what I think the new year has to offer us. As per previous years, I’m giving myself either a +1 or a -1 based on a purely subjective and highly-biased evaluational criteria as to whether it actually happened (or in some cases at least started to happen before 31 Dec 2016 ended). Bear with me for a moment, though. This is just too good. In 2015… … I said: Microsoft acquires Xamarin. Oh, baby. Off by a year. I’m should go back and give myself a +1 for this one. It was really surprising that they hadn’t. As a matter of fact, if Microsoft had listened to me and done it in 2015, they’d probably have saved themselves a TON of money compared to what they actually paid for Xamarin in 2016. But they made the acquisition, Xamarin is now part of the Microsoft family, and (finally!) .NET developers have access to the Xamarin toolchain and can build native iOS and Android apps without having to shell out additional cash to do so. ‘Bout time, Microsoft. (I suspect this had everything to do with Satya, to be honest.) OK, gloat over. In 2016… … I said: Microsoft will continue to roll out features on Azure, and start closing the gap between it and AWS. Calling this one a +1; it doesn’t take much research to see this has definitely been happening in 2016. However, it’s not necessarily a true statement that they’ve been closing the gap; Amazon keeps adding stuff as well, and the feature-parity lists are starting to get ridiculous. Whether these features are actually of use, however, is an important distinction, and something for the second half of this post. (X)-as-a-Service providers will continue to proliferate. Oh my, yes, Ted gets another +1 for this. When running a gaming convention has an (X)-as-a-Service for it (seriously, here) then you know the proliferation is in full swing. PaaS providers are exploding everywhere, and while a few have disappeared (farewell, Parse!), it’s clear that this was the gold rush of 2016. Apple will put out two, maybe three new products, and they’ll all be “meh” at best. I should’ve broken this into two predictions: one about Apple’s “meh” products, and one about wearables. If I’d done that, I’d have scored two +1’s for it, because not only have wearables not really gone very far (show me somebody wearing a smart watch, and I’ll show you a geek with too much time on their hands and not enough “discrimination” in their discriminatory income), but Apple’s product releases have been… “meh”! I’m looking at you, iPhone 7, and I’m really looking at you, MacBook Pro. (When Consumer Reports doesn’t give the MBP its top rating, you know the luster has failed.) More on Apple in the second half. iOS 10 will be called iOSX. Dangit. Such an opportunity wasted. -1 Android N will be code-named “Nougat”. Why, hello there, Android 7.0 Nougat. So pleased to make your acquaintance. +1 Java9 will ship. As I noted last year, @olivergierke pointed out that Java9 had already slipped to 2017, so this one was already a -1. Sigh. And I called it a “no duh” event, too—I’m going to let this one cancel out the extra +1 I’d have given myself for the Apple/wearables thing, just to keep the math safe (and my ego relatively sized). The article he cited says that Oracle “blamed the delay on complexities in developing modularization”, a la Project Jigsaw. Facebook will start looking for other things to do. Welllllllll, it’d be really tempting to say that Facebook’s now “things to do” was “Be the deciding factor in who gets e[...]

Speaking Tips: Evaluating Your Talk

Tue, 25 Oct 2016 21:50:30 -0700

tl;dr The talk is given, and inevitably, some well-meaning soul asks you afterwards, “How did it go?” I won’t tell you how to answer, but for me, the answer is always, “I have no idea; that’s for them to judge, not me.” Quite honestly, part of the reason I say this lies in the simple realization that no matter how you answer, you’re either wrong, arrogant, or falsely humble. If the audience thinks the talk went well, but you think it was terrible, you seem either out of touch or affecting a false sense of humility. If you think it went well but the audience thinks it was terrible, you look like an idiot or a douchebag. If you and the audience both think it went well, you run the risk (smaller, perhaps) of seeming arrogant or “overly proud”, and if you think it went horribly and the audience agrees with you, you seem out of touch and/or “if you knew it was bad, why didn’t you fix it?“. But part of the problem is that sometimes the audience gets more out of the talk than you realize, so even if you didn’t get what you wanted out of the talk (your message got lost in the noise of your demos, perhaps, or your demos didn’t go as well as you would’ve liked or any of dozens or other things), the audience may have an entirely different opinion. (Matter of fact, I’ve had that exact scenario happen to me: gave a talk, every single demo I gave bombed, and still it came back as one of the highest-rated talks I’ve ever given, because—as one audience member told me later—they loved that I just kept rolling with it, didn’t derail the talk trying to force the demos to work, and that “it was nice to see that even industry thought leaders can have a bad day at work!” Evaluating the evaluations Which means, then, that your best source of talk-effectiveness lies in the evaluations that a conference will ask the attendees to fill out. Not that this is the best source, but not an always-accurate source; lots of things can interfere with an honest appraisal of your talk: Attendees will blame you for conference issues. Too hot, too cold, seating issues, bad food, slides weren’t available on a CD (or, for reals, one attendee gave me a lowest-rating-possible because the slides weren’t available on a floppy disk), there’s always something that an attendee can find wrong with the conference, and use your talk eval as a way to communicate their displeasure to the conference as a whole. Attendees often don’t read your abstract, and grade you on the talk they wanted you to give, not the talk you gave. “Would have liked to see more on WebSockets,” reads the evaluation, despite the fact that this talk was on AngularJS. Or, “Speaker didn’t get into aspect-oriented programming” in your talk on .NET Generics. Or, my personal favorite, “Too much time spent on Swift” in a talk… on Swift! Attendees will contradict each other. “Speaker needed to spend more time on generic functions.” “Speaker spent too much time on generic functions.” Yup, thanks for that. Comments can cancel each other out, particularly if they’re one-offs on each side. Attendees are not professional speakers. They can tell you what they liked, or what they didn’t like, but they often can’t tell you why, any more than you can tell a professional chef why the dish they made just didn’t quite do it for you. (It’s actually much harder than you might think.) Only about 10% of the attendees will turn in an evaluation. Hey, come on! There were only a limited number of donuts at the break table, and if they’d taken the time to fill out the evaluation, they’d have missed a shot at one of the rainbow sprinkles! Only the attendees with strong feelings will turn in an evaluation. If they hated you, they’ll turn in an eval. If they loved you, t[...]

Revisiting Rotor

Thu, 13 Oct 2016 01:34:07 -0700

tl;dr As part of preparing for a workshop next week in Poland, I’ve been diving back into the CLR source code—which takes me back to my old friend, Rotor.

For those of you who came to the CLR late, back in 2002 Microsoft offered up an open-source version of the CLR called the Shared Source CLI. (“CLI”, for those who don’t know, is the official ECMA Specification describing the virtual machine that .NET uses as its runtime. The “CLR” is the commercial name for Microsoft’s implementation of the Common Language Infrastructure specification.) I can still remember the feeling of shock and awe when I heard that Microsoft was actually going to release the source—albeit with some of the core parts simplified for easier research purposes—to what it considered its flagship technology for the coming decade. Wow.

And then I got to write a book on it. Double wow.

And then Microsoft decided to pay me to follow up on the first edition with a second edition, which they would give away for free. Which, by the way, you can get off of my professional site here.

Triple wow.

But I want to call out something I wrote eight years ago, in the Prologue to the second edition:

“[T]he book also marks a turning point, as well: with the release of the FCL source to the wider world of the development community and the lack of significant changes to the execution engine since v2, the Rotor distribution has effectively been “cut loose” by its original creators, to stand on its own within the community, as every open source project must do at some point. This is not a cause for alarm or concern—-the Mono project continues full force, and Microsoft‘s growing comfort with the open-source community leads to the distinct possibility that the commercial CLR source will, one day, stand where Rotor once stood.”

It’s probably bad form to smirk as hard as I am right now. But I’m still doing it.

Thank you, David Stutz, for blazing the trail that Rotor could go down, and in doing so start the avalanche that would eventually become Microsoft’s engagement in the larger world of open source. We in the Microsoft community owe you a pretty big debt.

Speaking Tips: Tell A Story

Mon, 19 Sep 2016 00:49:15 -0700

tl;dr When doing a presentation, there should always be some kind of “story” to the presentation. It doesn’t have to be a full-blown Shakespearean “Things get worse, things get a little better, then things get way worse, and either they eventually get better (a comedy) or they just end worse (a tragedy)” plot arc, but your audience needs to have a narrative arc to the talk that they can sort of hang on to while you’re doing your thing. And, as it turns out, you need it as much as they do. Too often, when an apprentice speaker shows me their outline, it’s a wonderfully crafted entity of logic, detailing a lovely introduction to the thing, three core aspects of teh thing, and a conclusion that describes the thing and wraps up the talk. It’s a carefully-crafted Aristotelian arc, following the ancient Churchillian formula of “Tell ‘em what you’re going to tell ‘em, tell it to ‘em, then tell ‘em what you just told ‘em.” It’s also boring as shit. The key element that many novice presenters forget is that sitting in chairs for an hour-plus is an actual battle of willpower. The body wants to remain in motion—it hates being constrained to one place for any length of time. It’s why humans fidget in their chairs, take out their laptops, check their phones, and all the other little (distracting) things that people do during talks. Here’s the ugly little secret that nobody wants to tell you: they’re bored. And when people are bored, their bodies start to create physical stimulation so as to alleviate some of the boredom. Sometimes they’ll be polite about it and keep it to a minimum, but not always. Now, I’ll grant you, not all motion is an indicator of boredom—some people like taking notes, be it longhand on paper or in computerized (or, more recently, tabletized) fashion. But in those cases, those people will be otherwise very still—they are concentrating on what you’re saying, and they won’t be engaging in some of the other physical movement that alleviates the boredome. And, of course, this is a gross stereotype; everybody is a little bit different. However, keep this in mind as you gaze out across the room as a whole. If lots of people are fidgeting, it’s pretty likely that you’re boring them. How, then, do we not be boring? Stories vs facts Consider this: “Mary left her house at 7:30 am. She walked to the store. She purchased a ham, some asparagus, and some cooking spices. She returned to her house at 9am. She began to clean, and at noon she went out with some friends for lunch. When she returned at 1:30, she began preparing dinner for her husband. He did not arrive until 10pm, and the two of them began to argue.” Meh. Boring. But now, consider it this way: “Mary woke up in the morning, determined to not let the events of the previous day ruin her plans for today, the anniversary of when she and her husband, Tom, first met. She went to the store, picking out the things for the special dinner she was going to make for the two of them that night, and when she got back, she began to clean the house so that she could surprise him with a candlelit dinner in the living room. She went out with some friends, who were all just as excited about the evening’s plans as she was, and when she got back from lunch, she began to cook.” You know, I don’t know that I even have to tell you how this one ends. You already know. What’s the difference between the first rendition and the second? Easy: emotions. Feelings. The reader can put themselves into a story, whereas plain facts just rest on the paper. Either you’re Mary, excited about surprising somebody you care about with a special celebration, or you’re Tom, who really doesn’t understand why the hell anybody celebrat[...]

I have ADD

Thu, 15 Sep 2016 01:28:29 -0700

tl;dr In the wake of the recent Simone Biles “scandal”, it’s important for people who are in like situations to stand up and be counted. So, although this is something I’ve never really kept a secret, it’s well past time to ‘fess up and admit: I, too, have been diagnosed with ADD. Simone Biles, for those who haven’t heard, was recently victimized by Russian hackers who sought to expose her as a gymnast who takes forbidden medication and thus expose her as much of a fraud as the Russian gymnasts who were banned from the Olympics were. Turns out, she takes Ritalin, as prescribed by the doctor, and has for most of her (admittedly, to this point, fairly short) life. She’s not hiding from it, though, and has come out publicly to say that she’s not ashamed of being somebody who wrestles with ADHD. Attention Deficit Disorder, cousin to its more easily-spotted condition, Attention Deficit Hyperactivity Disorder (ADHD), is not an uncommon thing among adults. Daniel Amen, of the Amen Clinic (one of the leading organizations involved in ADD/ADHD and autism research), has estimated that 1 in 10 members of the general population has ADD/ADHD. He’s even suggest that there are biological reasons for why human beings would evolve such a scenario among the brain’s chemisty: the characteristics of the ADD/ADHD individual are actually the exact same characteristics one would want in a hunter: broad spectrum of attention, quick shift of focus, intense burst of focus on a particular topic/subject/entity/scenario for short periods of time, and so on. Granted, ADD/ADHD doesn’t do well when you’re trying to be a “farmer”, which requires careful and close attention to detail over long periods of time and an ability to concentrate despite what might be going on in the background. But that’s why 1 in 10 are ADD/ADHD, and the rest… aren’t. Or at least, according to Amen. And the CDC, who probably know a few things about medicine. ADD and ADHD aren’t what you think they are, but numerous other places that describe it in much more glowing detail. Suffice it to say, it’s generally not what most people think it is, and in fact I’ve known a number of adults that I’m pretty sure are undiagnosed ADD/ADHD. ADD/ADHD is, however, considered a medical condition, and not something that can be corrected with “better parenting” or “stricter rules”; in fact, that’s probably the easiest way to turn your kids into extremely anxious and unhappy teenagers. It’s sort of like saying “Your lack of one arm is just due to bad parenting and lax discipline; if your parents would just take a more strict position, you could do everything two-armed people could do, too.” And if you think it’s limited to just kids, I’ve got an interesting question for you. Two of them, in fact: one, do you think ADD/ADHD just popped into the world a few years ago, and two, what do you think happened to all the kids with ADD/ADHD before now who grew up with it? Some of us figured out coping mechanisms on our own, some of us never really got a handle on it (ever known an adult who just couldn’t help but be the center of attention, even at great personal cost?), and some found chemical ways to provide the stimulation, usually at great personal cost. Myself, I was diagnosed as an adult. The story is one that I’ll not tell here, but suffice it to say it was one of those “OH!” moments. Specifically, the psychologist was saying that somebody else I knew very well probably had ADD/ADHD, because they did X, Y, and Z, and my reaction was classic: “They can’t possibly have it because I do all those things, too.” The psychologist looked at my wife, my wife looked at the psychologist, and then they both looked a[...]

Seattle Code Camp 2016

Thu, 15 Sep 2016 00:41:22 -0700

tl;dr I spoke at Seattle Code Camp last weekend, and I wanted to make links to the slides available for anyone who was interested in consuming them.

The two talks I gave, “Why My International Relations Degree Trumps your CS Degree” and “PsyPhilProg”, were pretty well-received overall, but as always, I find I have things that I want to tune. Still, that being said, if you enjoyed the talk(s), that’s awesome, and if you’ve been inspired to go dig up some non-CS reading material to improve your development career, even better. If I can carve out some time, I’ll amend this post to include a suggested reading list.

The Fallacies of Enterprise Computing

Wed, 24 Aug 2016 23:55:16 -0700

More than a decade ago, I published Effective Enterprise Java, and in the opening chapter I talked about the Ten Fallacies of Enterprise Computing, essentially an extension/add-on to Peter Deutsch’s Fallacies of Distributed Computing. But in the ten-plus years since, I’ve had time to think about it, and now I’m convinced that Enterprise Fallacies are a different list. Now, with the rise of cloud computing stepping in to complement, supplment or replace entirely the on-premise enterprise data center, it seemed reasonable to get back to it. I’ll expand on the items in the list over future blog posts, I imagine, but without further ado, here’s the Fallacies of Enterprise Computing. New technology is always better than old technology Enterprise systems are not “distributed systems” Business logic can and should be centralized Data, object or any other kind of model can be centralized The system is monolithic The system is finished Vendors can make problems go away Enterprise architecture is the same everywhere Developers need only worry about development problems As Deutsch said, “Essentally everyone, when they first build a [enterprise] system, makes the following [nine] assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.” Naturally, I welcome discussion around these, and I may edit and/or append to this list as time goes by, but this is where the past decade has led me. New technology is always better than old technology After building IT systems for more than sixty years, one would think we as an industry would have learned that “newer is not always better”. Unfortunately, this is a highly youth-centric industry, and the young have this tendency to assume that anything new to them is also new to everybody else. And if it’s new, it’s exciting, and if it’s exciting, it must be good, right? And therefore, we must throw away all the old, and replace it with the new. This cannot be emphasized enough: This is fallacious, idiotic, stupid, and brain-dead. This fallacy is an extension of the old economic “limited market” fallacy: The more gains one entity makes in a market, the more that other entities lose. (Essentially, it suggests that the market is intrinsically a zero-sum game, despite obvious evidence that markets have grown substantially even in just the last hundred years since we started tracking economics as a science.) Thus, for example, if the cloud is new, and it has some advantages over its “competitors”, then every “win” for the cloud must mean an equal “loss” for the alternatives (such as on-prem computing). Never mind that the cloud solves different problems than on-prem computing, or that not everything can be solved using the cloud (such as computing when connections to the Internet are spotty, nonexistent, or worse, extremely slow). Now, for those of you who have been engaged in the industry for more than just the past half-decade, here’s the $65,535 question for you: How is “the cloud” any different from “the mainframe”, albeit much, much faster and with much, much greater storage? Those who cannot remember the past are condemned to repeat it. –George Santanyana, Historian I’ve seen this play out over and over again, starting with my own entry into the IT universe with C++ (which was the “new” over C), and participated in a few system rewrites to C++ from other things (Visual Basic being one, C being another, sometimes some specific vertical stuff as well). Then I saw it again when Java came around, and companies immediately started rewriting some of their C++ systems into Java. This time around, I started to ask, “Why?”, and [...]

Developer Supply Chain Management

Thu, 18 Aug 2016 23:38:17 -0700

At first, it was called “DLL Hell”. Then “JAR Hell”. “Assembly Hell”. Now, it’s fallen under the label of “NPM-Gate”, but it always comes back to the same basic thing: software developers need to think about their software build and runtime dependencies as a form of Supply Chain Management. Failure to do so—on both the part of the supplier and the consumer—leads to the breakdown of civilization and everything we hold dear. Well, OK, fine, not exactly the breakdown of all civilization. But certainly a breakdown in the part of civilization that is currently occupied by those who would lead a happy and productive lifestyle in the platform under discussion (whether that be native code, Java, .NET, JavaScript, or what-have-you). For those who haven’t seen the disaster that was NPM-Gate, allow me to refer you to a few links: The Timeline. Probably the closest thing to an “official” history of what happened. ARS Technica’s views on the subject Business Insider UK also reported on the mess The upshot, however, was that the removal (rightly or wrongly) of a package that a core package (ExpressJS, among others) depended on led to an obscene number of sites suffering an outage. Interpreting the deploy To some, particularly those coming from the native, Java or .NET persuasion, this missing dependency may seem odd—after all, it would really only make itself felt when the project was compiled, not at runtime. If the project had already been “built” (which, in the NodeJS world, would mean having already downloaded all of the dependencies and deployed), then why would the package’s subsequent removal really make all that much of a difference? Here, we come to the part where conventions and cultural habits come into play; when a NodeJS-based system is deployed, it’s typically deployed without its dependencies, rather than with them. Recall that NodeJS, like all Javascript-based environments, is an interpreter, not a compiler or virtual machine. Thus, the habit among the NodeJS community is to deploy the source code along with a manifest file (package.json) that in turn describes all of the dependencies. Then, as part of the deploy, one issues the command to pull the dependencies down (npm install), and the application is ready to go. “OK, fine, then each time they deploy, there’s a problem. I still don’t see why this caused so much outage across the Internet”, might be the reasonable reply. And this is where we get into why this matters to people outside the NodeJS world. The NodeJS community, you see, has been at Ground Zero for a lot of the DevOps movement—many of the ideas and concepts around DevOps have been put into play in NodeJS environments. After all, think about it: write your source, then commit the changes, and boom, everything is ready for a deploy—so it’s trivial (in a way) to wire this up into a full-blown DevOps pipeline, particularly since most NodeJS-based systems are using REST/HTTP APIs for the back-end, which are always much, much easier to automatedly test than other middleware options. So when you go “all in” on the DevOps thing, and start doing daily—or hourly—releases, suddenly a break in your deployment process becomes a really big deal. Particularly if your “rollback” strategy is based around the idea of doing a re-deploy of old code, as opposed to having a full backup of the server (or server container image) that you can simply spin up without having to actually run the deployment script. Lessons This kind of event, which qualifies as a black swan event if ever there was one, still leaves quite a few lessons that developers can learn from. First of all, th[...]

Speaking Tips: Mentor and Be Mentored

Sun, 14 Aug 2016 15:59:34 -0700

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. And one of the key things I advise new speakers to do is to sit on both sides of the mentoring fence. It’s a pretty simple thing: If you’re a speaker, look for a mentor. This is the first thing any newcomer to Toastmasters does—pick a mentor—so it’s not like this is rocket science. I had a few mentors when I started teaching at DevelopMentor two decades ago, and I learned a ton from watching them do their thing. But there’s more to learning than just learning. Maths, teaching, and me Many, many years ago, in grade school, I confidently informed a math teacher that I didn’t need to do the in-class exercise—I understood the concept (heck if I can remember what it was; probably something like multiplication or something really hard like that). The teacher looked at me, then said, “Well, fine, if you understand it, that’s great, you don’t need to do the work. But could you do me a favor and explain it to your classmate over here? He’s still struggling.” Brim-full of confidence, of course I strode over to the other desk where my classmate was still working to understand it (whatever it was we were taught), and Lo and Behold! I couldn’t really teach it to him, either. Because, as my math teacher then rather gently and kindly explained to me, “You can’t teach what you don’t know.” Political science, lectures, and me What he neglected to tell me—which I discovered for myself years later—is that teaching a subject also helps you learn it a lot, lot better. I found that out while in some college study sessions; I had this habit of reciting the professor’s Poli Sci lectures in her voice and accent, and wouldn’t you know it, it was vastly easier to recall her lectures when I did. I always ended up with some interesting new insights on the subject whenever I did that, and in some cases, was able to work that into essay questions during tests and papers. You cant teach what you don’t know, but you learn more when you teach. Mentoring me, mentoring you If you’re looking to be a speaker, offer to help those who are also just getting started. The act of looking critically at their abstracts and presentations will help you better critique your own. This is because you will be able to critique their work far more easily than you can your own, since you will not have the emotional connection to the work that the other speaker has to it; and once you get more accustomed to judging a work in a more objective and unemotional manner, you’ll start doing it to your own work more effectively. And yes, I can now let the cat out of the bag: All these years that I’ve been mentoring speakers, if you thought I was doing it to “give back to the community”, now you know I’m actually just a selfish conniving manipulator: this entire time I’ve been mentoring others, I’ve actually been learning more about speaking by teaching, and getting better myself as a result. What a jerk! (Well…. OK, you caught me; that’s not the only reason I’ve been doing it. I also do it because I just like teaching. And, sure, whatever, “community”, we can go with that too.) Point is, even if you try to mentor somebody who’s just getting started as you are, you’ll effectively be forming a study group, critiquing each other and learning from both positions. And that, dear readers, is a large part of how we get better. [...]

Speaking Tips: No Speaker Notes

Sat, 13 Aug 2016 03:31:26 -0700

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. I’ve seen numerous speakers bring notes to themselves up to the podium, and reference them during the presentation. In some cases, they try to hide the fact that this is what they’re doing, and in others, they just openly make reference to them. And to many speakers, this may come as a surprise, but…. Not. A. Fan. First reason: eyes down on the notes is just as bad as eyes down on the script on the monitor. Keep your eyes up. It’s bad enough that you have to be looking at the screen while you’re typing out the code for the demo, don’t ruin your few moments for making eye contact with the audience by giving your eyes something else to look at right there on the podium. But secondly…. why, exactly, do you need them? More importantly, what’s the message you’re sending? Using speaker notes sends one of several signals to the audience, any or all of which might be true, but even if they’re not, this is still how it can/will come across: This stuff is really hard, so much so that not even the presenter can get it right all the time. That means it’s REALLY hard. Matter of fact, if you don’t have the notes, you may as well just abandon hope, all ye who try to recreate this demo at home. This presenter doesn’t really know the thing they’re trying to demo. I mean, if this isn’t that hard, but you’re using notes, how often have you actually ever done this? Matter of fact, how often have you even used this thing? Are you actually qualified to talk about this stuff at all?!? This presenter hasn’t really practiced this demo at all, so they need the notes to remind themselves of everything they need to do during the demo. And if you haven’t practiced it at all, then how much practicing did you do for the talk as a whole? (It’s just inviting the audience to examine and criticize the talk with a keener eye.) The thing I am demoing is so new and/or so fragile, if the speaker deviates from any part of the happy path, the results are likely to be as spectacular and unpredictable as they are wrong. Is this what you’re trying to communicate to the audience? On top of all that, what’s the first thing the audience is going to want from you after the talk? Those very same notes, so that they can follow the notes when they try to do the demo themselves at home, after the talk. Are you prepared to give them up? If yes, then put them into a README and put the whole thing up onto GitHub. Then you can reference your README in front of the crowd, and everybody feels like they’re back ontp a level playing field. If no, then figure out how to do the demo without having to refer to the notes, because the attendees will feel cheated and/or shorted when you refuse to turn them over. Even if you say, “Oh, these are just personal notes, it’s not that hard, you shouldn’t need them”, it doesn’t work; in that particular case, attendees know you’re LYING, you liar liar pants on fire, because you needed them yourself! Most of the time, speakers I talk to say they want the notes because they are afraid of bombing a demo and looking bad in front of the audience. Audiences don’t care that much if you bomb a particular demo—they are willing to forgive a mistake or two, so long as it doesn’t deviate from the flow and pace of the talk as a whole. Just say no to speaker notes in any form. [...]

Speaking Tips: Never Memorize

Sat, 13 Aug 2016 02:39:12 -0700

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. One of the most important things, although it seems like a good idea at first, is to never, never, EVER memorize your talk. And that includes having a script for it. It feels counterintuitive: If you’re not a good extemporaneous speaker, wouldn’t it make sense to have what you want to say written down, so that you don’t have to try and think and speak at the same time? You can focus on the speaking, since the thinking is already captured there on the script, and that way you can deliver a better talk. The Fallacy of the Script Frankly, I find this to be a speaking fallacy, one which is perpetuated by a variety of sources, particularly politicians. And honestly, given how badly the current Republican candidate is at spontaneously speaking to the audience, it would seem even more counterintuitive. To begin with, let’s put one thing to bed: You simply do not have the time to memorize a talk. Nobody does. I’ve been speaking for twenty years (even longer if you count my high school stint through Toastmasters), and only twice in my life have I ever delivered a memorized speech. There is simply no way I could memorize and deliver all of the technical talks I’ve delivered over the years. Do I have a few well-traveled jokes that I like to carry from one talk to the next? Sure—that’s a different scenario. A memorized speech makes more sense when it’s a one-off and it’s absolutely imperative that you deliver exactly the right words with the right nuance and the right emotion at the exact right moment. A funeral, a wedding, a commencement speech, these are places where a memorized speech is appropriate. A technical talk, not so much. And if you notice the use of the two different words there—“speech” against “talk”—it’s apparent there’s a significant difference between giving a persuasive and/or emotional speech, and delivering a technical talk. To start, the lengths are wildly different. When President Obama delivers a speech to the factory workers in Pennsylvania, he’s generally not talking for an hour—but when you do a technical presentation on OData for the local user group, generally that’s the length of time you shoudl be aiming for. (Of course, each group has its own organization and it’s own wishes, but 50 - 75 minutes is the rough range for almost all the software development conferences I’ve seen.) Secondly, Obama has a TelePrompter. You, sadly, do not. Yes, PowerPoint and Keynote will allow you to put your speaking notes right there on the screen in front of you, but the tendency then will be to put your eyes down onto the screen, and not out to the audience in front of you. And your eyes need to be on the audience in front of you—you need to read their body language to see if they’re getting it, or if they’re all confused, or if somebody has a question, even. Keep your eyes on the audience, not your notes. But lastly, Obama has speechwriters who understand how to craft the spoken work in such a way that it sounds compelling, uplifting and meaningful. All you have is you. What’s more, the spoken word and the written word sound very, very differently from one another. To see what I mean, go pick up the last technical book you’ve read, and flip to the the middle of a chapter. Now read the first three paragraphs out loud. Seriously. Go do this. I’ll wait. whistling That was awful, no? Our eyes and our ears process information very[...]

Speaking Tips: Slow Down and Drink

Sat, 13 Aug 2016 02:01:18 -0700

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. In this installment, we talk about speaking—and by that, I mean pacing. It is a common theme with most new speakers that they need to slow down when they speak. And by common, I mean pretty much every new speaker (and even a few experienced ones) falls victim to this. So one of the things that I tell new speakers to do is to put a Post-It somewhere on their laptop that reads, “Slow Down and Drink”. Slow down Part of the reason a speaker goes faster during a talk is because they are nervous, to be sure. That part, you’re not going to get past until you get a little bit of experience and practice under your belt. While I wish there was a magical recipe for making the nervousness and anxiety go away, alas, I know of no such thing. And, frankly, I’m not sure I would take it even if I could; nervousness, anxiety, whatever you want to call it, is usually the dark corners of your mind trying to wind you up, and the reason those dark corners can do that is because you’re concerned about doing a good job. If you didn’t care about the quality of your presentation, you really wouldn’t be nervous, because seriously, who cares? Nail it, blow it, whatever. That nervousness is A Good Thing, so don’t be so quick to toss it away. (True story: Thirty years ago, I was attending a youth soccer/futbol referee camp hosted by the legendary referee Ken Aston. This is the man who invented the red and yellow cards, people—he was the gold standard of international soccer/futbol refereeing as you can get. During the closing ceremonies of the camp, one of the other campers asked him about his career and why he retired. He paused, then said, “You know, during my last World Cup, one of the other gents asked that same thing.” He sort of went into himself for a second to think, and then he said: “Picture this: We are standing in the tunnel leading out to the World Cup Final. Thousands of people are screaming, singing, chanting. The teams are preparing to take the field. We five are standing in the tunnel, looking out onto the pitch, having our briefing before we begin, and that question comes up. ‘How can you walk away from this?’ was sort of the implication. I said, ‘Gentlemen, extend one of your hands and hold it flat to the ground.’ They did so, and all four of them were visibly shaking. I put my own hand out, and it was steady as a rock—no nervous shaking whatsoever. I looked at them and said, ‘That’s how I know.’“) Another reason speakers tend to speed up, however, is because they labor under the misguided notion that they need to put as much material into the attendees’ brains as possible—the attendees will be so bored if I don’t, and every second I’m not piling new stuff into their heads is a second they’re going to think I’m wasting their time, and— Bzzzzt. Nope. Wrong. Attendees, like you, are human. They need time to process the information you have told them. As a matter of fact, in some cases, they may even need time to just translate your words, if your language is not their native tongue, before they can even begin to parse the meaning. Particularly for heavily conceptual talks, or new ideas that the audience hasn’t seen before, it will take them some degree of time before they can process it. Don’t believe me? Go to a standup show sometime. Watch the audience. Particularly if the comedian is a dry-sense-of-humor[...]

Speaking Tips: Critique Others

Wed, 10 Aug 2016 00:00:51 -0700

For many years, I’ve quietly mentored a few speakers in the industry. Nothing big, nothing formal, just periodically I’d find somebody that wanted to get in front of audiences and speak, and either they’d ask me some questions or I’d get the feeling that they were open to some suggestions, and things would sort of go from there. Now, as I start to wind down my speaking career (some), I thought I’d post some ideas and suggestions I’ve had over the years. This time, it’s to critique (not criticize!) others speaking. And ask for their critique in return. Note first of all that “critique” does not mean “criticize”. Where the use of the term “criticize” is, colloquially speaking, intended as a negative concept meaning “to put down” or “to find fault with”, I use the term “critique” here to mean “give honest feedback”. There’s a technique to giving feedback (the so-called “compliment sandwich”, although to me its more subtle than that), but first of all, there’s an important thing we must address. You are not your talk. It’s all too common for people to invest their ego into their work. Whether that’s code, art, fiction, or any other kind of creative or productive activity, it’s all too easy to put “us” into the work. This is made all that much easier when everybody out there is telling you to “follow your passion” and “be passionate about what you do”, which thus makes you want to pour your heart and soul into the work all that much more deeply. Unfortunately, this carries with it a large negative consequence: when the work is criticized or found less than perfect—and let’s be really clear here, your work is always less than perfect, because there is no such thing, get that through your head right now—then the criticism of the work is implicitly a criticism of you, of your ego, of your commitment to your passion, of your ability to execute, and from there it’s really short step to HOW DARE YOU QUESTION MY COMMITMENT TO THIS WORK YOU UNBELIEVABLY RUDE PIECE OF SH–. Pause. Nobody is calling you a terrible person. Nobody is saying you are worthless. Nobody is telling you that you are a waste of oxygen and food and water. Even if your talk was the worst that was ever given, that doesn’t mean you as a person are worthless. Because you are not your work. If this does not make sense to you, please return to the top of this page and try again. Nothing else I say here will make sense until you can imbibe and absorb this mantra. Still having trouble with that? Try this: When’s the last time that you said, “This code could be made a little bit clearer by using this different approach”, and what you really meant was, “I can’t believe your mother didn’t do a service to all of humanity and just strangle you in the crib”? Funny thing is, people critiquing your code—or your talks—are in the same boat as you are when you’re offering up criticism. Usually they’re trying to help. Sometimes they’re not doing it well, but hey, most of the time, you’re probably not doing it well, either. And here’s the funny thing about criticism: It becomes easier to accept criticism of your own work when you are able to criticize others’ without judgement. And, of course, when you actively encourage others’ criticism of your own work. By the way, just keep friends and family out of this. They will mean well, but they will generally tell you use[...]