The life of a programmer...
Hi, I'm just a kid who's considering which career to choose when I grow up. I've heard a couple negatives about C++ programming... Mostly that sitting in front of a computer all day is bad for your health and that you can get called at irregular times. Is this true? Is it a big problem for you or is it alright?
| I've heard a couple negatives about C++ programming... |
The language you use, be it C, C++, C#, Java, Delphi or another is only 10% of the job. You are a software developer, and there are lots of other things you need to do as part of your job.
| Mostly that sitting in front of a computer all day is bad for your health |
Breathing the air in most major cities is bad for your health. So is too much, or too little exercise. It's all about moderation and keeping a healthy body/mind in your life in general, not just work.
| you can get called at irregular times |
Yes. Alot of jobs require an on-call component to them. This is similar to being a Doctor. Your knowledge is required when major critical systems have issues (and they usually do in the middle of the night :P). Some jobs don't have on-call, but many larger companies that run real-time systems or large data storage systems do. (e.g Hospital, Gambling Agencies, Telecommunications).
| Is it a big problem for you or is it alright? |
Personally, I hate being on-call. You can't leave town (Unless you have guaranteed access to net) and you don't get paid fk all extra for it too. I have turned down a job that wanted me on call 1 week out of every 4. 1/4 of my life on call, no thanks!
Now, I work at a job that I do not ever have to be on call for :) Much better for me.
Last edited on
I've never worked in an on-call environment purely as a programmer. I have as a combined sys admin/programmer though. In an ideal world on-call programmers shouldn't really be necessary, if it is then there is usually something wrong with the way the company work. On call is usually in response to a problem on mission critical systems. If a programmer can do on the fly changes on mission critical systems then there is something wrong with the way the company's configuration management works. If a programmer needs to do on the fly changes then what is being changed wasn't properly tested before installation/release.
Like I said sys admin is a whole different ballgame or a job where you cover both roles.
Like I said sys admin is a whole different ballgame or a job where you cover both roles.
@bnbertha: Almost correct.
Typically, when you are working on large systems (especially clinical/financial) there is going to be nobody with the expertise of software, and knowledge of the systems than a programmer. Programmers are typically 3rd or 4th level support (so some sht must really hit the fan before they are called).
We don't do on the fly code changes, but we try to isolate the problem and propose a work around until it can be fixed. This may involve immediate rollbacks of changes that may have been done earlier that are causing the issue etc.
Even if the software developer isn't proficient in that specific software; their understanding of software development is usually relied upon to isolate the cause of bugs so they can be explained to the vendor (many vendors want detailed information about the bug, including logs, samples etc) or provide possible work-arounds until it can be resolved.
As I often say, knowing a language and coding is typically 5% of the job :)
Typically, when you are working on large systems (especially clinical/financial) there is going to be nobody with the expertise of software, and knowledge of the systems than a programmer. Programmers are typically 3rd or 4th level support (so some sht must really hit the fan before they are called).
We don't do on the fly code changes, but we try to isolate the problem and propose a work around until it can be fixed. This may involve immediate rollbacks of changes that may have been done earlier that are causing the issue etc.
Even if the software developer isn't proficient in that specific software; their understanding of software development is usually relied upon to isolate the cause of bugs so they can be explained to the vendor (many vendors want detailed information about the bug, including logs, samples etc) or provide possible work-arounds until it can be resolved.
As I often say, knowing a language and coding is typically 5% of the job :)
@Zaita
It's funny you should mention clinical because that's the area I work in now. Maybe our sys admin team are better than average, they do have a good understanding of the software at a system level and get called out fairly regularly. Our systems are vast well into millions of lines of code running on Solaris boxes and we have to write our software to be robust and with redundancy. To the best of my knowledge, software engineers get about one call a year at home and I can't remember anyone ever having to actually go in.
We do occasionally get involved in having to find a temporary work around while the permanent fix is written but even that only occurs once every few months.
i would say code is about 20% rather than 5% but it is certainly well less than half
It's funny you should mention clinical because that's the area I work in now. Maybe our sys admin team are better than average, they do have a good understanding of the software at a system level and get called out fairly regularly. Our systems are vast well into millions of lines of code running on Solaris boxes and we have to write our software to be robust and with redundancy. To the best of my knowledge, software engineers get about one call a year at home and I can't remember anyone ever having to actually go in.
We do occasionally get involved in having to find a temporary work around while the permanent fix is written but even that only occurs once every few months.
i would say code is about 20% rather than 5% but it is certainly well less than half
Last edited on
@bnbertha: What sort of clinical systems do you guys run? At a hospital?
I was unfortunately working a local hospital, who had alot of vendor systems tied together with their own code. At times it'd be communication links between the many many different applications that caused problems. The System Admins had no knowledge of these links, so they had to have programmers on call.
The job I turned down because of the 1/4 on-call was for a company that does national gambling software and systems (incl TV Channels) for betting etc. The programmers weren't often called, but they had to have them on-call j ust in case.
Now, I work for Science Org. When I go home, I go home :P Nuff said til I am back in the Morning (or Monday :D)
I was unfortunately working a local hospital, who had alot of vendor systems tied together with their own code. At times it'd be communication links between the many many different applications that caused problems. The System Admins had no knowledge of these links, so they had to have programmers on call.
The job I turned down because of the 1/4 on-call was for a company that does national gambling software and systems (incl TV Channels) for betting etc. The programmers weren't often called, but they had to have them on-call j ust in case.
Now, I work for Science Org. When I go home, I go home :P Nuff said til I am back in the Morning (or Monday :D)
Last edited on
@Zaita
No, not in a hospital. We hold and process a lot of clinical data for drugs trials. Because of the global nature of the trials and the timezones, the system never sleeps.
If we didn't have such a stringent development and validation processes, I should think software people would be called out quite a bit.
No, not in a hospital. We hold and process a lot of clinical data for drugs trials. Because of the global nature of the trials and the timezones, the system never sleeps.
If we didn't have such a stringent development and validation processes, I should think software people would be called out quite a bit.
Last edited on
Topic archived. No new replies allowed.