The other day I was thinking about the skill set requirements for a strong senior level .NET Developer/Architect and I came the conclusion that the ideal candidate would be a strong mesh of a wide variety of skills. So I put together a list of topics of thing that I look for in ideal people I work with. I've always looked for these things, but never put them down on paper before now.

To be completely honest, the list of based partly on what I have always consciously looked for, but also on my pet peeves. For example, it drives me bonkers when a senior .NET framework developer doesn't have ANY ethical nature at all, when a senior .NET web developer doesn't even know the fundamentals of Ajax or even how to use Firefox Firebug at all, or when the same doesn't understand the difference between JavaScript from 1999 and Modern JavaScript (of course these are real examples.)

It's not that I'm looking for someone with 100% of the list, but for someone who can admit with humility that they don't and can learn as they go (though the ethics and attitude sections absolutely are non-negotiable!) Also, to be clear... I strongly believe in fairness. So, I do not put anything on the list that I do not possess. I do not feel comfortable demanding that someone I hire follow gender-neutral guidelines if I myself don't.

So, here's the list... is there anything that you would add? Please leave a comment if you have a skill that you wish someone would have in your own team (but make sure you have that skill before requesting it.) Also, obviously, for non-web developers, the web sections are not applicable and obviously some section are required more than others for certain roles.

Senior Level .NET Developer Skill Set (the absence of 'fundamentals', 'mastery', or 'proficiency' means 'general knowledge')

Programming

• General Programming Skills (Data Types, Iteration, Functions)
• Algorithm Proficiency
• Unary/Binary Operation Proficiency
• Declarative Programming Fundamentals
• Regular Expression Familiarity
• Framework Design Guideline Proficiency
• Collection/Array Differences

Language Specific Skills

• C# (or VB) Mastery
• Enumerators
• Delegates and Events
• Nullable Types
• Generics
• Preprocessor Directives
• P/Invoke Fundamentals
• COM Interop Fundamentals
• XML Documentation

CLR/Framework

• CLI Fundamentals (Memory Management, Assembly Loading)
• Framework Type Mapping (int -> Int32, long -> Int64)
• IL Fundamentals
• Framework Navigation Fundamentals
• Reflection / Dynamic Invocation
• Understanding of the 'Object' Type
• Core Assemblies
• Global Assembly Cache (GAC)
• Boxing/Unboxing Fundamentals

ASP.NET

• ASP.NET Concepts (CodeBehind, Compilation Model, Intrinsic Objects, ViewState, etc)
• ASP.NET Control Proficiency
• ASP.NET Page Life Cycle
• ASP.NET HttpHandler, HttpHandlerFactory, and HttpModule Proficiency
• Object-Oriented Nature of ASP.NET

Client-Side Development / General Web Development

• ECMAScript 3 (JavaScript 1.7) Proficiency (Closures, Anonymous Calls, etc)
• CSS Proficiency (Specificity, Selectors, Rules, etc)
• DOM Familiarity
• XHTML Mastery (and it's relation to HTML)
• Web Standards Familiarity
• MOS (Mozilla, Opera, Safari) and IE Development Differences
• Firefox Utilities (Firebug, Web Developer Toolbar)
• Core Ajax Fundamentals
• Classic Web Development Concepts (State Management, Stateless Development)

.NET Data

• ADO.NET Fundamentals (DataTable, DataSet, DataColumn, etc)
• Data Binding Fundamentals
• XML Serialization

.NET Concepts

• Assemblies
• Exception Handling
• Streaming
• Attributes
• Versioning
• Strong Naming
• Disposable Resources (and IDisposable)

Object-Oriented Principles

• OOP Principles (Inheritance, Polymorphism, Encapsulation) Proficiency
• OOD GRASP Patterns Mastery
• OOD GoF Pattern Fundamentals
• UML Fundamentals

Enterprise Architecture

• N-Tier Architectural Design
• Service Oriented Architecture Fundamentals
• Component Oriented Development Fundamentals
• Enterprise Services/COM Fundamentals
• MSMQ Fundamentals
• Web Service/WS-* Fundamentals
• RSS/Atom Fundamentals
• WCF Fundamentals (Address, Binding, Contract)

Data

• Set Theory Fundamentals
• Database Design/Data Modeling Mastery
• ACID and Normalization Concepts
• SQL Server 2005 Interaction Familiarity
• SQL Server 2005 Query Optimization
• SQL Server 2005 Index Design
• SQL Server 2005 Tuning
• T-SQL Proficiency
• O/R Mapper Familiarity
• XML/DTD/XSD/XSLT/XPath Fundamentals

System Technologies

• Windows Server 2003 Familiarity
• IIS 6 Proficiency
• Component Services (COM+) Familiarity (the tool)
• TCP/IP Fundamentals (Basic IP Theory, DNS, ping, tracert)
• Networking Fundamentals (Routers, Switches, DHCP Servers)
• Web Server Farm Fundamentals
• 'Run' Window Proficiency
• Batch File Fundamentals
• Windows Client Proficiency (Network Mapping, File Operations)

General Software Development

• Software Development Life Cycle Fundamentals
• Iterative/Agile/Waterfall/MSF Familiarization
• Version Control Familiarity (CVS, Subversion, etc)

Quality Assurance

• NUnit Familiarity
• Unit/Regression Testing Familiarity
• Profiling Fundamentals

General

• College Algebra Proficiency
• Statistics Fundamentals (probabilities mainly)
• Calculus Theory Fundamentals (rates of change fundamentals)
• Cryptography Fundamentals (asymmetrical, hash, checksum)
• Proper English Grammar (who vs. whom, etc)
• Solid Spelling Skills

Attitude

• Results Focused Attitude
• Vision Oriented (mainly for Architects and Team Leads)
• Paradigm Shifting Abilities
• Unlearning Abilities (the ability to unlearn obsolete paradigms)
• High Standards ("takes pride in his or her work")
• Unbiased to Vendors (i.e. doesn't say Microsoft SUCKS! or Linux blows!)

Ethics

• Patience for Technology and Other People
• Strong Ethical Nature (Honest, Trustworthy)
• Common Sense Sexual Harassment Law Adherence (a.k.a. maturity)
• Common Sense Use of Proper Language In and Around the Work Place (a.k.a. maturity)
• Common Sense Politics/Religious Respect
• Work Place Software Piracy Law Adherence
• Gender Neutral Language Guideline Adherence (mainly in documentation and professional correspondence)

As a technology architect who has an emphasis in web architecture, one thing that I find that most ASP.NET completely misunderstand is the concept of CSS architecture.  It's incredibly important to learn that CSS is not simply "styling". This is one of the most common misconceptions about CSS in existence. CSS is more than the silly “style” attribute on XHTML elements. If that were the case, then none of us should ever rely on CSS as the “style” attribute does little more than dramatically increase the coupling between page structure and style.

Fortunately , however, CSS is more than simply "styling". In fact, CSS is an acronym that stands for Cascading Style Sheets. It's not just some nice marketing acronym used to make the technology sound cool, but is rather a very well thought out acronym that explains CSS very well. When most people come to CSS, they only look at the middle letter ("style") and completely ignore the other two letters completely. You need to understand each of the letters in order to fully grasp the architectural power of CSS.

The third letter represents CSS is "sheet". This means that CSS is a technology designed to be placed by itself in its own file.  By keeping your CSS rules away from your XHTML structure you are maximizing the potential of your system be removing all coupling and maximizing cohesiveness. That is, your XHTML is doing what it does best by representing the page structure, leaving CSS to do its job by focusing on the visual elements. There is no sharing of responsibilities and the aren't directly tied to each other, thereby allowing reuse of your CSS rules.

There are secondary reasons for doing this as well. One of them deals with manageability.  Instead of being forced to change each "style" attribute on each element across multiple files manually, you now have a centralized place for your style.  Saying "it's just one 'style' attribute, what's it going to hurt?" is a sign of laziness and unprofessionalism that will leads only to more people saying the same thing leading to a complete nightmare of spaghetti code. Imagine if people did that with C# and ASP.NET: "what's the big deal? It's only one script block." You can destroy anything by taking cutting corners.

Another secondary advantage of keeping your CSS in "Style Sheets" (CSS sheet) is that it keeps your client download time to a minimum. If you keep your CSS away from your ASP.NET/XHTML structure, your client web browsers can cache the XHTML document and CSS page separately.  When the ASP.NET/XHTML page changes, the web browser doesn't need to get all the CSS information again. In the same way, if you need to change the "style" of something, you can do so in the CSS sheet without affecting anything else. If you kept your CSS either in the "style" attribute as a sloppy blob of CSS rules in a <style/> element, then even the slightest color change is a modification of the ASP.NET/XHTML structure leading to a recompilation.  You may have killed your page cache as well.

The cascading nature of CSS, or to the “C” in CSS, is also at the heart of CSS architecture. If you manage your CSS sheets correctly, then you should have a system where you can literally change one file and have it reflect across potentially thousands of pages. Your changes will naturally flow from XHTML page to XHTML page, from CSS to CSS, and from parent elements to child elements with well thought out, virtually object-oriented element style overriding. Trying that with HTML or with CSS coupled to your XHTML elements or pages!

By working with CSS as true CSS, not simply as a nice technology to change font sizes and colors, we are able to take the potential of CSS to its logical conclusion: CSS themes. If you create a set of CSS sheets that specify the images, layout, colors, and various other style related aspects a specific look and feel, then you are in the perfect place to allow themeing of your web site.  If the term "theme" doesn't appeal to you, what about the term "branding"?  A few years ago I was involved in a project for a major fast food chain who had about 10 different brands.  They basically wanted 10 different store fronts, which made the resident e-commerce developer about flip out.  However, using a properly designed CSS architecture, I was able to provide a simple, yet powerful branding model.  First, I defined the XHTML structure based on their semantic representation.  Second, I applied a colorless and image-less CSS page which gave each website its element positioning.  Third, I gave each brand its own folder with its own root CSS page and its own images and other media files.  All the developer had to do was look at the URL path to obtain the brand name and then change a single CSS page between brand.  The developer was actually able to sleep that night.

As you can see from this story, CSS themes can be very powerful and save a lot of time.  You could event go more complex in your CSS themes.  For example, you could use a CSS coordinator.  Then is when you attach a single CSS sheet to your XHTML page and have that single CSS sheet contain a series of “@import” statements.  You could then actually change the look and feel of your entire website without ever touching the ASP.NET/XHTML structure and thereby never forcing a recompile anywhere.  I often use this technique to coordinate a CSS page for screen size (800.css, 1024.css, 1280.css) with a theme (plain.css, green.css, blue.css), with a core feature set (report.css, membership.css, landing.css-- which would be tiny, so your landing page is very quick to load).  This technique should look familiar to anyone deep into object-oriented design as it's similar to some of the GoF structural design patterns. Having said that, this is not always a required technique and sometimes it can lead to caching problems itself. For example, how will the page know to get the new CSS sheet? Sometimes it's OK to invalidate cache or to force a recompile.

Another reason for proper CSS design that is continually growing in importance is media specific CSS. Say you created a screen for management that allows simple report creation. You put a set of ASP.NET controls next to the report to allow management to refine the report data. How can you allow management to print the report without printing the ASP.NET controls? How can you turn off the colors of the report to maximize print quality on a black laser printer? How can you remove the application header from the form so that the report prints professionally or to make sure the document prints on one sheet? All these things are possible with media specific CSS. By having one structure stating the content of the document you have a base level entity that can then be transformed to various output media. Media specific CSS works for more than just printers. If you thought ahead in your web architecture and therefore created a proper semantic representation of your XHTML elements and separated your CSS from your XHTML, you can easily add light-weight mobile support with very little effort. When a web browser views your page it will display in all its glory, when a printer accesses the page the buttons and header will be gone, and when a mobile device views the page the sidebar is now hidden, the fonts are now smaller, text shows in place of images, and the menu is now abridged.

You can easily add media specific CSS to your documents by placing more <link /> elements in your XHTML head element.

For example, the following will set a general CSS page, a print theme, and a mobile theme.

<link href="Style/ClassicTheme/default.css" rel="stylesheet" type="text/css" />
<link href="Style/ProfessionalPrintTheme/default.css" media="print" rel="stylesheet" type="text/css" />
<link href="Style/SimpleMobileTheme/default.css" media="handheld" rel="stylesheet" type="text/css" />

One thing you may want to keep in mind about this is that the iPhone is not considered a “handheld” device. To add a media specific CSS page to the iPhone, please see this article.

It's hard to overestimate the importance of proper CSS architecture, yet I find that most web developers have never even heard of this before.  I suspect that it's because its a fusion of diverse topics which with most web developers aren't familiar.  For example, many ASP.NET developers I work with know software architectural principles, but can't even spell CSS.  Other times, I'll see awesome web designers who have no idea what software architecture is.

In this third part of the series, I discuss how to manually create an XML service and a SOAP service using XML serialization to maximize the flexibility in your service interop work. The technique allows you to very quickly accept just about any XML format from the wire and work with it in a strongly typed manner in your .NET applications.

• XmlHttp Service Interop - Part 3 (XML Serialization)
• XmlHttp Service Interop - Part 2 (Utilizing WCF)
• XmlHttp Service Interop - Part 1 (Simple Service Creation)
• XmlHttp Service Interop Article Series Home