Archive for August, 2010|Monthly archive page

Coding without a License: The trick question of “Counting code with LINQ”!

The job offer

My small business recently posted a job offer for a part time contract C# and WPF developer. Here’s a snippet from my job posting:

I am not really interested in your resume or schooling as much as I am interested in:

  • Your programming prowess
  • Your communication skills
  • Your ability to work independently and with others
  • Your ability to get things done and done elegantly

If you are interested, please send me your answers to the following:

  • What is a dependency property?
  • When would you use an attached dependency property?
  • Write a thread-safe singleton in C# and explain why it is thread-safe.
  • Write a C# program that counts and displays the number of lines of C# code across all files in the current directory and all subdirectories.
  • Compare and contrast an RRSP with a TFSA.
  • Suggest some alternatives to using dialog boxes from a usability perspective.

You are of course welcome to use the internet to help answer these questions

And at the very bottom of the job posting I wrote:

“BTW, I will only be contacting applicants that have great answers to the above questions.”

I received about 15 job applications from people that had not even bothered to answer the questions and who “spoke English really good” (or words to that effect). I of course deleted their e-mails without a second glance, but I wondered why people do that? Do these people really get jobs that way? Why on earth would you expect me to hire somebody that can’t even follow the simple directions in the job application?! I can only imagine how badly they would do if I asked them to program something reasonably complex (literally – I have no idea how they program because they didn’t send me any code…)

However I was happy to receive a healthy number of job applications that did answer the questions and provided a C# program to count lines of code. Some of the solutions were simple console applications, while others were multi-threaded Windows Forms applications that were hundreds of lines of code (I know of course because I ran the program against its own source code).

I had not realized that such a seemingly simple task would be solved by different programmers so dramatically differently, and it was really interesting looking at everybody’s code and the different ways they solved the problem. I think you can learn a lot about a program from a small sample of their work (which is of course why I had asked them to write some code). Thank you to everybody that provided a response and I really am keeping you on a short list when I hire next time.

My code-counting solution

Before I posted the job, I wanted to ensure that I wasn’t asking anything that I couldn’t do myself in just a few lines of code; so here is my LINQ solution in only 20 lines of (non-blank) code:

using System;
using
System.IO;
using System.Linq;

namespace
CodeCount {

/// <summary>
/// A simple program that counts all the lines of C# code in the
/// current directory and all sub directories.
/// </summary>

public class Program {

public static void Main(string[] args) {

var cwd = Environment.CurrentDirectory;

int lineCount = (from fileName in Directory.GetFiles(cwd, “*.cs”,

SearchOption.AllDirectories)
where
!fileName.EndsWith(“AssemblyInfo.cs”)

from
line in File.ReadAllLines(fileName)

where
line.Trim().Length > 1

select
line).Count();

Console.WriteLine(“Number of non-blank lines of C# code:” + lineCount );

}

}//class

}//namespace

I took the liberty of also excluding the AssemblyInfo.cs file, which most programmers usually don’t even modify and so do not really reflect on the size of the application (although it doesn’t add much either).

What I love about LINQ is that it’s possible to accomplish a lot of functionality in very few lines of succinct but highly readable code. I think I could provide the above code to another programmer who could easily modify it to meet additional requirements (perhaps excluding C# line comments (lines starting with // and ///)).

To see how this performed I added a Stopwatch around the line counting code to see how well it was performing:


var timer = Stopwatch.StartNew();

var cwd = Environment.CurrentDirectory;

int lineCount = …

timer.Stop();

Console
.WriteLine(“Counted in “ + timer.ElapsedMilliseconds + “ms”);

On my reasonably powerful developer-desktop this program took 572ms to count »135,000 loc, which is pretty slick (although completely without any baseline, but it’s fast enough that I went “Ohhhh… Ahhh…” which is all I was looking for).

Trick question!

However, my job posting question was actually a trick question! The real answer to my original question #4 – and
the answer that unfortunately nobody gave me – was simply, “Can you please provide more details around exactly what you are looking for?” I would have been very happy to open a dialog with any job applicant about what my “requirements” for the program were. I would hire a developer that asked for clarification over a developer that programmed a multithreaded GUI application in a heartbeat because I’m paying by the hour! As a small business I really can’t afford to be paying somebody $75/hour to build the wrong thing! I had decided ahead of time to respond that a “console application would be fine, and perhaps LINQ would simplify the code” – but nobody asked.

Theorem:

At a very fundamental level: No programmer can possibly know everything about anything! Off the top of my head:

  • Textbooks on just basic coding practices (on things like why multi-exit functions aren’t actually a slippery slope to hell)
  • The subtleness of object-oriented analysis and design
  • A small pile of textbooks around design patterns
  • The .NET framework is an amazing but enormous pile of functionality
  • C# has piles and piles of subtle points (for example, what’s the difference between throw; and throw e; ?)
  • There’s all the complexities and wonderful weirdness of WPF, Silverlight and XAML
  • There’s the huge kettle-of-fish called WCF

There’s simply no way for a developer to know everything (which is also why it takes at least 10 years to get really good). Of course any reasonable manager/boss should know and accept it, expect a constant learning curve, and offer continuous mentoring.

Aside: I remember one time when my family doctor said, “Hold on, I’m going to look-up the best medicine for these particular symptoms” – I was both delighted and relieved, and then awestruck when he pulled down a textbook the size of three thick design-pattern books with font ¼ the size and started flipping through it. Why isn’t every doctor doing this? Are they really pretending to have memorized ever possible medicine out there and all of its side-effects and interactions with other medicine? What are they prescribing anyway?! Sure there are the classic standbys, but in more than decades of going to doctors this has only happened once…

The main corollary to the theorem “You can’t possibly know everything” is that “You need to be good at looking things up”. That’s why I asked the questions in the job application and specifically stated that of “course you are welcome to use the internet to help answer these questions”. I wanted to know how good people were at looking things up and summarizing and (maybe even) understanding what they found.

Robert

BTW, the individual to whom I offered the job included this comment with his code: “I wasn’t sure how fancy or complicated this program should be, but in the end, simple usually trumps gold-plating.” I thought that was pretty wise.

Advertisements