I don't often met new people and thus question of what I do does not pop up this frequently. But it has been hard to describe what I do to people who are not in the software development community since the first day I started my first job. Normally I just say I am a software developer and that tends to put most people off since they don't understand software at all. To them software is a black box, it is magic, it is voodoo. But every now and then there will be someone who does a bit of Visual Basic Scripting in the office and thinks s/he knows software development. This person would then try to probe deeper about what I actually do. In that situation, I'd have no mercy and just tell the person exactly what I do. 99.99% of the time, eyes would glazed over within 10 seconds and conversation would die as soon as I finish my sentence.
We are developing the build & deploy system for the whole enterprise. That is, a system that allows in-house developers to build their applications and deploy the applications to the machines. Sounds simple but we are also implementing Continuous Integration concept using build servers, trigger off source control checkins. (The main reason ThoughtWorks was brought in as we are known in the industry as build expert, re: CruiseControl)
We are also solving their source and binary dependency problem so applications would be self-contained when they are built, tested, and packaged by the build server. The deployment/install process would allow environment specific properties to be substitute during deploy time so packages can be deployed to multiple environments without going through the build process again. (Build once, deploy everywhere)
Deployment process also includes workflow steps to manage code review/gatekeeper approvals, security audits, and code signing.
All of these are built with extensibility in mind so future technology, such as Ruby, IronPython, can be introduced into the organization via plugins with minimum alteration to the system.
In addition, we are also advising the client on code branching and merging strategy, best development and unit testing practices, dependency management, database upgrades (model and data) using delta scripts, etc.
I also understand people's frustration with Ruby since you often feel like you're in Quebec and have to point at the menus to order food. At best the locals humor you, at worst they hate you and want to seperate into their own country.
One of the responsibility of being a manager is that I have to do job interviews. Our team is on the constant look out for new developers to join our team, partly due to pressure from upper management to staff up for some mythical project that may or may not materialise in the immediate future, but really we want to increase the team's overall skill level by hiring better developers, replacing the lesser skilled ones.
Unfortunately finding good developers is not as easy as one may think despite the large number of available candidates out there. Competent programmers are plenty but good, if not great, developers who are not only good at programming but also able to see the big picture, able to visualise the problem domain space and devise solution that not only solve the problem but also fit with the design, seem very rare indeed.
Most of what we've encountered thus far are mostly the competent type with only a very selected few exceptional developers (we hired them as fast as we could, of course). We organise our interview very much with that in mind. Unlike some of the interviews I had taken myself before, we don't ask the candidate technical/code-related questions. We generally take it for granted that if the candidate has been working in the industry for over 5 years, s/he knows how to code. Rather, we ask the candidates about their views on programming paradigm debates; OO vs. procedural, static typed language vs. dynamically typed language, and business logic in code vs. database, etc.
For example, one of the question that we always ask the candidates is what books have they read that change how they feel about programming or how they see the discipline. The question looks innocent enough and generally we ask the candidates about three quarter way into the interview so most of them don't pay much attention. 8 times out of 10, they would answer with the usual collection of 'how-to' book titles: "Programming with C#", "ASP.NET programming", etc. A few, in fact, did not read any software-related books at all. I don't know about the other manager but if I get that kind of answers, that candidate has just lost the job. Reading 'how-to' books, in my opinion, does not improve ones skill as a developers. Sure the book teaches how to solve problems with a specific language using specific tools, but skills like that can always be learnt in a few weeks if required. Rather, we are looking for candidates that want to elevate themselves from being just a programmer to a more rounded developer. The kind of books that we hope the candidates have read are high level books such as Code Complete, Refactoring to Patterns, etc.
Unfortunately, almost none of the candidates we interviewed read this type of books. This left me and the other manager very puzzled because surely there are outstanding developers out there, looking for jobs. Are they so contented with their current job that most of them are not on the job market? Perhaps because if I were the company who has one of them in my team, I'll do a lot to keep him around.
Or are most programmers out there satisfy with their skills set and are not looking to become a better developers? Is this why most software development projects fail? Do all these big corporations out there realise that they are not getting what they are paying for? Is this why we, the software developers, are still not considered a profession like lawyers or doctors despite the complex skills that we need to develop highly intricate software system?