Criticality and Communication

The title of this blog post was originally to be ‘criticism’, but This Developer’s Life already used that. I suppose it’s for the best anyhow, since the idea behind this post is to address not only criticism, but the ability to communicate as well. It stems from a discussion my wife and I had as we walked home from a screening of the extended edition of Lord of the Rings: Fellowship of the Ring last night.

Being a nerd, engineer, computer scientist, programmer, coder, web developer, or any other such title that you can lump us into, is hard. It’s not only hard because of the increasing complexities of emerging technologies. Some of the biggest difficulty for us is actually around interpersonal relationship skills. We find others to be strange, alien creatures, who we do not understand. We marvel at how easily it can come to some, but at the same time look with a perplexed eye, since we do not think as they do. Why is this? It’s because we see the world through monochrome tinted glasses; We see a world of boolean logic, in which something either is, or it isn’t. It is with this polarizing conviction that we derive our deep seated views, holy wars about technologies, and get extremely testy when confronted. Further, because the world is of course not black and white, true or false, we find middle ground to be… uncomfortable. So then what you end up with is a personality type that is not only polarized, but also critical. We are critical of those things which are not tidied, tied off, cleaned up, made parallel, and understood. It’s really a double edged sword.

So, when you confront someone with a different view from their own, and that view is firmly seated in their mind, what happens? The reaction is, perhaps surprising, perhaps not, that they actually will stick to what they know more adamantly than before. This is known in the psychology community as the ‘backfire effect‘. My wife posits that this could actually be the cause of many of the world’s serious problems, such as religious wars, government policy stance on moral issues, etc. So what is one supposed to do to attempt to pry open anothers mind? How do we do it without seeming like we’re forcing our views on theirs? We just want to crack through ever so slightly, so as to allow alternative perspectives to enter their locked mind. I’m not sure I have the answer on how to do this. Maybe you do.

Nerd psychology is a vast, complex topic. The personality of the ‘alpha geek’ is so pervasive in the industry of software engineering, that you can often times learn how to deal with many, by just basing your interactions off of one. The attitudes of “I know it all”, and “this way is best”, and “obviously this technology X is not as good as Y”, are like a poison, a poison which threatens to turn our programmers world of creation into a cesspool of bickering, snapping at one another, dismissing eachother as not intelligent, and an all around gnashing of teeth. Too often this poison presents itself, and when it does, its typically accompanied by a very unpleasant, snarky, “I’m better than you” attitude. This attitude leaks through in a very obvious way, even when it is not vocalized or intended to be communicated. We must drive this poison out, and attempt to make eachother see the world through a spectrum of colors. The value of other perspectives in software engineering cannot be overstated, and is too often a blind spot for otherwise gifted developers.

Const vs readonly

In C# when you want to have a named constant you have a choice between ‘const’ and ‘readonly’. For example:

public const string FooConst = "Bar";
public static readonly string FooReadonly = "Bar";

Which is appropriate?

Assembly Recompilation

You should only ever use ‘const’ on private fields. Using ‘const’ on a public field means that constant must be compiled into any consuming assembly. You might ask why having a constant compiled into consuming assemblies is a problem: The issue is that if you change that field, all consuming assemblies must be recompiled. Using ‘static readonly’ will not require consuming assemblies to be recompiled.

Flexibility/Mutability

Using ‘const’ is only possible with primitives, other value types, and strings, as its value is burned directly into the assembly. ‘Readonly’ on the other hand has no restrictions whatsoever, since it’s just a one time allocation of memory that has measures in place to prevent modification.

Also important to note is that ‘readonly’ only prevents the reference from being modified, not the actual memory being pointed to by the reference. To illustrate, the following is legal:

    public class Foo
    {
        public static readonly IList<string> barReadonly = new List<string>();
 
        public static void AppendString(string newString)
        {
            barReadonly.Add(newString);
        }
    }

Run time vs Compile time

A ‘const’ must be initialized immediately in code, and is initialized at compile time. A ‘readonly’ can be initialized at runtime, so long as it’s taken care of before the ctor exits.

Summary

In general, use ‘const’ when you know for certain that a value will never change, ever, or if the value is private. Otherwise, use ‘static readonly’.

Unit Testing Principles

Writing good unit tests is challenging. Over time I’ve accumulated a number of principles about what to do in unit tests, as well as what not to do. This list is incomplete, but I’ll start it now.

• Test every possible code path. This means that for each ‘if’ statement, you’ll have at minimum 2 tests. Also known as code coverage.
• Write your tests first. TDD is a hard mindset to get into, but well worth it.
• If you have doubts about whether your code will do what you intend, you haven’t written enough tests.
• Your tests should never make calls to external resources such as a database, filesystem, etc.
• Every test should be self-sufficient and isolated. Your tests should not rely on other tests, or external factors. Be skeptical of setup/teardown code for a test harness class. (xUnit embraces this)
• Don’t test outside your code. There is no need to write test cases for an assembly you are dependent on.

This list will grow over time, especially if you have suggestions I might add.

IL Merge

There’s a neat little utility created by Microsoft Research called IL Merge which takes multiple .NET assemblies and merges them into one. I’m not sure I have a practical use for it myself, but the availability of such a tool to do so is nice. There is also a chocolatey NuGet package available.