September 2015 Speaking Engagements

It's hard to believe that it's September already. I have a couple of speaking engagements scheduled in the Phoenix area this month. And there are a few more beyond that.

Wednesday, September 23, 2015
Northwest Valley .NET User Group
Glendale, AZ
Website
Topic: I'll Get Back to You: Task, Await, and Asynchronous Methods

Consuming asynchronous methods can be confusing. But not for long. We'll look at how to use Task (along with continuations, statuses, and schedulers) and also async/await. I share some of the gotchas that really stumped me when I was first diving into this area. I did this talk back in July, and we had a lot of fun.

Thursday, September 24, 2015
Southeast Valley .NET User Group
Chandler, AZ
Meetup Event
Topic: Unit Testing Makes Me Faster: Convincing Your Boss, Your Co-Workers, and Yourself

I've been pushing unit testing for a while now. That's because I've seen how unit tests allow me to code more confidently and more forward faster. Come see real-world examples and leave inspired to look further into this great tool.

A Look Back
August was kind of a crazy month. I spoke at the Quicken Loans Technology Conference in Detroit, MI. And then I went on to speak at That Conference in Wisconsin Dells, WI. In between, I did some sightseeing and had an amazing two weeks on the road. Check out pictures here: Two Full Weeks of Awesome.

Quicken Loans Technical Conference

That Conference

In addition, I did a review of That Conference from the perspective of a Social Developer. Lots of cool stuff there. Along those same lines, I recorded an episode of .NET Rocks! which will publish in just a few days.

Finally, I went to Mountain View, CA and spoke at SouthBay .NET. I had a great time (including a little banjo playing).

SouthBay .NET

That's 23 events so far this year. If I'm lucky, I'll hit 30 by the end of the year.

A Look Ahead
The first week in October, I'll be headed back to the Silicon Valley Code Camp (in San Jose, CA). This should be a lot of fun. There are always great speakers and tons of people to talk to.

And in November, I'm speaking at Visual Studio Live in Orlando, FL. I'm really looking forward to this one. I've been test-driving my talks, and things are shaping up really well.

As always, if you're interested in having me come to your developer event or visit your company, just drop me a note. I'll look forward to seeing you at an event soon!

Happy Coding!

On Being a Social Developer: Observations from That Conference

I've been thinking quite a bit about being a social developer, particularly because I talked to Richard Campbell and Carl Franklin about it recently on .NET Rocks! (look for the show to be published next week). Because of this, I was a bit hyper-sensitive to the topic when I was at That Conference 2015 a few weeks back.

[Update 09/2015: Check out .NET Rocks! episode 1187: Becoming a Social Developer with Jeremy Clark. And be sure to visit the official website: Becoming a Social Developer]

Loners at Mealtimes
Previously I talked about how mealtimes always seemed to be the most stressful to me. I didn't want to sit by myself, and I wasn't confident enough to easily go up and join someone else. I've managed to get past that from 5 years of introducing myself and sitting down with strangers. It was terrifying the first few times, and I'd be lying to say I'm entirely comfortable with it now -- but it is a lot easier than it used to be.

I'll go back to my observation that developers like to talk, but they don't like to start the conversation.

I took a couple of pictures at breakfast at That Conference. I was there fairly early, but there were a lot of people already in the room. Here's the scene looking toward the front of the room:

And toward the back:

I did some rough counts of how many tables had just 1 person and how many tables had more than 1 person. This is pretty rough because you can't see all of the tables (you can see most of them, though -- note the man in the blue shirt on the right hand side of the top picture is on the left of the bottom picture).

Rough Counts
Top Picture: 8 Singles, 11 Multiples
Bottom Picture: 16 Singles, 3 Multiples

This gives us a grand total of 24 tables with only 1 person and 14 tables with more than 1 person.

Tables don't stay empty for long. Here's a picture of the full room doing the "power stance" (just before the opening keynote):

Resolution: Never Sit Alone
I'm resolved to never sit alone at a conference. I used to think that if someone was sitting by themselves that they wanted to be left alone. But what I've found is that most people are welcoming and open to meeting someone new, but they are reluctant to initiate the process themselves. It is scary, it does make you vulnerable, so I fully understand this.

Great Conversations
I've made some really great contacts this way. At the first breakfast, I ran into someone I knew in the food line (Mike Clement) and we went and sat with someone new who turned out to be John Strobel. John works for Progressive Insurance and lives in Ohio.

I hadn't seen Mike for several months (he's a fellow speaker who I seem to run into quite a bit). I found out that Mike recently moved to Atlanta, GA to work with a developer boot camp. This got the conversation rolling since this is a topic that intrigues me. I mentioned how I had met Sarah Dutkiewicz at the Microsoft MVP Summit, and we talked about the boot camp in Ohio that she was involved with (The Software Guild).

It turns out that John was familiar with The Software Guild (and Sarah, who everyone knows as @sadukie). And we had a great conversation about what makes for a successful boot camp, what qualities companies are looking for in the graduates, and how we can nurture more developers who are just starting out.

And all of this started by sitting down with someone I didn't know.

Picking a Table
Picking a table to sit at can still be a challenge. In the past, I've chosen tables with a group of folks all from the same company. This can turn out to be good or bad. If they're talking about work, then the conversation is usually not that good for me. But at That Conference, I ended up at tables with 3 or 4 people from the same company, and we had good conversations about tools and languages.

I've talked about the table picking dilemma with several people. I recently got a good piece of advice (sorry I can't remember who it was from (it may have been Jeff Fritz (aka @csharpfritz)) -- I've been talking to a lot of people). When deciding where to sit, he looks for a table with 2 people who are not sitting next to each other. Then he goes up and sits opposite them to form an equilateral triangle at the table.

The idea is that this gives you a better chance at conversation. The people (who may or may not be talking) probably don't already know each other, so you minimize the risk of work talk. And if one person doesn't want to talk, then you're not stuck in silence; there's someone else to talk to.

And people are attracted to active conversations (as mentioned in the previous article). So more people will come up and join you at your table. And things grow from there.

Conversations Get Longer
One interesting thing is that I'm never sure which conversations will turn into something bigger. As I mentioned when I talked about last year's Microsoft MVP Summit, I often keep running into the same people over and over again. And this is a pleasant surprise.

John actually turned out to be one of those people at That Conference, we had some great conversations on topics like functional programming (I really like functional programming, and he's trying to figure out how to spread functional programming among the developers that he works with), unit testing, and code craftsmanship.

Another example is David Neal (from Georgia) who I ran into several times. My first encounter with him was at a get together on Monday night. Later, I went to his presentation on Node.js which had this gem that I mentioned in a previous post:

David Neal: You Don't Need Permission to be Awesome

(BTW, I'm totally stealing this phrase to use as often as possible).

Then on Wednesday, I ran into him while I was on the hallway track. John, David, and I had a great conversation about effective presentation techniques, and David showed us his hand-drawn slides that he uses for his presentations. Really cool stuff.

Continuing Relationships
I also had the chance to continue some relationships. I first talked to Ondrej Balas (from Michigan) at Nebraska.Code() in Lincoln NE earlier this year. I saw him on the speaker list for That Conference, so I kept an eye out for him.

We talked for a little while at the water slide party on Tuesday night (and Water Slides are totally better than Powerpoint Slides). We found that we were both on the same path for building our brands as developers. He shared some things that were working for him (such as video blogging -- and he has a really cool idea for an ongoing series (I won't spoil it)), and I shared some things that I've seen. We decided that it would make for a good Open Spaces discussion and decided to put in on the board for the next day. If nothing else, the two of us could sit down to continue our conversation.

Our Open Spaces slot was during lunchtime on Wednesday, so I went to grab some food and head to the circle. In the lunch line, I met Phil Busch from Milwaukee. I told him about the conversation that Ondrej and I were planning, and he decided to join us. There were about 6 of us who joined the circle, and we had some great tips and observations for each other.

Old Friends and New Friends
I knew a few of the speakers from previous events, and it was great to talk to Cory House, Brian Lagunas, Bill Wagner, James Bender, Jim Wooley, and Danny Warren. And it was by hanging out with some of these people that I got to meet Nik Molnar, Keith Elder, Shane Charles, and many other folks.

I feel bad because I'm listing lots of people that I talked to, but there were many, many more. I try to talk to the person sitting near me in the sessions (before they start), and this results in many short conversations with new people.

Among the registration line, evening get-togethers, meal lines, meal tables, hallways, and pre-session times, I must have talked to 40 or 50 people. Some conversations are more memorable than others. But because of these conversations, I spent time looking into IoT devices, JavaScript debugging, Node.js, Erlang, and several other technologies/techniques that I haven't spent time on previously. And this makes my world (both technical and social) just a little bit bigger.

Why Attend Developer Events?
And this all comes back to why we attend developer events in person, whether it's a local user group or a large conference. We can get all of the information presented in the sessions on-line. But the real benefit of being there in person is the interaction with other developers.

I really feel like I missed out on a big part of conferences when I was a young developer. I did learn a lot from the presentations, but I completely missed out on building on the experience of the developers around me.

By making these connections, we learn about technologies we don't currently use. We learn how different techniques work in different environments (from start-up to corporate development). We can share our frustrations and look for solutions together.

I never saw myself as a social person. And I am completely different in this regard than I was 5 years ago. I'm pretty amazed to look back and see the difference in how I interact with developers now compared to how I used to interact (or not interact) with them.

Take the first step: the next time you're at a developer event, introduce yourself to someone new. It could be the start of something really amazing.

Happy Coding!

Twitter Photo Preview - Smart Cropping

So, I just noticed something in Twitter that I find kind of amazing. It seems like photos attached to tweets are cropped intelligently for the preview.

I noticed it with a tweet that I put out this morning (these are just screenshots):

When I first uploaded it, the preview was less than flattering:

But it seems like there was some analysis done on the photo (full photo below), and the preview was moved to show the face in the picture.

This is pretty cool in itself, but nothing too amazing. Lots of sites and applications have face recognition, so centering the primary face (or faces) shouldn't be all that difficult.

But then things got a bit more interesting.

The Really Cool Preview
Here's a tweet from last week where I was showing how excited I was to be on an upcoming episode of .NET Rocks!

Here's the full picture:

And when I first uploaded the picture, it showed the middle part in the preview:

But notice what Twitter eventually did when it re-cropped the preview: it used the part of the picture that had my name on it (the bottom part of the picture).

This tells me that in addition to facial recognition, they must also be doing some sort of OCR to figure out that the main part of this picture -- the part that I cared about -- was the part with my name in it.

Kind of freaky, but really, really cool.

I know I shouldn't be amazed by technology. But sometimes I have to marvel at the cool stuff that people come up with.

Happy Coding!

Two Full Weeks of Awesome

I spent two weeks on the road in August, speaking at both the Quicken Loans Technology Conference (in Detroit, MI) and That Conference (in Wisconsin Dells, WI). Since I haven't spent time in that part of the country before, I took some time for sight-seeing as well.

Nothing code related this time; just a few pictures of my time on the road.

Day 1 - Flying Out
With time changes and flight times, it takes a while to travel from Southern California to Detroit. The entertainment started at John Wayne Airport where I saw two planes staring each other down.

Who will win?

Day 2 - Detroit
I had a day to sight-see in Detroit. This is not the blighted city that we often hear about in the media. The downtown area has been going through an amazing transformation over the last 5 years. Abandoned buildings are being renovated, and improvements to public spaces invite people to spend time downtown.

Detroit

Detroit has a view of Canada. It's just across the river.

Windsor, ON - Canada

Later that night, I attended a dinner for the Quicken Loans Technology Conference. Lots of good conversations with some folks I haven't seen for a while, plus good conversations with people I met for the first time.

Dinner

Day 3 - Quicken Loans Technology Conference
The next day was the Quicken Loans Technology Conference. There were lots of interesting speakers, including keynotes by Dan Morales, CIO of eBay and Richard Campbell & Carl Franklin of .NET Rocks.

I had a great time speaking about Clean Code (as I usually do).

Jeremy Talks "Clean Code"

I met a lot of great people at Quicken Loans and got to see first-hand all of the good things that I've heard about the company.

Day 4 - Henry Ford Museum
I had decided to rent a car and drive from Detroit to Wisconsin Dells (it's only about 400 miles -- I'm driving that far this week just to get to the Bay Area in California).

Along the way, I stopped at the Henry Ford Museum in Dearborn, MI. What an incredible place. If you like mechanical things, this is the place to be. I was amazed by things that seem simple now but were a great innovation at the time. For example, here's a hay mower:

Hay Mower

The blades look like a modern hedge trimmer (with an oscillating blade moving over a stationary one). But it was geared into the wheel, so the blade would move as the wheel turned. Really cool stuff.

Plus, planes, trains, automobiles, tractors, plus the Dymaxion House by Buckmeister Fuller. If you're ever in the area, you need to stop by.

Day 5 - Indiana
The next day was mainly travel. I drove across Michigan and into Indiana. It was beautiful and green along the way.

Welcome to Indiana

Day 6 - Wisconsin
The next day was more travel. I drove by Chicago, IL and Milwaukee, WI. It was great to see the skylines of the cities (and I was looking forward to going back to Chicago the following week).

At a rest stop in Wisconsin, I saw that they take their recycling really seriously.

Recycling

Day 7 - Madison
I stayed in Madison,WI and went to the Henry Vila Zoo. It's a free zoo that has quite a selection of animals. I spent quite a bit of time with the goats (someday, I'll have goats of my own):

GOAT!

I've always loved goats, and they seem to like me as well. They would run over to folks who had food to give them. But once the food was gone, they would come back to me for scratches.

Then I drove on to the Kalahari Resort in Wisconsin Dells -- the location of That Conference. I spent about an hour in the registration line that night. It sounds like a long time, but it gave me a chance to talk to 10 new people. If you want to hear more about that, be sure to tune in to .NET Rocks! on September 3rd, where I'll be talking about becoming a social developer (or check out this recent article about That Conference).

Day 8 - That Conference
That Conference was a really great event. I met tons of great people and saw a lot of great tech.

Day 9 - That Conference
There were tons of great sessions, and a few pearls of wisdom. Here's one from Stephen Cleary in reference to asynchronous programming:

Every Time You Use Async Void, Rory Dies

And here's something from David Neal that we should never forget:

You Don't Need Permission to be Awesome

Later that night, there was a party at the water slide park at the resort. I think I figured that I hadn't been on a water slide for over 20 years, but I didn't let that stop me. I went on pretty much everything, including the 4-story, straight down slide. I had chlorine in my sinuses for the next 2 days. But it was totally worth it.

Day 10 - That Conference
The last day of That Conference, I was mostly on the hallway track -- speaking to folks I had met during the week, and hosting an open spaces session with Ondrej Balas on building your brand as a developer.

I finally got to speak on the last day of That Conference. In fact, I presented during the last breakout session of the conference.

Jeremy Talks "Clean Code" (again)

Thanks to all the people who came. We had a great time together. Here are a few tweets from that afternoon:

Watching @jeremybytes talk about clean code and murder #thatconference

— Stefen Benton (@BentOnCoding) August 12, 2015

"Clean Code: Homicidal Maniacs Read Code, Too!" with @jeremybytes easily my favorite talk all week. #ThatConference

— Keller McBride (@rellek77) August 12, 2015

Awesome session on clean coding @jeremybytes #ThatConference

— nicbrat (@nicbrat) August 12, 2015

There's a lot more that I could say about That Conference, but we'll save that for another day. I met a ton of great people, got to catch up with a few old friends, and had some really amazing conversations. I'll look forward to going again next year.

Day 11 - Circus World
After That Conference wrapped up, I had a few days to make my way back to Chicago where I would be flying out.

I spent a day at Circus World in Baraboo, WI. This was the winter home for the Ringling Bros Circus, and the site dates back to the early 1900s.

Novelty Musical Intruments

I got to see the novelty musical instrument show, which included this interesting contraption. The cranks were attached to hammers that struck a xylophone-type tuned bar. In addition, there was a big top show with unicyclists, clowns, performing dogs, camels, elephants, and aerialists.

Later that day, I went to the Timbavati Wildlife Park, where I got to pet a kangaroo:

Kangaroo

And I went to the races as well:

Pig Races

Day 12 - Wisconsin State Fair
The next day, I spent the day at the Wisconsin State Fair (just outside Milwaukee). I was especially happy to be there since I was missing the Orange County Fair back home.

Wisconsin Cows

This was much different from my local fair. For example, at the Orange County Fair, most of the animals are 4-H or FFA projects. The Wisconsin State Fair had tons of animals from working farms. There were 2 cow barns, a 2-story horse barn, a sheep barn, a goat barn, and a bunny and chicken barn, plus a big covered arena (which was nice since it was hot and sunny out).

While in the arena watching a horse competition, I heard someone say, "I'm more of a cow person. I would buy a cow if I could afford one." Not something I'm used to hearing.

There was also a Cream Puff building where they were making tons of fresh cream puffs (and selling them just as fast as they made them).

Cream Puffs being made

Really tasty. Lots of other great stuff to eat, too.

Day 13 - Little Amerricka
The next day, I found myself in Marshall, WI at the Little Amerricka amusement park. This was an awesome little place between the corn fields and the cemetery. Lots of rides and lots of fun. The Mad Mouse was a historic little ride that is a lot more terrifying than it looks.

Mad Mouse at Little Amerricka

This is one of those rides that was made before lawyers existed. You just get in the little sled with wheels and hang on -- no lap bars or seat belts.

In addition, a great wooden roller coaster, a toboggan ride, a "monorail", ferris wheel, bumper boats, haunted house, mini golf, and lots more. I had a really great time. And I was hot and exhausted by the time I was done. A great place to visit.

Day 14 - The Field Museum
My last day was in Chicago, IL. Rather than trying to park in the city, I decided to take the "L" in.

The "L"

This was a great system to use. It was easy, the trains and stations were well marked, there was good air conditioning, and the station announcements made it easy to know where to get off. As an aside, I always thought the Chicago train was referred to as the "el" -- short for "elevated train" -- I stand corrected.

This was also a great way to see the city. There were good views from the elevated track, and I got to see a variety of neighborhoods (at least until it went underground near the "Loop").

The goal was The Field Museum. I've wanted to go there for many years for one reason: to see Sue the T-Rex. And I was very excited when I finally saw her:

Jeremy and Sue

This journey started many years ago when I first heard about Sue on television. Then a bit later, I visited the Black Hills Institute in South Dakota (the folks who found Sue). Then I got to see a replica of Sue in Orlando, FL a few years after that. I was excited to reach the end of the journey.

There was lots of other cool stuff at The Field Museum. This little picture really made me laugh, though:

Oxygen

This is showing how photosynthesis in early cells resulted in the oxygen in the atmosphere. I got a chuckle out of the cell farting out oxygen like "What are you gonna do?".

Out one of the windows, I got a good picture of the Chicago skyline.

Chicago, IL

Day 15 - HOME
I ran myself pretty ragged during these two weeks. So, I was really glad to be headed back home. I didn't get to do an architectural tour of Chicago (there are tons of really cool skyscrapers), but I'm sure I'll have plenty of other opportunities to go to Chicago. And I bought a "Pocket Guide to Chicago Architecture" at the airport. So I have a good reason to go back.

I'll get back to the technical articles soon. Plus, my YouTube channel just passed 1,000 subscribers, so I'd better produce a new video soon. Until then...

Happy Coding!

Reconciling Clean Code and the Startup Mentality

Last week, I was at That Conference, and it was an awesome week (more on that later). But it was also a bit awkward. On Wednesday, the keynote by Max Lynch (co-founder of Ionic) was about startups and getting functionality to the users (or potential users) as quickly as possible. It was a great talk about some key features of successful projects.

A big theme to this was "It doesn't matter what your code looks like." The awkward part is that I was speaking about Clean Code and the importance of caring about the readability of code later that day.

Fortunately, a lot of people showed up for my presentation, and we had a really great time together. But I did get an interesting question afterward from someone who worked at a startup:

How do I reconcile "It doesn't matter what the code looks like" with the principles of craftsmanship?

The developer believed in craftsmanship and readable code, and he was a bit distressed that his boss was saying that they had to do things fast and dirty. As a bit of a surprise to myself, I actually had a good answer to give (at least I thought it was a good answer):

Treat the version 1 product like a prototype.

Let's explore this a bit more.

The Importance of Moving Quickly in Multiple Directions
I understand the startup mentality of "it doesn't matter what the code looks like" -- but with full understanding of the consequences of that approach.

The problem is that we only have an idea to start with, and we're not even sure if anyone will be interested in it yet. So we put together just enough code to get things working. And a lot of times, we don't even get that far; we just create a landing page to see if anyone is interested in the product before we even write a single line of code.

And once we start coding, we cannot invest too much time or effort into this. If it is a complete flop, we discard the code and move on to the next idea. We don't know what we need at this point. We're really just exploring. Ultimately, we're working toward a minimum viable product, which is just enough functionality to be useful to someone.

Even then, we don't know what feature will really resonate with our users, so we have to be ready for unexpected responses and to move quickly in another direction.

Just a Prototype
The only way we can use this approach is if we treat this code as prototype code -- even if we are releasing it to the users. This is our exploratory code -- where we figure out what excites our users and differentiates us from the rest of the pack.

There Will Be Problems
When we write code like this, there will be problems. We will have bugs that are hiding in the code. We will have issues scaling for more users. We will reach a point where it is difficult to add a new key feature.

And this is the point were "it doesn't matter what the code looks like" really starts to cause us pain. The best thing to do is discard what we have and write the code for our real product based on the prototype.

Clean Code Does Matter
It's really easy to fall into the trap of thinking that clean, readable code doesn't matter. After all, if we can be successful without it, who cares?

This works short term, but things fall over in the long term.

Once we have our viable product, and we start coding "for real", we need to pay attention to craftsmanship principles. We have to make sure that we don't introduce bugs in our code. And we do this through automated testing (the proof that our code does what we think it does) and through readable code (if the code is easily readable, then the bugs have nowhere to hide).

In addition, since we now know what features make our application successful, we can leave spots for abstractions and extensibility points so we can easily add new features.

And this is where we start to think about the long-term viability of our product. If we treat our version 1 as the real version rather than the prototype, we're just setting ourselves up for a lot of pain. But if we take the learnings from the prototype to then create the actual product, we can reap the benefits of our quick, maneuverable process and use them to create a sustainable product.

Final Words
In the Wednesday keynote with Max Lynch, the focus was really on starting many companies (one after the other, and sometimes several at the same time) based on ideas that we don't know will work. We need to figure out what resonates with our users quickly so that we can focus our efforts.

So, my advice to people who are coding "fast and dirty" and don't feel right about the process: think about this as a prototype. It is an exploration of what might be useful. And just because we release that product to our users does not make it any less of a prototype. Expect to discard this code once we have gotten what we need to know from it.

It Does Matter What Code Looks Like
Ultimately, it *does* matter what the code looks like. Having readable code is what makes it easier for us as developers to make changes to meet our users needs. If we can't quickly meet our users needs, then we've failed. If we don't go back to replace that prototype code, then we'll end up falling over at some point.

If we create a mess so that we can get some learnings out of it, that's fine. But we can't leave things that way. For long-term viability, we need to think about the quality of our code which ultimately impacts the quality of the product.

Happy Coding!

When Does DRY Become ARID?

The DRY Principle is a great thing to keep in mind:

The DRY Principle
Don't Repeat Yourself

But like all principles, we need balance. Otherwise we might find we've gone from DRY to ARID:

ARID Code
All Readability Is Dead

To me, readability is king. Sometimes I will pick a not-completely-optimized way of writing code so that it is more understandable. (Obviously, if I really need speed optimized code -- such as tight loops or other processes -- then that will get prioritized.) Let's see why we need to watch out for over-doing DRY and straying into ARID code.

Challenged By a Friend
I'm a big fan of the DRY principle, and that's because it's caused me a lot of grief in code I've dealt with. And this is one of the reasons I spend time sharing my stories with other developers (see "Clean Code" and "Abstract Art").

One of my friends -- a developer I worked with for many years -- recently watched my Clean Code presentation, and he made a comment about the refactoring part.

"I don't think you went far enough... You're violating DRY."

I'm always up for some exploration, so let's take a look at the code.

The Original Refactoring
If you want to watch the refactoring in video, here's a link to the right spot in the recorded presentation: YouTube - Clean Code 46:03.

In the sample, we start with a simple (but a bit difficult to approach) method:

Then we extract a couple of methods to hide some details and add some good method names to let us know what's going on:

This makes our "Initialize" method much easier to understand. If we need to know how we "get the service from the container", we can drill into that method. Otherwise, we can simply move on.

A Bit Drier
My friend pointed out that there is duplicated code in the two extracted methods. So this is where we should concentrate our efforts.

When we look at these a bit closer, we see a lot of similarity. We have conditions based on "IsRegistered" to see if an item is in the dependency injection container. Note that these are not *exactly* the same. The first method has a "CurrentOrder" string as a parameter; the second method has no parameter.

If the object is not in the container, then we throw a MissingFieldException (same exception with a slightly different message).

Then we resolve the actual item from the container. Again, one of the methods takes a string parameter, and the other does not.

To help us get rid of some of this duplication, we can combine them into a single method with the help of a generic type parameter. Here's a first stab at this:

Now we have a single method that returns a generic type ("T"). But we really haven't eliminated the duplication. We simply have 2 conditional blocks based on whether we have that optional string parameter. If we have a string parameter (like "CurrentOrder"), then it is passed to the "IsRegistered" and "Resolve" methods. And it is also used in the message of our exception.

If there is no parameter, then we use the name of the type itself in the exception message.

With a little more understanding of how the underlying methods work, we can eliminate some duplication:

This takes advantage of the fact that if we call "IsRegistered" with a "null" parameter, it works the same as if we had no parameter. The same is true of "Resolve". It was very easy for me to verify this functionality because I have unit tests in place that test both the success state and the error state for this.

We still need to use the right string for our exception message. So for that, we create a variable ("missingObject") that we can populate with the parameter or the type name as applicable.

Using the Drier Method
Now that we have our drier method, we need to actually use it in our code. Let's update our "Initialize" method:

All of our unit tests still pass, so we know that this code is functionally the same as we had before, but have we made the readability better or worse?

This exposes some details that we don't have in the other version. For example, we see that the model is of type "CatalogOrder" (which we could tell from inspecting the "_model" variable as well). But it also tells us that the model is referred to as the "CurrentOrder". Is this important? Or does it just get in the way?

Let's put the methods side by side:

Original

A Bit Drier

Personally, I prefer the original version in this case. We don't need the details here; that's the reason we extracted the methods to start with. In addition, I know the environment that this code came from. It's based on real code and a real situation. Based on my understanding, the original refactoring is a better fit for the developers who would be maintaining the code.

As with all of our best practices, this is a matter of balance. For a bit more, see Beware of "Never" and "Always".

Truly ARID
I would not consider either version above to be unreadable, but readability is always at the top of my mind. The primary reason for this is that in addition to seeing violations of the DRY principle, I've seen people take this much too far. The result was something completely unreadable.

Here's an example. I was working on a WPF project, and we had several value converters to get our UI working the way that we needed for our users. (Value converters are one of the great things about data binding in WPF -- it let's us do cool things like bind a color in our UI to a date property in our data.)

Someone got tired of the proliferation of value converters, so they decided to create "one converter to rule them all". The idea was to have one value converter that had all sorts of options that could be provided as parameters. We'll look at just a little bit of this code (unfortunately, there was much, much more).

This is the main "Convert" method. And we can see that there are a couple of properties used in this method: StringFormat and FalseText. And there are a couple of methods called as well: IsStringFormatConversion and Match.

Let's take a look at the Match method:

Yikes. This contains more properties: ConditionalText, IsNullCompare, IsStringCompare, and IncludeEmpty. The mixture of "&&" and "||" also makes the logic extremely difficult to follow.

But worse that this is that the converter was confusing to use. Here are a couple basic examples:

These only use two of the possible parameters: ConditionalText and IsStringCompare. But there were examples that used many more.

The big question is "What do these converters actually do?" And that's the problem. Just by looking at the usage, I have no idea what's going on. I would need to dig deeper.

This code has definitely crossed the line into ARID.

Balance in Everything
As developers, we have to constantly find the right balance. This could be weighing the pros and cons of a particular tool. It could be finding the balance between readability and testability. Sometimes it is finding the sweet spot between speed and memory footprint.

Sometimes these choices are clear cut. But often, they are subjective -- especially when we're talking about readability. Because we always have to ask, "Readable by whom?" Readable by a senior developer? Readable by a new developer? Readable by our users?

In the example we looked at today, I could see arguments being made either way. I have a bit more insight since this is based on real code, and I know the developers who needed to understand the code. Because of this, I erred on the side of simplicity. These projects had a lot of new concepts to this team (DI, XAML, delegates, and a few more), so I would simplify wherever possible.

The decisions aren't always easy. But that's part of the fun of this type of work.

Happy Coding!

August 2015 Speaking Engagements

The summer is going by quickly. We're already at the end of July. I've got a busy August (which is good). I'm looking forward to some great events.

Wednesday, August 5, 2015
Quicken Loans Technology Conference
Detroit, MI
Topic: Clean Code: Homicidal Maniacs Read Code, Too!

I'm looking forward to speaking at Quicken Loans. I know some folks who work there, and they rave about the environment and the company philosophy. It will be great to see that in person.

As a reminder, I'm available for corporate events. So if you have a company tech event, I'd be glad to talk to you about coming out. In addition to presentations, I also do half-day and full-day workshops for those who want to dive a bit deeper.

Monday - Wednesday, August 10-12, 2015
That Conference
Wisconsin Dells, WI
Website
Topic: Clean Code: Homicidal Maniacs Read Code, Too!

I'm very excited about being part of That Conference this year. I've heard great things about it in the past, and this will give me a chance to experience it for myself. There are a ton of great sessions lined up as well as a keynote from Uncle Bob. Plus, it takes place at a resort with a waterslide park. Water Slides > Powerpoint Slides.

Thursday, August 27, 2015
SouthBay.NET
Mountain View, CA
Meetup Event
Topic: Unit Testing Makes Me Faster

I'm headed back up to the bay area later in the month. I'm talking all about how unit testing has made me a faster developer. I've been thinking about this topic for a long time, and it's finally taken shape. Look forward to a lot of fun and hopefully enough hard facts to convince you to take another look at unit testing.

Keep checking my website (or follow me on Twitter @jeremybytes). I often have late additions to my calendar, so there may be something near you.

A Look Back
My schedule was pretty light in July, but I ended up with back-to-back speaking days. At Inland Empire .NET in Riverside, I managed to show that you don't have to be an expert in a technology to talk about it. I had a lot of fun showing people how to get started with Git, and there were a couple folks who were using it regularly, so they helped out with some of the more advanced questions. And that's why I called my talk "Getting Started with Git". I'm still relatively new, but I'm hooked on it now.

Inland Empire .NET (the orange shirt keeps people awake)

The next night, I was in downtown LA for C# Entertainment. Reynald Aldophe came up with an interesting concept: combining tech and stand-up comedy. The event was a lot of fun. Christian Zezza provided us with some amazing guitar playing. Then I talked for a bit about tasks and asynchronous programming. To round out the evening, Chris Fairbanks provided the comedy. (I know everyone was relieved to hear that I was not doing the comedy or the music.)

Keep track of C# Entertainment and check out an upcoming event.

A Look Ahead
It looks like I'm going to stay busy. I really love to speak, meet new people, and catch up with old friends. In September, I'll be in the Phoenix area to speak at 2 of the .NET groups there. And in November, I'll be speaking at Visual Studio Live! in Orlando. It's still really cool to see my name on the speaker list. I'm really looking forward to that.

Hopefully I'll see you at an upcoming event. If you don't find one nearby, contact me. Let's see if we can set something up in your area.

Happy Coding!