You are here:

C++/jobs with c++




i just have a question related to jobs in
computer science, not c++ itself
i have decided to ask u because u have a lot of experience
in the programming field

as a student, we r given assignments such as
multiplying matrices, create pointers, linked lists
and all of that, but most of those operations are
already available in the c++ libraries

so what does exactly a professional programmer do?
i suppose we r not going to get paid by writing
code that is already written!!


Take any piece of software - an application, an add on, an operating system, a device driver. Each of these will (in most cases) have one or more teams of people working on them.

And these are just the pieces of software you see day to day. Many electronic devices these days contain embedded processors and each of these will require some sort of software.

Certain organisations maintain their own in-house systems - banking, financial, stock control, order processing, payroll, billing etc., etc. etc.

Some of the things you mention can be considered as part of your tools box. So it is like asking:

   We have built a hammer and a screw driver, but I can buy these at any good DIY store so
   what is left to do?

Oh and yes you may get to create something that already exists. It may exist for compiler abc but not for some new compiler xyz. It is more likely that the makers of compiler xyz will ask a library developer to modify their product for use with compiler xyz (for a fee of course). But someone has to write and maintain (see below) these things, just as with any other software.

All projects tend to have two main phases in their life time: The initial creation phase and the maintenance phase. The ratio of time and effort expended on these phases is often quoted as (another) case of 80/20 - 80% of the time is spent maintaining existing software and only 20% creating it.

So you are most likely to perform some sort of maintenance on existing software than work on a green fields (i.e. totally new) project. This is especially true if you are just starting out (even if you are experienced you may start out at a new job doing some bug fixing to get you acquainted with the code base and local procedures etc.).

Let's take as a real world example some work I did for a client, with no specifics (as I am under similar constraints to non-disclosure agreements).

The initial problem was to port a large, existing, well established set of code that ran under one operating system using one set of libraries and frameworks so that it would run natively under the same operating system and another operating system. The ported application would have equivalent functionality as the original but with some look-and-feel differences to cater for the different operating system GUI conventions as well as a bit of a general tidy up.

I worked with a team of about half a dozen people with an approximate 50/50 split between full time staff working for the client and short term contractors like myself. Only two of the full time staff had any prior knowledge of the existing code base and how and what it should be doing.

My first order of the day (as usual with new work) was to get the project build environment setup on a workstation (in fact getting desk, workstation etc, can sometimes be _the_ first order of business). This involves ensuring all tools and libraries are available, that I have access to required services and the tools are set up correctly. This usually takes a day or so to get sorted. Some places are better than others.

The first order of the day on the project (which had been sorted out when I arrived on the scene) was to determine a set of conventions for the overall shape of the software - an architecture. This had to separate the functional parts (business logic) of the code from the user interface parts using the operating system GUI/GUI frameworks required. The existing code had not been implemented in this fashion so each section had to be teased apart into GUI parts and functional parts and re-worked to fit in with the new architecture.

This was a task myself and most of the other people on the team worked at. Only one person was tasked to make the results work on the new operating system. This shows how much work is involved re-working and tidying code bases that have accreted (as it were) over several years and have lost a lot of their structure and are no longer documented in any useful way - in fact no-one had a complete understanding of all parts of the code.

In doing this I required a good understanding of (among other things) the tools I was using, C++, the C++ standard library, the specifics of the actual version of C++ in use (as compilers and libraries have limitations and bugs and sometimes non-standard extensions), the operating system API and framework used for the existing application we were porting and the ability to read and  understand often badly structured code and determine what was needed to transform it from its existing form to the required form. In addition, as the application was a GUI application, knowledge and experience of GUI resource management (dialogs, menus, icons, bitmaps, etc.) was required.

Some time later I was asked back to help with fixing bugs for the version that ran on the original operating system. This task was slightly different. The bugs were logged using a bug tracking tool with descriptions and severities. I would tackle them mainly in order of severity - most serious first, although while getting up to speed each day over my initial coffee I would tackle simple bugs such as spelling mistakes on dialogs. Some bugs required quite a bit of research in the code (reading the code, using debuggers etc.) and planning to fix (not always on my own). Other bugs were quite straight forward. Others required me to ask questions as they concerned what the client needed the application to do and I needed to ensure I understood the requirements.

Note that while working on such code bases you will have to work with others. This means that control over how changes are made has to be taken. This generally involves using version control systems to handle code base repositories (examples are: Subversion, Bazaar, git, Mercurial, CVS, Microsoft team system, Perforce, Starsystem, Clearcase, Microsoft Visual Source safe, PVCS, RCS, SCCS).

At the end of the debugging work I was asked if I would like further work on a completely new project. This was very different again. My first task was to produce a prototype with one other person. This was code for applications that had very limited usage and life time. Even so the task was large enough that quite a bit of thought and care needed to go into it. The code was placed under version control for example. We re-used as much existing code from the client's other projects as possible and built what was required on top of this code. The project required coordinating processing between several PCs in a very specific manner. For this some sort of remote request system utilising networking, threads and synchronisation was required: again we built on available facilities.

Next I joined the main project work. This was still at the specification stage so involved many meetings, documentation, UML diagrams etc. to bash out what was required. During this phase we realised that C++ would not be the best language to use for much of the system and that Microsoft .NET would be a better fit (in fact we settled on C# but VB .NET could also have been used I suppose; I did look at managed C++ but rejected it as too fiddley). This was despite the fact none of us were really up to speed on .NET. The system required a specific server applications, client applications, use of a database etc.

Finally, just a hint here:

When communicating with people you do not know I suggest you take the time to type sentences and words out in full preferably with adherence to the rules of grammar. Do not use text-messaging or other abbreviations. Do capitalise the first words in sentences. Do spell check your text. Do read it back. It did not impress me (I thought yuck! as I read your question) and it will not impress prospective employers. On the other hand a certain number of typos will still get through <g>!  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.