Trying to impress people with your code

March 24, 2016

In this post, I’d like to write about the personal traits we all possess. Namely, I want to talk about being proud of your code and trying to impress people with it.

Trying to impress people with your code

Most programmers like to program. No surprise here, of course. Otherwise they wouldn’t become programmers in the first place. It is also common for us, humans, to be proud of our craft and even brag about it from time to time. That is totally understandable and shouldn’t be frowned upon by anyone.

However, the subject of that brag often tells a lot about the values the programmer carries. It’s a good litmus test for the principles he or she thinks are the most important in their job.

I remember a couple years ago someone boastfully demonstrated me a piece of code similar to the following:

IReadOnlyList<Customer> customers1 = GetCustomersFromFirstSource();
IReadOnlyList<Customer> customers2 = GetCustomersFromAnotherSource();
 
foreach (var customer in customers1
    .Select(x => new { x, IsFromFirstSource = true })
    .Concat(customers2.Select(x => new { x, IsFromFirstSource = false})))
{
    if (customer.IsFromFirstSource)
    {
        DoSomething(customer);
    }
    else
    {
        DoSomethingElse(customer);
    }
}

What does this code can tell the reader? Well, it certainly tells you that its author knows LINQ and can work with anonymous types in C#. However, as far as the actual purpose goes, it is not as obvious.

This code can be easily simplified so that the need for both of these features vanishes:

IReadOnlyList<Customer> customers1 = GetCustomersFromFirstSource();
IReadOnlyList<Customer> customers2 = GetCustomersFromAnotherSource();
 
foreach (Customer customer in customers1)
{
    DoSomething(customer);
}
 
foreach (Customer customer in customers2)
{
    DoSomethingElse(customer);
}

This version is not as exciting, of course. Moreover, it’s a plain bore to write such code. How can we apply our abilities and demonstrate them to the colleagues when we are supposed to write code like this? Shouldn’t we as programmers try to fully use all our skills and knowledge at work? A little bit of brag wouldn’t hurt either.

The line of thinking above isn’t completely wrong. As I mentioned, there’s nothing wrong in trying to impress people with your code. A mild brag indeed wouldn’t hurt anyone. However, many programmers choose an improper subject for their brag. They try to optimize the solution by maximizing the number of features and unique programming techniques applied in it. Whereas, a better optimization target would be simplicity.

Instead of showing how many language or framework features you know, try to impress your colleagues with how simple the solution you came up with is. I’ve written about it before but it’s worth repeating it here: the simpler your solution is, the better you are as a programmer. A sign of the greatest mastery is building a code base the purpose and the execution flow of which is so obvious that it becomes boring to read it.

It doesn’t mean you should avoid difficult tasks. In fact, your ability to deliver simple solutions even for complex problems is what you should aim for. Programmers who would support your code base afterwards will be grateful for such an attitude of yours.

It may sound unattractive but to become a great software developer, you should embrace boring code. The simplicity of your solution and the boredom of the developers reading it is what you should strive to achieve. Don’t try to impress people with how many language and/or framework features your know. Instead, impress them with how you are able to simplify the problem you were given.

Trying to impress people with your architecture

The same is true when you are building a high-level architecture for your application. It’s often the case that a programmer tries to foresee the future needs and include as many "configuration points" to the application as possible. They try to build a framework which will stand the test of time in that it won’t require a lot of modifications even in the face of possible requirement changes.

It shouldn’t be a surprise that one of the reasons for such a behavior is an effort to impress people. Many programmers consider their ability to build an architecture which is complicated enough to handle requirements changes a good indication of their great abilities as software architects.

That is also a false goal. A general guideline when you design your application should be to delay as many architectural (i.e. "set in stone") decisions to the future as possible. You never know for sure whether or not your current implementation will be sufficient for the future needs. And you never know whether or not the configuration points you laid in your code base will handle everything the business will require from it.

The only way to reduce the amount of work you will need in the future is to build as specific solution as possible for the requirements you have at hand. So specific that it will be easy to understand and change it if needed.

So, again, trying to impress people with your architecture is fine but there’s nothing impressive in an overcomplicated solution which tries to handle requirements no one even posed. The simpler your architecture for a given problem is, the better you are as an architect.

Here’s a nice figure that depicts all said above:

Types of problems vs types of solutions

Summary

A little bit of brag in our work is fine, we all like to be proud of our craft. However, don’t try to impress people with how many features you used in your code or how complex the architecture of your code base is. Impress with the simplicity instead. Ideally, your code should be so simple that reading it becomes a plain bore.