Plus ça change

Hello, and welcome to Overload 85.

Here I am, a newish face at the helm, and this time not as a one-off guest editor. Alan is bowing out after quite a few years, leaving Overload in excellent shape. I'd like to thank Alan for all his work - being editor is one of those jobs where people don't really know exactly what's involved, so it's not given the recognition deserved. But after talking to many people at the Conference about my taking over, it was clear just how much people enjoy the journals and rate them highly, even more so in a world where many other computing magazines have stopped publishing. He can be rightly proud of what he has achieved.

What's in a name?

Talking of jobs, I had an embarrassing moment on accu-general the other week. A couple of people had been mailed by an agency about a contracting job, but part of the description amused one so much that they posted it for discussion. It read:

This is not a Web Application Developer role, nor a Programming role. This is a position for a Software Engineer.

What a strange turn of phrase! Even more intriguingly, it was in my local area, so I asked those who'd received it who on earth it was for. The embarrassing part turned out that this was not just about a job at my current employers, it was for a contractor doing something pretty much identical to my job. Looks like I'm not a programmer after all.

The phrase had actually come about because our recruiter was trying to explain to an agency what sort of role it was, and was having trouble getting them to understand that it wasn't a web 2.0 application or whatever - the above was the final frustrated attempt after they still hadn't grasped it. Unexpectedly the agency just wrote it down and used it verbatim in their mail shots.

But it did get me thinking about how we describe our jobs, in the software industry in particular, and how it has changed over the years. For example, in my first job, I was a plain old 'Programmer'. This was fair enough as it was the main part of the job, but it wasn't the only thing I did. There was also talking to customers to gather requirements, architectural decisions, software design, programming, build systems, testing, on-site installation, graphic design, and digitising maps (at which I freely admit that I was rubbish). This wide range was helped by it being a small firm, so everyone just mucked in to do what was needed - in a larger place you'd tend to have different people dedicated full time to these different tasks.

Since then I've been a Software Developer, a Software Engineer, a Risk Developer (which sounds excitingly edgy, but in fact referred to the sort of software - Financial Risk Models - that was very much not exciting until the sub-prime crisis happened), and currently back to a Software Developer. Other job names I've seen include things like Architect, Analyst, Field Application Engineer, Release Engineer, Build Manager, Scientist, Consultant, Web Developer, Technologist, and even Evangelist. Then these root names often get tagged with some sort of grade or title, and I've seen ones like Graduate, Junior, Senior, Principal, Lead etc. and sometimes a tag to describe the product or field, such as my Risk Developer, or Materials Scientist.

So what are these names trying to describe?

Well, those Junior/Senior type labels are trying to indicate what level of experience, and more importantly, responsibility, people have. One thing to be careful of is that they can't refer to age or years of experience - that's now illegal. Instead I think of them as describing what sort of tasks, decisions, and responsibility the role demands. They can sometimes be a rough label, or come from a more detailed and formal grading system where these labels describe a certain level.

Some try to describe the product, science, or technology area you're working in, hence things like 'Risk Developer', or 'Materials Scientist'. These tend to occur when the area is rather unusual and a particular expertise is needed. Other names could describe a particular area of responsibility, for example 'Build Engineer', but this only works when you're concentrating on just that one niche, whereas most jobs cover a range of technology and roles.

Fashion plays a part too, evidenced by the changes from 'Programmer' to 'Developer' to 'Engineer' and back to 'Developer'. I think I'm happiest with the term Developer - it's what I do, it doesn't describe the details of how I do it, or limit the tasks to just programming, and it doesn't try to elevate it to precision engineering, or worse, a science.

This theme crops up periodically on accu-general - is what we do 'Engineering', or is it a 'Craft', or even 'Art'. Personally, I tend to favour thinking of it as a 'Craft' with parts of engineering involved, based on some theoretical underpinnings that could be described as a science. I justify this view partly by comparing what we do to how people design and build buildings - you need structural engineers to make sure your foundations are good enough and so on, but the people who actually put things up, make the tweaks so that things fit, and the people who adjust the building over the years of use are not engineers - they are much closer to the artisan craftsmen, with years of practical experience of getting things done, and enough knowledge of when to go back and check with the engineers. Craft doesn't imply 'slapped together' though - the best craftsmen build with great skill and elegance, making things that cope well with the inevitable adjustments and changes to requirements. They just accept that not everything has to be perfectly engineered, and in fact would argue that having it too perfect leads to over-optimized brittleness - things change and what was once just right is no longer adequate.

So how good are these names? Well it depends on what you are trying to describe, and who you are describing it to.

We started with a job spec. This is trying to describe two different things - it comes from what the company wants the employee to do; but also it's trying to describe the sort of people who might be suitable for the role, which is much broader and seems surprisingly hard to describe in practice. After all a job advert should be getting people to think 'I could do that', and 'That sounds interesting'. This is going to be a combination of selling the product or company, and roughly describing the role so that the reader thinks they're suitable - but beware of too detailed a description as you'll put off people because they no longer think that they fit.

Then there's the job title once you're in it. This is mainly so that other people know what your expertise and responsibilities are, and for HR to grade you so you get paid enough (although they'll most likely do that with a much more detailed scheme of which your job title is a reflection). As such I don't think the details are actually that important, although some people seem to take it very seriously.

And then there's on your CV, when you're trying to sell yourself to a prospective employer who is trying to match you to a role. Here's where your job title has some importance as you want to sound responsible and multi-talented, but not too specific which would make it sound like you'd only be able to do exactly the same again. And surely worse are those weird job titles where you haven't a clue what they did. You can go into details of the job in the rest of the CV, but the job title is the headline to get the reader's attention.

So how does the original job description phrase fare against these criteria? Well, it isn't developing web applications, so it would have been bad to describe it so incorrectly. A programming role? That's certainly a part of it, but not exclusively so this would be too limited a description. A 'Software Engineer'? Although I don't think software is really an engineering discipline - I would prefer 'Software Developer' (which is in fact the real job title) - this terminology is quite common for this type of wider role, and it works quite well describing it for advertising, HR, and CV purposes.

Not quite so embarrassing after all.

Back in the real world

But there's more to life than your job, and things have been happening in the outside world.

The OOXML standard finally got approved and renamed OXML and is now officially ISO/IEC 29500, which has caused some controversy in certain quarters. There's lots of comment online so I won't add to it, but did notice that one issue seemed to be the voting-in of lots of last minute changes to a very large document (one report mentioned thousands of changes to a document that is several thousand pages long), which has the odd result that the de facto file format that it was meant to standardize is now incompatible without lots of changes! See [ Brown ] for one such test. With something that big and important, I have to wonder whether fast-tracking was the best way of getting a good quality standard.

This is in stark contrast to the other big standardization process that will be of interest to many of you - the new version of C++ [ WG21 ]. This has been proceeding steadily for the last few years and is now on the final stretch. There's a draft version of the new standard [ N2588 ], which is now around 1254 pages - up from around 800 in C++98 reflecting the extra features. Searching the web will find various compilers that have some of the new features implemented eg ConceptGCC [ Concept ] and have been used for 'road testing' various ideas. My understanding of the timetable is that the standard is pretty much 'feature complete', then there will be revisions and 'bug fixes' for the following 18 months, and it is due to be finally approved around December 2009. I'm pleased to say that several ACCU members are heavily involved in this process and have been giving talks at conferences and local meetings to update people on what's in it. There seems to be a lot of interest, and I fully expect Overload will be covering many of these new features in depth in the run up to standardization. Watch this space.

References

[ Brown] http://www.griffinbrown.co.uk/blog/default.aspx#a3e2202cd-59a3-4356-8f30-b8eb79735e1a

[ WG21] http://www.open-std.org/jtc1/sc22/wg21/

[ N2588] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf

[ Concept] http://www.generic-programming.org/software/ConceptGCC/

Postscript

Just before publication I checked my job title: my business card says 'Senior Development Engineer'...