As part of a new ASP.NET Core project that I've been blogging about recently, my team and I have reached the phase where we need to get the project onto some of our development servers, not just running on our local machines.

Problem is, I've been having a hell of a time getting our Azure DevOps system to correctly deploy this site. Once I'd worked out the myriad issues with our YAML deployment system, I was left to determine why our app couldn't talk to its dev database. Turns out, I hadn't set the ASPNETCORE_ENVIRONMENT variable properly on our development servers, and to do so with our setup required a bit of black magic and a visit from an old friend.

Journey to the Real Problem

The app that we are trying to deploy is an ASP.NET Core 3.1 application, and our server cluster are all Windows servers running IIS.

I found out, rather suddenly, that our project was the trailblazer app for these servers; no one had tried to deploy an ASP.NET Core application onto them up to this point. This was news to me, as I could have sworn someone else on my same team had already had these issues. It turned out later that I was both right and wrong at the same time.

No matter, I thought. This can't be that hard. Longtime readers will know that when I think that, things never go well.

It was, in fact, that hard. YAML kicked my butt, and to top it off, when I finally got the app deployed to the correct location, I received the following error:

Some pair-programming with my server team later, we found out that .NET Core had not actually been installed on these servers yet. So much for there being another app that had already done this. Server admin Raul fixed this issue for me, and we were in business.

Except, not really. Now we had a different issue: the app couldn't actually talk to its database.

Connecting is Hard

This particular app has two available databases; one in a dev environment that we use for things like local debugging and integration testing, and the official prod one. It also has three environments: development, staging, and production. In development and staging, the app should talk to the dev database; in production, it should talk to the prod one.

The app sets up an IDbConnection with the appropriate connection string, and then adds that connection to the services layer so that it can be injected; all of this happens in the app's Startup.cs file. That code looks something like this:

Where the Constants values are ultimately sourced from an appsettings.json file.

The key issue is the first if statement, the one that checks to see if we are running in the production environment. See, ASP.NET Core checks the value of an environment variable called ASPNETCORE_ENVIRONMENT in the environment where it runs, and if it doesn't find that variable, it assumes it is running in production. That's what was happening here; the app assumed it was in production mode because it didn't find that variable and so tried to use the production connection string, but it was really in a dev environment which cannot even talk to the production database server.

Now I had an issue. After about four hours of fruitless debugging and Googling, I finally went to my teammates and described the issue. At which point, one of them remarked:

"Oh, yeah, we've seen that before. You have to set it in a web.config file."

Which absolutely blew my mind. How did they know that if I was writing the trailblazer application? Turns out, they had already written one, but it was deployed to an entirely different server cluster. Doh!

What's Old Is New Again

But that wasn't really what bothered me. I was under the impression that one of the reasons ASP.NET Core was so damn cool was that we didn't need to use these antiquated XML files any more. It turns out I was half right; if we didn't need to set the ASPNETCORE_ENVIRONMENT variable, we would not need the web.config files at all.

That said, my teammate showed me how they set up their application to do this. Their web.config file was pretty short:

Once I had this file deployed to the server, the application just worked! It set ASPNETCORE_ENVIRONMENT to "Development" and the correct connection string was used in my app. It was like magic, albeit old and unsavory black magic.

In all seriousness, this did feel like going backward. I really thought I wouldn't have to deal with web.config files anymore once we moved to ASP.NET Core. But hey, our app works in the dev environment now, and quite frankly that's all that matters.

Summary

In our environment (Windows servers, running IIS, hosting ASP.NET Core 3.0 apps), we needed a web.config file in the app to correctly set the ASPNETCORE_ENVIRONMENT variable so that the app would run in the preferred environment.

I doubt I'm the only person out there who has had this problem, and if you've needed to do something like this, please feel free to tell me about it in the comments!

A while back I wrote a post that I am still particularly proud of: The Ten Commandments For Naming Your Code. In it I published ten "commandments" for variable naming that I believed would help all of us get rid of bad names.

I still think these commandments are good guidelines, but in the four-plus years since I published that post, I've gotten a bit more nuanced in how I name my variables. I've come up with a process, a process that I can use to accurately name almost anything.

Problem was, until recently it was very difficult to describe that process to others, though. I just knew, and I didn't necessarily know how I knew. For example, I can look at this declaration and just "know" that it can be made better:

byte[] ctnt = docClass.Content(dID);

After a bit of trial and error, most likely I'll replace those names with the following:

byte[] content = documentRepository.GetContent(docID);

But if anyone were to ask me "why did you rename those variables to those specific names" the best explanation I could come up with was "because these are the only ones that sounded right" which is terribly unsatisfying.

But now, I can answer these questions not with the ten commandments above, but merely one rule: the Golden Rule of Variable Names.

The Golden Rule

So what is this golden rule? It is merely this:

Variable names should be as descriptive as necessary while still being as concise as possible.

That's all there is to it.

"But Matthew" I hear you dear readers saying, "there's still a lot of room for interpretation in that rule, isn't there?" You are correct. Naming things is an art and a skill, one that we gain only through practice and failure. This rule, while very helpful, does not account for all situations, for such a "one and only" rule would be impossible to make.

Nevertheless, it's still an enormously useful adage. Take that earlier example:

byte[] ctnt = docClass.Content(dID);

From the Golden Rule alone, we can make the following conclusions:

The name "ctnt" is concise, yes, but not descriptive. This is not a word, merely a collection of letters, and is easily misinterpreted. We should replace it with a name that accurately describes what it represents.

The name "docClass" is pretty generic. What is this class: a service, a repository, a mapper, something else? We can't tell. We should replace this name with something that tells the reader what this class is generally supposed to do.

The method name "Content" is both readable and concise, but not descriptive enough. What does this method do to the content? Does it retrieve it, or update it, or delete it? We can't tell. We should replace this name with a more active name, something that spells out exactly what this method does.

The variable "dID" is concise but not understandable. Most likely it's the ID of a particular document, what if there are business objects such as "diary" or "dialogue"? We can't know what this is supposed to represent without digging further into the code. We should replace this name with a more descriptive one.

So, by applying the Golden Rule of Variable Naming, we can arrive at a better example:

byte[] content = documentRepository.GetContent(docID);

This is much better than we started with. It is now clear that this line of code is retrieving the stored content of a specific document from some data store.

Summary

The Golden Rule of Variable Naming helps us name our variables in such a way that other people can read our code and more easily understand the intent we were trying to convey. It's not a be-all, end-all rule, but helps us inch closer to the ultimate goal of writing readable code: understandability.

Let's be real: no one has the ability to pay attention to someone talking at them for an hour. Twenty minutes into a boring lecture and more than half the audience will have either tuned out or left. One of the ways you, as a speaker, can keep their attention is to do more than just stand and shout.

If the setup allows, start by moving around the room more. Walk slowly in front of the audience while delivering your talk, as this gives the audience something to do (e.g. follow you) rather than just sitting there passively listening. Make them engage with you, make them move their heads, and their attention will follow. You don't want to go nuts and sprint from one side to the other (more than once anyway), but walking and talking can do the trick just fine.

You can also turn one of the points from an earlier post on its head and ask your audience questions. I do this all the time in my code-heavy presentations; I will set up a demo and ask "will this work, and why?" More than once has an audience member answered this question and reasoned out something that I didn't even consider, and found a better solution than the one I was going to show. You can make your presentations collaborative by asking the audience questions, and listening to their answers.

A presentation is not a lecture, it is a conversation between you as the presenter and your audience. A lecture is formal, an expert explaining to novices. A technical presentation is informal, a colleague showing how they do something to their peers. By allowing the audience to participate in the conversation, by being an interactive presenter, you simultaneously show that you respect their opinion and want their participation, and in return they will give you their attention.

Chat with the Audience Before You Begin!

One of the tricks I use to get to know my audience is to chat with them before my talk. I'll ask them things like "how many of you are from out of town, like me?" These are simple icebreakers that help the audience get to know me, and vice versa. The key thing is to do this before the talk.

One reason I do this is to make my audience feel more comfortable in this room, at this time, with this random long-haired coder dude that's standing in front of them. I want them to feel like they can participate, that I want to hear their opinions and ideas.

I have longer hair and no beard, so I don't look quite as much like a Jedi. Photo by Tavis Beck / Unsplash

Here are some of the questions I have asked my audience in the past:

Where is everybody from?

Is this your first time here at <conference name> (or alternately <city name>)?

How many of you would consider yourselves programmers? How about testers, or designers, or database engineers, or management?

What kind of company do you work for? Are you independent, freelance, a consultant, part of a startup? Does your company have 5 employees, 50, 500, 5000, more?

Of course, don't forget to put your own hand up when the answer includes you.

If the audience feels comfortable, they are more likely to interact with us and remember our content, and that is what we speakers want: to have them learn something and participate in the talk.

Don't Introduce Yourself, No One Cares!

Something that I am still working on getting rid of is the seemingly-compulsory "here's my name, who I work for, and what I do" first minute of any given talk. This is, quite frankly, nothing but wasted time. No one cares who you are, they care about what you can teach them.

If you want to introduce yourself, do it while chatting with the audience before the talk. If you don't do this, stick to "Hi, I'm <first name>, and this is my talk <title>". One sentence, a quick intro, no filler. Get to the content, because that's what the audience is here to see.

Be Funny!

Any given talk needs to have some way of remaining interesting to the audience. People do not have the attention span to keep diligent focus on a single thing for an hour. Regardless, a speaker needs a set of ways to keep their audience engaged, and one of the strategies many of us use is to be funny.

Being funny, or at least amusing, helps your audience remain engaged with you and your content. If they're chuckling, they're more likely to be listening next. You don't have to tell outright jokes (though you certainly can), but you should be unexpected.

For example, in one of my talks I discuss how people might help themselves debug their own code. One of the statements I make during that part of the talk is this:

"This will often help you when you are thinking, 'why does my code not work?' Or, in the worst cases, 'why does my code work?'"

Your talk should not be entirely jokes; partially because that's not useful to your audience and partially because it gets boring after a while, defeating the entire purpose. But a few jokes, at the right time and with the right delivery, add a significant kick to your talk.

This takes practice, and failure. You will bomb on stage a LOT before you start getting chuckles. Keep at it, and as long as your topic is well-researched and useful to your audience, they will stick with you long enough to hear your jokes.

(As a recommendation, I would limit the amount of self-deprecating jokes you include. This style is terribly overdone in technical presenting, to the point where some people just sound like they are actually putting themselves down, not making a joke. A few is fine, a lot is asking for people to feel bad and not laugh.)

Be Enthusiastic!

If you take nothing else away from this post, take this. None of the preceding ideas matter if you don't have any enthusiasm for your presentation! Make sure your audience can see that you actually enjoy talking with them about your topic.

Hey, Mark, how long are they going to sit up there? My shoulders hurt. Photo by Jade Masri / Unsplash

Enthusiasm doesn't mean "jump around the room screeching about how awesome X is"; that will most likely get you thrown out of the room, or at least a few sarcastic five-star reviews. Having enthusiasm means that the audience can see how excited you are to present about this awesome tip, trick, architecture, format, pattern, or app.

Part of being enthusiastic is knowing your topic, and part is being excited to share it. That's why we are speakers! We want to share what we have learned with our peers. The trick is to have your audience know and feel that we enjoy talking about this topic, and there are several ways to show that: by being interactive, by being funny, by not wasting our audience's time. By doing these things in concert, we can show our audience that we truly enjoy being here, with them, in this room, at this time, talking about this topic.

Summary

The most important thing for speakers to remember is to not be boring! That's how you get your audience to tune you out. Don't be boring, and still be knowledgeable, communicative, approachable, and respectful, and you have the makings of your next fantastic technical presentation.

Thanks for reading my Improving Your Technical Speaking Skills series! Everyone has it within them to be a great technical speaker, and yes, that includes you. Get started today, and you will see the results for many years to come.

Even someone who will bring the coffee to all the early morning meetings. Photo by Nitish Meena / Unsplash

This is scary for a lot of programmers. Many of us are introverts, used to dealing with a screen, not a real person. But I urge you all to step out of your comfort zones to do this, because there's no faster way to foster a real sense of community that being available to converse with the members of it.

There are three important aspects of this: always take questions, have places where your attendees can chat with you, and have a place to show off your work.

Always Take Questions

The single most important thing you can do to be approachable to your audience is to take questions. Questions allow your audience to get answers (or at least opinions) on their specific problem, and they make your talk interactive, which (as we'll discuss in a later post) helps improve recall and helps reinforce your throughlines.

But why bother taking questions at all? Most speakers get hung up on a damaging idea: that someone will inevitably ask a question that I do not know the answer to, and so I'll look like a fraud and no one will like my talk.

This destructive thought is merely your impostor syndrome rearing its ugly head. No member of your audience ever expects that you will have every answer! (If they do, you have my permission to aggressively ignore them.) By merely showing up to your talk the audience has already communicated that they want you to succeed, want you to do well.

That is, so long as you don't evade the question, or pretend like you know the answer when you really don't. The BS-meter of your audience is VERY sensitive; they are professional problem-solvers, after all. Don't profess to know something that you don't, because once the audience figures out you don't know what you are talking about you instantly lose credibility with them. Your audience is smart and busy; treat them as such!

When to Take Questions

Exactly when you choose to answer questions can vary by talk, with the most popular options being

Take questions throughout the presentation OR

Take questions only at the end.

I'll occasionally see a hybrid of the two, where the presenter stops multiple times and asks if there are any questions, but only answers them during those times.

Personally, I'm partial to option 1, because it keeps my audience engaged throughout the talk. I have occasionally needed to say "I'll have to answer the remaining questions at the end of the talk" but most of the time I can answer one or two good questions at any given point.

The important point is this: always take questions! They are invaluable in helping both parties, audience and presenter, learn something from the talk.

Be Reachable

Part of being approachable is being reachable, available to chat to anyone who was in your talk (and those who weren't) through a variety of methods.

The first is through social media. For many of us technical speakers, "social media" primarily means Twitter. Twitter is the fastest, easiest (if not the most thorough) way of contacting individuals. If you don't already have a Twitter account, I highly recommend getting one, and using it often.

Other social media (including Facebook, LinkedIn, Slack, Instagram, etc.) are still useful, though IMO not required for technical speakers. They primarily exist as a way for people who have attended your talks (or read your blog posts, or watched your videos, etc.) to get in contact with you should they have questions.

Of course, there's also the old standby, an email address. I would specifically recommend having two email addresses: one for your "professional" life and one for your personal life. The former one I would make known to your attendees, readers, viewers, and others, and the latter I would keep private.

In short, have some way for people who want your opinions to ask you questions outside of your talks, blog, YouTube, etc. Then the trick is: actually answer as many of these questions as you feel is reasonable.

Have a Public Place For Your Work

I would say that this point is just as important as the previous one: have a publicly-accessible place to store your work.

This might take several forms: GitHub for code repositories and sample projects, Sessionize for talks you can give and conferences you've attended, SlideShare for slide decks, even just a YouTube channel. The form doesn't particularly matter; what matters is that you have some place that showcases the kind of work that you do.

I have a feeling that many programmers (might even be most programmers) are introverts, and are thus apprehensive about sharing their work with others. When you work all day staring at a screen that can neither compliment nor criticize you, you might start to wish that was always the case. But I urge you to take the plunge and have some place you can share your work on, primarily because you can now use that place as an addition on your resume.

When you get a new job, people will search for you. Though, if you have a very common name, as I do, there's no guarantee they'll find the correct you.

What’s the biggest problem you have with your name?

My biggest problem?

Ever tried to google for someone with a really common name? You find them, and EVERYONE ELSE with the same name.

You can make this easier on them by providing a place for them to look, and that place should be wherever you store your work.

One other thing that a "work place" provides, and quite possibly another reason why so many programmers don't want to have one, is that people who see your work can submit or suggest changes to it. I suspect that a significant swath of programmers see this as, if not insulting, at least challenging, because they forget that they are not their code. But we as a group need to get over this fear; programming is a team sport, and we must get along with all sorts of teammates.

Summary

A big part of being a better technical speaker is being approachable. Take questions, answer them honestly, have social accounts where people can reach you, and show off your work publicly. Make your audience feel like you are a real person who is more than willing to help them solve problems in your topic.

In the next and final part of this series, we will talk about what is possibly the most important thing for speakers to do during their talks: don't be boring!

Being intentional is knowing what you are going to say, and deliberately choosing words that best describe what you mean. Talks require deliberation, and planning.

Note that intentional does not have to mean planned; you can say things that were not practiced but still add value, and that would still be intentional.

A large portion of being intentional, and possibly the most critical, is choosing what to say first. Whenever you show a new slide, switch examples, or generally change topics, the audience has an expectation that the first few things said or shown to them are the most important. We as speakers need to know and intentionally choose what we say in these occurances. When you change slides or examples, know the first two or three sentences that will come out of your mouth, and practice them.

In addition to being intentional, we as speakers want to use language that is evocative, that causes a feeling in our audience. For example, I have a talk about programming and time management while being a distracted developer. I needed a section of the talk to properly evoke what it feels like to have your mind so overflowing with random thoughts that you can't focus properly.

Ever feel like you just can't focus? I do, all the time. What's worse is that I cannot control it.

But that doesn't convey emotion; it tells the audience what it is like, but they don't actually experience it. After a lot of practice and revision, I changed it to this.

It's a burden, this mental weight I carry. It starts small: "where did I leave that note?" or "what was I supposed to get from the grocery store?" But then the guilt sets in. "I'm so stupid, I can't even remember a simple task." "Of course she's mad at me, I forgot something from the store so now I have to go back." "Of course my kids are upset, I didn't do that thing I promised to do." And it doesn't stop. With each small, trivial thing I forget, the negative thoughts swirl and tighten and squeeze and keep building and building and building and BUILDING until they become... insurmountable.

This is a lot more words, but far more evocative of the feelings I actually get when my ADHD causes me stress. This kind of language sticks with the audience, makes them feel a shadow of what I feel. You want your audience to feel along with you, and the language you use can make that happen.

A significant part of making your presentation intentional and evocative is your delivery; if you can present your talk with confidence, you can convince the audience that you know what you are talking about, and they will believe you. This confidence, in my experience, comes primarily from practicing the content until you're sick of doing so.

Practice, Practice, Practice

There is no substitute to practice. This is true for anything, not just technical speaking. Practice your talk repeatedly, ad nauseum, until you can do it in your sleep.

Practice at home, practice at work, practice in front of your peers, in front of your family, in front of your seven-year-old daughter's stuffed animal collection (yes, I really do this) and then listen to their comments. Practice until you can't screw up, then do it again.

There is no substitute for practicing your talk. Your audience will notice; practice gives you the "polish" on your topic, the shine on your knowledge, the cherry on your information sundae. Further, practice gives you the ability to change certain portions of your talk, to notice where the content isn't what you want it to be, and to make the presentation as a whole more useful, more insightful, generally better than it would be otherwise.

What I generally tell prospective speakers is that it takes 20 hours of research and practice to make a good one-hour talk. A good portion of that time is spent is removing whatever isn't actually necessary.

Delete Anything That Isn't Valuable to the Audience

Much of the work of making a talk intentional and evocative is practice, of course. A large part of the remaining work consists of eliminating what doesn't truly need to be said, things that do not impart any value to the audience.

"Perfection is achieved not when there is nothing more to add, but when there is nothing more to take away." - Antoine du Saint-Exupéry

A presentation of any kind is expected by the audience to be an demonstration of intentional communication; they know we aren't making this up as we go along. We as speakers owe it to them to not waste their time, and part of that eliminating words, sentences, or paragraphs that don't add anything useful to the conversation.

When you practice your talks, I urge you to record yourself and listen back to that recording sometime later (even if, as it is for me, it is painful to listen to yourself talk). This recording will expose the places where you say things that are not of value to the presentation, and once you know where those places are, you can work on either removing them entirely or replacing them with ideas, thoughts, comments, or examples that are actually of benefit to your attendees.

That recording might also prove useful for the next point: we should attempt to reduce or eliminate "filler" words in our presentations.

Reduce "Filler" Words

I guarantee that if you've been at enough conferences, you've encountered a speaker who did not work to eliminate filler words. These are words such as "um," "like," "so," and other which serve to fill pauses in the speaker's presentation, and they become quite noticeable when you are standing in front of a room of a hundred people.

In natural language and normal conversation, filler words crop up naturally to allow the speaker a bit of time to think and form a coherent response to an inquiry. But a technical presentation is not a normal conversation, and we should not treat it as such.

Part of respecting your audience is not wasting their time, and filler words do exactly that. Don't waste your audience's time! Recording yourself (as mentioned earlier) and listening back to it will help you notice when you personally tend to use filler words.

Summary

A large portion of making a technical talk worthwhile to the audience is our ability, as speakers, to communicate our ideas in a thoughtful and interesting way. This might mean using intentional or evocative language to impart a feeling to your audience, removing any topics or words that are not truly necessary, or just striving to reduce the number of times you say "um." You can use many of these methods to improve your own ability to communicate effectively.

In the next part of this series, we will discuss ways in which speakers can be approachable to their audiences, whether that's through asking and answering questions, maintaining a social media presence, or just having a place to show their work.

A big part of being an effective technical speaker is understanding your audience. In this post, we break down exactly who they are, why they are there, and what you can do about it. All of that starts with the most important idea in this whole post...

Don't Waste the Audience's Time

Ever been in a conference talk that turned out to be nothing like what you expected? Maybe the presenter didn't cover the topic they said they would in their abstract, maybe they were too high-level when you expected something deeper, or maybe they were just boring as hell.

Whatever the reason, if the audience feels like you are wasting their time, you will not get through to them, no matter how "compelling" your content is.

This is your audience. That paper is you. Don't be that paper.

So that's the overarching idea of this post: it is paramount to not waste your audience's time. But in order to do that, we must first know who our audience actually is.

Know Your Audience

As a speaker, you should know a couple of things about any audience that shows up for one of your talks. First, they want you to succeed; merely by being present they reveal that they want your presentation to go well and to learn something from you. Second, they expect that you will be the expert on whatever topic you are speaking about, even if you don't know everything. You don't want to prove them wrong.

How many people are asleep in this picture?

There's something else speakers need to keep in mind. Technical conferences are filled with technical people. This might mean developers, QA personnel, testers, managers, DevOps, designers, DBAs, server maintainers, or any of a hundred other specializations that I am certainly not qualified to discuss. What they have in common is that they are all extremely busy people. They do not have time to waste on a presentation that isn't useful to them. In fact, the bolder ones among them will walk out of presentations that clearly aren't going to be useful to them, a trait that should be encouraged by speakers.

Know that your audience are busy professionals. They have chosen to take time out of their conference day, work day, some day to come and see your presentation. Don't make them regret that choice.

A few ways you might make them regret that choice include:

Not talking about the topic you told them you would talk about. I've been in talk where the speaker did not stick to their abstract AT ALL, and around 1/3 of the audience left because none of them found the new topic useful. Don't be that person.

Constantly repeating yourself. Some repetition is good, and key to learning. But constantly repeating what you just said using different words is a great way to allow your audience to take a nap.

Being boring! We'll talk about this particular problem more in the last part of this series.

Respect your audience as the busy professional people they are!

Speak as a Colleague, Not as an Expert

The fastest way, in my experience, to have an audience tune you out is to imply that they are somehow less smart than you. Our goal should be to speak to our audience as colleagues, even as friends, but not as an expert looking to show off their knowledge.

"Simply put, we can clearly improve our site trivially by..." OMG NO.

You don't want to say something like this:

"It becomes obvious that, with this simple change, you can easily implement these ideas to make your system more extensible and reduce the number of security problems you will encounter..."

The main reason to not say something like this is because it won't be simple or obvious or easy for at least some people in the audience. The words you choose to say reveal what you actually think about the topic; choosing words like easy or clearly or trivial suggests that the underlying concepts are easy to understand. What if they aren't? Or, at least, aren't to some people at this very moment? Those people are most likely skeptical of anything you say now, because you made them feel like this was easy, and it isn't to them.

Instead, say something like this:

"See this here? This is an example of how we can implement these ideas we've been talking about. By removing X and replacing with Y, we allow our system to become more extensible while, at the same time, reducing the likelihood that we will have any security problems."

Notice the language here; they describe something tangible, measurable, something that is recognizably a good thing. They say the same thing as the first quote with the implicit bias removed. They make no assumptions about the skills of the audience; rather, they show a clear and obvious way we can improve something.

The language you use during a presentation reveals what you actually think about the topic. Don't reveal that you think it is easy; it had damn well better be easy for you, because you've spent countless hours researching it. The audience hasn't. Don't assume the audience knows the things that you know!

Let Them Leave

If anyone leaves while you are presenting, under no circumstances should you point out that this is happening. I bring this up because I witnessed this happen, though the circumstances will remain obscure.

Walking off into the sunset.

The fact that people are leaving your talk probably has nothing to do with your skill or knowledge. Most likely, they are leaving because the content isn't what they thought it would be, or just won't work for them, or they already know it. It doesn't reflect poorly on you if a few people leave during your talk; the only time you should be concerned is if people leave en masse, all at once, and quite frankly I have never actually seen this occur.

Summary

Your audience is made up of busy people; treat them as such. Respect their time by not wasting it, and respect their autonomy by allowing them to leave unmolested. Speak to them as someone who wants to share knowledge, not someone who wants to revel in knowing. Most of all, remember that your audience are people, people who want to learn and be made better, and that they want you to help them do so.

In the next part of this series, we will discuss ways to communicate your ideas to your audience, ways in which your language can show intent and evoke emotion, and why practice and deletion are two of the most valuable tools in your speaker toolbox.

We're starting a new series today, one that talks about how to improve your abilities as a technical speaker. I firmly believe that within all of us technical people is a presenter who can speak intelligently, concisely, informatively about a topic that we are interested in and enthusiastic about.

I refuse to accept that I refuse to accept my own accomplishments. Photo by Charles / Unsplash

This series (with this post being the first of five) will dive into how to make our talks more thoughful, more engaging, more useful to our audiences. It is my hope that more of you will choose to pursue technical speaking, as it is a fantastic way to learn, share, and become more a part of the wider technical community.

Let's get started!

Be Knowledgeable

All worthwhile technical talks start with a knowledgeable speaker. There is no getting around this: you have to know your sh*t to be able to speak about it. The question is: how can you learn a topic enough to be able to talk about it for an hour?

"So, I'll need everyone's hands for the next part of the demonstration." Photo by Austin Distel / Unsplash

The first goal is this: figure out what are the most important things for your audience to take away from your talk.

Establish Throughlines

A common problem I see with new speakers is that they have the mindset of "well it's all related, so I need to include everything that could possibly be related to my topic." That's a great way to overload your audience and ensure that they don't remember anything you said. Instead, what you want to do is create and thoroughly flesh out two or three "throughlines".

Throughlines are the most important points you audience can take away from your talk. Before starting to write the presentation, decide on the critical throughlines you want your audience to take away with them. These might be "here's five reasons why framework X is better than framework Y" or "here's the three things you need to remember when doing task Z" or "here's the one key reason why soft skills A, B, and C are the principal ones to apply to your career." Whatever the throughlines are, we as speakers want to be sure that they are the ideas the audience leaves the room thinking about.

When you nail down what your throughlines are, remember the following adage:

"Tell them what you're going to tell them, tell them, and then tell them what you've told them."

Some repetition is a good thing in technical talks! Don't be afraid of repeating the throughlines over and over, because that emphasis is what reminds the audience that they are in fact important points, points they should remember and apply to their careers.

The longer your talk is, the more leeway you have in determining your throughlines. For a lightning talk (e.g. 10 minutes or less), you might only want a single one. For a half-hour or hour-long talk, two to five would be doable. For a longer format (e.g. a 4-hour or 8-hour workshop) you might want multiple "sets" of throughlines, each associated to a different aspect of your topic. However long your talk is, it will be that much more useful to your audience if you know, and can communicate, your throughlines to them in a way they will understand.

Once you've got the throughlines down pat, how do you learn what kinds of details and examples you should include in your talk? The fastest way to learn something is to build it yourself.

Do The Research Yourself

Blog posts and YouTube videos have their place in learning, and that place is to inspire people to build, or create, or refine. What they cannot do is be a quality substitute for doing your own hands-on building.

Read blog posts or watch videos related to your topic, and try to reproduce their results with your own code. Take their sample projects and run them on your own system. This kind of setup work will tell you amazing things about how these problems get solved in the real world, and that's exactly the sort of content your audience wants! They want to know "how can I solve a problem I'm having?" not "how did this random person solve a related problem?"

Know About Common Pitfalls

A side-effect of doing the research yourself is that you will most likely encounter problems that the blog posts or YouTube videos did not mention. At this point, you will have to solve these problems by looking elsewhere, either at more posts and videos, or by using your own problem-solving.

Remember this: if you are encountering issues trying to solve a problem, you will almost never be the only one.

These kinds of problems are absolute gold for technical talks, because the people in them are, like you, trying to solve problems in the real world. They don't just want the theoretical solution, they want solutions to common pitfalls as well, fixes to issues they themselves might be encountering. Including this kind of content in your talk makes it that much more robust, and likely to help your audience.

Go Beyond Scope to Handle Questions

When doing the actual talk, stick to the scope you defined with your throughlines. When doing the research, you will want to go slightly beyond that scope. This is because of a feature of technical talks that introduces some randomness to your presentations: questions.

IMO you should always allow for questions from your audience (more on why I believe this in a later post). These questions will almost certainly expand beyond your original scope, so any research you've done outside your original boundaries might be useful in answering them.

However, don't be afraid to say "I don't know" and then try to offer places where the answer might be found.

Know About Further Resources

Finally, a technical speaker should, if possible, know about further resources that might provide answers to questions the audience has and the speaker is unable to answer. This might be a dedicated forum, a Stack Overflow tag, a personal blog, a YouTube channel, or something else entirely. Even if you don't know the answer, you should know a place that will likely give the asker the answer they are seeking.

Summary

The first part of being a better technical speaker is to be a knowledgeable speaker. If you know your stuff and can communicate it well, the audience will leave the room with both appreciation toward you for sharing your ideas and knowledge, and awe at the things they can now accomplish in their own lives.

In the next part of this series, we will discuss how important it is to respect your audience, and how that starts and ends with not wasting their precious time.

]]>I've been making a few upgrades to my blog design recently, and one of the things I've wanted to do for quite a long time was create a "Random Post" link that my readers could click on to browse through my archives.

I've been making a few upgrades to my blog design recently, and one of the things I've wanted to do for quite a long time was create a "Random Post" link that my readers could click on to browse through my archives.

Only just recently was I able to accomplish this, thanks to some very neat features that my blog engine Ghost provides.

That first <script> tag pulls in the Ghost JavaScript SDK that we need in order to run any samples in this post. It is inside the second <script> that the rest of our code will be placed.

The JS code in the second <script> instantiates a class GhostContentAPI, which allows us to call the Content API via a set of methods. This class needs three inputs:

url: The root URL of your Ghost blog site.

key: The API key for this integration.

version: The version number (which always starts with a 'v') of the API call.

The first and third should be obvious, but the second requires some explanation.

The "key" is termed an API key, and you can generate one in your Ghost admin site. Here's how to do that:

In the Ghost admin site, click on Integrations, then click Add Custom Integration.

Create a name for your new integration.

Find the field "Content API Key"; this is the key you need to use the Content API.

If you're wondering why I didn't black out the Admin API Key, it's because this integration is already deleted.

With the API Key in hand, we can create some calls to the Content API to get a random post.

Generating a Random Post

Note: This methodology assumes that a link for the "random" post already exists on the page in question.

There's immediately problem with our quest to generate a random post; Ghost does not provide such functionality natively. There's no random() method or anything like that. Instead, we need to come up with our own methodology to get a random post.

Here's the methodology I went with:

First, get all posts.

Second, randomly order these posts.

Third, use the post at the first index of the array as the "random" post.

The first part is relatively simple: here's the query to get all posts:

Note the call to browse(), with two parameters. The 'limit' parameter says how many posts to return; in this case we want all posts, so the value is 'all'. The 'fields' parameter says which fields that are part of a post object to return; this can be quite a lot of data, so we limit the fields being returned to just the URL and title since that's all we need to create a link.

The second part of this methodology, randomly ordering the posts, is also relatively simple. We need to use something called the Fisher-Yates Shuffle algorithm to randomly reorder the posts. That method looks like this:

Where Do I Put This?

In my blog, this code is injected to the bottom of every page using the Code Injection tab in my Ghost Admin. In your site, you can put it anywhere your scripts would normally be called.

Drawbacks

There's one major drawback of this methodology: if the number of posts is large, this script might be unacceptably slow.

At the time of this writing I have around 330 published posts. In my tests, this seemed to be acceptable in terms of performance, but only when selecting just the title and URL of the posts as show above; including any other fields made the query take seconds longer.

If you're going to use this method on blogs with thousands of posts, you may want to find an alternate option.

Summary

Using the Ghost JavaScript SDK and Content API, we can now select a "random" post and place it in a link.

What do you think of this methodology? Do you see something that can be improved? Please feel free to share in the comments!

Happy Coding!

]]>After a great many years of resisting, it has finally happened. I have joined the dark side.I find your lack of faith disturbing...

I had heard for years (mostly from my teammates) that dark mode helped reduce "eye strain" and that sounded pretty good to me. But partially due

After a great many years of resisting, it has finally happened. I have joined the dark side.

I find your lack of faith disturbing...

I had heard for years (mostly from my teammates) that dark mode helped reduce "eye strain" and that sounded pretty good to me. But partially due to stubbornness and partially to laziness I refused to budge, refused to try out this cool new thing that all my teammates were raving about. That lasted until earlier this year.

For four months now, I've done everything in dark mode if it is available. Visual Studio, Chrome and Firefox, various web sites, my email client, the Ghost editor pages; if it has a dark or night mode, I'm turning that puppy on and relishing the relief it gives my poor eyes. I'm looking forward to the new Dark Mode in iOS 13; my phone is the other device I'm staring at most often and I'm sure Dark Mode will help reduce my headaches even further.

Oh, did I not mention that? I didn't switch because it was the cool trendy thing to do, no, I switched because I getting headaches so frequently I thought I must be bursting out of my skull. At one point I would develop a splitting headache almost daily, whenever I had been staring at my screen for most of the day. I tried several things (both external and internal, ergonomic and medicinal) to get my headaches under control, and while many of those helped, one thing seemed to do the most good: switching all of my applications to dark mode.

I can literally feel the difference. Reading dark text on a bright background now feels like burning my retinas out. Sites which don't offer a dark mode are sites that I leave as quickly as possible. It shouldn't make this much difference, but it does, and I'm surprised at how much I can feel it.

In short, dark mode on my devices has helped me get my headaches under control for several months now. I'm a total believer in how dark mode helps reduce eye strain, as it certainly has for me. I'm living proof that dark mode provides tangible benefits. Problem is: tangible benefits for whom?

What I found surprising while doing some Googling about this topic is that there's no scientific consensus that dark mode is better for your eyes. Optics is a finicky science, and what's good for one person doesn't make it good for another. The only real consensus I could find is that it is contrast, not color, that provides the biggest difference in readability and strain. Black-on-white and white-on-black provide very high contrast, hence why they are the default.

I am no longer surprised as to why my teammates were raving about dark mode years ago. It works for me, and it's definitely helped ease my headaches. I appear to be one of the people for whom dark mode is a benefit, and I am grateful for it. But as with any new fad, it isn't some universal panacea for all people who suffer from eye strain, as much as I (and the companies issuing their own dark modes) want you to believe it is.

But, and hear me out, it is worth trying. I didn't because I figured my headaches had some other root cause, like my posture, and so I missed out on years of less pain and distraction. Don't be like me. Try out dark mode, and if it works for you, keep using it. If it doesn't, go right back to light mode. There's no downside.

I am eagerly awaiting the time where "dark mode vs light mode" becomes the next silly flame war topic, right after "tabs vs spaces", "command line vs GUI", and my perennial favorite "real programmers use X".

(And as soon as I can, I'm going to have to figure out a dark mode for this blog, one that doesn't completely undo the design.)

I do quite a few technical interviews in my current position. Generally this means that I am responsible for determining a candidate's ability to code clearly, comprehensively, and as fulfills the requirements given them.

"Where do you see yourself in five years?" "In your job." [1]

I ask lots of different questions to prospective candidates, most of which I'm not going to share here. But one particular question often becomes useful: the FizzBuzz problem.

This is a common technical interview question that tends to demonstrate if the interviewee can code at all, rather than if they can code well. But given how many candidates can't even write code (yes, this does still happen), it's become a useful tool in my interviewing toolbox.

In this post, we're going to show a definitive guide to answering the FizzBuzz problem, with lots of examples in C#. Let's go!

The Standard Question

In technical interviews, I normally state the FizzBuzz problem as follows:

"You have a collection of integers, 1 to 100. I want you to cycle through this collection. For each number found that is evenly divisible by 3, output the word "Fizz". For each number that is evenly divisible by 5, output the word "Buzz". For each number that is evenly divisible by both 3 AND 5, output the word "FizzBuzz".

What Are Interviewers Looking For?

There are several things that I, as the interviewer, am looking for in candidates who are given this question:

I want the candidates to be aware of the remainder operator. In C#, this operator is the percent symbol %. It gives the remainder of a division operation (So, 5 % 3 would be 2, and 50 % 5 would be 0).

I want candidates to understand the concept of a loop and how to implement one.

I want candidates to know how to output text.

A "valid" solution will do these three things. Exactly how they are done is open for interpretation.

The Basic Solution

Here's a common pseudocode solution for this problem as stated:

GIVEN COLLECTION 1-100
FOR EACH NUMBER X IN COLLECTION
IF X DIVISIBLE BY 3 AND 5
OUTPUT "FizzBuzz"
ELSE IF X DIVISIBLE BY 3
OUTPUT "Fizz"
ELSE IF X DIVISIBLE BY 5
OUTPUT "Buzz"
END IF
END FOR EACH

Two Common Mistakes

Assuming the interviewee can solve this problem at all, they often make one of two mistakes.

Forgetting the Remainder Operator

By far the most common mistake is forgetting what the remainder (aka modulus) operator is. To be fair to them, in my experience this is not a commonly-used operator, and so forgetting it is forgivable depending on how the interviewee ultimately solves this problem. Alas, these people often end up with a solution similar to the one below.

They use the division operator (/) instead of the remainder operator. This poses an issue because those IF statements will now never be true, and hence we will never get any output. In these situations I often have to remind them, gently, of this fact, and more often then not they will reach an alternative, acceptable solution.

Forgetting About Foreach

The second most common issue interviewees have with the FizzBuzz problem is forgetting that Foreach is a construct in most modern languages. They then write a solution using a For loop instead:

There's nothing wrong with this solution, at least not technically; it will output the proper "Fizz" and "Buzz" items. The only thing I'd point out to the interviewee in this situation is that it is a bit more difficult to read. That said, people who provide this solution will, in my mind, be considered to have solved the problem.

A Better Solution

If I'm interviewing you, and I ask the FizzBuzz problem, and you provide me with the basic answer from earlier, I will be completely satisfied with that. It's a good, valid answer, provided you arrived at it naturally and didn't just write it down from memory. However, there are ways you can make this basic solution better.

Let's re-state the problem:

"You have a collection of integers, 1 to 100. I want you to cycle through this collection. For each number found that is evenly divisible by 3, output the word "Fizz". For each number that is evenly divisible by 5, output the word "Buzz". For each number that is evenly divisible by both 3 AND 5, output the word "FizzBuzz".

That last sentence, the one that states "evenly divisible by both 3 AND 5" is a trap statement. I word the problem this way because I want to be super clear about the requirements. Most interviewees interpret this as an order, translating it to mean that there are three conditions (divisible by 3, divisible by 5, divisible by 3 and 5) that must be fulfilled. Consequently they will write the three IF statements from the basic solution.

But in many languages you do not need three IF statements; you only need two. Consider the following:

Notice that there are no longer any "else" keywords. This solution fulfills the requirements as stated. However, the output from this doesn't look very nice:

"FizzBuzzFizzFizzBuzzFizzFizzBuzzFizzBuzzFizzFizzBuzz..."

I've had two candidates reach this solution, and in my mind they have not only completed this problem but improved upon it: they made the code simpler (at the expense of the output's formatting, but since the technical interview is not the real world I will often let this slide).

The reason I will be impressed by this solution is that it shows that the interviewee can think outside of the bounds of the problem defined; that they can think about the code and how to make it better. This is a critical skill for modern software developers, and one that I find is all too lacking.

Of course, if you really wanted to blow me away, you could make some modifications to this answer:

There are quite a few ways to improve upon the basic FizzBuzz solution, and using any of them will impress your interviewer. At the very least, going the extra mile can't hurt.

Summary

The FizzBuzz problem is a commonly-used technical interview question that helps determine if candidates can write code at all. It means to show that the interviewee can write a loop, use the remainder operator, and write to the output. There are two common mistakes, both of which can be avoided. Finally, going the extra mile and improving upon the original "basic" solution is never a bad thing and may even impress your interviewer.

What happens if you step on this? Twist and shout!

As an aside, any interview answers are subject to the biases and expectations of the interviewer, and I am not exempt from this phenomenon. You should not regard my opinions as written here as the only valid ones (hence why this post is a definitive guide and not the definitive guide). The key takeaway from this post is that you should always put extra effort into solving these kinds of problems in a technical interview. Think about the problem, and how to solve it more efficiently, and you'll impress any interviewer worth their salt.

Got another common interview question you'd like to see dissected? Let me know in the comments!

Want more FizzBuzz solutions? Check out this thread on Reddit. Even though the answers are in JavaScript, the meaning should still be clear.

]]>That's all folks! Thanks for reading my new mega-series, The Daily Software Anti-Pattern. I had a TON of fun writing this series, and my hope is that it was useful, insightful, or at least amusing for my readers.

That's all folks! Thanks for reading my new mega-series, The Daily Software Anti-Pattern. I had a TON of fun writing this series, and my hope is that it was useful, insightful, or at least amusing for my readers.

I wanted to close the series with some thoughts that occurred to me throughout the last few weeks in which I was publishing these posts.

...WTF are "microservices" and why are they not just "services"?

"Bad" Is Subjective

Several of the commenters on posts in this series have pointed out, correctly, that many anti-patterns are a matter of opinion, or else aren't clearly defined. That is an inherent problem with the idea of "anti-patterns": what's "bad" is more subjective than what's "good".

Put a bunch of people in a room and ask them to determine what "bad" and "good" are for any given problem set, and I'll bet you'll get far more consensus on what the "good" is than the "bad." This is because the very nature of a problem is that a solution exists. How that solution can be used, whether it fulfills the necessary requirements, and other criteria are what separate bad from good. In other words, "good" is a goal, and is usually more defined than all the possible ways to not meet that goal.

The point of this mega-series is not to discover what is and is not within the bounds of the anti-patterns described, but rather to bring awareness of the terms and, hopefully, some level of awareness as to what might be included in each anti-pattern.

Hindsight Is Necessary

My experience: god objects are not designed in first place, but they are growing into the god object state. Every time the developer has to implement a new feature, it is added in this class, because hey all the data is already here and it is quite easy to add it. Because it is just a new method and a new attribute. Splitting the responsibilities just for this feature would be exaggerated. And some features later you have this class which knows everything and does everything...

In case when you are building a system that is then used as a platform for other systems - then building a platform like thing isn't a bad thing. And there are many cases when building complex platform like thing is the right choise (sic). So I think it is really hard to look at the code and say - this is the inner platform effect. This can be told only after knowing project history.

Very often, anti-patterns can only be identified after-the-fact. No one sets out to write something that falls into an anti-pattern; they only do so accidentally and without malice. Because of this, anti-patterns can very often only be pointed out after they have already occurred.

It's (Probably) Happening To You. So?

If you read this mega-series and thought "these anti-patterns are so general, I need more specifics to determine if one is happening to me," then it most likely IS happening to you. That doesn't mean you need to do anything about it, or at least, not right this second.

The problem with anti-patterns is not a lack of solutions but rather a lack of awareness. Merely being aware that something might be considered an anti-pattern is the first step to being able to solve it when that time comes. After all, you need knowledge and awareness to formulate coherent solutions.

This Is A Blog

Remember that ultimately this a blog, and specifically my blog, and therefore all posts within are subject to my biases, thoughts, and general stance on things. I encourage all of my readers to think for themselves; I am expert on nothing but my own problems, and even then I could use a little help sometimes.

Good morning everyone! Welcome to the Less-Common C# Keywords Tour here at Exception Not Found! My name is Reggie and I'll be your tour guide today. For those of you who are visiting us for the first time, welcome! For those of you who have taken our other tours, welcome back!

On this tour, we will be learning about some of the less-known and less-used keywords in the C# programming language. We'll see plenty of examples you can take back with you, and discuss some of the situations and scenarios that might arise from the use of these keywords.

Please stick together as we make our way through the exhibit halls, and please, if you have any questions, feel free to ask them.

I wish someone would have told me we were having high school tours today. I hope Mike changed that display...

OK everyone, if you'll follow me, we can get this tour over with underway!

Modifier Keywords

Let's begin our tour with a few keywords from the Modifier wing; follow me please.

const

First up is the const keyword, which many of you may know already. It marks a variable as being "burned in" or unable to be changed or modified after declaration, known as a "constant". For an example, take a look at this display:

public const int YearFounded = 2015;

As you can see, the YearFounded constant is now declared, and cannot be changed later, just as our museum's founding year cannot be changed. My coworker Kathleen has a few notes she'd like to share with you about the const keyword; you'll find them right at the end of our tour.

readonly

At the next display we can see some examples of the readonly keyword, which marks properties or fields as being unable to change after their class's declaration. This means they can be set in a constructor method, but not later. Here's an example:

Notice the line in the ChangeAddress() method that is commented out. If we were to uncomment that line, we would get a compilation error, as the property _streetAddress is marked readonly and thus cannot be changed except in a constructor.

Let's move right along down the row to the next display!

static

The static keyword marks a member as belonging to a type, not to an instance of that type. It often adorns methods and properties, but can also be used on operators, events, constructors, and other things. Let's see an example:

static class FunnyWords
{
static string Cow = "Cow";
}

This means that we use the string Cow like this:

do
{
Console.WriteLine(FunnyWords.Cow);
} while (1 < 2) //Forever

So while const makes a property unable to change at all and readonly makes a property of a class unable to change after the class's declaration, static makes a member belong to a type, not an instance. Easy enough right? Right. Moving right along...

sealed

The sealed keyword marks a class as unable to be derived from. That means that a sealed class does not allow any other classes to inherit from it. Here's our example:

class Animal {}
sealed class Dog : Animal {}

Our class Animal is inherited by class Dog, but nothing else can inherit from Dog. We wouldn't want any werewolves running around, would we? No, we wouldn't.

virtual

In the next two exhibits we will see examples for two closely related keywords. The first is virtual, which some of you may have already used in your programs. virtual means that a particular method or property can be overridden in a derived class.

Now, using virtual goes hand-in-hand with using our next keyword, which is just a few steps this way.

override

Whenever a property, method, event, or other item in C# is marked with the virtual keyword, classes which want to implement their own version of that property, method, or whatever use the override keyword to mark their implementation (this also works for methods marked as abstract). The display case to my right contains a simple snippet which builds off the virtual example:

There are a few more examples in this hall, including volatile and unsafe, but in the interest of time and my sanity let's continue on to the next hall. Right this way, please.

Code Structure Keywords

OK, now we can get started with a few examples from our Code Structure wing. To begin, let's.... Excuse me for a moment.

Hey! You two! Get out of that display! Yes, you! I'm looking right at you! Now!

Pardon the interruption. As I was saying, let's see a few examples from our extensive Code Structure wing.

using Directive

I'd be willing to be that many of you have used this keyword before, but how many of you know that it has several more less-known uses? The using directive actually has several contexts where it can be used.

Judging by your rather poorly-hidden groans, I'll refrain from making more puns. You could say I'll be... using more discretion?

OK, OK, that'll be enough puns. For now.

First, when allowing the use of a types in a namespace (most commonly at the beginning of C# files):

Please pardon this display, it appears to have been... tampered with. Let's move quickly on to another example of the using keyword.

using Statement

Gotta come up with some synonyms for "use" real quickly...

While using can be... deployed to those three main scenarios, it also has another common... situation where it can be... employed.

Here's the example:

using (MyContext context = new MyContext) { }

This syntax ensures that objects which implement the interface IDisposable are in fact disposed at the end of the section between the braces. This is particularly useful in programs that use Entity Framework contexts.

Let's see a few more examples of keywords for code structure and how we can... use them efficiently.

break

Ahem. You have almost certainly used the break keyword before, but it is good to review it compare against our next example. The break keyword merely stops execution of a loop, like in this display case to my left:

for(int i = 0; i < 100; i++)
{
if(i == 69)
{
break;
}
}

Quiet please. In this example, the for loop stops when i is equal to 69.

continue

Right next to the break example, and on my right, is the continue keyword. The continue keyword passes the control to the next iteration of the encosing loop...:

goto

Now, you may have heard that this next keyword is the cause of a great many problems in the programming world. I'm here to tell you that's not necessarily true. The goto keyword transfers control to a labeled statement, and though you probably won't use it very much, it is certainly nice to have when you need it.

As you can see, once the, um, desired number is found, we immediately end the search since we got what were looking for.

Let's see one last example in the Code Structure wing thank God.

yield

The yield keyword deals with iterators, and solves a specific problem: how do we return each item from a collection individually?

yield is used in two forms: yield return and yield break. The yield return form returns items in an enumerable-collection individually, and yield break stops this iteration. The display case behind you shows an example:

It's important to note that yield is especially designed for iterators, so if you aren't using one, you won't be using yield.

OK! Let's move on to our last stop on this tour, the Hall of Assorted Keywords. Step this way, please, and stick together.

Other Keywords

Here in the Hall of Assorted Keywords we have assembled a few quality examples of other keywords in the C# langu... Excuse me for a second.

Psst. Greg. Greg! Could you check the men's restroom please? I seem to be missing a few people, and if they're doing what I think they're doing the smell never comes out. Thanks.

As I was saying, this Hall contains a few more useful keywords for the C# language. We'll discuss three of them on this tour. Let's start with the display on my right.

params

Sometimes, we need methods to take an arbitrary or variable number of arguments; this is where the params keyword becomes useful. The params keyword allows us to send a comma-separate list of arguments which get combined into a collection. Let's look closely at the example in the display case on the far wall:

If you'll follow me to the far wall, we'll take a look at our last two examples on this tour.

dynamic

The dynamic keyword is a dangerous one to use, because it bypasses compile-time checking of types, instead doing that check at runtime. This means that your program might treat a dynamic property as being of type int, but there's no guarantee it actually is an integer; it could be a string. Therefore, use caution when using this keyword.

as

Now we come to another keyword you've probably used before: the as keyword. This keyword is used to convert an object to another type, with certain restrictions. For example, the first display shows us how to convert an integer to a double:

You might notice that this is very similar to casting, with one important difference: if the as keyword fails to convert the type to the target type, it returns null, rather than throwing an exception.

With that, we've finished our tour! Finally!

Summary

Thank you for coming on this tour! To recap, here's the keywords we discussed today:

const: Declares a "burned-in" value.

readonly: Makes a field read-only.

static: Denotes a property of a type, and not an instance of that type.

sealed: Denotes a class which cannot be inherted.

virtual: Denotes a method or property which can be overridden.

override: Denotes an overriding implementation of a virtual or abstract method or property.

using: Declares types in namespaces usable in the current file.

using static: Allows usage of static members of a class.

using clause: Disposes an IDisposable object at the end of the clause.

break: Ends the execution of a loop.

continue: Ends the current iteration of a loop, starts the next iteration.

goto: Transfers control to a named label.

yield return: Returns individual items in an enumerable collection.

yield break: Stops the iteration over a enumerable collection.

params: Allows for an arbitrary number of parameters to a method.

dynamic: Allows a property to bypass type checking at runtime.

as: Attempts to cast a value to a different types, and returns null if that fails.

Please feel free to stop at the bookstore on your way out; there are quite a few useful books there that'll teach you a bit more about the C# language and keywords. One of my favorites is Professional C# and .NET Core 2.0 by Christian Nagel; check it out if you think you'd like to develop web application with the .NET Framework.

The bus will be here to take you back to school in about thirty minutes; for now, please enjoy the rest of the museum. Have a great rest of your day!

Phew! That could have gone better. Now, where's Mike? Ah. Mike! Would you kindly come here for a second? I need to have a word with you about those displays you seem so fond of...

I had a conversation this morning with one of our QA testers that could have gone south really quickly, and I'm very glad it didn't. It didn't largely because I presented our solution to them visually, proving that a picture really is worth a thousand words.

The Wordy Problem

We're developing an app which allows us to help our customers more quickly. I know that's super vague, but NDAs and all and I like not being in prison so don't @ me. This app has the ability to edit and maintain certain information voluntarily given to us, but in its current design it looks like FontAwesome had a sneezing fit:

My team and I, after a bunch of deliberation and negotiation with our product owner, decided that we needed to significantly reduce the number of icons on this page. I eventually got them to agree to removing the Edit functionality altogether, and reducing the Add functionality to only two lines. As I was given the green light to proceed with this, I made a few feature requests and we were off to races.

Problem was, I neglected to tell our QA testers this was happening.

See, the old, too-many-icons design was still "new" so it was still under testing. Because the two sets of Add icons weren't behaving identically, and because we hadn't actually removed the excess items yet, QA was failing our tasks because nothing behaved in a consistent, predictable, prescribed manner.

That, by itself, was not a problem. Tasks get failed all the time, we fix them, QA tests them, the circle of life continues. No, the problem was that the two groups could not find the words necessary to communicate what they meant, particularly since our primary means of communicating is over Slack.

This had nothing to do with fluency; everyone on all sides is fluent in English, both verbally and written, even if it isn't their first language. Rather, it had everything to do with the fact that communication is stupid hard and doing it effectively in the heat of the moment is nigh impossible. The QA lead did not understand that she did not need to test these now-extraneous features, and my team (myself included) did not understand that due to the way our task items were written she was compelled to test these things she didn't actually need to. We had our wires crossed.

A Visual Solution

I've had problems like this before. Humans are visual creatures; we want you to show us and not tell us, and despite what many self-righteous bloggers will yell at you developers are still human. So, I showed the QA lead this screenshot, which I made in five minutes in MS Paint:

She immediately got it. She told me what to do so that her team could not test these items, and we all got back to work. All the words we could write were nothing compared to a rush job in Paint.

Communication is hard; communication about design is doubly so because design is an inherently visual endeavor. We'd have spent a lot more time arguing about what to do if we'd just stuck to words.

So, in short: Developers, learn to use Paint! It'll save you a ton of arguments!

Or you could, you know, just use the appropriate form of communication for the issue you are trying to get across. That would work too.

There's a new guy on my team, a guy we just recently hired straight out of college. He's pretty smart, quick on the uptake, and generally been a valuable addition to our team. Best of all, because of him I suddenly find myself on the defensive.

He's peppering me with questions like "why did we do this thing this way" and "what purpose does this serve" and making me defend my decisions. And I consider it a high honor that he does so.

To be fair, a small part of me is rather annoyed at him. Part of me, that worst part of me, wants to tell him: "Dude, stop with all the questions, you'll learn them eventually; you just got here, sit down, shut up and code."

But the rest of me, most of me, is grateful. The rest of me knows that I need this, that I need the new ideas and new philosophies and new questions. I need people to ask me "why?"

That's the most powerful question in the world: "why?". Why does this behave that way? Why do languages choose to be strongly-typed or not? Why do frameworks include this feature and not that one? Why do babies come from mommies's tummies and not daddies's? (That was a real question from my five-year-old). Why does anything ever work?

That question, "why?" has untold powers. It explains progress, propels science, causes depression, starts arguments, stirs debate, kindles passion, forces negotiation, brings out the best ideas and the worst. It powers all facets of the human experience. You could even argue that the ability to ask "why?" is what makes us human.

It's a small wonder then why some people want to shut it down.

The question "why?" is an unspoken threat, unintentional but a threat nonetheless, to people who already have power, to people who are in charge. It forces them to examine their behavior, their decisions, their actions, to think about the reason they are doing something and reckon with the idea that maybe, just maybe, it wasn't the best idea in the first place. Being asked "why?" forces people to inspect their own faults and insecurities, and they don't always like what they find.

But, if you are in a leadership position, you need people to ask you why. Unless you are infallible (and if you are WTF are you doing here?) you will not always have the perfect idea, the right direction, the appropriate response. There will be times when you are wrong, when you have incomplete information. It is in those times when you have to ask "why?"

The tricky part is ensuring that others feel comfortable enough to ask "why?" when they need to. As a leader, it is our job to ensure that junior-level developers in particular feel comfortable enough to ask "why?" This is not an easy thing to do.

So, let me try to make it simpler. Here's are four rules I've been quietly implementing at my workplace for my team. Even by just applying these rules to myself I can already tell that my team feels more empowered to ask "Why?" than they have before. I'll bet they'll help your team as well.

Don't disparage the asker. Ever. There is no faster way to create a toxic environment than to tell people they're stupid (or lazy or any other form of "not good enough") for merely asking questions. Unless you want to a) have your teammates secretly resent you and plot your eventual downfall and b) miss out on all their potentially-brilliant ideas.

Don't disparage the question. This is totally separate from not disparaging the speaker; I've seen a lot of people in power take great pains to not put-down a person (often in the name of an "inclusive environment") but instead mercilessly mock the question itself for being too dumb, too simple, too easily Googled for. If the speaker feels a need to ask, assume until proven otherwise that they have tried to find the answer already, but don't have the information or experience necessary to do so effectively. You can infer or suggest that they Google a bit before asking next time, but there's no need to be harsh about it.

Always assume best intentions. It is entirely possible, even probable, that the asker simply has no idea how to even begin finding the answer they are searching for. Keep in mind one of my favorite adages, Hanlon's Razor: "Never assume malice for what is adequately explained by ignorance."

Ask them questions. Model what you want them to do. Have them defend their decisions (gently). Point out areas of concern, corner cases, situations they may not have accounted for. By proposing these sorts of questions to them, you force them to either explain the plan they've already got to handle them or learn a bit about what to plan for.

Programming is a team sport. Individuals succeed when the team succeeds, and a team succeeds in a welcoming, inclusive environment. Creating that environment is the job of the leaders, the managers and leads, the people who set the tone. My job.

If you're in a leadership position, it's on you to create that welcoming environment, one where juniors and seniors alike are free to ask questions without worrying about being made out to be stupid, or lazy, or not good enough. A good environment is worth far more than a high salary, and you can create that environment.

Just watch out for inquisitive five-year-olds with questions about babies. Or don't. After all, sometimes being on the defensive is when we learn, and teach, the most.

Anyone can create a technical talk. Yes, even you. Here's the 10-step process I use to make my technical talks the best they can possibly be.

1. Settle on an Idea

This is usually the step that takes the longest. There are a LOT of technical and programming conferences today, and a lot of attendees for them. On the one hand, that's wonderful, because most people can find one near them to attend. But on the other hand it also means a lot of speakers, both new and established, and a lot of topics. Ultimately this results in prospective speakers (like myself) needing to find ideas that a) we know enough about to be able to talk about, b) are interesting and c) aren't already presented better by someone else.

The time involved in this task varies for different people. For me, I want to be as engaging as possible while also still being able to teach something. That means that my topics have to be stuff I'm familiar with (you'll never see me teaching a course on Kotlin, because I have no idea what that is).

The trick is that while ideas may be shared by many people, experiences aren't. Experiences make for engaging technical talks, because everything you know is something someone else doesn't. If you want to make a new talk, start looking at your experiences first.

2. Find The Goal Of Your Talk

Here's a dirty little secret of technical talks and public speaking in general: no one will ever remember all the things you said. You'll be lucky if your attendees take away just one thing from your talk that they can apply to their life and career. This one thing, the one idea you want your listeners to be able to use, is the goal of your talk.

To be honest it is super tricky to figure out what that goal is. It could be "here's a tip for the newest JavaScript framework" or "here's a best practice that saved my butt twice over" or "here's how my team built our project on time and on budget and you can do it too". You might now even know what it is when starting to write to your talk. But knowing what you want your attendees to take away from your talk makes the next several steps that much easier.

3. Make an Outline

Once you've got a goal for your talk in mind, you can start writing up an outline. Never jump full-bore into writing a technical talk without an outline, even if you've got a killer idea; you'll give up before getting half way. Instead, make a list of the points you want to talk about, and how each is applied toward the goal of the talk; these two items are important in equal measure.

Ever heard the adage, "weeks of coding will save you hours of planning"? Well, weeks of writing will save you hours of outlining. Take the time to make a plan!

4. Be Entertaining!

This is the step most often forgotten in technical talks. Here's the thing: talks are entertainment first and teaching second. You can be as helpful as you like, but if you're not entertaining you'll lose your audience at some point during the talk, and that's the worst thing that can happen for you as a speaker. Being boring is a death knell to speakers. Don't be boring, be.... not-boring!

This is Step 4 in this process because being not-boring takes planning and practice. The form of this entertainment could be many things: tell jokes, tell stories, use memes, do something to break the monotony of having to listen to the same person for an hour. The absolute worst thing you can do when giving a technical talk is to be boring! Delivering a technical talk is a performance. Use any tools at your disposal to make your performance as not-boring as it can possibly be.

5. Write a Script

Once you've got your goal, outline, and entertainment options, you are now ready to write a script your talk. This step varies quite a bit; many speakers I've interviewed are comfortable with a simple outline and a few jokes before stepping on stage. I am not one of these people. Consequently I have a tendency to write an entire script for my talks.

This script doesn't need to be as detailed as, say, a movie script. It just needs to show the important points, tips, and stories you're going to use. You could even list the maximum time you want to spend on certain sections.

The real trick, though, is that you might not even need the finished script. The mere act of writing it will cement the points you want to make in your mind, and for many people (myself included) that's enough to be able to deliver it effectively. But if you do need it, put it somewhere discrete but easily accessible when it comes time to deliver your talk.

6. Revise...

With the script written, it's time to throw it away. Not even kidding.

The first pass at your script is probably garbage. It'll be a jumbled mess of half-formed ideas, flat jokes, meandering stories without a point, and other boring junk. Once you've finished it, leave it alone for a few days and come back to it, and you'll see just how terrible it is. Now is your chance to make it better. As you make changes, you'll start to see how best to deliver your ideas, how best to be entertaining.

Most software development teams develop their code iteratively: write it, test it, use it, fix it till it doesn't break anymore (Daft Punk songs being optional). Talks are no different. In fact, there will be several points during the life of a talk at which you'll do revisions, up to and including five minutes before you are scheduled to perform. Accept them; they'll probably save you once or twice.

7. Practice

I cannot say this more clearly: by the time you are scheduled to deliver your talk you should have already practiced it multiple times. DO NOT go on stage having never practiced your talk, because it will be immediately and incredibly obvious to your attendees. If you don't care enough to practice your performance, why should they care enough to listen?

Instead, do a series of dry runs, whether in front of people are not. In my case, I sometimes deliver talks-in-progress to my five-year-old daughter's stuffed animals, because I know they won't hold back with their criticism.

What? That monkey is vicious. Might as well get the toughest critic out of the way.

In any case, practice your talk! Several times, preferably. Believe me, it make a huge difference.

8. ...and Revise Again

Yes, revisions are two different steps in this process. You should always be making incremental improvements to your talks (for whatever you define as an "improvement"). By keeping your talks as up-to-date as feasible, you make them more useful to attendees. Revise as often as necessary!

9. Practice the Final Talk

Practice is also two steps, because it is the only thing standing between you and the embarrassment of "um, hang on, let me find my notes, now where were they again?"Photo by Rob Bye / Unsplash

Once you've revised multiple times, you can settle on a temporarily-final version that you can practice in full. Whether you practice this in front of people or stuffed animals doesn't matter, just practice it until you're comfortable with it.

10. Perform

This is it. The moment you've been preparing for, the performance of your life! Or, at least, the performance of your last two weeks.

This is where it all comes together: the goal, the outline, the not-boring jokes, the practice, the revisions, all of it builds to this moment and this place. It is now that you can go out on stage and rock your performance. Or, more likely, elementary-school-band your performance.

If this is your first technical talk or your hundredth, you are going to stumble, to lose your train of thought, to mix up words. At one of my talks I mentioned my beloved wife K.C. but totally spaced on the words "wife" and "spouse"; I ended up calling her "person that I live with" and then pointing fretfully to my wedding ring. I must have looked like an idiot.

You will probably end up looking like an idiot at some point. But the resolve you show by merely standing on stage more than cancels that out.

Take the performance slowly. Remember to slow down, to take breaths, to drink water if you need it. You've already done the hard part: the planning and practice. All that's left is to show your attendees that you know something, that you're willing to share and learn and grow with them. That's all attendees want: to learn something, and to be entertained. If you give them that, you've already won the battle.

Summary

Creating a technical talk is hard. It takes planning, goal-setting, practice, revisions, and at least an attempt at being not-boring. But anyone, anyone, can do it. Yes, even you. Keep these steps in mind as you create your talks, and you'll hopefully find, as I have, that your talks will be funny, engaging, useful, and attended.

Did I miss a step in the process above? Am I totally off my rocker? Did I forget a synonym for "spouse" that you feel a burning desire to inform me about? Share in the comments!