I have come across varied attempts to quantify the learning process of developers as they march from green-behind-the-ear rookie to master code wizard. The world is awash with metaphors, cliches and gross innacuracies when it comes to describing the process of change as the individual gains experience in his craft. I spent much time in college trying to keep a straight face as I observed quality processes such as ISO and CMM being applied to software - I had a lecturer who had a much more scientific method than this when grading papers - he would throw them down the stairs and the heaviest scored highest.

I have just started reading "Pragmatic Thinking & Learning - Refactor Your Wetware" by Andy Hunt, and was very impressed by the Dreyfus Model of Skills Acquisition he describes. The study is the work of the Dreyfus brothers almost thirty years ago as they sought to understand the nature of human learning for the purposes of A.I. Since then, it has become very popular in the field of nursing and medicine in general.

It doesn't matter what your field is, it was originally used with airline pilots, chess masters, chefs and so on. In the 1980's, it was adopted successfully by the nursing field which was undergoing a crisis with comparisons to the field of software development today. The main point is that there are five stages one goes through in becoming an expert in anything.

Contrary to popular belief, as you become expert, you don't just "know more" than the next guy. Rather, you undergo changes in your perception as you advance. You see things differently in general and approach problem solving much more differently as you move through stages one through five. Not only that, but the external factors that either hinder or assist you both change also.

This has ramifications not only in the social workplace fabric, but also on how managers can get the most from their staff. Staff interaction is much easier when each person knows where they fit on the scale because this makes it easier to communicate with colleagues in a meaningful and effective way. Quite often it is better to assign the task of training new hires to the advanced beginner because they are more likely to understand the other person's mindset. Another myth that this study puts to rest is that it is good to throw the novice in at the deep end. This is the truest litmus test of a manager's ignorance that there is.

1) Novice   
   * Little or no experience
   * Need set rules to follow
   * Need short term goals
   * Need assistance debugging

When considering the novice, think call centers; just follow the rules to get started. Still wearing the blue shirt and khaki dockers.

2) Advanced Beginner   
   * Starting to try things on their own
   * They want information fast
   * Starting to see the jig-saw pieces
   * Still need help debugging

Advanced beginners are basically your eager beavers. They don't want lengthy theory, they only want to play. Just don't leave them alone.

3) Competent   
   * Starting to form good mental models
   * They are able to solve problems on their own
   * They will ask for expert advice when needed
   * Still having problems focusing where it's needed
   * Can mentor the novices and keep out of the way of the experts

Competents still lack a little maturity and reflection as developers, but are now in a position to mentor novices and are smart enough not to get into too much trouble. At this stage, you'll probably get an annoyed look when asking them to fetch the coffee! Very valuable team members to have.

4) Proficient   
   * More analytical and asking more intelligent questions
   * Better at analyzing their past performance
   * More able to learn from mistakes and take advice
   * Much better focus plus they know where to look
   * Tendency to over-apply software patterns

Moving from Competent to Proficient is a major jump compared to the other stage transitions. Someone at this level can understand things in context and this is what sets them apart.

5) Expert   
   * The people we look to to move us forward
   * They write the books we have to read
   * They work purely from intuition, not reason
   * They make it look easy
   * Total inability to explain why they do things

If you want to derail an expert, just tell him to follow the rules! Most experts are named Scott.

In summary, the Dreyfus model does not follow the typical bell curve model when it comes to distribution of skills in the field of software. Evidence shows that the vast majority of software developers today never get past the Advanced Beginner stage. This ties in with the drop out rate I witnessed in the first year of Computer Science in college. By the end of four years, only one in three of the original intake remained.

The accepted wisdom is that it takes ten years of practise to become expert in anything. So, keep the head down and march on... :-)

I'm no security expert, and as such, I think I'm a member of an ever-growing group of Web developers who fly by the seat of their pants when it comes to the security of their Web forms. As an ASP.NET developer I have had a tendency to presume that the framework is going to insulate me from most of the "nuts and bolts stuff". Of course this is not the kind of beneficial abstraction that frameworks were meant to provide us with. It is up to each of us to take responsibility for the code we create. Testing, even when it is carried out, shouldn't stop as soon as we find out that our code "is working". There needs to be some baseline better practise for creating everyday Web forms other than relying on ValidateRequest being set to true.

Recently I published a post entitled 500,000 SQL Injection Attacks. The half a million attacks actually occurred in a single week. This is mind boggling. A lot of the attacks targeted older ASP sites and I was surprised at how much of this old code was still out there. What surprised me most was how many idiots were out there calling themselves developers, not to mention the bottom-line execs who hired them in the first place. That 500,000 sites were attacked in a single week should be telling us something. We need more qualified programmers in the industry and we need the education system to introduce students to the World of IT that they are going to be living in.

Most security holes are created by developers with little understanding of security issues. These security holes are then exploited by hackers who understand these security issues only too well. It's a lethal recipe. Developers need to understand what it is they have to protect against and how to go about doing it. The tools and guidance for creating safer Web forms are available to us right now if we know where to look.

From a security point of view, our Web forms are naked and 100% vulnerable. We need to look at all the ways data is passed to them and test as appropriate:

    * Form Fields
    * URL Query Strings
    * Cookies
    * Database
    * ViewState

The most prevalent forms of attack seem to be Script Injection, Cross Site Scripting and SQL Injection. As for SQL Injection, this can be mitigated against by using parameterized queries. It is the act of parameterizing the database queries that make stored procedures so resilient to attack. The other forms of script attack can be handled by downloading and using the Microsoft Anti-Cross Site Scripting Library in your Web application projects.

A best practise would consist of the use of this library in conjunction with proper data validation (validators) and filtering (regular expressions). If you have existing code which you know is vulnerable you can still use tools to inspect your code and then you can implement the necessary protection measures where needed.

On the MSDN Code Gallery, there is a complete ASP.NET 2.0 Reference Security Implementation which you can download and explore. It was created in VS 2005 and includes an installer. This is a very helpful resource to answer any questions you may have. Note: you must have VS 2005 installed for this to work.

I've saved the best news for last :-) The Microsoft CIGS (Connected Information Security Group) are working on the new Security Runtime Engine. It is a HTTP module which will provide protection against the most common Web application security vulnerabilities, including Cross Site Scripting. The CIGS group are currently testing it and the beta should be available shortly.

If anything can drive this Irishman into a fit of cursing, it's the need to create a regular expression quickly. With a little application, I know I could learn to create them myself but I figured some time back that the frequency with which I use them would not equate to the time invested in the study. So, I either have to rely on ones that I have, and can never locate, or turn to a good tool.

Well, I was reading Professional ASP.NET 3.5 in C# and VB by Scott Hansleman and others recently when I saw mention of a Regular Expression Editor in VS 2008. This was news to me! Then I noticed a regular expression facility in the Find and Replace tool (CTRL-F); how long has that one been around? Anyway, it was just what I needed for some basic regex's for email and phone numbers.

The only problem is trying to find the thing... they couldn't have hid it better if they tried. First, you have to be in design view to begin to locate it. Do people actually use design view? Then you have to refer to the control's properties window and click on the button next to the ValidationExpression property to launch the editor. Obvious, huh? :-|

Granted, it's pretty basic but if you're in a hurry this will save you some Googling time! I wonder is it possible to extend this tool to add in one's own custom regex's for reuse?

One more thing: Scott's book is a great reference with over 1600 pages of info. I have only two gripes about it: 1) If you read it in bed you'll need a hoist to avoid the hernia, and 2) The entire book is based on the Web Site template. What were they thinking of?