Title: Editorial

As C Vu moves toward the future, it is changing in a number of different ways. This goes some way towards excusing the dreadful joke at the top of this editorial. (There are reasons why I edit a technical journal rather than writing amusing weekly summaries of popular television shows, and my sense of humour is not the only one!)

C Vu is changing in terms of people: you'll have noticed the apparent disappearance of Francis Glassborow from the editor's role at the start of this year, but as well as contributing a regular column Francis has still been hard at work behind the scenes as C Vu's production editor during this transitional time. Pippa will pick up that job from the next issue - she's already been doing the equivalent job on Overload for a while. This will relieve Francis from the effort of taking the lump of material I pass to him and turning it into the journal you hold before you, and leave him time to do other things including writing his regular C Vu column; hopefully it will continue long into the future. This issue's instalment covers a wide range of issues, including some directly related to software development and others which ought to concern all of us who work in the broader context of the IT industry.

Putting the people to one side for a minute, another way in which C Vu will be changing over the rest of this year is in terms of content. There's no plan to drop any of the existing scope, but the ACCU is now covering more ground than ever before, and it's fitting that a Python section should make an appearance in C Vu from next issue. It's often recommended that programmers ought to learn a new language each year to keep ourselves open to new ideas. Maybe Python can be your next language. Watch this space to find out. There will also be some Java coverage. It's been the intention for some time now to include Java, but that depends on the submission of articles. I'm happy to say that some Java material has appeared, and will be making its way into C Vu soon. Not everyone will be interested in all of this new material, but please do have a look, and tell the authors either directly or via <editor@accu.org> what you think. The blend of articles is intended to reflect the interests of the readership. If you want to influence it, you can do so by either (a) suggesting what you would like to see, or (b) writing articles yourself.

With a complete new editorial team in place for next issue, we can (and must) look at how C Vu works for its authors and readers. My thanks go to the authors who have been patient with me so far this year, but now it's time for them to get in touch and tell me what could or should be done better. I'm already aware, thanks to feedback, that a consistent process for getting feedback to authors is needed, and I plan to describe a first pass at that both here in print and on the ACCU web site soon.

Which brings me [oh-so-neatly?] to the question of the composition of the readership of C Vu. We know how many copies go out, and where they go. We don't know exactly who reads them, and even when we do have names, we don't have a lot of information about our readers except that they have some kind of interest in software development in general and probably in C and/or C++ in particular. Some of our readers participate on the ACCU mailing lists or come along to the ACCU conferences when they can, but if we assumed that all of our readers are the same we'd be wrong. For many of our members, programming was originally a hobby and happily turned out to be a viable career path. For some, it's a second career. Maybe there are others out there for whom programming in C or C++ is not a central part of their work, but rather a tool to accomplish some purpose. For such people, the quest to understand many of the dark corners of these programming languages is not important. They will rightly focus on knowing how to keep in the well-lit areas, and to get the job done. There might be pleasure in taking two days to sculpt a beautiful program which will compute something complicated in seconds using smart algorithms, but if it is to run once only and a simple brute force approach which could be coded in an hour would run in 24 hours, we should recognize that good engineering practice might prefer the less elegant code. I would be interested to hear from members for whom software development is not a central part of their work or study. How do you view the programming part of your life.

Why do I bring up the subject of our invisible readership? There is a tendency to make assumptions based on the observation that the people most actively involved in the ACCU are largely those who have a very strong interest in learning technical details. This can lead to two things: firstly, we can assume that this is representative of the whole ACCU membership, and secondly we could follow the stereotype that those who have a strong interest in technical issues don't have any leaning towards business or human issues.

The first is just wrong, and could lead us to effectively exclude many of our members by failing to take account of their needs. The second is not only wrong but dangerous. Professional software development cannot focus only on technical issues; they may be some of the most interesting and tractable, but we develop software for people to use and in most cases those people are not other programmers. Most software is developed to solve problems for people. So, while C Vu will continue to focus on technical issues, don't be backwards in submitting material covering wider issues: what is the real goal when you write software, or what are the human causes behind problems in your software development process. Part of maturing as a software developer is knowing when to focus on the technical side of things and when to step back and look at the big picture. Sure, it does matter if you use a consistent indentation style or give your objects meaningful names - but it matters much more that the code you write makes life better for some group of people, and that your work enhances your own life. Step back once in a while and consider doing things differently, and indeed whether changing some of the aims and motivations of your project or your organisation would make it better.

By all means let's continue to meet up in public houses and debate the best alternative to malloc/free in C++ or how to simulate OO in C, but don't forget that the most important things in such a debate are the people (and possibly the beer). Certainly I will look forward to setting some of you straight on the One True Brace Placement Style over a beer in the near future. With enough liquid encouragement we can all walk away thinking that we won the argument, and carry on coding just as we always have.