Brendan Enrick

Daily Software Development

Parameter and Return Type Interfaces

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.

NP-Interface-Segregation

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.

Side Note: IEnumerable is not technically the requirement for a foreach loop.

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

3364773646_ebc547a3fa_o

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

6555544311_79789a44b9_o

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.

Schedule Standups in the Morning

It may not seem like it’s that big of a deal. I know a lot of people make sure to have a daily standup meeting either with just the team or involving the client. Either way, it’s very important to schedule these meetings in the morning. The reason for the level of importance I place on this is the tone of the meeting.

The most important thing to get out of a standup meeting is having everyone on the same page for what’s going to be done that day. You need to know who’s there, who’s working on what, if priorities are changing. It’s your opportunity to know what is going to happen that day (most likely happen).

If you conduct this meeting in the afternoon or near the end of the day, the tone can shift to discussing what did or didn’t get done. That’s all well and good to know, but it detracts from the discussion of the future. Remember, you only get so much time; use that time to make the next step a better one. Focus on where you’re going, not where you’ve been.

Deleting a Remote Git Branch

Another bit of git command line that a lot of people struggle to remember is the syntax to delete a remote branch. If you read my post from a couple of days ago, I mentioned a couple of things about deleting git branches. That’s how you delete them locally. If you want to push that deletion up to the remote repository as well, you need to take one additional step.

The command I use to delete remote branches is this:

git push origin :my-branch-name

It’s that “:” that tells it to delete the branch. Yes, it may seem confusing, but there is a reason for it. I’ll explain below for those who are interested in learning more.

Here is a slightly easier syntax, but I don’t like typing the additional characters.

git push origin --delete my-branch-name

Feel free to use this syntax, it’s newer, but you most likely have support for it. It’s been out for years now.

Here is the reason (other than its being shorter) that I like the first syntax better.

If you want to push our a git branch, you use this command:

git push origin my-branch-name

If you wanted it to have a different name remotely than it has locally, you would do this:

git push origin my-local-name:my-remote-name

Which means that if you wanted to push “nothing” over the remote branch with that name you would do this:

git push origin :my-remote-name

Notice how the command is pushing empty over that branch, which is then interpreted as a “delete” by git. That’s how I make sense of it, plus this is a neat little bit of info about the command.

I hope this helps people adopt and use git more easily. If you’re new to git or GitHub, I recommend that you check out my Pluralsight course, GitHub for Windows Developers. The course takes an easy-to-follow approach to getting you set up using Git, GitHub, and GitHub for Windows.

Deleting Git Branches Carefully

I noticed someone recently using a “hard delete” in the git command line recently. I commented on it being brave, but it turns out that he didn’t realize there was a different way to delete a branch in git. In case anyone else is wondering the difference, here is a quick tip on it.

In the git command line, you can use the “-D” parameter to delete a branch. It looks like this:

git branch –D my-branch-name

This will delete the branch regardless of whether it’s been merged back in. This can be dangerous, since you may lose changes that you’ve not yet merged elsewhere.

If you want to be more careful with your branch deletion, you should use a lowercase “d” with the “-d” or “—delete” parameter. That would look like this:

git branch –d my-branch-name

This will delete the branch only if you have merged the branch up already. This means that the branch’s changes should have been saved in the parent branch already, so it’s safe to delete. If you try this when it hasn’t been merged, you’ll received a message telling you that the branch was not deleted for this reason.

If you want to see the branches that still need to have their changes merged, you can do that using the following command:

git branch --no-merged

If you want to see the branches that can safely be deleted, because their changes have already been merged upstream, you can use this command:

git branch --merged

I hope you found these quick tips useful while you’re using git. If you’re new to git or GitHub, I recommend that you check out my Pluralsight course, GitHub for Windows Developers. The course takes an easy-to-follow approach to getting you set up using Git, GitHub, and GitHub for Windows.

Drag Drop Repo - GitHub Tips 5

I’ve got a Pluralsight course about using GitHub that went live on Tuesday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

There are a ton of ways to get a repository into GitHub for Windows to use it to manage your repository. I go over all of these in my Pluralsight course, but one of the neatest ways to add a repository is to just drag and drop the folder or the page.

You literally just need to go to the folder in explorer and drag the folder into GitHub for Windows.

DragFolderToCreate

Once you’ve dragged the folder in, it will bring up this “Create” context menu if it’s not already a repository. This will also call “git init” on the folder, so it becomes a repository.

AfterDragging

Once it’s done, you’ll have a repository. It will commit an initial .gitattributes and .gitignore file for you.

AfterDragAndCreated

If you already have a repository on GitHub, you can drag the URL into GitHub for Windows.

DragDropBrowserUrl

Once you drag it in, GitHub for Windows may want to know where to store the local copy. Just choose a location for it.

DragDropBrowserUrlChooseFolder

After it is done cloning the repository, you’ll have a local, connected copy.

DragDropBrowserUrlCloned

I hope these little tricks make it easier for you to set up repositories with GitHub for Windows, and if you want to learn more about GitHub, check out my Pluralsight course.

Open Shell Here - GitHub Tips 4

I’ve got a Pluralsight course about using GitHub that went live on Tuesday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

When you need to use the command line, it’s nice to open it right in your repository instead of having to “cd” your way there. When you’re in GitHub for Windows, you can use the Tools context menu to “Open Shell” like this:

OpenGitShellContextMenu

Once open, you’re in a git shell in your repository with context-aware information to help you complete your task.

GitShellOpenInRepo

I hope this quick tip is useful for you, and if you’d like to learn more about GitHub and GitHub for Windows, please check out my Pluralsight course.

Two Factor Auth - GitHub Tips 3

I’ve got a Pluralsight course about using GitHub that went live yesterday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

One of the main concerns that I hear from businesses about hosting their code off-site is security. While nothing can ever be “completely secure”, you can help yourself a little bit by enabling two factor authentication in GitHub. It uses most two factor authentication apps, so you can set up any device as the second key.

Once you’ve got it set up, GitHub for Windows will even prompt you for that auth token after you type your password. Annoying to have an extra step? Yes. More secure? Yes.

GitHubTwoFactorAuth

I hope that tip helps someone keep their GitHub account safer, and if you want to learn more about GitHub, please check out my Pluralsight course.

Descriptive Icons - GitHub Tips 2

I’ve got a Pluralsight course about using GitHub that went live today, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

When you’re running in GitHub or GitHub for Windows, you’ll see some icons that are near the repository name. These tell you a bit about the repository. They can indicate that a repository is a GitHub repository, non-GitHub repository, or a fork of a GitHub repository. They’ll be here when you’re running GitHub for Windows.

HighlightGitHubIcons

This icon indicates a GitHub repository:

GitHubIcon

This icon indicates a forked GitHub repository:

ForkedIcon

This icon indicates a repository that is either local-only or connected to a different remote (not GitHub):

LocalOrOtherRemoteIcon

I hope you find this quick tip useful. If you want to learn more about GitHub and GitHub for Windows, please check out my Pluralsight course!

Enter To Commit - GitHub Tips 1

I’ve got a Pluralsight course about using GitHub that will be going live this Tuesday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

I thought I would start out these posts with a very simple time saver. When you’re typing your commit message, you can just click enter to commit your changes.

Click Enter To Commit

If you’re including additional information in a description, clicking enter will just give you a new line like so.

 EnterNewLineDescription

I hope knowing this will keep you from having to move your hands from your keyboard, and if you want to learn more about GitHub, check out my GitHub course! This tip is not mentioned in my course, so you’ll need to watch it to learn more.

Being a Leader

I started my career as a software developer, because I love computers and I love building things. Building software, no matter the type of involvement, is an experience worth working toward. There are few things that can provide as much joy in such a short amount of time than seeing the text you’ve written come alive. In the last 5 years of my software development career, however, I’ve been leading teams of developers rather than just typing the lines of code that go into the software. Working with a team and building great things together is something I love regardless of the type of contribution I am making.

Now that I am transitioning back (at least for a time) into a primarily development role, I want to take some time and reflect on that change. I have enjoyed all of the work that I have done in my career, and I look forward to many more years building great things with great people.

I will never stop writing code. It’s too much fun to give up completely, but I also love people and working with people. For that reason, I enjoy leading teams of developers as well. I’ve spent these past 5 years trying to improve my leadership, not just for my own benefit, but for the benefit of my teams and the software we create. As many of you know, I blog so that I can share what I’ve learned with everyone (including my future self).  Let’s talk about leadership.

Know Your Team

As a leader, it’s important that you know your team’s strengths as well as their weaknesses. This is not exactly a radical idea, but it’s one that I’ve seen ignored far too often. Every member of your team has goals, opinions, preferences, etc. They’re people. If you don’t know anything about them, you’re not leading your team. The best experiences I’ve had as a leader are always when I am communicating and soliciting feedback and ideas from everyone involved.

I make a point of getting to know my team. I make sure to lighten the mood, so I can meet the professionals as well as the people they are. If I know that certain people have tendencies toward certain things, that allows me to lead them better. It’s my job to make sure that they’re doing their job well and are happy about it.

A good friend of mine, Steve Smith, recently took on the role of CTO of Falafel Software, and I was chatting with him about that new role. He was commenting about getting to know his team and having discussions with them. I suggested he spend an hour or two pair programming with everyone he’ll be working with. This gives him the chance to talk with them and also learn how they like to work. It comes with a couple of very important benefits: it lets Steve write some code and it also lets him learn about the projects.

Know Your Projects

One of the most frustrating things as a developer is having to constantly explain and re-explain a project to a manager. Don’t be that guy. Make sure you know the project. You’re involved. Sure, you need to talk and ask about how things are going, but you should understand what’s being done. You’re not there to tell people what to do. You’re there to help people get those things done.

If you need to sit down and pair with your team, do it! Sit with the designers and help them design. Sit with the developers and help them code. Work with the team. You’re a part of the team.

When I am leading a team, I am with the team. I’m only in my office when I need a quiet space. The rest of my time, I am sitting right next to the team. If I roll my chair back, I’m bumping into a developer or a designer. That’s my ideal situation. When anything happens in the project, I need to at least be aware about it, and constantly pestering my team for status updates is not an appropriate way to do that. It wastes their time and reiterates that my time is more valuable than theirs (completely false).

Solicit Feedback

Clearly, before I make a decision, it’s a good idea to make sure that the team has a chance to weigh in on things. When you are a leader, it is likely not a democracy. Make sure you know that and make sure the team knows that. If a decision I make will impact the team, I at least alert them to it before the decision is made. This gives the chance for cries of outrage. More often, I prefer to actually have a quick discussion before making my decision.

One topic that comes up all too often is physical versus digital kanban boards. This often has to do with the circumstances of the project. Obviously if everyone involved in the project is in the same room, a physical kanban board has a lot of benefits, but if you’ve got a single remote user, you’ll lean the other way. I’ve had a few developers with strong opinions one way or the other, so I try to accommodate when I can. I know which to use for each project because of the developers who are on them, because I get to know my team.

Asking for feedback allows the team involvement in the decisions and gives them some stake in things. Make sure you’re listening and taking their suggestions to hear. I know that I never know the best approach from the start. I chose my team, because they’re smart and can help me make the right choices. Often the right choice is based on the team, so you really should ask the team.

Identify Leaders

As a leader, you need to help other leaders become better leaders. Often leadership qualities are on your team. That’s great for you! Let them take on some leadership. Give them the chance to lead some discussions, meetings, projects, etc. It will help them (and the team) to build great things. Sharing responsibilities with others will let you focus more, and will let them grow as leaders. You’ll need peers to help you lead others and people to cover for you when you’re busy or out of town.

Your team is often better at leading than you (or they) might expect. A leader who has never had the chance to lead may not know they can. If you can identify and grow leadership in your team, you will have empowered your team to make good decisions. The more your team can do on their own, the more you (and the entire team) are able to accomplish. Build more. Build better. Build the leadership in your team. It’s there already. You just need to find it and grow it.

Lead the Team

Yes, this also sounds kind of silly to mention here, but I am serious. There is a big difference between leading and directing. If you’re leading, you’re out front blazing a trail. If you’re directing, managing, or even guiding, you don’t have to be out front. When you’re leading a team, you’re setting examples. You’re doing things the right way (whatever that is for your project). You’re not cutting corners or doing a sloppy job. It’s your job to not only help, but to make sure that everyone else can follow in your footsteps to achieve success.

How you lead a team is extremely important. If you cut corners, your team will as well. If you have a sour attitude about the project, that will spread. If you’re lethargic and bored by the project, you won’t be seeing an interested, engaged team. Be the team you want your team to be. If you don’t you can’t expect any better from anyone else. This doesn’t mean you need to be the best developer, designer, tester, copy-editor, or anything else. You just need to be willing to put forth good, positive effort. You’ll be amazed at the results. When I do that right with a project, I am always impressed with how the whole teams steps up to every challenge. Whenever I’ve cut a corner, I see it repeated. It’s just not worth doing.

Set an example. Be a leader to emulate. Stay positive. Keep things moving smoothly. That is your job. Leading is hard. Doing it right is harder, but it’s very worth it. If you do it right, your team will do amazing work that will have you in awe. With that said, I’d like to thank all of the developers and designers who have ever been on my teams. I was glad to have every one of you on my teams, and you did fantastic work. (You all knew that already though!) We all achieve some great things! Now it’s my turn again!