As a disclaimer, this is a 55k employee, $11 bil. company.

He said he wanted to organize “communities of practice” (in other words: “networks of experts”) so that people interested and expert in various IT subjects could collaborate.  So, for example, there would be a .NET community of practice – a venue, for example, for questions, answers, ideas and experiences to be shared across a globally and organizationally distributed set of company .NET developers.

This was taking some time – his directs are wanting plans, structure, resources and causing delays.

I’m definitely not at the level my boss (3rd removed) is at, nor do I have anything approaching his experience in business or IT, but this struck me as super strange.

We spend millions of dollars on servers, client software and email servers to facilitate these discussions.  I told him he could do it in 5 minutes.  Send an email to the helpdesk requesting that an email distribution list be created, all the developers subscribed to the list.  Then send a note to the list asking everyone to send an introductory email.  If the list gets busy and starts asking questions and sending interesting things, problem solved, task accomplished.  If they don’t, then you don’t need the community of practice to begin with.  If the list needs to share code snippets or something then they’ll find a service or make one.

I’m sure there’s more to this than what I understand, but I can’t help but wonder if sometimes we think an entire culture needs to change when all it really needs is an email to the helpdesk.

1.  The strategy pattern and others

Chapter 1 of Head First Design Patterns changed my life, and I’m not afraid to admit it.  I devoured the rest of the book.  And then, newly motivated, I read a bunch of other books.  This led to the understanding of other patterns and formalized principles behind OOP, and I gained a base upon which to build more skill.

2. Inversion of control

Tools that transform patterns and principles out of the realm of “elegance” and into the reality of “efficiency” have changed the way I work.

3. Test first

I attended TechEd 2005 and the VS 2005 team was showing off all the new features.  The one that grabbed my attention was the “object workbench” – where you could instantiate objects and play with them in isolation.  “This is great,” I thought, “because now I’ll be able to see exactly what my code is doing.”  I never did play with the object workbench (was it just vapor?), but when I understood later that this vision had been realized already in the form of unit testing I was immediately hooked.

I didn’t get it at first.  Like everything else, I had to cut my teeth on it.  I picked some side project and did it with TDD.  I could see my design being different than I would have done it before.  When I went to make a change I was able to do so with confidence.

I test drive almost everything now.  And trust me – I still make many stupid mistakes.  But I understand that’s part of the process and it’s trivial to fix most of them.

4. Refactoring

Specifically the book.  This is something they don’t (or didn’t) teach at University.  I can actually use a rigorous process to correct myself!

5. The transition from ADO.NET to ORM

I started with ADO.NET (that’s all I knew about) and had my little helper classes and everything, just like everyone else did.  I built some nice active recordy type frameworks for applications I wrote.

I read with great enthusiasm Mitchell’s data access tutorials for/from Microsoft and built entire applications with those practices.  I remember cringing every time I had to add a row to a grid or change a screen – the logic was almost entirely in the markup.

I discovered Subsonic, and found it very cool but mostly unusable for several reasons I won’t list.

Then I finally got around to reading Billy McAfferty’s NHibernate article and stepped through the demos.  What took me so long? I built a sample app to cut my teeth and have never looked back.  Nothing in my career, in my daily tasks, has saved my company more money than my tiny start at understanding NHibernate.  “Finally,” I thought, “I can program with objects.”  I later tried several other ORMs and shelved them for reasons usually related to friction.

I find it very odd that a lot of guidance from Microsoft (MSDN, the MOC I was teaching as an MCT) centers around object orientation but their data access strategies do not properly support it.  Line of business software is (or has been, for me this is starting to change) all about data – reports, CRUD, legacy data, etc. is involved in almost every feature I deliver to the business.  And if the data access is not OO, nothing is OO.

6. Domain driven design

I have to admit I haven’t trudged my way through the entire book.. I have it and I’ve probably read most of the words in it but I find it a terrible beating to read straight through.  My understanding is therefore limited.  But concepts I have picked up while working on open source and through the community have helped.  I also read DDD Quickly, a summary pdf ebook.  I get the yahoo group messages in my email inbox.

DDD has allowed me to further my application of object oriented programming even more. DDD took what I had learned from NHibernate examples and blew it up to a fuller and richer object orientation.

7. Contributing to open source…

… is one of the most exhilarating things in the world for me.  This is not an exaggeration.. there is nothing like it.  I will never forget my first sweaty-palmed commit, watching cctray like a hawk.

8. Community

I spent a long time just looking for communities without realizing that’s what I was doing.  Joining them has elevated my level of discourse (technically), exposed me to new ideas, and introduced me to people I can social network with.  Communities oriented around software user groups, ecosystems and practices are extremely helpful.  Mentors are the best – if you don’t have one, get one.  A lot of the time, online, you don’t even need their permission.  =)

I have had 5 minute phone conversations with people that have enabled me to jump ahead farther than any one book or principle.

I have always been pretty good at using social networking tools, but now I have a frame of reference that allows me to collect more and better information.

Passion breeds quality.  Passionate people are involved in communities.  Involving myself in communities and surrounding myself with other passionate people has upped my quality.

9. Vertical slices

My professional experience with Agile is limited.  It is not “what we do” on my current team.  Because I usually work on projects by myself and have a large degree of control over the software I produce, I am able to practice pieces of it on a micro level.  The main tenet that I have found to be helpful is to deliver working software early.  Working software is all we have to give, the rest are “gets”.  As I work in vertical slices rather than in horizontal tiers, and refactor as I go, my designs are much more robust and flexible.  Frictionlessness is also key.  XP concepts like contiuous integration have really made things much easier than the “Program and pray” method.  Time to login screen is a great metric.

10. The old “The more you know the more you know you don’t know” thing

I realize that a lot of these things are so common now and passe (at least it feels that way compared to the level of the people in the communities I listen to).  I strive to be the “dumbest guy in the room.”

11. Technical books read different

I have learned that reading technical books is different than reading textbooks and not at all like reading fiction or prose.  I always thought I was a quick reader, but I am not afraid to read a page several times to understand it completely.

12. I do something new in every project

Because of the level of control I have over my projects I require myself to try something new with each one.  This has not caused me more friction – I consider it self guided training.  I spike random stuff more often.