I recently came across a Nov. 25/09 post on Davy Brion’s blog, The Inquisitive Coder, that enumerates his recommended reading list for software developers who are wanting to step up their game.  This is a common theme on coding blogs, and there have been literally a galaxy of postings with some great and not so great recommendations guaranteed to perplex and flummox the average coder.

The implied line with all of these articles is that you ignore these tomes at your peril – you just won’t get to the “A” levels without them.

I like how Brion has broken his recommendations into three strata according to developer experience:  newbie, sophomore and grizzled veteran.  Well, sort of.  I mean, learning agile/iterative/lean software development really should occur at the start of your career as you’re going to have to unlearn the BDUF/waterfall crap that was loaded into your head by your CS/SoftEng profs who last “delivered” software (if at all) when 8–bit CPUs were da bomb.

What I don’t like is the complexity of some of the volumes that Brion shows – some of them are just so dense as to be inaccessible and not immediately applicable, eg. Eric Evans’ Domain-Driven Design.

Read/Master These Books First

If you want to get immediate benefits, try this shorter reading list:

1. The Pragmatic Programmer:  From Journeyman to Master (Hunt & Thomas)
2. Pragmatic Unit Testing in Java/C# (Hunt & Thomas)
3. Refactoring:  Improving the Design of Existing Code (Fowler)
4. Practices of an Agile Developer (Subramaniam & Hunt)
5. Agile Software Development with Scrum (Schwaber & Beedle)

These books will help you begin to develop good habits – and in some places, possibly fired for wanting to implement.  That’s ok, because you don’t want to waste your life there, anyway.   It should take you 6–12 months to get through these and really internalize the practices and make them second nature.  I’ve recommended #5 because, as I mention above, you should get exposure to agile practices like Scrum sooner rather than later.

Read/Master These Books Next

You’ve got a couple of years under your belt and have seen the good, the bad and the ugly in the industry.  You’ve likely been on some bad projects and you’re beginning to question the wisdom of your chosen career path.  Take solace in these books to notch your game up further:

1. Design Patterns (Gang of Four – Gamma, Helm, Johnson, Vlissides) – Alternatively, any book that explains patterns in your language of choice will help you “grok” them.
2. Clean Code: A Handbook of Agile Software Craftsmanship (Robert “Uncle Bob” C. Martin)
3. Agile Estimating and Planning (Cohn)

By the time you get through these (another 6–12 months) you will be truly cynical about the state of the industry, as well you should.  But you’re not wanting to be a “mort” or a “501” kinda coder – you’re wanting more.  So, you should supplement the above list with these titles:

1. Death March 2^nd Edition (Yourdon)
2. The Mythical Man-Month (Brooks Jr.)
3. Agile Project Management with Scrum (Schwaber)

These titles will give you the intellectual “legs” to position your strategies and arguments (yes, arguments) for implementing best practices with peers and managers.

Ongoing Professional Development

After you’ve reached your fifth or sixth year in the industry, you should have a pretty good idea about who you are professionally and where you think you’re headed:  Leadership, Consulting, Management.  Depending on your path, different books will influence your thinking.  You will likely be wanting to show what you’re capable of – perhaps in a new role or firm.  Some of these titles will help:

1. Fearless Change:  Patterns for Introducing New Ideas (Manns & Rising)
2. Agile & Iterative Development:  A Manager’s Guide (Larman)
3. Implementing Lean Software Development:  From Concept to Cash (Poppendieck)

Conclusion:  Just Do It

In my experience, not very many folks who have a lot of “paper” experience have actually ready many of these books.  They’ve heard of them, but never read them or applied their lessons.  I’ve come across consultants who are really smart and with scads of experience who have yet to write a single unit test – or worse, think that a tool can do it all for them.  Common sense ain’t so common.

If you master 60% of the above list, you will be a better coder and professional than 3/4 of the people you’ll come across over your career.  It will take time, some personal commitment and in some cases risk – but it will be immediately worth it.  Follow the advice of Ken Schwaber (co-creator of Scrum) who urged attendees at a conference to actively begin improving their software delivery experience by implementing agile techniques by getting out there and doing it:  “Don’t procrastinate; do something – no matter how small.” 

A quick reminder:  Say you have a SharePoint Survey List in a site that you want to populate using a console application.  Further, say that said Survey List has an Event Receiver attached to it that needs to pick up settings from the web.config file for the host web app – let’s say a connection string.

You run your console application and notice that nothing is happening – well, something is happening, just not what you intended.  A quick look in the Event Log reveals a bizarre error indicating that an object reference isn’t instantiated and it appears to be originating several lines of code before you make a call to the ConfigurationManager thus:

_connectionString = ConfigurationManager.ConnectionStrings[SQL_CONNECTION_STRING_NAME].ConnectionString;

The line that that is generating the error has nothing whatsoever to do with this line.  It is a puzzling sort of puzzle.

You decide to check first principles and see if you can trigger the event receiver by hitting the list in the browser.  Yup:  Works fine.  So what gives?

Then you remember:  Your console app isn’t running in the same context as the browser app.  Of course it can’t find the <connectionStrings> element – it doesn’t exist as far as it’s concerned.  The called code in the Event Receiver is running blind!

<foreheadSlap> Simply add a {nameOfConsoleApp}.exe.config file local to the console .exe file and stash the configuration settings from the web.config that the called code needs to find. </foreheadSlap>

I knew this, you know.  I was just not thinking clearly while debugging.

Earlier today, I was working on a custom survey list event receiver that ports results into a SQL database table when I noticed some peculiar behaviour:  Every time I added an entry to the survey, two duplicate rows were added to the SQL table.

Poking around the web, I see that this is indeed a common issue – David Birin captured the problem (and a solution) quite succintly on his blog in his January 2009 entry.  As he notes, the root of the problem is that if you have your event receiver deployed as a Feature (I did) and then create a template of a targeted list (you bet I did that) then the event receiver registrations are “baked in” to the template definition.

Now, when you create a list based on this template in a site that has the same event receiver Features enabled, you now are running each event handler twice.  As you repeat this process, you register more event receivers and things get out of hand geometrically.

NOT GOOD.

A Hack for a Solution

David’s solution is to add in some custom code that loops through the event receivers and deletes them individually.  While this is robust for future-proofing, I wanted an easier way so that I could get back to coding.  Here’s what I did:

1. First, I went to the List Template Gallery for my Site Collection and saved the offending list template to my C:\ drive and renamed the extension from “.stp” to “.cab”
2. Next, I opened up the .cab file and extracted the manifest.xml file within and tossed it into Visual Studio where I cleaned it up with an Edit -> Advanced -> Format Document
3. I located the <Receivers> element and removed each <Receiver> child element.
4. I changed the <TemplateTitle> to reflect the new version, eg. “My Survey V4”
5. I made similar changes to the <Form> and <WebPart> element URL attributes, eg. “Lists/My Survey V4/DispForm.aspx”
6. Next, I saved this file and then used MAKECAB.EXE to package it up (comes with the Windows SDK) and renamed the extension from “.cab” to “.stp”
7. I opened up a browser on my test server, navigated to the List Template Gallery and uploaded my revised template and created a list from it.
8. Presto!  The ItemAdded event was only firing once as it should.

Hope this helps anyone encountering the same issue – it’s a quick-fix which helps avoid the ground-zero for the issue which is building a template of a list while the event receiver feature that targets that list is enabled.

Just came across this rather interesting post by “morgan” on the blog PHP vs. .NET in the oft-used “Top x Tools to do Y” format (always popular in the dev community).  Despite being common, I think Morgan’s list is a good compilation of resources that should be in your kit if you’re developing ASP.NET solutions, including SharePoint:

1. Code Profiling – RedGate ANTS – Personally, I use AQTime because it works well with both ASP.NET and SharePoint 2003/2007 instances.
2. App Stress Tool – NeoLoad – Never used it myself, as I’ve preferred to use Visual Studio Team System’s web test projects for this purpose.
3. Performance Monitoring – perfmon – But of course!  You can also hook up VSTS to track performance counters and record results – this feature has been available in Visual Studio since 2005, and offers a better way of visualizing this critical operational data.  Mind you, if you are on a server and just need to see what’s what, perfmon is still the standard.  Looks even better on 2008!
4. HTTP Recorder – Fiddler 2 – No arguments here.
5. Interface Manipulation – FireBug – Definitely one of the best browser add-ons;  I use it interchangeably with the IE Developer Toolbar.
6. Debugger -Windbg – This is a given;  if you’ve never used it, give it a whirl:  It’s a great tool.
7. FX-Cop – For policing the standards to keep the code clean;  it’s worthwhile, even if you’re a one-man show.
8. ViewState Decoder – A good idea for ASP.NET and SharePoint apps – Sometimes ya gotta see what’s going on in that mess of stateful info on your page.
9. Text Editor – UltraEdit/Notepad2 – I prefer the latter – to each their own.  I definitely like being able to bring up a lightweight editor with syntax highlighting, regex patterns, hotkeys and shortcuts, etc.

Morgan also offers up the venerable .NET Reflector by Lutz Roeder – a staple if you’re developing against the SharePoint API since the documentation can be at odds with reality.  It’s great to be able to crack open Microsoft.Sharepoint, find your object and see how it works in disassembled C# or VB.NET or any other .NET language.

Colorful cartoon caricatures of common coding calamities.  See all 10 here.