I got hooked on creative programming during the brief few years I sullied the field of software development by working as a programmer. I had a clear sense of myself as an explorer, taking the Apple II places no one had ever taken a computer before. The industry’s relatively few books on algorithms and program structure were unknown to me, and I wouldn’t have understood them if I had blundered into them. So I learned to program through trial and error, intuition and experimentation. When I got a program to run – and I’m still proud of the apps I created in those days – my triumph was both practical and artistic. For me, programming was a creative endeavor.

I know I’m not alone. I’ve talked to many programmers over the years, and the chance to exercise creativity is one of the things they like best about software development. Many of the developers I talk to these days are preoccupied with mundane tasks like extracting data from mainframe tables, formatting information for output, and patching up apps with new layers of data-security scaffolding. It doesn’t look like creative work to me, but I’ve learned that creativity refers to the way you approach a problem, not the problem itself. Even the most mundane task can be accomplished in a creative way (without compromising the quality of the app or missing the project deadline, of course) by practitioners who see themselves as creative.

I hope you see your work as an outlet for creativity. For me, that was what made programming satisfying. Yes, I liked solving users’ problems. I loved dismantling complex challenges and finding the inner simplicity. But mostly, I saw programming as a means of personal expression.

Everyone who works in a creative discipline draws a blank sometimes. It’s hard to be creative on demand, especially when facing tight deadlines.

Of course, little we do as developers is truly original. For me, at least, a creative triumph was when I arranged well-known, frequently used programming tropes in novel ways that met my application’s needs. You might call this “combinatorial creativity.”

I was reminded of this the other day when I happened upon a letter that Mark Twain once wrote to Helen Keller. It seems that Keller had been accused of plagiarism. The charge was dismissed, but Twain still had more than a little to say about it, and about creativity itself:

Oh, dear me, how unspeakably funny and owlishly idiotic and grotesque was that “plagiarism” farce! As if there was much of anything in any human utterance, oral or written, except plagiarism! The kernel, the soul – let us go further and say the substance, the bulk, the actual and valuable material of all human utterances – is plagiarism. For substantially all ideas are second-hand, consciously and unconsciously drawn from a million outside sources, and daily use by the garnerer with a pride and satisfaction born of the superstition that he originated them; whereas there is not a rag of originality about them anywhere except the little discoloration they get from his mental and moral calibre and his temperament, and which is revealed in characteristics of phrasing. When a great orator makes a great speech you are listening to ten centuries and ten thousand men – but we call it his speech, and really some exceedingly small portion of it is his. But not enough to signify. It is merely a Waterloo. It is Wellington's battle, in some degree, and we call it his; but there are others that contributed. It takes a thousand men to invent a telegraph, or a steam engine, or a phonograph, or a telephone or any other important thing – and the last man gets the credit and we forget the others. He added his little mite – that is all he did. These object lessons should teach us that ninety-nine parts of all things that proceed from the intellect are plagiarisms, pure and simple; and the lesson ought to make us modest. But nothing can do that.

Web recommendation: I know too much about how computers work to consider robots a threat to my life or my job. But this series of articles got me thinking. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He enjoys a shot of Scotch now and then.

I encountered a fascinating Web site today. The care and love behind its construction are evident. The personal messages from the site’s managers reflect their commitment to exceeding users’ expectations. The idea is novel and the implementation, from what I’ve seen, is first-rate.

So what’s the problem? The problem is that the site fills a need that doesn’t exist, as far as I can tell.

The site is compilr.com. It’s an online IDE and compiler for Python, node.js, PHP, JavaScript, HTML, C, C++, Ruby, Java, C# and VB.NET. Think of it as Google Docs for developers.

compilr.com instantiates a bunch of hot buzzwords. It’s cloud-based. It’s virtual. It’s SaaS. It supports collaboration. All good, right?

Yeah, it’s all good. But I’m left with one question. Who needs it?

If you’re a professional, you want your development environment on your machine, or at least on a local server where you can control the installation. You want to know which patches and revisions have been loaded, and which versions of the libraries are installed. At compilr.com, you don’t know what compiler is running in the back end. If the installed libraries are documented, I can’t find the details. These details matter.

Also lacking are version control and facilities for testing and debugging. Judging from the site’s user forum, these features have been on the back burner for a couple years.

I want to like compilr.com, but I think it’s a solution in search of a problem. It’s easy enough for students and casual developers to download free development environments from the Web. Professionals know where to get their power tools. A Web-based development environment sounds like it ought to be useful, but once you think about it for a few minutes, the usefulness evaporates.

Too bad.

Web recommendation: Here is another alarming article, this one from the good folks at Wired. Little by little, piece by piece, a larger picture is becoming clear, and it’s a disturbing one. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He wishes Aaron Sorkin still had a series on the air.

One of the things I like about programming is that it is a little too hard for human beings to do.

I’m serious. And I don’t think programming is the only task beyond our abilities. Playing chess is too hard too – no one plays with perfect skill. We can only approximate perfection in ballet. We don’t know the rules that will allow us to create compelling, well-conceived novels on a routine basis. I venture to say that every human activity worth doing is just a little bit beyond our capacity. That’s what makes the activities interesting to do and, often, to observe. That’s why they drive us to learn and practice, to challenge ourselves on a daily basis.

This may explain why there are no tic-tac-toe tournaments on television. The game is well within our abilities, and therefore boring.

That said, I think parallel programming is a level beyond ordinary coding. It’s way beyond our abilities.

In recent months I’ve read dozens of articles on writing code for parallel systems, especially multicore processors. I’ve looked at libraries and language extensions intended to support parallelizing everything from C to SQL. I’ve seen clever code rewrites that deliver impressive performance benefits.

From all this, I’ve concluded that writing parallel code is unjustifiably difficult. The first 20% of the job, the code that delivers 80% of the benefits, is simple enough. (Typically, it’s a matter of performing the same transformations that you would apply if you were optimizing the code for single-thread performance.) But the remaining optimization steps are too complex. They require us to think like CPUs, to work at a very low level while writing high-level code. There’s no way to do it without knowing just what the compiler is going to do to each line of code you write.

We’re missing deadlines already, as we focus on manifesting user requirements in working code. If we can add a “think like a compiler” stage to development projects the whole enterprise will grind to a halt.

And yet…the multicore processors are there. Extra performance is a tweak away.

The industry seems to think that the only way to wring optimal multithreaded performance out of advanced hardware is to change the way developers write code. But I’m convinced that’s a dead end. We can’t ask a generation of programmers to start second-guessing the way their compilers work.

No, the answer is to concentrate parallel-programming wisdom in a cadre of programmers who specialize in the task, who eat complexity for breakfast. These programmers should go to work for compiler vendors, and build their knowledge into the tools we use. That’s where insights about parallelization belong: not in our code, but in our compilers.

Compilers are already doing impressive optimizations for parallel programming. That’s the right way to proceed as we milk modern hardware for ever-increasing performance.

Web recommendation: Don’t view this page at lunch unless you’ve got a strong stomach. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He doesn’t get much sleep these days.

The ancient Greeks had no computers, but their mythology includes one figure who embodies an unchanging reality of programming. I am speaking, of course, of Tantalus. You may remember the story.

Tantalus was a king of Phrygia, in what we now call Turkey. He was a friend of the Greek gods until he offended them. Then he received a distinctive punishment. In the underworld, Tantalus was tied to a fruit tree that stood in a river. When he reached for a fruit, the branches would rise until the intended meal was just beyond his grasp. When he leaned down to get a drink, the water receded. Tantalus was sentenced to eternal hunger and thirst, and the objects of his longing were forever just out of reach.

So it is with programmers. But instead of fruit and water, we hunger for reusability.

You don't have to write code very long to realize that almost all of what we do has been done before. We are constantly solving problems that have been solved over and over again in the past. We write boilerplate code and reinstantiate well-known algorithms.

We would be more productive – and our days more enjoyable – if we weren't always reinventing the wheel. What if we could bundle code for reuse? Then we could incorporate algorithms and boilerplate code by reference instead of tediously rewriting it with each new app.

This dream has been the motivation behind many of the technologies that support our industry. Off the top of my head, the list includes these:

• Unix command-line utilities

• system libraries

• function libraries

• class libraries

• dynamic link libraries

• subroutines

• object-oriented programming

• package-oriented languages like Ada and Modula-2

• code generators and CASE tools

• component-based development

• visual programming

• use cases and design patterns

• application frameworks

• service-oriented architectures

It's a rare project that doesn't make use of several of these technologies. But the software we write can still be characterized as ad hoc. We continue to reinvent the wheel with each new project.

I don't have a solution to offer – the technologies on the list, plus, no doubt, others that escaped my attention – should be sufficient. The benefits of reuse are obvious. Yet software reuse remains maddeningly – tantalizingly – out of reach.

Web recommendation: Imitation is a form of reuse, I guess. And they say (do they still say?) it is the sincerest form of flattery. If so, the good folks at Apple must feel awfully flattered these days, due to this effect. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He is grateful for the days Internet service, water delivery, and electricity are all uninterrupted.

I've been thinking about literate programming lately.

LP is the brainchild of legendary algorithm-master Donald Knuth, one of our field's undisputed deep thinkers. For the past 50 years Knuth has been toiling on his masterwork, The Art of Computer Programming, an encyclopedic exploration of algorithms, languages, and compilers. Knuth has finished just three of the planned seven volumes in his first 50 years of work, but it's not entirely his fault. He gets distracted. Disappointed with the state-of-the-art in typesetting when he published the first volume, for instance, he took some time off to create TeX and METAFONT.

Knuth introduced LP in an article called “Literate Programming” that appeared in the British Computer Society's Computer Journal in 1984.

The idea behind LP is that developers should write text that describes each aspect of their programs along with the code, in the same file, using a markup language to signal logical structure (headings, subsections, and so on). Special tools make the text visible and invisible, and strip out the text before compilation.

Knuth argued that describing code in prose would lead programmers to think more carefully about what their code did and how it operated. A mental feedback cycle would be established as the programmer wrote the text and the source code, and the result would be better software.

“The practitioner of literate programming,” Knuth wrote, “can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.”

LP aficionados flame anyone who suggests that LP is just a mechanism for writing better-documented code. They emphasize that the programmer is really writing an essay about the intentions behind the code, and explicitly explaining how those intentions are mapped into source code. It's not just documentation. It's not just a discipline. It is a (dare I say it?) paradigm.

A central assumption behind LP is the notion that programmers can write well-structured essays that explain the why and how of their code. I'm skeptical about that. Going back to college showed me that the ability to write a well-structured essay is surprisingly rare (even at Columbia). Anyone with the ability to organize his thoughts sufficiently to write an essay about their code probably doesn't need help getting the code organized properly.

In other words, literate programming can help only those who least need its assistance.

The tools page at literateprogramming.com seems a bit out-of-date, but it provides a list of LP tools for use with different languages. A quick search of the Web turned up dozens more, most of them free. If you want to get started with LP, there's no reason to hesitate.

But modern operating environments have brought substantial formatting capabilities to source code editors, and I think those capabilities have rendered LP obsolete.

Yes, we should embed more and better documentation in our code. But once we've made that commitment, LP and LP tools don't bring much to the table.

Web recommendation: Computerworld's Preston Gralla is a super-smart guy and I've learned a lot from reading his columns over the years. But I think he's missed the mark with his latest effort. Gralla argues that those who are urging Apple to insist upon better working conditions for the offshore workers who manufacture its products must be prepared to pay more for Apple products. I think Gralla missed an obvious point. Apple could invest more in worker safety and working conditions without raising prices if it were willing to reduce its legendary profit margins somewhat. Apple is a profit machine. In the final quarter of 2011 the company had revenues of $46.33 billion and quarterly net profit of $13.06 billion. The company has $97.6 billion in the bank. Sharing some love with abused workers in overseas sweatshops shouldn't force Apple to raise prices. Gralla's article is here. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He feels virtuous today because he spent the morning mopping floors.

For a few months now, I've been intending to comment on a short essay by SD Times blogger Victoria Reitano. Maybe you remember it. Reitano posted “Software development: manufacturing process or creative idea?” from Salt Lake City's Agile 2011 conference back in August. The title caught my eye immediately. Reitano's question is a variant of a classic recurring debate: Programming: Art or science? It seems like everyone has taken a shot at this question at one point or another:

• Blog post: Knuth: Computer programming as an art

• Question on Object Mix forum: Is programming/computer science an art or a science?

• MSDN article by Stanley B. Lippman, circa 2006: Is programming an art?

• Slashdot discussion: Is programming art?

• Net Objectives blog post by Bob Hartman: Is programming an art or a science?

• Follow-up post by Bob Hartman: Is programming an art or a science? (Part II)

• Blog post by Aater Suleman: Is programming an art or a science?

• CodingForums.com discussion thread: Programming: An art or science?

• CatsOnKeyboards.com blog post: Programming: Art, not science

• Rebuttal to Lippman's MSDN article: Dear Stanley B. Lippman

• Blog post by Rodrigo Monteiro: Programming is art

• Blog post at O'Reilly's ONLamp.com: Is programming art?

• Discussion thread at </dream.in.code>: Programming: A science or an art?

• Knuth's original essay (PDF): Computer programming as an art

If you think I'm going to wade into this debate, you're crazy. The problem is that the question, as framed, doesn't allow for a sensible answer.

You want to know what programming is? It's...a creative discipline. I know, because it tickles the same part of my brain that is tickled by other creative disciplines.

When I was young, I had very serious musical ambitions. I did a fair bit of composing. You know what I liked about it? The combination of rigor and complexity. Musical composition requires mastery of a hugely complex set of rules, some inherent in nature and some established more arbitrarily through centuries of tradition. Despite the thousands of rules, composers are expected to exercise immense creativity. In fact, creativity is a sine qua non for achievement in musical composition.

Architecture is much the same. Those who design buildings must first master in-depth knowledge of materials, structural relationships, and historical precedent, all of which are more or less binding upon their subsequent efforts. Yet within these bounds, they must employ their creative senses to create aesthetic affects.

I think that even chess-playing is a creative discipline, at a certain level of seriousness. The would-be grand-master must internalize a complex set of more or less arbitrary rules, then deploy his pawns and pieces according to an overall strategy that can only be described as artistic.

Cooking and the writing of fiction rely upon similar mixes of complex conventions and an aesthetic element based on creativity.

Human brains – at least the brains of computer programmers, composers, architects, chess players, cooks, and writers – are drawn to tasks that conform to this mix of requirements. The essential elements are complexity, rigorous rules, and the opportunity for creative expression.

We programmers like to think of ourselves as a unique branch of humanity, spawned mere decades ago along with the microprocessor. But that isn't the case. Our love of complexity, rigor, and creativity makes us more, not less, human.

Web recommendation: I love the blogs at SD Times and I feel honored to have a home here. If you're looking to do some reading, you could scarcely do better than browsing the archives here – even before I joined the team a few months ago, the nuggets among these posts were pithy and frequent. But if you find that you have additional time and curiosity, then you simply must check out the blog network at Scientific American. These posts are funny, serious, timely, in-depth, provocative, and relevant. Be warned – if you dip your virtual toe into these waters, you may find yourself drawn in like Hylas among the nymphs. The Scientific American blog directory is here. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He likes pizza, but who doesn't?

Corey Haines, a software journeyman, has introduced Code Retreat to help developers practice their craft in a worldwide effort to enhance software code quality. 

“Our business and personal lives are powered by software. Well-crafted code hides in our pleasant daily existence. But when code fails, mayhem occurs: air-traffic-control systems go down, bank accounts get hacked, people lose money, the lights go out, communications go silent, commerce grinds to a halt,” said Haines in a release. 

Haines will start in Sydney, Australia and then use "reverse time travel" to start the event in Honolulu, Hawaii the next day. 

Haines believes software developers need to work together to move quickly and effectively to build software for businesses, organizations, governments and communities. Software, in his mind, is a craft that must be practiced in order for practitioners to excel. 

A list of the locations for the day can be found here with more to be added the day of the event. 

Will you attend one of these events? You can also join the Code Retreat on Ning social network here.

You have probably heard by now that Google is shuttering its developers-only search service, Google Code Search. According to a blog post by products VP Bradley Horowitz, the service will shut down on January 15, 2012.

Judging from traffic on the service's user forum, Code Search didn't see a lot of use. And that's too bad – I think I would have used the service constantly, during my coding days, to find documentation and code snippets that would help me solve programming problems.

The end of Google Code Search is an opportunity for other sites dedicated to helping developers avoid reinventing the wheel. I've visited a bunch of them lately.

• Black Duck Software's koders.com is a full-blown alternative to Google Code Search. It indexes just code – no doc files. Where GCS employs – employed, I suppose I should say – regular-expression syntax to let developers fine-tune their searches, koders.com relies upon a spare set of include and exclude operators.

• Aragon Consulting Group's Krugle looks like a general-access code-search tool, but I haven't found a way to make it deliver many hits. It seems primarily intended to persuade you to install the Krugle Enterprise Edition as a sort of searchable repository for your corporate code, test plans, and configuration files. Still, Krugle gets a lot of mentions in developer forums as a viable successor to GCS.

• SourceForge is a tremendous resource – a huge library of open-source projects, each with complete source code. But it isn't searchable on a keyword-by-keyword basis, and it really isn't intended to augment your docs with sample code.

• Like SourceForge, github is a large collection of project files for working projects. You can find a lot of vendor sample code there too. But ultimately, this isn't the kind of searchable library that developers need when they're searching for line-by-line solutions to coding problems.

• I like the Merobase Software Component Finder. If you're looking for Java or C++ code, it's a pretty good source. Of course, one of the strengths of GCS was that it searched so many languages at once. Merobase simply doesn't have the same breadth of coverage.

• DZone Snippets is run by the good people at DZone. I love the idea of Snippets but the service is unfortunately undermoderated. And it's more of a public-access repository than a comprehensive search engine.

• Codase is promising but apparently the project was abandoned years ago. Maybe the shutdown of GCS will motivate the folks behind Codase to put the project back on the front burner.

• I like Snipplr too – it's a good source of code snippets. But it searches only code that has been stored at the site. Oh well.

• Search[code] is a terrific site but it has a misleading name. It doesn't really search for code, but for documentation. Of course, the docs often include example code, so the site is plenty useful. It's fast, too. I really like this one.

That's it for me. If you've found a worthy successor to GCS, drop a note in the Comments section.

Web recommendation: Rumor has it that the link I appended to my last post is no longer active. (Don't you wish the Web had technology that would inform bloggers of such events before readers notice?) Anyway, here's a link that may still be active by the time you get to it: Disturbing Article. J.D. say check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.

Writing code is hard. Luckily, the world is full of resources to help us with the task. Books, conferences, seminars, university courses, magazine articles, blogs, Web sites – all promise to teach us how to write programs. But the luxury of writing programs represents, in my estimation, the smallest part of the software developer's career. Far more commonly, we inherit responsibility for someone else's program code. And on this topic, the development experts are lamentably unhelpful.

It's a shame, because this job – maintaining, correcting, documenting, updating, completing, and extending existing code – is much more difficult than writing new programs. It is, after all, harder to read code than to write it.

My first programming job centered around an inherited codebase. I was first called upon to write little patches for the bugs that halted the existing application now and then. Eventually I began adding features. After some months of this, I had a vision of what the app could be if it were fundamentally restructured in a new release. I sold the vision to my employers and got permission to rev the app. It was only after that rewrite was complete that I won permission to create a completely new app.

I imagine this sounds familiar. This is what a career in software development looks like.

It's all wrong, of course. Maintaining and extending a body of existing code is much more difficult than writing new code. We should assign our most experienced and efficient programmers to maintenance. But that would lead to a revolution, wouldn't it? Because we all want to exercise more creativity on the job, and there are more opportunities to be creative in writing new apps.

Search the Web for advice on maintaining an inherited code base and you'll find two sorts of information. You'll get articles that look promising, but turn out to be advice on how to write new code that is more maintainable and extensible – useful, important advice, but not relevant to the task at hand. Or you'll get advice on refactoring.

Don't get me wrong, I'm all for refactoring. But how many of us have the luxury of spending months making small improvements to the underlying design of inherited codebases, without making a single change in the software's functionality? Where does one find such an unlikely confluence of management enlightenment and budgetary largesse?

Years ago, CASE tools promised to read source code and create navigable graphic representations of the code's workings. You could look at a high-level diagram to explore the application's main functionality and zoom in to see the individual modules, classes, functions, and lines of code that instantiated that functionality. I thought those tools had real promise.

Alas, the tools have not kept pace with the reality of modern apps. They worked well enough for applications that were built of a single source-code file. But today's apps, as you well know, are built in modular fashion of libraries, subsystems, Web resources, and code files written in multiple languages. I don't know of a visual tool that can cope with such complexity. (I would be delighted to learn of one.)

So here we are, stuck. We arrive at the workplace full of great knowledge about how to write new programs and find ourselves challenged with a harder task that no one warned us about.

It's just one of the reasons I think our so-called profession is a mess. I'll share more in future posts.

Web recommendation: The good folks at whitehouse.gov – yes, the President's Web site – have added a feature called We the People. It's a page where any user can launch a petition, and where visitors can virtually sign petitions if they find themselves moved to. Officials promise that petitions receiving 5,000 or more signatures will get replies, and perhaps even move the administration to action. I learned about We the People because I got excited e-mail from correspondents who wanted me to sign a petition calling for a ban on software patents in the U.S. I'm not going to post a link to the petition because the proposed ban is not sufficiently detailed, and it is wrongheaded to boot. Software patents do more good than harm. I do appreciate the Obama administration's little experiment at populism, however. We the People may not be the most efficient or well-implemented scheme of getting people involved in politics, but I think its creators have their heart in the right place. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.

What does the future of software development look like? For the first time in decades, it appears that no one knows.

It used to be fairly easy to peek a few years into programming's future. Languages evolved according to a predictable path from lower to higher levels of abstraction. We incorporated objects, then visual development environments, then Web architectures, then managed-code platforms. Development methodologies and project-management philosophies approached with plenty of warning – it took no special insight to see them coming.

My subjective feeling – backed up by a few hours of earnest Googling – is that all of that has changed.

The future? Well, let's see. We have some broad agreement that development methods will become more agile, though we are not entirely sure what agility means. It seems clear that the future will be cloud-oriented, though every definition of “cloud” is different. Our code will need to adapt to the availability of parallel architectures, though we can't say whether the parallelism should or will reside primarily in the code we write, the libraries we incorporate, the tools we use, or the architectures we employ. Security, mobile platforms, portability, interoperability, declarative programming, functional programming...all are likely to be important. One way or another.

As for languages – oh my! At the moment it appears that every nontrivial app will incorporate modules, libraries, frameworks, and custom code written in multiple programming languages. Or maybe we'll resolve that complexity by adopting a new language with the flexibility to address all the challenges we face.

For once, the pundits are quiet. Search the net for predictions about the future of software development and you'll retrieve a list of Web pages that are years out of date and devoted to particular narrow problem or language domains.

We are in need of the same sort of paradigm-buster that object-oriented programming and visual development environments were, back in the Windows era.

Search long enough through all the partisan arguments and language-specific rants, and one name keeps coming up: Anders Hejlsberg.

Hejlsberg has been around the programming world since before the IBM PC. He is the original author of Borland's Turbo Pascal and Delphi, and since he joined Microsoft he has created C# and become director of Microsoft's programming-language strategy.

You can learn more about Hejlsberg and his views in these videos:

• Where are programming languages going?

• Trends and future directions in programming languages

• Tour through computing industry history at the Microsoft Museum

(Disclaimer: Hejlsberg's views are pretty much guaranteed to be the official views of Microsoft. I'm the last person to sign up mindlessly to Microsoft's view of the world. While I don't see the company as a customer-exploiting evil empire, neither do I think it has always acted in the development community's best interests. Although I owned and edited Windows Tech Journal, my relationship with Microsoft was always an arm's-length one – much, as it turns out, to my personal cost. But that's a long story for another day. What I'm trying to say is that you have a responsibility to take Hejlsberg's point of view with a grain of salt.)

I think the Hejlsberg videos have great value. They identify both the challenges facing our community and some of the technologies and approaches that will help us address them. Hejlsberg has proved himself to be a visionary throughout his career, and he is uniquely positioned to see the problems and possible solutions that we will encounter in the next few years.

What's your view of the future? Drop a keyword or two into the comment section below and I'll use your feedback to shape a future post. Because ultimately, the future isn't something that just happens. It's something we create. Together.

Web recommendation: Research for this post brought me for the first time to Microsoft's MSDN Channel 9. This Web site contains hundreds of videos about (Microsoft) technology and how to get the most out of it. There's a predictable amount of corporate flag-waving, of course. But there's also tons of useful content. I have some reservations about video as the medium for dispersing such information – text is more readily searched and recalled, in my view. But there's no denying that there's real value here, for free. And the site has a mission statement you can dance to. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.