ALT.NET Conference, take two. When I signed for this conference for the second time I didn't honestly think it was going to be as good as the first one. Boy was I wrong. I got the feeling that the attendees came incredibly prepared. Prepared to stand up and voice their opinions instead of simply watching. Prepared to listen diverging point of views. Prepared to take part in spontaneous conversations, in the conference rooms, in the corridors, in the shared rides, in the hotel lobby, in the restaurants, in the frigging airport waiting to board the plane. And, most of all, prepared to be surprised. I was surprised at so many different levels. Who would have thought that a discussion around JavaScript would spark so much interest? I was certain that the participants that came straight out of the MVP Summit would be all geeked out, but no. I was surprised to see a few MVPs that chose to fly in only for the ALT.NET event and not the summit. I was also surprised to see that some of the greatest talks happened not during the conference hours, but late in the night after a few drinks. Maybe if I start drinking I will become one of the smart guys? From the sessions that I stopped by, several discussions and questions came back with me for further processing.

• Microsoft v 1.0 vs Stable OSS
  • Is that decision based only on risk assessment?
  • MS is clearly happy with OSS built with .Net. Brad Abrams and ScottGu were there to assure that.
  • Are we lacking a corporation (not-MS) to back OSS, like Canonical, Red Hat, mySQL AB, etc?
  • Too many questions, no clear conclusion
  
  
  
• Functional Programming: Great talk. As you may or may not know, I am interested in this type of stuff. Just to reiterate, I think FP has its place and we are just seeing the beginning of it in the .Net universe.
  
  
• ASP.NET MVC update: Among all the surprises in the conference, this was the most intriguing one. I went in as a MVC believer and got out happier with webforms. Weird. Some of the upcoming changes in webforms will address important annoyances, like the id munging and routing for urls.
  
  
• Innovation: I arrived late at this discussion and was kind of shocked to hear Scott Hanselman question (or even suggest) that we already have enough implementation of OSS alternatives for many things and maybe there's nothing left to be innovated there, maybe we should just move on instead of creating another mock framework or another blog engine. I think this is kind of absurd. A great part of the innovation is powered by lower level innovations. My example: we didn't seem to need Moq, but now that we have lambdas in .Net, Moq could innovate in that area. As long as the CLR and the language teams keep feeding us new tools, we will keep using the tools in new and creative ways. Anyway, the central point of the discussion was supposed to be if there's innovation in .Net or if we are only porting existing projects from other languages.
  
  
• JavaScript tools and patterns
  • JSUnit - this is slow. too slow.
  • Do we need a JS-specific test runner?
  • We felt that we lack some guidance and some patterns
  • Watch for a new community around these premises
  
  
  

...at least for the next three days

Tomorrow I'm hopping on a plane to Seattle/Redmond, WA to take part in the second ALT.NET Open Spaces Conference. I had the chance to be at the first one last October in Austin, TX and what a great experience that was.

My main motivation to attend the event in Austin was to learn from the more experienced folks how they adopted these practices and culture in their organizations. I wanted to participate in discussion about creating interest in self-improvement in my organization, my local .Net community, and eventually in the global .Net ecosystem.

The sessions I took part in included mostly these topics, like how can we help MSDN and MSDN Magazine become a great vehicle for spreading into the .Net community, among other things, practices that go beyond what Visual Studio shows in its Add » New Item, and the lessons that we can learn from the non-.Net space. The March 2008 issue of the magazine was a glimpse at what types of techniques and tools we could be seeing applied by more .Net developers, helping create more maintainable applications and more scalable development and support processes.

This time around I'm hoping to be in discussions that are more specific of Agile processes. I want to understand how to get started and how demonstrable Agile value really is. I'm tired of reading from people that quickly attached themselves to the Agile label just because it looks like the thing to do at the moment. I, for one have never experienced Agile in any organization I worked at. This event will give us a great opportunity to hear and question some of the people that are really employing Agile and experiencing some form of benefit from it. I want to make sure Agile isn't just another bandwagon.

There's always the risk that events like this become the proverbial echo chamber, where folks that think alike tap each other's back, celebrate their common thinking, and waste time discussion irrelevant technicalities. I'm happy to see a lot of blue badges and even people that I'm sure will be there to challenge ALT.NET to put up or shut up. One such individual is JDN — if you read the altdotnet mailing list you're familiar with his point of view. I think that is a good thing.

So, if you happen to be there too and see me, come and talk. That's why we are there for, right. And I'm not one of these guys that can only talk about software. I could spend hours chatting about other things like soccer and .... and ... darn it! Nevermind :)

It's nice when you're trying to say something and find out that it has already been said by someone way more qualified than you.

In the end it's good to know it happens because we like this software development thing. It's all in good spirit.

Seriously, how can someone not be thrilled to work as a software developer? Think about this, how many jobs out there give you the ultimate blank canvas where you constantly discover a new and better way to get things done? It's hard for me to consider this just another 9 to 5 job.

On the other hand, I can see how someone lands in an environment when such freedom or room for exploration is not granted, and settles for stability and a decent paycheck in exchange for suppressed dreams and aspirations. People have their families and different priorities than I and I fully sympathize with that compromise. That doesn't stop me from trying to bring them back, though.

It should be no news to you that people work better when they like what they are doing and who they work with. I haven't seen any effective way to make people start to like working with each other, but getting someone to restore the lost interest in the job they once loved: that sounds doable. The key here is that many of our seemingly uninterested fellow programmers one day chose this career and went into it with high hopes. At some point down the line, something caused them to slip into this low energy state where the clock ticks slower and learning something doesn't seem worthwhile.

I think nothing explains the above behavioral pattern better than reading and observing Wally. I bet you have a Wally working with you right now or at least had one in the past, in that previous job that you are glad you left behind. As the Wikipedia article shows, even a nerve-racking co-worker like Wally can have very active and promising past (as twisted as that sounds.)

I'll have to take a break and acknowledge that some people just don't have any interest in changing their attitude and I'll be respectful of that. I won't be that annoying car salesman that keeps coming back to offer the car you don't need.

But back to the question, how can someone like Wally regain his original momentum? I think there isn't one big solution to that. Instead there are lots of small things that accumulate over time and can effect change. Most of these things relate more to ourselves than to the intended peer. It all revolves around attitude.

Positive attitudes are often contagious, the problem is that the incubation period can be long. You have to hang in there. Throughout the entire process you cannot refrain from displaying your enthusiasm with the tasks you complete or with new things you learn. Keep sharing interesting and reusable information. Show that you are always available to help by the simple fact that it is a pleasure for you to engage on a challenging debugging session or after-hours discussions on emerging technologies.

Some people would say it's not a programmer's job to deal with motivational issues of other developers. I think this is a very short sighted view of your role in the team. If one team member is no longer bringing his A-game, the other members will have to pick up the slack, which is not exactly fair.

Wally is a bright guy, it's to our own advantage to rescue him from zombie-land.

One of the things I often discuss with other developers is how little (on average) we automate our work-related tasks.

Think about this. We make our living automating our users' activities:

• We write applications to replace manual processes.
• Our programs send notifications so that they users don't need to waste time checking for process status.
• We make our programs talk to each other and to third party systems so that the slow and expensive human interaction is avoided,
• In more general terms, we go through great lengths to ensure our users are adequately empowered and hopefully more productive.

Contrast that to the way we historically see developers conducting their daily chores.

• We often work with incredibly powerful IDEs or text editors with macro support or even an extensibility model. When was the last time you employed a macro?
• How many times will that manager will have to send you that updated Excel spreadsheet or CSV file until you write a script to verify each line instead of the tiresome and error-prone manual check you have been doing?
• Aren't you tired of keeping track of which files changed since last time you updated the application? Have you ever thought your Source Control Management tool could make this much simpler?
• Are you kidding me? You're writing that same SQL query for the Nth time? How hard is to save this query for a change?
• If your work cycle looks like this: Save, Build (wait), Debug (wait), Click, Click, Click, Type, Type, Click, Verify result, OK;  someone needs to introduce you to a unit testing tool immediately.

I'm as guilty as the next guy of falling in one of the the above anti-patterns. The way I found to make these traps the exception, not the norm, was to make them less comfortable than the automated alternative. The key in the entire process is lowering the automation entry barrier by learning. It also helps if you cultivate a positive attitude toward learning.

Here's my laundry list of steps to make those CPU cores earn their salt and leave my own processing power for more challenging things. I have some of these items pegged but I'm not done with all of them yet.

• Take the time to explore and learn the capabilities of your IDE/text editor. Find a cheat sheet and print it. Learn one or two interesting keyboard shortcuts every day. Learn how to write/record a macro, it's usually so easy that you'll be ashamed you hadn't done that before. Some tools even have strong user communities sharing macros. See how your IDE can be extended, if it's beyond your reach, maybe there are third party productivity add-ons that will boost your productivity and pay for themselves quickly (if not already free.)
• Other applications, like MS Office apps, also have a rich extensibility and automation model behind them. If that application insists in being part of your workflow, investigate how you can show it who the boss is.
• One of the best things I've done in the recent years was to add a scripting language to my toolbox. I highly recommend that. If possible pick a scripting language that is reasonably different from your primary development language, it will make the learning phase more interesting. I'm currently working with C#, so I thought Ruby would be an interesting language for scripting tasks, and that's what I use most of the time.
• Be adamant about using your SCM as part of your deployment process. Learn how to do labeling/tagging, diffs, updates, etc not only using the GUI but also through an API or the command line. You'll be writing scripts against your SCM in no time and the weight of tracking changed files will be lifted.
• I tend to include a tools directory within each project directory structure where I keep (among other things) all the scripts I create to assist development and maintenance of the application. These files can be SQL scripts, Ruby scripts, .bat files, and anything that can be repeatedly executed. Some scripts turn out to be generic enough that I keep them in a common location, such as c:\projetcs\tools.
• I won't attempt to get yo hooked on TDD or Continuous Integration here, that's something for another day. I will say, though, that if you don't already use an automated unit testing framework, you owe yourself a closer look into that. Why write several test applications or run the entire application all the time to manually verify that everything still works when there are tools to automate this? Take a look at JUnit/NUnit (the xUnit family), RSpec or whatever there is in your language of choice.
• No text about software development automation would be complete without at least mentioning build automation tools. Tools like Ant (NAnt), MSBuild, Make, Rake go a long way toward providing complete solutions for automating the build, testing, packaging/deploying of an application. Very few things are more satisfying than executing go.bat and seeing your application being compiled, configured, and tested in a fraction of the time that it used to take when you did all this manually.

As many things in life, the hardest part is getting started. Once you have your first one or two tasks automated, you will be more aware of tasks that can be automated and you will be more confident that you can indeed automate this task that you were just about to start for the second time.