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>!