It's the time of year where people set themselves goals - for the whole of 2011, for the next few months, or just in general. And you can read a lot about SMART goals and how great they are. Opinions vary on exactly what the letters stand for but I'll go with Specific, Measurable, Attainable, Relevant, and Timely. So if I'm giving you a performance review and I say "you should be more helpful", that is not a SMART goal because we can't measure your helpiness and it's also not terribly specific and I haven't given you any kind of time frame for improvement. If you're not helpier tomorrow, have you failed your goal? What about next week? Next month? How long do you have to get more helpful? If I say "you should fill out your timesheet more often" it's still not a SMART goal because it's vague and doesn't have a time element and so on. I can make it a SMART goal by saying something like this: "over the next 6 weeks, at least 5 weeks' timesheets will be completed by 10am
of the next Monday morning." The relevance will have to come into play when I explain to you that late timesheets delay our billing of clients and mess up our cash flow. (Or whatever; we actually don't use timesheets here, but that's not the point.)

So OK, we have this concept. And it seems like a pretty good one. After all, if you write it like that, we can come back after 6 weeks (or whatever) and say "pass" or "fail". But let's look at the timesheet-laggard above. Let's say that person misses week 1 and week 2, then goes flawless after that. Still fail? If you feel that way, then as soon as the laggard misses week 2, why keep trying? You've blown the goal, right?

Then there's the matter of the consequences of blowing the goal. Am I going to fire you for messing up my invoicing and causing cash flow headaches and just generally not caring about the business? (I might.) But if you have a goal to pass a particular cert, and you fail it, is anyone going to fire you? Or you have a personal goal to run some distance under some time and you don't get to that time, will you give up running?

Here's I. M. Wright on why having a dozen year-long SMART goals is just wrong - they take so long to write, if people meet 11 out of 12 they can still have a fail of a year, they're all about you when you're actually part of a team, and so on. Since they're unavoidable at some companies, he has some suggestions how to have 4 or 5 really good ones. He also doesn't like SMART for stretch goals, and I agree. Christophe is more about how things change over an entire year, so the goal is probably not relevant by the time limit. The top answer to this StackOverflow question says they're not good for developers, period.

In answering this StackOverflow question I realized something. SMART goals are good for "shape up or else" goals, put on a person by someone else, that allow just a few weeks to achieve something really, well, specific, measurable, and relevant. Do your timesheets. Come to work on time. Include a decent comment when you check in your work. They're really not good for "be a better person", "lose weight", "make more money", or even "get a paid acting job". You just need a different way to express and measure progress on those kind of goals. If you're setting a goal for yourself, unless you think you're correcting a deficiency and have consequences lined up for failure, don't make it a SMART goal.

According to Darryl Taft, the top languages for next year (and this may surprise you) are going to be Java, C, and C++. You're probably all ready to disagree, but understand the criteria:

... the workhorse languages such as C and C++ continue to remain at the top end of
the software development landscape in terms of language use and job potential
(despite growing more slowly and even decreasing, according to some sources).
Moreover, this list is not intended to highlight the hot, hip new languages on
the horizon, but to focus on where programmers can go to look for work.

There's a large body of work being done in languages that are not new, or hot, or trendy, but that have been around for long enough to develop a body of developers and libraries that enable getting things done. The volume of code that will not be ported to new and exciting languages, and will be maintained in its current language for years and decades, will always outweigh the volume of code that is being written from scratch right now or being ported. If you want a job, knowing an "old workhorse" language is a good thing.

Darryl profiles 18 languages in all: Java, C, C++, C#, JavaScript, Perl, PHP, VB, Python, Ruby, Objective-C, ActionScript, Groovy, Go, Scala, Erlang, Clojure, and F#. That is an awful lot of curly brackets, a very high placement for Objective-C given that it really does only one thing, and a fair dose of hot/new/trendy once you get past the top ten. Worth a read!

Many people really don't understand where P/Invoke signatures come from, or what they mean. They head over to pinvoke.net, which - don't get me wrong - is a hugely important resource, and then blindly paste in whatever they find and try compiling and running their code. Or they use the superbly helpful P/Invoke Interop Assistant. Again, paste, build, run, works on my machine.

This is a great way to start. The problem is assuming that once one run worked, you're done. You need to read and understand the P/Invoke signature you are using. Especially when you are passing in a pointer, or getting a pointer back, you must know who owns that memory and who will clean it up. Are you handing it over to the native code to manage? Is there a risk your managed code will clean it up before the native code is done with it? Is there a risk the native code will clean it up, and then later the managed code will also try to clean it up? Don't think these things don't happen, they most certainly do.

Here's an example: a long running intermittent bug that was caused by a P/Invoke declaration that said the managed side would clean up, but that should have said the native side would (since the native side did.) And here's a nice summary of ways to make sure that native resources (like handles) aren't cleaned up too soon by the managed side. Sorry, but you need to understand this stuff in order to interop successfully. That's where the phrase "head spinning interop" came from, after all.

Don't like it? Don't want to learn it? Then use an interop library like the Code Pack that takes care of those sorts of things for you and exposes an entirely managed interface. Have to learn it whether you want to or not? Consider using the Code Pack as a reference for how to do interop properly. The full source code is available, and nicely commented too.

It's over 200 pages long, and over four years old, but I just heard about it recently. A long, dense discussion of whether certain C++ features (templates, namespaces, RTTI, etc) have a performance cost, and how to write code that incurs as little performance cost as possible. Its official name: ISO/IEC TR 18015:2006(E) Technical Report on C++ Performance. In addition to runtime performance, it also touches on compile slowness, the "brittle base class" problem, and the different performance characteristics of various STL collections and algorithms. If you care about the speed of your C++ code, you should read this, even if some of it is already familiar to you.

I'd like to give some kind of "Restrained Understatement" award to this sentence:

Template meta-programming and expression templates are not techniques for novice programmers, but an advanced practitioner can use them to good effect.

To be clear about where these authors are placing the "advanced" bar, I don't use meta-programming, I consider it too advanced for me. And I have 20+ years of C++!

The whole report is platform independent (though embedded systems are discussed separately) and compiler independent, too. I wish it were updated for C++0x, but I guess that will have to wait until C++0x is settled . There's a 14 page bibliography, and you would do well to read many of them, though my source for the link winkily pointed out another possible paper. That one is old enough to get a driver's license, but I think you might enjoy reading it anyway. As the introduction begins:

It is important to understand how your programming language is implemented. Such knowledge dispels the fear and wonder of “What on earth is the compiler doing here?”; imparts confidence to use the new features; and provides insight when debugging and learning other language features. It also gives a feel for the relative costs of different coding choices that is necessary to write the most efficient code day to day.

It's only 23 pages long, and concludes:

... we have considered many of the significant C++ run-time implementation issues. We see that some wonderful language features are almost free, and others can incur significant overhead. These implementation mechanisms are applied quietly for you, behind the curtains, so to speak, and it is often hard to tell what a piece of code costs when looking at it in isolation. The frugal coder is well advised to study the generated native code from time to time and question whether use of this or that particularly cool language feature is worth its overhead.

Those hardworking elves at the All in One Code Framework keep releasing more samples. They've added some ASP.NET samples (including a very interesting "get location from IP address" one) and some Windows 7 shell extensions, specifically a preview handler. Ah, the good old .recipe file type - an old friend of mine. But as always the samples are going to save you hours and hours of time.

Here's an index to all the samples for you to explore. You might be a little astonished if you haven't checked it out before, they have:

Slowly but surely the samples are accumulating to live up to the name. This should be the first place you look when you want to take on a new task. Generally speaking, everything is available in native C++, C#, and VB (the exceptions are things you can't do in native C++, like ASP.NET) with the language included in the sample name (look at CppWin7TriggerStartService, CSWin7TriggerStartService, and VBWin7TriggerStartService for example.) And remember, if you don't see what you want - you can ask for it!

At the moment these are announced in the USA only. A full day of client development training for Windows 7, including IE9 and SL OOB. They say:

We will look at application compatibility and transitioning your applications to
Windows 7, integrating with the Windows taskbar, developing for IE9, utilizing
the cool functionality in the Sensors and Location Platform so that your
application better responds to its current environment, leveraging the
multitouch capabilities (especially in kiosk scenarios), and creating
Silverlight 4 out of browser applications. This event is a unique opportunity,
partnering classroom learning with hands-on-labs and leveraging experts to
advise you so we can help you “win” with Windows 7.

You bring your own laptop with VS 2010, the Code Pack, the Windows 7 Training Kit, IE9, and Silverlight 4 installed (there are links on the bootcamp page) and do the labs as you go. The training is all free and you'll get hands on experience right while you're there. (It doesn't say so, but my guess is this is all managed code and that the labs are in both C# and VB.)

And if there isn't one near you, you can help arrange one! It's all packaged as an event-in-a-box so all you need is a trainer who'll agree to deliver it and a room to hold it in. But check the dates and locations first -- there are over a dozen sessions scheduled already, so perhaps there's one near you.

Back on December 7th, Jason Zander announced the beta of Service Pack 1 for Visual Studio 2010. December announcements can often go un-noticed, but you should pay attention to this one. You can get the beta and start using it in production immediately.

What's in it, and why does a service pack matter, anyway? Well this one brings Silverlight 4 Tools for Visual Studio "into the box", updates some MFC capabilities, and fixes things people raised on Connect. (Remember, complaining about missing features or bugs to your cubicle mates may make you feel better, but raising them on Connect gets them fixed. I should know, I submit things there and they get fixed.) STL has a comment on the VCBlog post that spells out many of the fixes in detail.

Take a few minutes and update your Visual Studio, especially if you're a C++ developer, whether MFC or C++0x (or both, of course.)

Herb Sutter has blogged a "trip report" (except he didn't travel, but anyway) about the November meeting of the C++ Standards Committee. In it, he tells us:

Things are going well and we are on track to complete the Final Draft
International Standard (FDIS) for the C++0x standard after the Madrid meeting in
March. If that happens and that ballot succeeds, the C++0x standard will be
published in 2011.

There are still decisions being made, and I have to say I like the way they're going. I think contextual keywords are wicked smart, and that if compilers can understand them, developers sure can. Compare Herb's two examples:

Contextual keywords make the second option possible, and I think it's much better. You can also read about noexcept and the whole exception-checking backstory, as well as rules for generating move constructors and move assignment operators. It's all good.