Charles has over 30 years experience in consulting, he started out as a developer, moving between various projects before becoming an architect. The projects he has worked on have varied widely; starting out on developing in assembler and writing low-level device drivers for railway signalling equipment to more recently being an architect on large government projects.
Title – What is your job title?
What is your role about?
I worked for a software house, designing large software systems for clients. Each system is built as a project, lasting perhaps 18 months, where we go through the whole lifecycle: specify requirements, design the system, write the code, test, integrate, test again, train the trainers, put into service, support. A large project may have over 100 people on it, though not all developers. Sometimes I would join or leave a project part-way through — typically a project has more staff in the middle. At specification time, if I am not actually writing the specification, my work involves doing feasibility studies and starting the design, and monitoring the requirements to make sure that they are clear and not impossible to implement — checking that the chosen software packages will do what is asked.
The design is done iteratively, adding more detail as we go. The exact method of documenting the design tends to vary from project to project, depending on the views and experience of the senior staff (both client and supplier). It is a mixture of descriptive text and diagrams. The next stage is writing the code and unit tests. I tend to get given peripheral tasks, as I am a bit expensive to be given standard coding. But for peripheral tasks I am good value because I can be relied upon to complete the work with minimal supervision. For example I spent about 8 weeks in one project generating test data for performance testing. Then we integrate the software in staged releases, and get a whole system working. Again I sometimes do peripheral tasks like once sorting out the configuration of the proxy servers. Then the developers tend to move onto a new project, but some of us stay to nursemaid the system, diagnosing problems and fixing them.
At the detailed level the work is varied: sometimes sorting out a mess created by someone else, sometimes doing constructive work. There is a lot of learning — the requirements (sometimes hundreds of pages), how the planned system works, how the products work which make up the building blocks. The output from your work is almost always a Word document as well as code. We are team based, but you usually do the individual tasks on your own.
Almost all projects were either Microsoft-based or Java-based. I went down the Java route. I used Perl for ad-hoc programming.
What are the best/most positive parts of the job/industry?
Doing a design and writing code and seeing it all work. Working on something which is going to be useful in the real world. Working on something large.
You get a lot of variety in a software house, moving from project to project. There is a lot of design work as well as programming, and you may be using several programming languages. The work is always challenging — if it starts to get repetitive, you write a program to make the computer do it.
What are the negative parts to the job/industry?
I never like doing unnecessary work, eg spending twice as long getting something done because a foolish decision was made previously. We all make mistakes, but it still annoys me. For example senior technical architects who know less about the technology than I do, and don’t get on with the things which really need doing, and don’t admit what they don’t know. Poor requirement specifications caused by an unwillingness to accept that they were taking the wrong approach. Incompetent staff generally. Having a whole project scrapped, though I was lucky that this didn’t happen to me very often: in one case I was pleased it was scrapped, as the main architect was going in completely the wrong direction.
What is the standard career path/qualifications?
In my company there was a tradition of having no formal job titles. There was no formal promotion, just a pay rise most years. You only needed a job title for your business card for external use, and in later years they were dropped on cost grounds for staff who were not primarily customer-facing. Generally a project is staffed up with a bunch of people in a pyramid, ie more people at the lower costs, with a range of skills. The people are assigned as required to tasks as the project progresses. You often learn a new skill rather than getting someone in from outside, because you need someone who understands the system being built, which is often very complicated. I called myself a Technical Architect eventually as that was the generally accepted term for someone in my position. I never got a qualification after my BSc.
A lot of programmers become team leaders who manage a team of say 5 people, and do technical tasks as well. More senior managers manage full time. There are many other roles, eg requirements, standards, managing the reviewing process, testing, development environments, training, security, purchasing, hardware.
What are the prospects?
Sometimes it was difficult for me to get onto a project because I was too expensive as a developer, but not experienced enough as an architect. You often do better going into management if you have the skills and enjoy it; I had neither. But in later years I built up a reputation and I was kept fully employed, though earning rather less than others of my age.
In your experience are you aware of any differences your role has between industries/sectors?
I don’t know — I stayed with the same company too long.
Reflection and The Future
What was it like coming into the industry?
I started as a hardware engineer, and it was difficult to find out at interview time what I would be doing. The managers who interviewed me didn’t know where I would be deployed, and couldn’t commit themselves. But I had a good first year. The project was half way through, and they were commissioning the prototype hardware — I held the oscilloscope probe and the senior engineer looked at the circuit diagram and the oscilloscope screen, and told me where to move the probe “The input data looks OK, check the clock on pin 6, yes that’s OK, now the output on pin 10, no that’s stuck at zero” then we would pull the board out and get the magnifying glass out and remove a solder blob. This was a good way of seeing real example designs that worked.
Then I moved into writing specifications, and then into software, almost entirely self-taught.
Do you have any thoughts on the future of your role/industry?
Software houses always play down the amount of bespoke code in a system, because of the perception that bespoke code is more expensive and less reliable than COTS (Commercial off the Shelf) products. But there is, in my experience, always loads of coding to do. So there will always be a place for programmers in one-off systems as well as software products.
What advice would you give someone entering your industry?
My advice is to do what you enjoy. Keep your ears open, make friends with everyone, and you can move in the direction that suits your skills and temperament.
The main mistake I regret was in my last year at university: the professor suggested that I do a special project for/with him, and I turned him down because I thought it would be easier to get a top mark with a taught course. I didn’t realise that the professor would have given me a good mark whatever happened as long as I made an effort. But I expect I would have gone into industry anyway (the alternative was to be an academic).
Have you come across anything or anyone that has helped you move forward in the industry?
Some of my colleagues were inspiring. But mainly I just learnt about the things that I found interesting, and always tried to produce good work.