Why long emails should be avoided as a Dev Lead

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 they 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 didn’t know.
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.

Code Review – Quick Reference

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 n2 vs when it could be constant or log n.
See: https://en.wikipedia.org/wiki/Big_O_notation

Parameter Value Coverage by Type

This article is a reference to Unit Testing with Parameter Value Coverage (PVC).

Primitive or Value Types

See this reference.

Short Name.NET ClassTypeWidthRange (bits)
byteByteUnsigned integer80 to 255
sbyteSByteSigned integer8-128 to 127
intInt32Signed integer32-2,147,483,648 to 2,147,483,647
uintUInt32Unsigned integer320 to 4294967295
shortInt16Signed integer16-32,768 to 32,767
ushortUInt16Unsigned integer160 to 65535
longInt64Signed integer64-9223372036854775808 to 9223372036854775807
ulongUInt64Unsigned integer640 to 18446744073709551615
floatSingleSingle-precision floating point type32-3.402823e38 to 3.402823e38
doubleDoubleDouble-precision floating point type64-1.79769313486232e308 to 1.79769313486232e308
charCharA single Unicode character16Unicode symbols used in text
boolBooleanLogical Boolean type8True or false
objectObjectBase type of all other types
stringStringA sequence of characters
decimalDecimalPrecise fractional or integral type that can represent decimal numbers with 29 significant digits128±1.0 × 10e−28 to ±7.9 × 10e28

byte

  1. Zero, 0, which is also byte.MinValue.
  2. A positive byte between 0 and 255.
  3. byte.MaxValue or 255

sbyte

  1. Zero, 0, which is also sbyte.MinValue.
  2. A positive sbyte between 0 and 127.
  3. A negative sbyte between -128 and 0.
  4. sbyte.MaxValue or 127
  5. sbyte.MinValue or -128

int

  1. A positive int between 0 and 2,147,483,647
  2. A negative int between -2,147,483,648 and 0
  3. Zero, 0
  4. int.MaxValue or 2,147,483,647
  5. int.MinValue or -2,147,483,648

uint

  1. Zero, 0, which is also uint .MinValue.
  2. A positive uint between 0 and 4,294,967,295.
  3. uint .MaxValue or 4,294,967,295

short

  1. A positive short between 0 and 32,767
  2. A negative short between -32,768 and 0
  3. Zero, 0
  4. short.MaxValue or 32,767
  5. short.MinValue or -32,768

ushort

  1. Zero, 0, which is also ushort .MinValue.
  2. A positive ushort, such as 1 through 65,535.
  3. ushort.MaxValue or 65,535

long

  1. A positive long between 0 and 9,223,372,036,854,775,807
  2. A negative long between -9,223,372,036,854,775,808 and 0
  3. Zero, 0
  4. long.MaxValue or 9,223,372,036,854,775,807
  5. long.MinValue or -9,223,372,036,854,775,808

ulong

  1. Zero, 0, which is also ulong.MinValue.
  2. A positive ulong between 0 and 18,446,744,073,709,551,615.
  3. ulong.MaxValue or 18,446,744,073,709,551,615

float

  1. A positive float between 0 and 3.402823E+38
    1. Note: This includes the float.Epsilon, but you could test double.Epsilon separately
  2. A negative float between -3.402823E+38 and 0
  3. Zero, 0.0
  4. float.MaxValue or 3.402823E+38
  5. float.MinValue or -3.402823E+38
  6. float.NaN
  7. float.PositiveInfinity
  8. float.NegativeInfinity

double

  1. A positive double between 0 and 1.79769313486232E+308
    1. Note: This includes the double.Epsilon, but you could test double.Epsilon separately
  2. A negative double between -1.79769313486232E+308 and 0
  3. Zero, 0.0
  4. double.MaxValue or 1.79769313486232E+308
  5. double.MinValue or -1.79769313486232E+308
  6. double.NaN
  7. double.PositiveInfinity
  8. double.NegativeInfinity

decimal

  1. A positive double between 0 and 79,228,162,514,264,337,593,543,950,335
  2. A negative double between -79,228,162,514,264,337,593,543,950,335 and 0
  3. Zero, 0
  4. double.MaxValue or 79,228,162,514,264,337,593,543,950,335
  5. double.MinValue or -79,228,162,514,264,337,593,543,950,335

string

  1. A null string
  2. An empty string, String.Empty, or “”
  3. One or more spaces ” “
  4. One or more tabs ” “
  5. A new line or Environment.NewLine
  6. A valid string.
  7. An invalid or junk string
  8. A string with many special characters: `~!@#$%^&*()_-+=,.<>/\?[]{}|
  9. Unicode characters such as Chinese
  10. An long string, over 256 characters, or even 1 million characters.
  11. (Occasionally) Case sensitivity. For example, for string comparisons, case sensitivity of a string is a required Parameter Value Coverage test.

Struct

  1. It is impossible to know. You need to define this per struct you create. For example, if your struct is a point with int values X and Y, then it is simply the int list above twice, once for X and once for Y.

Enum

  1. Any of the enums.
  2. You may need to do each of the enums, depending on how your enum is used.

 

Class or Reference Types

Class Object

Objects that are defined with the class keyword need the following tested:

  1. Null (This might go away or become optional in .NET 4.8)
  2. Instantiated
  3. Class properties can be primitive or value types, reference types, etc., and may need to be tested according to the type of the property.

Array, List, Dictionary, and other collections

Array, List, Collection

  1. Null
  2. Empty (instantiated with no items)
  3. Not empty but values of array are tested according to the value type. For example, an int[] would need to have the values tested in the ways listed above for int.

Dictionary

  1. Null
  2. Empty (instantiated with no items)
  3. Key exists
  4. Key doesn’t exist
  5. Value at key is tested according to its value type. For example, a Dictionary<string, int> would need to have the values tested in the ways listed above for int.

Amazon Ec2 Instance Management with C#: Part 3 – Uploading and Importing a Key Pair

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.
  2.         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#

Interviewing: A developer should have a portfolio

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.

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.