I keep failing to a avoid a common mistake as a leader. Sending long emails. It seems so easy. For whatever reason, as the dev lead, I cannot talk to a person face-to-face so I write a long email.

I could spend time talking about why email is bad, or I could show you how emails make people feel by showing you an email dialogue.

Why long emails should be avoided:

Dev Lead: I’m being a good mentor. Write a nice long email that will help the team grow on a subject A, that includes tons of info on Subject A, including its 5 benefits. I send this email to Dev1 and CC the other two members of my team.
Feels good about his leadership.

Dev 1: What the dev thinks: Uh, oh. The dev lead is having a hissy fit again. Looks like he is pissed at something I did. What a jerk.
Feels angry.

Dev 2: Oh no. I have no idea what the dev lead is talking about. Do I know my stuff? Googles and tries to learn what the dev lead is talking about.
Feels shamed.

Dev 3: Ugh! Why is he trying to teach me crap I already know.
Feels patronized.

Manager: Hey, the team didn’t appreciate that email.

Dev Lead: Feels like a poor leader.

Manager: Feels like he is losing his team.

Why it would have happened better face-to-face:

Dev Lead: Hey devs. I want to discuss subject A. What do you know about it already?

Dev 1: I’ve used it before

Dev 2: Stays silent.

Dev 3: I know all about Subject A.

Dev Lead: OK, Dev 3, tell us about subject A.

Dev 3: Gives four excellent points about subject A. One of them the dev lead didn’t know.

Dev Lead: Adds two points about subject A that Dev 3 didn’t know. Changes his list from 5 to 6 adding the one item Dev 3 did knew.
Feels impressed by Dev 3.

Dev 1: Feels growth.

Dev 2: Feels good to be introduced to a new subject.

Dev 3: Impressed that the dev lead let him educate the team.
Feels more respect for dev lead. Also notes that the Dev Lead knew things he didn’t and thinks he should listen more.

Manager: Feels good about the team.

It is all about the feelings, and there is something about face-to-face team interaction that leads to good feelings and something about long emails that always leads to bad feelings.

So, if you look at the face-to-face interaction, you can see that it all started with a short question. You could simulate this in a short email:

Dev Lead: Who can give me all the benefits of Subject A using only the knowledge in your head. No browser search allowed until after you respond.

Dev 1: Responds with the single most common benefit if subject A.

Dev 2: Doesn’t respond.

Dev 3: Responds with four items, one that the dev lead didn’t now about.

Dev Lead: Interesting. Here are the items that the team responded with. I added two more benefits for a total of 6. Should we use subject A to get those 6 benefits in our project?

Now imaging the response was crickets.

Dev Lead: Who can give me all the benefits of Subject A.

Dev 1: Doesn’t respond.

Dev 2: Doesn’t respond.

Dev 3: Responds with one item.

Dev Lead: Subject A is interesting and important to our project. I am going to create a quick training on it.

Dev Lead: Writes a doc on it and sends it to the team.

Team: Feels good to learn something new.

Manager: Feels like the team is running itself.

Tips

1. Keep emails short.
2. Use many short emails.
3. Ask questions, preferable one-liners:
   1. Start by asking your team what they already know first.
   2. Ask follow-up questions second
4. Compile responses into a bulleted list
   1. Add to the list if you can
   2. Ask questions about the list
5. Thank the team

I am going to put these tips into practice next time I feel like sending a long email.

This is a simple check-list to make code reviews more valuable. Simply check these rules.

Download a single page word document: Code Review Cheat Sheet

Does the code follow the 10/100 Rule?

This is a quick check rule that isn’t extremely rigid. See the 10/100 rule of code

Method has less than 10 lines

Is the method that was added or changed 10 lines or less? (There are always exceptions such as Algorithms)

100

Is the class 100 lines or less?
Note: Model classes should have zero functions closer to 20 lines. Logic classes should be sub-100 lines.

Is the code S.O.L.I.D.

S.O.L.I.D. is an acronym. See this link: https://en.wikipedia.org/wiki/SOLID

Single Responsibility Principal

Does each class have a single responsibility? Does each method have a single responsibility?
Is this the only class that has this responsibility? (No duplicate code or D.R.Y. (Don’t Repeat Yourself)

Open/Closed Principle

Can you extend the functionality without modifying this code? Config, Plugins, event registration, etc.
Is there configuration is this code? If so, extract it. Configuration does not belong in code.

Liskov substitution principal

Is inheritance used? If so, does the child type cause issues the parent type wouldn’t cause?

Interface segregation principle

Does the code use interface-based design?
Are the interfaces small?
Are all parts of the interface implementations without throwing a NotImplementedException?

Dependency inversion principle

Does the code reference only interfaces and abstractions?
Note: If new code references concrete classes with complex methods, it is coded wrong.

Is the code Unit Tested

99% coverage

Is the Code 99% covered? Is code not covered marked with the ExcludeFromCodeCoverageAttribute?

Parameter Value Tests for methods with parameters

Are all parameter values that could cause different behavior covered?
See these links:
Unit testing with Parameter Value Coverage (PVC)
Parameter Value Coverage by type

Naming things

Typos

Are your names typo free?

Naming convention

Do your file names, class names, method names, variable names match existing naming conventions?

Big O

Do you have any glaringly obvious Big O problems? n or n² vs when it could be constant or log n.
See: https://en.wikipedia.org/wiki/Big_O_notation

Before getting started

Skill Level: Beginner

Assumptions:

1. You have completed Part 1 and 2 of Managing Amazon AWS with C# – EC2

Additional Information: I sometimes cover small sub-topics in a post. Along with AWS, you will also be exposed to:

• .NET Core 2.0 – If you use .NET Framework, the steps will be slightly different, but as this is a beginner level tutorial, it should be simple.
• Rhyous.SimpleArgs

Details

We may already have a key pair that we want to use, so we don’t want to create a new one. If that is the case, it can be uploaded.

Step 1 – Get key in the correct format

I used OpenSSL to do this.

1. Download OpenSSL.
2. Run this command:
   [sh]
   .\openssl.exe rsa -in c:\users\jbarneck\desktop\new.pem -pubou
   t -out c:\users\jbarneck\desktop\new.pub
   [sh]

Step 2 – Edit InstanceManager.cs file

We’ve created InstanceManager.cs in Part 1. Let’s edit it.

1. Add a method to read the key file from disk and upload and import the key pair.

        public static async Task ImportKeyPair(AmazonEC2Client ec2Client, string keyName, string keyFile)
        {
            var publicKey = File.ReadAllText(keyFile).Trim().RemoveFirstLine().RemoveLastLine();
            string publicKeyAsBase64 = Convert.ToBase64String(Encoding.UTF8.GetBytes(publicKey));
            await ec2Client.ImportKeyPairAsync(new ImportKeyPairRequest(keyName, publicKeyAsBase64));
        }

Notice: We are calling RemoveFirstLine() and RemoveLastLine(); This is because key files have a header and footer that must be removed before sending up to AWS. We’ll do this in the next section.

Step 3 – Add methods RemoveFirstLine and RemoveLastLine

1. By the time this publishes, you should only need to install Rhyous.String.Library. Otherwise, add this class file:

   namespace Rhyous.AmazonEc2InstanceManager
   {
       public static class StringExtensions
       {
           public static string RemoveFirstLine(this string text, char newLineChar = '\n')
           {
               if (string.IsNullOrEmpty(text))
                   return text;
               var i = text.IndexOf(newLineChar);            
               return i > 0 ? text.Substring(i + 1) : "";
           }
   
           public static string RemoveLastLine(this string text, char newLineChar = '\n')
           {
               var i = text.LastIndexOf(newLineChar);
               return (i > 0) ? text.Substring(0, i) : "";
           }
       }
   }
   

Step 4 – Configure command line Arguments.

We already have an Actions arguments to edit.

1. Add DeleteKeyPair as a valid action to the Action argument.
2. Add an additional argument for the key file.

                . . .
                new Argument
                {
                    Name = "Action",
                    ShortName = "a",
                    Description = "The action to run.",
                    Example = "{name}=default",
                    DefaultValue = "Default",
                    AllowedValues = new ObservableCollection<string>
                    {
                        "CreateKeyPair",
                        "DeleteKeyPair",
                        "ImportKeyPair"
                    },
                    IsRequired = true,
                    Action = (value) =>
                    {
                        Console.WriteLine(value);
                    }
                },
                . . .
                new Argument
                {
                    Name = "KeyFile",
                    ShortName = "pem",
                    Description = "The full path to a public key already created on your file system in PEM format. The full Private key won't work.",
                    Example = "{name}=c:\\My\\Path\\mykeyfile.pem",
                    CustomValidation = (value) => File.Exists(value),
                    Action = (value) =>
                    {
                        Console.WriteLine(value);
                    }
                }

You can now upload a public key file for use on the Amazon Cloud.

Next: Part 4

Return to: Managing Amazon AWS with C#

I recently started interviewing for some contract positions, one a Software Developer in Test position and one a Senior Software Developer position. I am deeply surprised by the candidates complete lack of having an online presence. As I thought more about this, I realized that we have reached a point of maturity in the Software Developer roles that portfolios are now expected. I expected every candidate to have an active account on some open source source control repository, i.e. GitHub, and have a portfolio of code there.

Portfolio

When it is time to interview for a position as a developer, you should have a portfolio. The days of coding on a whiteboard should be over. Instead, an interviewer should be able to easily see your code and what you have or haven’t done.

There shouldn’t be a question about whether you can write code. Instead, the question should be: Based on the code we can see this individual has written, can they be a good fit for our team?

Proprietary code

Your portfolio cannot include proprietary code. End of discussion. If you are a developer and you can’t find code that isn’t proprietary to put into your portfolio, then what are you doing?

Open Source/Non-proprietary code

Even when working with proprietary code, there are many pieces of code that are so ubiquitous that they probably should be part of the .NET framework. You may use this code in every project you work on. Such as common string extensions in C#, or a more complete string check in javascript that checks if a string is undefined, null, empty, or whitespace.

Even better is if your code is not just stored, but it is available to be used, such as with NuGet, npm, Maven, or other code or library packaging tool. This shows that you not only have a portfolio, but you aren’t going to waste your hours rewriting code you have already written.

Where to keep your portfolio

I used to have mine on SourceForge but have since switched to GitHub. Visual Studio online is another option. Where you store your portfolio of your work does not matter as much as the fact that you do store it.

GitHub is where I chose. But you can easily Google for GitHub competitors if you want it to be elsewhere.

Brand your portfolio

My internet handle is Rhyous. Every piece of code I write that is part of my portfolio (Non-proprietary or not for someone else’s open source project) is now branded with Rhyous. Some of my older code may not be, but my new code is. For example, all my namespaces in C# now start with Rhyous. That makes it very easy to differentiate projects I have forked vs projects that I have developed.

• Check out my account GitHub: https://github.com/rhyous/
• Also, search from Rhyous on NuGet.org to see my many NuGet pacakges.

What your portfolio must show

It must show:

• You have skills as a developer.
• SOLID principals.
• An understanding of the importance of Unit Tests.
• You refuse to waste time writing the same code twice.**
• You can work on projects with other developers.
• You bring more than just your skill set, you bring your ready-made building blocks.

** I find this to be so very important!

My Portfolio

My portfolio shows my skills as a developer. My code uses SOLID principals. Much of my code is Unit Tested.

I don’t like to write the same code twice. I for one, will never have to write a CSV parser in C# again as I have a good quality one: Rhyous.EasyCsv. Parsing arguments? I’ll never write an argument parser again because I have Rhyous.SimplArgs. I will never have to write many of my string extensions again as I can easily grab them for any C# project from my Rhyous.StringLibrary NuGet package. Tired of using TryGetValue to get values from your dictionary? Try Rhyous.Collections and use the NullSafe dictionary, which still used the TryGetValue but moves it inside the indexer so you don’t have to worry about it.

What a lack of portfolio shows

It has never clicked for you. What I mean by “It” is the idea of code reuse. The idea of object oriented programming. The idea of standing on the shoulders of giants. The simple idea of using building blocks as a kid and make things from building block.

Go out and make your portfolio and fill it with building blocks so every time you build something new, you can build on foundation building blocks that are SOLID and just get better.