Speaker Tip: Start Your Timer Now!

Many speakers use a timer. This helps you stay on track and not run over. I know some speakers who set up a tablet or phone with a countdown timer. A few years ago, I picked up a Logitech presentation remote with a built-in timer (it's a bit well-worn now):

1 hour talk (don't do this)

I like this remote because it buzzes at me when my time starts to run down. But when I was learning to use it, I made a big mistake. I would set it for 1 hour (or however long the presentation was supposed to be), but then I would forget to start it.

Then I picked up an awesome piece of advice (I heard it from Kathleen Dollard):

Don't set the timer for the length of the talk. Set it for how long until the talk ends from now.

So if the talk is one hour long, and it starts in 7 minutes, set the timer for 1:07 and then start it now.

1 hour talk that starts in 7 minutes (do this!)

This means that you start the timer while you're thinking about it -- because it is way too easy to forget to start it when you're worrying about starting your presentation. As an added bonus, it helps you remember when you're supposed to start talking.

Since I started doing this, I've never forgotten to start my timer.

Happy Speaking!

February 2016 Speaking Engagements

I'll be speaking at a number of user groups in February. Be sure to stop by if you get a chance.

Tuesday, February 2, 2016
LA C#
Pasadena, CA
Meetup Link
o Unit Testing Makes Me Faster: Convincing Your Boss, Your Co-Workers, and Yourself

Wednesday, February 3, 2016
So Cal Dot NET
Buena Park, CA
Meetup Link
o I'll Get Back to You: Understanding Task, Await, and Asynchronous Methods

Tuesday, February 9, 2016
Ontario C#
Ontario, CA
Meetup Link
o I'll Get Back to You: Understanding Task, Await, and Asynchronous Methods

Wednesday, February 10, 2016
vNext OC
Newport Beach, CA
Meetup Link
o DI Why? Getting a Grip on Dependency Injection

Thursday, February 25, 2016
DotNet Group.org
Las Vegas, NV
Meetup Site
o Learn the Lingo: Design Patterns

Past Events
I stayed pretty busy in January -- mostly because I was traveling (on the road for 15 days).

First, I headed to CodeMash in Sandusky, OH. This was my first opportunity to go to CodeMash, and I stayed pretty busy throughout the week. There were tons of people to talk to and lots of great sessions. I had a good time presenting on how to get the right level of abstraction in our applications:

At CodeMash talking about "Abstract Art"

I also built a really sad robot in the NodeBots workshop:

Built a rather sad robot at #CodeMash nodebots. Not bad for a first try. I guess I need some practice. pic.twitter.com/bmkSci3P9U

— Jeremy Clark (@jeremybytes) January 7, 2016

As if going to one conference isn't exhausting enough, I hopped on a plane and flew from Ohio to London for NDC London. It was my first time in London, so I took a few days to go around the city. I got to see things that were pretty amazing, including the National Gallery, Trafalgar Square, Tower Bridge, the British Museum (including seeing the Rosetta Stone!), standing on the Prime Meridian at Greenwich, and walking across the London Bridge. This means that I've walked across *both* London Bridges -- the one in Lake Havasu City and the one in London.

NDC London was a really awesome conference. I had a lot more people attend my presentation on Task and Await than I was expecting.

A full room at NDC London

I had a really great time (as usual). Thanks to folks on Twitter for the pictures (@ChrisAnnODell, @jakegreenwood, @jplebre):

At NDC London talking about Task and Await

I was also very happy to see the response:

Look at all the green!!! :) @jeremybytes #ndclondon pic.twitter.com/ZJ30ErigCy

— Anthony Chu (@nthonyChu) January 15, 2016

The total counts for my session were 157 Green, 7 Yellow, and 0 Red.

This past week, I went to Riverside, CA to speak at IE.NET. I had a great time talking about one of my favorite topics: Interfaces.

At Inland Empire .NET in Riverside, CA

Upcoming Events
My calendar for the rest of the year is starting to fill in. At the end of March, I'll be at Code PaLOUsa in Louisville, KY. In May, I'll be at Visual Studio LIVE! Austin in Austin, TX. And I've been invited to speak at NDC Oslo in June in Oslo, Norway. (My picture is currently on the front page!)

In addition, I'll be speaking at user groups in Southern and Central California. If you'd like me to speak at your Meetup or developer event, be sure to drop me a note. I've got tons of topics that I'm passionate about, and I'm adding to the list all the time.

I hope to see you at an upcoming event.

Happy Coding!

The Evolution of INotifyPropertyChanged

When we implement the INotifyPropertyChanged interface, it's pretty common for us to copy code from a previous implementation or use a shared base class. What we don't normally do is review the code that we've been reusing.

But there are some features in .NET 4.5 and 4.6 that we can use to improve our implementation. Let's take a look at those to see how we can reduce our code without reducing functionality or safety.

Update: As Andrew points out in the comments; this article previously used the incorrect terminology for the null-conditional operator "?.". This has been corrected.

A Bit of Background
I really love data binding in XAML; it's extremely flexible and powerful. But in order for data binding to work appropriately, we need to implement the INotifyPropertyChanged interface in our data classes.

Original Implementation
The INotifyPropertyChanged interface only has a single member: the PropertyChanged event. To make it easier to raise this event, it's pretty common to create a helper method. Common names for this are "OnPropertyChanged" or "RaisePropertyChanged" (I prefer "RaisePropertyChanged").

So here's an implementation that I use to use:

Original Implementation (could be better)

This shows our helper method (RaisePropertyChanged) that takes the property name as a string. This is used to create the event args and then invoke the event.

This notifies the UI that anything bound to this property needs to be updated. If the event is called with a "null" parameter, then it is the same as notifying that all the properties have been updated.

To raise the event, we call "RaisePropertyChanged" in the setter for our properties:

Original Property Implementation (pre .NET 4.5)

If the value of the property has changed, then we set the property and then raise the event using a string value for the parameter.

Safer Implementation
This code worked, but it can be improved. First, let's look at it from a thread-safety perspective. It's possible that the PropertyChanged event could be updated in between the null check and the code to invoke the event.

To make things safer, we should use an intermediate variable:

Safer Implementation (pre .NET 4.5)

By using the "handler" variable, we create a copy the PropertyChanged event. Since this is a local variable, we know that it will not be updated in between the null check and the invocation of the event.

This gives us a thread-safe implementation of our "RaisePropertyChanged" method. (Again, thanks to Brian Lagunas for pointing this out to me.)

Improvements with .NET 4.5
The previous code works, and it will continue to work, but it does have some shortcomings. First is the use of the string parameter.

Original Property Implementation (pre .NET 4.5)

Hard-coded strings are rarely a good idea. If we happen to type the string incorrectly, then the data binding will not work as expected. This is especially frustrating to debug because there are no runtime errors; the UI elements are simply not updated like we want them to be.

In addition, if we change the name of our property, we need to make sure to update the string as well. Refactoring tools have gotten better; many of them have the option to update strings and comments when we rename a property. But it's possible to miss updating the string parameter.

Using the CallerMemberName Attribute
In .NET 4.5, we got a new attribute that can help us with our string problem: CallerMemberName. You can get a full description of how it works here: Using the CallerMemberName Attribute for Better XAML Data Binding.

The short version is that we can add the attribute to our INotifyPropertyChanged implementation:

Implementation with CallerMemberName Attribute (.NET 4.5)

Notice the attribute before the parameter. This value will automatically be populated with the name of the object calling this method.

Note: This is the non-thread-safe version of the code (it's taken from the example code in the article mentioned above). We should add the intermediate variable to make things safer.

With this new attribute in place, we can now update our properties as follows:

Property Implementation with CallerMemberName (.NET 4.5)

Notice that when we call "RaisePropertyChanged", we no longer pass in a parameter. Instead, we rely on the fact that "ProgressPercentage" (the name of our property) will automatically be passed because of the "CallerMemberName" attribute.

This gives us the advantage of no longer having a hard-coded string in our code. So we don't have to worry about typos or missed updates if we rename things.

Improvements with Visual Studio 2015
The previous code works (and will continue to work), but there are a couple of new features that came in with C# 6 that we can use. Since this is language/compiler related, we can use these with earlier version of .NET as long as we use the Visual Studio 2015 compiler to build the code.

"nameof" Expression
The "nameof" expression can get us the string name of a variable, type, or member. This is new in C# 6. Check out MSDN for more information: nameof (C# and Visual Basic Reference).

This lets us create our properties like this:

Property Implementation with "nameof" Expression (.NET 4.6)

Instead of passing a hard-coded string to "RaisePropertyChanged", we use "nameof" to generate the string for us. The end result is the same: we will pass the string "ProgressPercentage" to our method. The difference is that we will get a compile-time warning if we typo "ProgressPercentage" since this references the property.

In addition, if we use a refactoring tool to rename our property, the reference in "nameof" will get updated as well.

Using "nameof" will work with or without the "CallerMemberName" attribute.

Null-Conditional Operator
Another feature of C# 6 that we can use is the null-conditional operator (also called the "Elvis operator"). This takes of the form of "?.", and it combines a method or property reference with a null check.

Let's look at our INotifyPropertyChanged implementation to see how this operator works:

Original Implementation (could be better)

Compared to:

Implementation with "?." (.NET 4.6)

If the "PropertyChanged" event is null (meaning there are no event handlers hooked up to it), then everything after the "?." is ignored.

If "PropertyChanged" is not null, then the "Invoke" method is called. Note: calling "Invoke" explicitly is the equivalent of calling "PropertyChanged" with the parameters in the prior example.

The best thing about the null-conditional operator is that it is thread safe. This means that we no longer need the intermediate variable that we use earlier. So we end up with a very compact method that is thread safe.

Combining Features
We can also combine the "CallerMemberName" attribute with the null-conditional operator. Whether we do this depends on how we want to do our property code: either using no parameter or the "nameof" expression.

Reviewing Implementations
It's really easy for us to keep using the code that we're comfortable with. The "INotifyPropertyChanged" interface is especially prone to this. It is treated like boiler-plate code that has a consistent implementation. Because of this, we don't often review the code (as long as is continues to work).

I've described a very simple implementation here. Often people will use a base class or more involved implementation to make it easier to create properties. You can check out Dan Rigby's series of articles for some options on that.

From time to time, we should take a look at our boiler-plate implementations to see if they can be improved. In the case of "INotifyPropertyChanged", the "nameof" expression makes our code less brittle and easier to maintain. In addition, we can use the null-conditional operator to improve readability while still maintaining thread safety.

We'd never know about this without taking time for review.

Happy Coding!

Being Present

Sometimes we make decisions unconsciously, but we'll read an article or someone says something that makes us reflect on those decisions. I've recently come across one of those decisions, and I'm looking for ways to follow it consciously.

So this is not really a resolution, but it's more of a continued intention:

I will be present at every event.

What does this mean? As a speaker, I will be present for the entire event so that I have plenty of time for interaction with other people (and also time to learn new things from other speakers (and attendees)).

Background
I started speaking back in January 2010. That first year, I spoke at 8 events and only 1 of those events was outside Southern California. In 2015, I spoke at 28 events, and 13 of those were outside So Cal. So I was on quite a few airplanes and away from home a bit more than usual.

During those 6 years, my interaction with other speakers has also changed. When I originally started, my circle included primarily local speakers -- folks who would speak at 2 or 3 events a year in their local development community. As time went on, my circle grew to include regional speakers and folks who travel to major events in the US. And in the last couple years, my circle has grown to include people who speak across the US and internationally, and they spend much more time on airplanes than I do.

I've noticed a few things this past year that helped me focus my priorities.

Before going any further, I want to put in a disclaimer. I've been thinking about this article for quite a while, and I've had trouble figuring out how to write it. One reason is that I'll be referring to behaviors of some other speakers. I don't want this to come across as disparaging of those behaviors. Everyone is different and has different priorities. I'm making my decisions based on my own priorities.

Not Available
One of the things I've run across several times this year are speakers who fly in, do their presentations, and then fly out.

I always go through the speaker list for any event that I'm speaking at, and I make notes of folks that I've wanted to meet and talk to. I figure that we'll be around the same conference for 3 or 4 (usually very long) days, so I should have a chance to meet at some point, even if just for a few minutes.

But then the only place I'll see that person is during their presentation. And I don't usually go up after presentations because I want to give other folks a chance to talk to the speaker -- I'll wait for another opportunity. Unfortunately, that opportunity doesn't come.

Now obviously, that's a bit selfish of me because I'm thinking about my own disappointment. But I compare that to my priorities and what I what kind of accessibility I want people to have to me.

The reasons for the inaccessibility are many. Some speakers are horrendously busy -- sometimes doing 2 events the same week. Some speakers want to minimize time away from home and family (which is an awesome priority). Some speakers are not comfortable talking to people when they're not on stage. Some speakers have time-sensitive work to do while they are at an event.

Again, I don't want to disparage these decisions or priorities. I'm just using them as a reference point for my own priorities.

Talking to Other Developers

I've made it a big priority to talk to other developers. It was difficult for me to do the first few times, but I've seen so many benefits that I push down my discomfort and shyness to talk to people whenever I'm at a developer event.

And I've been doing my best to encourage other developers to give it a try: Becoming A Social Developer: A Guide for Introverts (and the podcast, and the website).

Especially Important for Speakers
I think this concept is especially important for speakers. There's a tendency for conference attendees, especially at professional conferences, to think of the speakers as special or gurus or geniuses. I know that I used to think of speakers this way (when I was just an attendee).

But speakers are just people who share things that they know. And just because we talk intelligently or authoritatively on one topic doesn't mean that we can do the same thing with *any* topic -- and I think that's the major misconception.

Joe Guadagno (@jguadagno) wrote an article about this earlier this year: Speakers are not Idols. The vast majority of speakers that I know and interact with are like this. They are developers who like to share what's made them successful. But they aren't perfect, and they really aren't that much different from the majority of attendees.

As a speaker, I want to make sure that people are comfortable talking to me. And often, that involves me going up to talk to people in the hallway or lunch line.

Not Available at an Event
I didn't realize how important this was to me until earlier this year. I spoke at a corporate event, and I came in, did my presentation, and left. That was the organizer's choice; if it were up to me, I would have loved to hang around for lunch (which was right after my presentation) to have a chance to speak to the attendees. I didn't realize how much I missed that interaction until I was back at my car. Something just felt really incomplete.

Being Present
My intention is to be present at every event that I speak at:

• I will be onsite for the duration of the event. 
• I will make myself as available as possible. 
• Even if I need to get work done in the speaker room, I will be out in the hallways during session breaks.
• This also means that I will be available at the noisy, crowded receptions that clash with my introvert nature (although I reserve the right to find a small group of people to go have coffee with in a quieter location).

Tough Decisions
This means that I will have to make some tough choices. But I'm okay with that.

Missing Events
This past year, I missed the So Cal Code Camp in Los Angeles. The event was on a Saturday & Sunday, and I was flying to another event on Sunday morning. I thought about attending part of the event (just on Saturday). But I decided against it.

It was a tough decision. But I knew that if I went, I wouldn't really be "present". I would be thinking about my travel plans and packing and the next event. I could have "given my presentations and left", but that's not the impression I want to leave with people.

I wish I could have gone to the event, but I don't regret my decision.

Reduced Opportunities
One thing that helped me get some perspective was a tweet sent out by Cory House (@housecor) earlier this year. It's an article from 2009 from Derek Sivers, but it's still very relevant: No more yes. It's either HELL YEAH! or no.

After reading this article, I did start to change my behavior. Since I've started speaking, I've been trying to expand my reach (meaning, speaking at larger events in different parts of the country/world). Part of my strategy was to take the shotgun approach: send in proposals to as many conferences as I can and speak at any opportunity that comes up.

But I've since focused my approach:

Rather than applying to "any conference that will take me", I've narrowed it down to "conferences that I want to attend".

This makes things a bit harder. If you get rejected from a conference you really didn't want to go to, then it's not a big deal. But if you get rejected from a conference you really wanted to attend, then it's a heavy blow. But ultimately, this is better for me, and it's better for my potential audience.

Fewer Events
This also means that I may be at fewer events. Multi-day or week-long conferences take up more time and effort, so I may end up doing fewer of them. But at the same time, this gives me an opportunity to focus on the people who will get the most out of my presentations. So I'm looking for an overall positive outcome.

Awesome Experiences
In 2015, I had some really awesome experiences. Fortunately, every event I had a chance to go to was something I was excited about. And I did turn down an opportunity to speak that wasn't as exciting (turning down a speaking opportunity was something new to me).

Everything that I have on my calendar for this year is something I'm excited about. This month, I'm going to CodeMash. This is a conference that I've heard great things about, and I've wanted to go for several years. (It's hard to believe that it's next week.) And the week after, I'm headed to NDC in London. Again, NDC is a conference that I've heard really good things about, and I'm excited about getting the opportunity to speak and attend.

A Great Year of Being Present
I'm really looking forward to this year. There are a lot of events that I'm excited about. I won't get into all of them (and that will be a big disappointment). But for the events I do attend, I will be present -- available to talk to as many people as possible.

This isn't really a change in my behavior, just an intentional focus. It's always good to review what we've been doing, figure out where we want our priorities, and adjust as necessary.

Happy Coding!