Wednesday, May 24, 2006

The Skills that Don't Pay the Bills

The other day I was asked a question by a friend/co-worker about what skills are important to have for a developer today. Reflecting on the question, I think he wanted to know what skills make somebody a more attractive candidate on the job market. Of course rather than answer the question, I went off on a tangent regarding a recent pet peeve of mine.

More and more, I'm finding that .Net developers are losing touch with how things work. Microsoft has abstracted many programming functions to such a high-level, many people in the industry have forgotten (or no longer bother to learn) what's going on under the hood. I suppose this is a natural and necessary evolution; the growth of the talent pool doesn't come close to the expansion of software development and implementation needs. By dumbing the work down with every release, Microsoft expands the pool of workers while fostering a need for the latest software and training.

The result is an increasing gap between programmers/engineers and coders. So my answer to the original question was--try to be the former rather than the latter. In many ways the distinction is subjective, but if I wanted to gauge somebody's programming abilities, here are some of the things I might ask.
  • Write a function that sorts an array. Describe it in big-O notation.

  • Write the pseudocode for a simple XOR encryption algorithm

  • You have a table in a database with 1,000,000 rows and need to extract a single-specific record. What is the maximum number of records that will need to be evaluated to return the required row if the column you're looking at has a clustered index vs non-indexed with unique values.

  • Write your own string-builder

  • Design a custom cache mechanism

From what I've seen of the job market of late, it's unlikely these things are going to help one command a higher salary, but I think this depth of understanding is becoming a lost art in business software development.