I read Ship It over the weekend. 

I finished two books over the weekend.   The first was ASP.NET MVC

written by Scott Gu and the gang.  The Nerd Dinner tutorial was helpful – at least the first 100 pages or so.  The mapping at the end was not really MVC specific (and does not work with MVC 2.0).  The best part for me was the chapters on Routing and Controllers – I have a much better understanding of MVC after going through those chapters.  Also, the security chapter was awesome – worth the price of the book for that chapter alone.

I also “finished” Agile Estimate and Planning. 

The takeaway that I got from it was a sentence in the first chapter – the plan is less important than the planning.  The rest of the book, complete with IRR and NOPV calculations, was a bit heavy for my taste.  I think there is a reason I prefer to read code than PM books…..

Speaking of which, did you know that there is not an out of the box way to change your password using the beginning ASP.NET project found in Visual Studio.  Do File -> New ASP MVC 2 application.  Note that there are is a view to change your password (ChangePassword.aspx). 

Press F5 to spin the site up and now try to change the password – nothing on the menu, nothing on the login/new user, nothing anywhere.  It is a small annoyance, I put this line of code in my LogonUserControl.ascx:

At least they made the Views for us…

I read The Passionate Programmer over the weekend:

I had three thoughts:

Much of the book is for people who never got a mba (not for the course content, but for the ethos of the environment) who don’t understand how to package their own labor.  In one sense, the IT industry was an easy place to identify as a topic because of the nature of the people and work in the 1970s and 1980s. My colleague Rob Seder had the same ideas in his coding best practices course – you name is your brand so you better control it, etc…

In our company, there are two types of developers – “real” developers and “business developers”.  The real developers use java, the business developers use .NET.  The real developers work on enterprise systems, the business developers work on toy systems.   The ironic thing is that the business developers are where the real developers are moving to – they are already engaging in a quasi-Agile methodology (some still cowboy) and business developers know about the domain.  Reading the Passionate Programmer, the #1 way you can offshore-proof you job is to becomes an expert in the industry of the company your IT supports.   It was also ironic that Fowler points out that both java and .NET are so prevalent in India that knowing that language is irrelevant in terms of commanding a premium salary.

The other pieces of his advice are much like an economist view – your name is your brand, you cost the company X amount and therefore need to generate X+1 is money for the company.  There is subtlety that he misses that most people don’t understand in IT.  Savings money is EASY using computers – we automate repetitive tasks so that the low level workers that are doing the project can be laid off, we shift work from higher costing workers to lower costing places using systems, etc…  When I talk to a business owner, I don’t talk about how much money I am going to save them (all of the low fruit has already been picked anyway) but how much money I am going to make them.  If I don’t talk dollars, I talk customers.  If I don’t talk customers, I talk items sold.   In 2010, businesses are looking for revenue and (even better) increased margins. 

On a separate note, my 10 year old daughter wrote her 1^st C# application last night.  She thought it was great.  I picked out this book for her to work through:

I enjoyed watching her eyes light up when the Console.ReadLine() worked.  I still remember when I had that feeling (7^th grade, using an Apple 2C, in summer computer camp)…

I finished reading Practices of An Agile Developer last night. 

I thought it was a worthwhile investment though much of their recommendations can fall into the common-sense category.  Some of my favorite pieces of advice were:

Architects Must Write Code – I agree with a caveat.  I think it should be “Architects Must Write Production Code”.  My current company suffers from a failure of its staffing model – most of the best developers are tracked to architect and then write less and less production code  – soon their value to a given team diminishes and the POC codes samples they do churn out become less and less relevant.  For me, the architect is the part of the ship’s crew – not a drop-in guest star.

Yes:

No:

Be A Mentor – Some people I run across still view knowledge as a personal resource/asset that cannot be shared.  Perhaps I am too sanguine, but I believe that the way one gets better in anything is to find as many smart people to be around as possible and share as much as possible.  I guess it is related to the advice I give kids on the teams I coach – always find the best player on the other team and want to play them.  You get better by hanging with the best, not by crushing the worst.

Allow People to Figure It Out – This burned me last year – I was on a team with some underperforming people and by waiting for them to figure things out, the entire project suffered.  At a certain point, an individual needs to take responsibility for their contribution to the team – finding that line takes some experience.