People have sometimes asked me if it's really worth it to go to a conference these days, given that so much material is appearing online via blogs, webcasts, online publications and Google. I think the answer is an unqualified "yes" (what else would you expect from a guy who spends a significant part of his life speaking at conferences?), but not necessarily for the reasons you might think.

A long time ago, Billy Hollis said something very profound to me: "Newbies go to conferences for the technical sessions. Seasoned veterans go to conferences for the people." At the time, I thought this was Billy's way of saying that the sessions really weren't "all that" at most conferences (JavaOne and TechEd come to mind, for example--whatever scheduling gods that think project managers on a particular project make good technical speakers on that subject really needs to be taken out back and shot), and that you're far better off spending the time networking to improve your social network. Now I think it's for a different reason. By way of explanation, allow me to recount a brief travel anecdote.

I spend a lot of time on airplanes, as you might expect. Periodically, while staring out the window (trying to rearrange words in my head in order to make them sound coherent for the current email, blog entry, book chapter or article), I will see another commercial aircraft traveling in the same air traffic control lane going the other way. Every time I see it, I'm simply floored at how fast they appear to be going--they usually don't stay within my visibility for more than a few seconds. "Whoosh" is the first thought that goes through my easily-amused consciousness, and then, "Damn, they're really moving." Then I realize, "Wow--somebody on that plane over there is probably looking at this plane I'm on, and thinking the exact same thing."

This is why you go to conferences.

In the agile communities, they talk about velocity, the amount of work a team can get done in a particular iteration. But I think teams need to have a sense of their velocity relative to the rest of the industry, too. It helps put things into perspective. All too often, I find teams that look at me in meetings and conference calls and say, "Surely the rest of the industry isn't this bad, right?" or "Surely, somebody else has found a solution to this problem by now, right?" or "Please, dear God, tell me this kind of WTF-style of project management is unique to my company". While I am certainly happy to answer those questions, the fact of the matter is, at the end of the day they're still left taking my word for it, and let's be blunt: my answer can really only cover those companies and/or project teams I've had direct contact with. I can certainly tell you what I've heard from others (usually at conferences), but even that's now getting into secondhand information, which to you will be third-hand. (And that, of course, assumes I'm getting it from the source in the first place.)

This isn't just about project management styles--agile or waterfall or WHISCEY (Why the Hell Isn't Somebody Coding Everything Yet) or what-have-you--but also about technical trends. Is Ruby taking off? Is Scala becoming more mainstream? Is JRuby worth exploring? Is C++ making a comeback? What are peoples' experiences with Spring 2.5? Has Grails reached a solid level of performance and/or stability? Sure, I'm happy to come to your company, meet with your team, talk about what I've seen and heard and done--but sending your developers (and managers, though *ahem* preferably to conferences that aren't in Las Vegas) to a conference like No Fluff Just Stuff or JavaOne or TechEd or SD West can give them some opportunities to swap stories and gain some important insights about your team's (and company's) velocity relative to the rest of the industry.

All of which is to say, yes, Billy was right: it's about the people. Which means, boss, it's OK to let the developers go to the parties and maybe sleep in and miss a session or two the next morning.

Recently, a number of folks in the Java space have taken to openly ridiculing Microsoft's use of the "Mort" persona, latching on to the idea that Mort is somehow equivalent to "Visual Basic programmer", which is itself somehow equivalent to "stupid idiot programmer who doesn't understand what's going on and just clicks through the wizards". This would be a mischaracterization, one which I think Nikhilik's definition helps to clear up:

Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems and focuses on productivity and learn as needed. Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learn while working on the solution. Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem, and typically learn in advance before working on the solution. ....

The description above is only rough summarization of several characteristics collected and documented by our usability folks. During the meeting a program manager on our team applied these personas in the context of server controls rather well (I think), and thought I should share it. Mort would be a developer most comfortable and satisfied if the control could be used as-is and it just worked. Elvis would like to able to customize the control to get the desired behavior through properties and code, or be willing to wire up multiple controls together. Einstein would love to be able to deeply understand the control implementation, and want to be able to extend it to give it different behavior, or go so far as to re-implement it.

Phrased this way, it's fairly easy to recognize that it's possible that these are more roles than actual categorizations for programmers as individuals--sometimes you want to know how to create the most efficient solution, and sometimes you just want the damn thing (whatever it is) to get out of your way and let you move on.

Don Box called this latter approach (which is a tendency on the part of all developers, not just the VB guys) the selective ignorance bit: none of us have the time or energy or intellectual capacity to know how everything works, so for certain topics, a programmer flips the selective ignorance bit and just learns enough to make it work. For myself, a lot of the hardware stuff sees that selective ignorance bit flipped on, as well as a lot of the frou-frou UI stuff like graphics and animation and what-not. Sure, I'm curious, and I'd love to know how it works, but frankly, that's way down the priority list.

If trying to find a quick-working solution to a particular problem means labeling yourself as a Mort, then call me Mort. After all, raise your hand if you didn't watch a team of C++ guys argue for months over the most efficient way to create a reusable framework for an application that they ended up not shipping because they couldn't get the framework done in time to actually start work on the application as a whole....

If you read the three days of Lang.NET posts I did last month and wondered "Man, I wish I could've seen...", fret no more.

My personal favorites:

• http://langnetsymposium.com/talks/1-05%20-%20Lively%20Kernel%20-%20Dan%20Ingalls%20-%20Sun.html
• http://langnetsymposium.com/talks/2-00%20-%20Democratizing%20the%20Cloud%20with%20Volta%20-%20Erik%20Meijer.html
• http://langnetsymposium.com/talks/2-01%20-%20Newspeak%20-%20Gilad%20Braha%20-%20Cadence.html
• http://langnetsymposium.com/talks/2-10%20-%20remotion%20Mixins%20-%20Stefan%20Wenig%20and%20Fabian%20Schmied%20-%20rubicon.html (You have to watch this one, just watch the intro even if you're not a C# guy or interested in mixins in the slightest; just get to the part where they talk about the sign--you'll know what I mean when you get there. You can hear us laughing in the background--easily the funniest moment of the 3 days.)
• http://langnetsymposium.com/talks/3-09%20-%20Intentional%20-%20Magnus%20Christerson.html
• http://langnetsymposium.com/talks/3-06%20-%20Visual%20Studio%20Shell%20-%20Aaron%20Marten.html
• http://langnetsymposium.com/talks/3-03%20-%20Parsing%20Expression%20Grammars%20in%20FSharp%20-%20Harry%20Pierson.html

Of course the other presentations are good, but each of these had a moment in them when I said, "Hmm...."

While tracking some of the links relating to the Groovy/Ruby war, I found this website, which purportedly tracks job trends based on a whole mess of different job sites. So, naturally, I had to plug in to get a graph of C#, C++, Java, Ruby, and VB:

java, c#, c++, ruby, visual basic Job Trends

java jobs - c# jobs - c++ jobs - ruby jobs - visual basic jobs

Interesting. I don't think it proves anything one way or another, mind you, but interesting nonetheless. Having said that, a few things stand out to me after looking at this for all of thirty seconds:

• Wow, what the hell happened in 1Q and 2Q of 2005? Java takes a huge drop in 2005, and all of them take a small drop of some form around the same time in 2006. What is it with summertime? Did the HR supervisor suddenly take a look at the company's job board and mutter, "Damn, I thought we closed all those listings already..."? (Or maybe, "Thank God for cheap college interns..."?)
• C++ jobs still outnumber C# jobs, even in 4Q 2007?
• C++ jobs remain essentially flat from 1Q 2005 to 4Q 2007; apparently, there's a lot more C++ going on than most companies are willing to admit to.... (Can't you picture it? The nervous candidate, sitting at the table, as the interviewer shuffles the paper and says, "So, you're here for a programming job?" The candidate sort of squirms in his chair as he replies, "Well, actually, I was hoping for a... a... C++ job." The interviewer quickly looks around to see who might be listening as he says loudly, "C++? What ever gave you the idea that we do C++ here at BigCorp?" Meanwhile, he surreptitiously scribbles on the back of a business card and slides it across the table to the candidate, then stands up and says loudly, "I'm afraid you've come to the wrong place, sir. You can see yourself out, I take it?" The candidate palms the card, and only once has he left the building does he look at the back, which reads, "8PM, corner of Mission and Vine, password is 'Lippman, Stroustrup, Sutter, and Meyers!' Viva C++!"...)
• VB jobs fall to below C#? So much for those vast hordes of VB programmers that supposedly form the "long tail" of the .NET community....
• Java jobs remain essentially flat from 1Q 2005 to 4Q 2007, despite numerous ups and downs. So much for the idea that Java is somehow going away....
• Ruby's penetration into the job market is much smaller than what I would have guessed.
• I couldn't help myself, I did another query with "cobol" added in, but I'll leave it to you to run your own query to see what that looks like. It's surprising....

Of course, statistics without any sort of understanding of how they were gathered or from what sources are essentially meaningless, but ooooh, it's in color....

LLVM definitely does some interesting things as part of its toolchain.

Consider the humble HelloWorld:

   1: #include <stdio.h>

   2:  

   3: int main() {

   4:   printf("hello world\n");

   5:   return 0;

   6: }

Assuming you have a functioning llvm and llvm-gcc working on your system, you can compile it into LLVM bitcode. This bitcode is directly executable using the lli.exe from llvm:

$ lli < hello.bc
hello world

Meh. Not so interesting. Let's look at the LLVM bitcode for the code, though--that's interesting as a first peek at what LLVM bitcode might look like:

   1: ; ModuleID = '<stdin>'

   2: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64"

   3: target triple = "mingw32"

   4: @.str = internal constant [12 x i8] c"hello world\00"        ; <[12 x i8]*> [#uses=1] 

   5:  

   6: define i32 @main() {

   7: entry:

   8:     %tmp2 = tail call i32 @puts( i8* getelementptr ([12 x i8]* @.str, i32 0, i32 0) )        ; <i32> [#uses=0]

   9:     ret i32 0

  10: } 

  11:  

  12: declare i32 @puts(i8*)

Hmm. Now of course, LLVM also has to be able to get down to actual machine instructions, and in point of fact there is a tool in the LLVM toolchain, called llc, that can do this transformation ahead-of-time, like so:

$ llc hello.bc -o hello.bc.s -march x86

And, looking at the results, we see...

   1: .text

   2: .align    16

   3: .globl    _main

   4: .def     _main;    .scl    2;    .type    32;    .endef

   5: n:

   6: pushl    %ebp

   7: movl    %esp, %ebp

   8: subl    $8, %esp

   9: andl    $4294967280, %esp

  10: movl    $16, %eax

  11: call    __alloca

  12: call    ___main

  13: movl    $_.str, (%esp)

  14: call    _puts

  15: xorl    %eax, %eax

  16: movl    %ebp, %esp

  17: popl    %ebp

  18: ret

  19: .data

  20: r:                # .str

  21: .asciz    "hello world"

  22: .def     _puts;    .scl    2;    .type    32;    .endef

Bleah. Assembly language, and in NASM format, to boot. (What did you expect, anyway?)

Of course, assembly language and C were always considered fairly close together in terms of their abstraction layer (C was designed as a replacement for assembly language when porting Unix, remember), so it might not be too hard to...

$ llc hello.bc -o hello.bc.c -march c

And get...

   1: /* Provide Declarations */

   2: #include <stdarg.h>

   3: #include <setjmp.h>

   4: /* get a declaration for alloca */

   5: #if defined(__CYGWIN__) || defined(__MINGW32__)

   6: #define  alloca(x) __builtin_alloca((x))

   7: #define _alloca(x) __builtin_alloca((x))

   8: #elif defined(__APPLE__)

   9: extern void *__builtin_alloca(unsigned long);

  10: #define alloca(x) __builtin_alloca(x)

  11: #define longjmp _longjmp

  12: #define setjmp _setjmp

  13: #elif defined(__sun__)

  14: #if defined(__sparcv9)

  15: extern void *__builtin_alloca(unsigned long);

  16: #else

  17: extern void *__builtin_alloca(unsigned int);

  18: #endif

  19: #define alloca(x) __builtin_alloca(x)

  20: #elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)

  21: #define alloca(x) __builtin_alloca(x)

  22: #elif defined(_MSC_VER)

  23: #define inline _inline

  24: #define alloca(x) _alloca(x)

  25: #else

  26: #include <alloca.h>

  27: #endif

  28:  

  29: #ifndef __GNUC__  /* Can only support "linkonce" vars with GCC */

  30: #define __attribute__(X)

  31: #endif

  32:  

  33: #if defined(__GNUC__) && defined(__APPLE_CC__)

  34: #define __EXTERNAL_WEAK__ __attribute__((weak_import))

  35: #elif defined(__GNUC__)

  36: #define __EXTERNAL_WEAK__ __attribute__((weak))

  37: #else

  38: #define __EXTERNAL_WEAK__

  39: #endif

  40:  

  41: #if defined(__GNUC__) && defined(__APPLE_CC__)

  42: #define __ATTRIBUTE_WEAK__

  43: #elif defined(__GNUC__)

  44: #define __ATTRIBUTE_WEAK__ __attribute__((weak))

  45: #else

  46: #define __ATTRIBUTE_WEAK__

  47: #endif

  48:  

  49: #if defined(__GNUC__)

  50: #define __HIDDEN__ __attribute__((visibility("hidden")))

  51: #endif

  52:  

  53: #ifdef __GNUC__

  54: #define LLVM_NAN(NanStr)   __builtin_nan(NanStr)   /* Double */

  55: #define LLVM_NANF(NanStr)  __builtin_nanf(NanStr)  /* Float */

  56: #define LLVM_NANS(NanStr)  __builtin_nans(NanStr)  /* Double */

  57: #define LLVM_NANSF(NanStr) __builtin_nansf(NanStr) /* Float */

  58: #define LLVM_INF           __builtin_inf()         /* Double */

  59: #define LLVM_INFF          __builtin_inff()        /* Float */

  60: #define LLVM_PREFETCH(addr,rw,locality) __builtin_prefetch(addr,rw,locality)

  61: #define __ATTRIBUTE_CTOR__ __attribute__((constructor))

  62: #define __ATTRIBUTE_DTOR__ __attribute__((destructor))

  63: #define LLVM_ASM           __asm__

  64: #else

  65: #define LLVM_NAN(NanStr)   ((double)0.0)           /* Double */

  66: #define LLVM_NANF(NanStr)  0.0F                    /* Float */

  67: #define LLVM_NANS(NanStr)  ((double)0.0)           /* Double */

  68: #define LLVM_NANSF(NanStr) 0.0F                    /* Float */

  69: #define LLVM_INF           ((double)0.0)           /* Double */