Daily Software Development

I’ve started our second series on DevChatter. We’re doing SOLID Saturdays now, which means that we’re dedicating each Saturday to a SOLID Principle of Object Oriented Design. Very likely, after we’re done with 5 SOLID Principles, we’ll add a few bonus SOLID Saturdays with the concepts of DRY, YAGNI, and maybe a couple of other good principles.

So far, we’ve completed 3 of the SOLID Principles, Single Responsibility Principle, Open/Closed Principle, and Liskov Substitution Principle. You can watch the videos of our SOLID Principles Series on Twitch. In each of those episodes, we started off by discussing the principle, why it’s important, and how to notice violations of it. We talked about where we’re following it in our code, and looked at real examples of the principle, rather than just some contrived examples. We then spend the rest of the stream writing code, and where it’s applicable, we mention the principle again.

In our next episode, we’ll be looking at Interface Segregation Principle, which will give us the chance to make some changes to our codebase and improve our interfaces to better match the design that Interface Segregation Principle would push us toward.

Join us each Saturday at 1:00 PM Eastern Time to learn more about SOLID programming and see some live coding as well.

Starting this Saturday, we’ll be doing a new series of streams on DevChatter. If you’re new to programming, new to C#, or just want to go back to basics on C#, this stream is for you!

On our channel, we’re normally doing either long-term projects or programming exercises, but we want to get some great educational C# content as well. To that end, we’ll be teaching people how to program using C# on a regular basis. If that’s something interests you, you can find our Learn to Code in C# series on Twitch. From that page you can ask Twitch to remind you of our Learn to Code in C# series. Also, make sure to follow DevChatter on Twitch to get notifications when we go live.

Back in 2015, I started working buying up assets and setting myself up to live stream while coding. I wasn’t sure at the time how much time I wanted to dedicate to talking with other devs, pairing, doing exercises/katas, working on OSS, and writing real code. I just figured it would be cool to do some streaming and interact with the developer community while writing code. A few people had actually been asking me to, so I decided I would do it.

When I started out, I was choosing where I wanted to stream. I figured YouTube and Twitch made the most sense, so I set up a DevChatter YouTube and a DevChatter Twitch. Subscribe on YouTube and follow on Twitch to see my streams and videos!

I also picked up the domain name, because it was available. It had that balance of discussion and coding in the name. I like it. We’re not supposed to be me just talking at people, and that balance will shift as we grow. My Twitch channel is growing already. I’m getting new people joining and following with each stream.

What I set up for DevChatter

I mentioned creating some accounts and picking up a domain name I’m not using yet. I also had a basic logo designed for DevChatter, and am now using that for the Twitch account.

I also set up an account and got some custom music created and licensed it for use on the stream. If you show up to the beginning of the stream, you’ll get to listen to the music. Rather than using it as background music, I’ve got it playing before the stream starts. Lucky for me, I have done some Twitch streaming of games in the past, so I knew how to get OBS set up for the stream. We’re set up with a GitHub account I created years ago as well.

What I’m doing on DevChatter

So far on DevChatter, I’ve had a few streams doing programming exercises. The code has been C# so far, but I don’t intend to always do C# on stream. We’ve done some of our C# exercises in .NET and some in .NET Core.

What I plan to do on DevChatter

I want to keep doing programming exercises and katas on stream, and I’m hoping to get more involvement from all of you. I also want to continue on our (and others’) open source projects; I think there’s a great deal we can learn while helping build the community. In addition, I want to bring guests on to pair program with. I’d actually started talking with potential guests a couple of years ago, but will obviously need to restart those conversations. I think we could do community discussions where we write code as we talk about things. We’ll see how it goes.

Is there someone you want me to pair program with? Let me know using whatever means you feel like for contacting me.

Why I didn’t start this two years ago

There are a couple of reasons why I didn’t start DevChatter a couple of years ago as I intended to.

DevIQ

The first of those reasons is that I talked with some other people who convinced me to redirect my attention elsewhere. As such, I’ve been working on DevIQ for some of that time. We’re building a really cool online educational program at DevIQ. If you haven’t checked it out, you really should. We’re working with new authors and preparing for new content now. We have plans for what we want on DevIQ and have been building some cool interactivity that both our students and authors will love. Check it out!

The Smallest Hurdle Ever

The other reason why I didn’t start years ago is a funny one. I really wasn’t sure how to classify my streams on Twitch. I don’t know if “Creative” existed as a game at the time and I didn’t notice it. I didn’t want it to be IRL, and there weren’t any specific to programming. I am currently streaming it as “Creative” on Twitch. Sometimes it’s the little things that get in the way.

Yesterday, I was working with my dev team, and some people came across some C# 7 code. Specifically, they were seeing some code using Pattern Matching, and weren’t sure about it. Not everyone was familiar with C# 7, a failing on my part. If you’re also not familiar with all of the new features in C# 7, I’d recommend checking out my What’s New in C# 7 course on DevIQ. In the course, I go through all of the new features of C# 7, explaining both how they work and when to use them.

I talk regularly at conferences about C#, and have given talks on C# 6, C# 7, and the combination of the two. When I ask people if they’re using a version of C#, most people acknowledge they are, but when I ask about specific features, most hands drop. I find that many developers are not using the features made available to them until long after it’s available to them. Don’t miss out on these!

As C# grows it’s important to stay up-to-date on everything that it offers you! Check out my course today and get your quick-start to using the new features in C# 7!

What You Will Learn About C# 7

In this course, you will learn:

Output Variables

Pattern Matching

Local Functions

Improved Literals

More Expression Bodies

Throw Expressions

Tuples

Ref Returns

What’s New in C# Bundle

And many developers need to know about C# 6 still. I did a course covering C# 6 as well, so you can check out the bundle I set up. The What’s New in C# Bundle includes both What’s New in C# 6 and What’s New in C# 7! Allowing you to learn everything you need to know to bring your C# project up-to-date!

Not a day goes by when I can avoid thinking about UI and UX. Sometimes, I’m thinking about real-world scenarios, but as a developer, I also have to consider it in the applications that I build. As developers, we really cannot avoid it, even when there’s someone else in charge of the UI/UX of the application we’re building. Thanks to Mark Miller’s DevIQ course, The Science of Great UI, I’ve been able to learn a lot more about UI and UX. It’s an in-depth course which really does focus on the science behind building good user interfaces. It’s not just a prescriptive, do X, Y, Z in this certain scenario, the course explains the science that’s dictating what makes a user interface good or bad. I learned a ton from this course!

As some of you may know, a few close friends of mine and I created a training company called DevIQ. We’re all passionate about technology and improving how people learn; we’re frequent speakers at conferences, run training workshops, and mentor other technology experts. As we create new courses, we’ll be posting them to DevIQ.com, so be on the lookout for more great courses all the time!

So once you’ve watched this course, you’ll be in the same boat that I’m in, waiting for Mark to produce the follow-up course Design Like a Pro. He’s doing a series of courses on design that will help you and me become better at designing great user interfaces.

If you’re looking to improve your C# 6 code by taking advantage of the new features added into the language, I’ve got you covered. By using C# 6, you’ll be able to clean up your code, and make things more concise. This was one of the focuses in the design of C# 6. You can clean up and remove the clutter from your projects by taking advantage of C# 6. My C# 6 course on DevIQ will show you how to use these new features to improve the code you’re writing today. You already have the tools and capability, and now you can learn how to take advantage of it!

As a consultant, I’ve worked with developers in different companies, and I find that most organizations are barely using the features of C# 5 let alone using C# 6. When I talk at conferences, most people say they’re using C# 6, and they technically are using it. Their code is compiled using C# 6, but they’re not using all of the features or know how powerful they can be!

To help teams with this, I created a quick-start, What’s New in C# 6 course on DevIQ that will help you get started using C# 6!

After creating software craftsmanship calendars for four years, we (the software craftsmanship calendar team) took one year off. All we heard through December of 2014 and January of 2015 was people asking us how to get their 2015 calendar! Well, there wasn’t one! Unfortunately, none of us worked together anymore, so making the calendar became quite the challenge. There was no longer an employer backing all of us and fronting the bill for design costs and printing costs.

We found our solution to the problem though, we set up a Kickstarter to fund the initial costs of the 2016 calendar, and with the support of all of the backers of that campaign, we were able to create the 2016 software craftsmanship calendar.

What are these calendars?

The Software Craftsmanship Calendars use the motivational poster-style formatting with an image of a humorous real-world interpretation of a concept related to software development. These images and jokes throughout the calendar acts as entertaining reminders of the standards we all want to hold ourselves to.

With the 4th and 5th calendars, we discussed the idea of doing a “Greatest Hits” calendar where we would mostly use our best ideas from previous calendars. Some we would reshoot the pictures, others might get touched up, and a few images would be new. This would make the it one of the best calendars we could make, since it was using our previous, great ideas! With five calendars under our belts, we’ve decided it’s time to do just that. We’ve got loads of previous images and ideas to choose from.

2017 Kickstarter

We’ve set up another Kickstarter. This time, for the 2017 Software Craftsmanship calendar.

Stretch Goals

We want most of the images in this calendar to be the best images from previous years, so that this calendar can be our best one yet. We are willing to take some chances by adding a couple of new ideas and images, so we’re setting those up as stretch goals this year.

Please go back our Software Craftsmanship 2017 Calendar Kickstarter, and get yourself or your team some calendars to remind you how you want to be building software. Or if you like, pick some up for those people who could really use the reminding.

I’m not exactly silent in my belief that pair programming will help our industry, so it should come as no surprise that Steve Smith and I paired together on a Pluralsight course on Pair Programming. It only made sense to me that a course on pair programming would be created by two people. We shared the work on each module of the course, and we think it turned out well.

In the course, we cover the theory, practice, benefits, technique, and research of pair programming. From this, we’re trying to make sure that people both know how to pair program effectively and know why it could benefit their team. If you or someone you know has heard of pair programming, I’d recommend watching the course.

Given the choice of typing twice as fast or thinking twice as fast, I know I would choose the latter every time. That’s why I always choose to pair program when someone is available to. We accomplish far more together than we do separately. You’ll learn how and why when you watch Pair Programming.

In case you missed it, Steve Smith, Michelle Smith, and I are Kickstarting the 2016 Software Craftsmanship Calendar. Make sure to support and share the project so that this awesome calendar can make a comeback! We are dedicated to making this happen, but need your support.

This will be our fifth calendar, so we’ve got a lot of practice. None of us work together anymore, so we didn’t have a company backing the 2015 calendar. As a result, it didn’t happen. We’re going to fix that for all of the people who were contacting us and others related to the calendar trying to get their 2015 editions; the 2016 calendar is for all of you. I know it’s really early to be thinking about buying a new calendar, but there a printing deadlines, so we really do make these calendars in the summer. As a result of our efforts, those of you who were lucky enough to have the 2012 or 2014 editions of the Software Craftsmanship calendar got to have a picture of me up on your wall for an entire month for each of those two years! I have no idea if I’ll make it into the 2016 calendar, but it will see be awesome. Here are the pictures I was in!

Death March

Mushroom Management

In the spirit of explaining what goes into making each of these calendar images, I’ve decided to write a post here showing how the Mushroom Management photo got the way it is.

Step 1 – A Principle or Anti-Principle

We always start with some principle that we want to make. There are so many to choose from that we have to trim the list down to any we can get an idea for. That means that we start by brainstorming ideas, and keep the principles that we got any ideas for. It doesn’t matter how good the idea is. If we could come up with a visual we keep it and continue working on the visual. We have this set of criteria for the visuals:

The image has to relate to the principle.

The image has to be interesting enough to have on a wall for a month.

The image should have a humorous aspect to it.

Step 2 – Sketch the Idea to Make Sure It Works

Before we make any props, find a location, and start taking pictures, we have to make sure the idea will actually work. We also want to know what we need to set up. Not all ideas require this, but it helps choose between multiple ideas. It’s also a great point to iterate on before we start shooting. Often the sketches only resemble the image, which is why we spiked the idea with a sketch first.

Mushroom Management Sketches

Golden Hammer 2.0 Sketches

Frankencode Sketch

Step 3 – Make Any Required Props

The golden hammers we’ve used over the years were all made by us. We’ve made 4 different hammers over the years. Only two of them made it into calendar images. Two hammers were real hammers that we painted gold. One was a plastic hammer painted gold. The one featured in the 2014 calendar that looked like something Thor might wield was custom made by our designer Weston. He sculpted it, painted it, and even cut and wrapped the leather for the hilt.

The Original Hammer

The Thor Hammer

And this is how the hammer was made:

Step 4 – Start Photographing

Perhaps the most obvious part of the process, we do have to take some pictures. We make sure to take quite a few pictures (including some making of pictures to go in the back of the calendar). For the Mushroom Management photos, we did a photo shoot, and the photos were not quite right. We knew we needed to make some changes Take a look:

We really thought that the team needed to look like they’d been sitting in that room for weeks, so we did some thrift store shopping and obtained some visually “interesting” shirts for the team to wear. We also wanted to Mushroom Manager to look a little more formal. We shot again the next day. That got us here:

Step 5 – Touching Up Some Lines

And to make things look amazing, our designer takes these images and makes them complete. OK, so it’s a bit more than just a few lines, but the work he does is fantastic. We’ve gone from an empty office to a development dungeon.

Step 6 – Choosing Behind the Scenes Photos

Our developers in that pictures are in fact developers, not actors. They’re actually pretty uncomfortable in that room. They’re sitting on the floor, closed in a room, with the air conditioning off in the August heat. Being the mushroom manager, I’m supposed to be comfortable, so I’m making sure to stay cool. That’s why I made sure to wear the lightest pair of shorts I owned for this shot.

That’s how you really class-up an outfit right there. worn athletic shoes and blue shorts go really well with a sport coat, shirt, and tie. Trust me!

Step 7 – Enjoying the Calendar

Yes, this is our favorite part as well. When we get to see our first, fully printed calendar. It’s amazing to see thousands of hours of work come to life in the form of a calendar. Yes, we know the number of hours that go into these. NimblePros was in the software consulting business, so we tracked the hours we billed toward our internal projects like these.

At some point, I’m sure you’ve had someone suggest that you use an interface instead of a concrete class as a dependency. Assuming you’re following the Interface Segregation Principle, that could be exactly what you want to do. Well written interfaces can make your code much simpler and more clearly define your dependencies. That’s why Interface Segregation Principle is one of those popular SOLID principles you’re always hearing about.

I recently read an interesting tweet from Derik Whittaker talking about using IEnumerable when an ICollection or IList would be the better choice.

Ugg, may want to fix your code rather than do this "// ReSharper disable once PossibleMultipleEnumeration"

This move toward making everything IEnumerable<T> is a trend happening across the C# community. I believe that ReSharper (a tool I use and love) is leading to some of this. When you write a method that takes in a collection as a parameter, and your method does a foreach over that collection, ReSharper will suggest (correctly) to change it to an IEnumerable. This is because you only enumerated it once, and that means that you can be more relaxed in your requirements.

The problem people run into with IEnumerables is that they’re not all collections. IEnumerable<T> just means that there is a method to get an Enumerator. In simple terms, I mean that it’s possible to walk through the items in the enumerable one at a time. Sometimes that requires work that’s more than constant time to get to the next item in the enumerable class. The comment that Derik mentioned in his tweet is one that tells ReSharper to not warn you about a possible issue. That issue is that you might be doing the work of walking through the enumerable more than once. When it sees an enumerable that is enumerated for a second time, you’ll receive this warning.

Keep Your Method Parameters Permissive

When you’re making a method parameter, you want to make sure that you’re only requiring exactly what you need. In doing this, you’ll likely create interfaces following the Interface Segregation Principle. When dealing with collections, you’re likely to accept an IEnumerable<T> if you only enumerate once. You might accept an ICollection<T> if you need to enumerate a couple of times, allow adding and removing, or need to count the items. If your collection needs random, array-like index access, you should consider using IList<T>.

This allows the caller of your method to give you whatever they have at the time. You really don’t care as long as it has what you need. If their object is an IEnumerable that isn’t also an IList, they can convert it before providing it to you. Working this way makes your API much more flexible, since you’re making your minimum requirements clear.

Return Usable Types From Your Methods

Sadly, I see the reverse being pushed as a positive. You will find information telling you to return IEnumerable<T>, so that you can easily change. This, however, means that you’re providing your method’s consumer with no information about the object they’re receiving. If they need access to array-like indexing, they have to call ToList() on your return value in order to use it.

Since ICollection<T> implements IEnumerable<T> and IList<T> implements ICollection<T> and IEnumerable<T>, you can return an IList<T> allowing your method’s caller to use IList<T>, ICollection<T>, or IEnumerable<T> depending on their usage. You’re using an interface and still giving the consumer the power of choice. You can avoid tightly coupling to a concrete implementation while still providing a useful return value.

I almost never return IEnumerable<T>. I don’t know that the return value will only be enumerated once. That’s outside my current layer of abstraction, so I shouldn’t be dealing with it. The safe bet is just to return a useful collection if that’s what I have. If my value really is enumerable, but not a collection, I will return an IEnumerable. In all other cases, it should be a more useful interface. lists an collections really are cohesive concepts that should be grouped into one object when needed.