Always an apprentice?

With the rate at which new software languages and technologies are appearing, its a tough job for a software engineer to keep up with the latest developments and trends as well as keeping existing skills sharp. Just as you feel you master one language or technology, a new one comes along and your apprenticeship starts over in this new field.

One of the best ways that I have found to both learn new languages/skills and to keep existing skills sharp is to practice each skill as much as possible. For programming languages this means regularly writing pieces of code in each language in the toolbox. I try to use each language that I know at least once a month for languages that I have become proficient in and at least once a week for languages that I am learning.

Dave Thomas describes this concept in greater detail in his CodeKata series.

I find the use of programming puzzles and challenges as excellent ways to find concise coding exercises that don't soak up to much time but yet provide opportunities to hone & develop skills as well as often providing opportunities to learn about new libraries, packages, algorithms etc.

Some of the best coding problem / challenge sites that I use are:
http://codekata.pragprog.com/
http://www.pythonchallenge.com/
http://www.topcoder.com/

Simple container dump using STL iterator

Quick and dirty printing of containers contents in C++ using STL ostream_iterator ...

#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

int main()
{
    vector<int> v(10);
    generate(v.begin(), v.end(), rand);

    copy(v.begin(), v.end(), 
        ostream_iterator<int>(cout, "\n"));
    return 0;
}

Pillars of Concurrency

Excellent article on decomposing and categorizing concurrency traits by Herb Sutter ... http://www.ddj.com/dept/cpp/200001985

The three "pillars" identified in the article:

1. Responsiveness and Isolation Via Asynchronous Agents
2. Throughput and Scalability Via Concurrent Collections
3. Consistency Via Safely Shared Resources

An interesting reference from this article is to an earlier article from Herb illustrating why lock based programming is hard and insufficient: http://www.ddj.com/dept/cpp/184401930