Hoping to become a programmer
Pages: 12
I became interested in C++ a few months ago. I'm hoping to go to college for Computer Science (maybe?) and become a programmer. What I'm curious about is how many of you work as a programmer or if you just do it as a hobby. I'd like to know how all of you became interested in programming, if you went to college and for what exactly and also where you work (city and company if you would) and what you do. I'm very interested in anything you would like to inform me on. I'd really appreciate any input. Thank you very much.
I became interested in C++ for the sheer thrill of being able to make my own programs and manipulating/modifying other programs. I myself have just started today (couldn't get the compiler working till now :P) so I can't wait to see how this turns out. Whether I completely blow it or succeed, I will still have fun :)
(Hopefully!)
I haven't really considered being a programmer, since I only have just started, so I will have to see how this unfolds.
(Hopefully!)
I haven't really considered being a programmer, since I only have just started, so I will have to see how this unfolds.
I started programming because my fathers computer had i virus and the only thing that was working was QBasic :P
Now I'm trying to learn c++ just for fan or to continue my fathers programming company, if I ever make it to learn because I don't have alot of time to spend on.
You must know that computer programing needs ALOT of hours and many nights to stay until 3 o'clock in the morning to find out that it doesn't work because of a silly mistake. But at the end you are gonna be happy with the result...
Now I'm trying to learn c++ just for fan or to continue my fathers programming company, if I ever make it to learn because I don't have alot of time to spend on.
You must know that computer programing needs ALOT of hours and many nights to stay until 3 o'clock in the morning to find out that it doesn't work because of a silly mistake. But at the end you are gonna be happy with the result...
I have been programming for many years now - started at school as something useful to do for myself, then later became my job.
The main (non programmming) things to learn are
1) Spend time working out what you want the program to do, then how (in outline) it will do it before you start writing the program - the time you spend doing this will be far less than the time you waste trying to get something made up as you go to work the way you finally realise you need!
2) If you can't find a solution to a problem in ~30 mins, take a break, switch to some other problem, etc. then come back a couple of hours later (or the next morning, etc.). Its amazing how many times you do that then look at the code fresh and the bug is suddenly obvious.
3) If you still can't see the problem, ask someone to help - often just explaining the problem and what the code does will enable you to spot the problem, and if not, a pair of fresh eyes often will.
The main (non programmming) things to learn are
1) Spend time working out what you want the program to do, then how (in outline) it will do it before you start writing the program - the time you spend doing this will be far less than the time you waste trying to get something made up as you go to work the way you finally realise you need!
2) If you can't find a solution to a problem in ~30 mins, take a break, switch to some other problem, etc. then come back a couple of hours later (or the next morning, etc.). Its amazing how many times you do that then look at the code fresh and the bug is suddenly obvious.
3) If you still can't see the problem, ask someone to help - often just explaining the problem and what the code does will enable you to spot the problem, and if not, a pair of fresh eyes often will.
I started programming as a hobby when I was a young boy, using from Commodore 64 to Visual Basic in Window 3.1.
Later I started programming some C++, still as a hobby, before I became a Computer Science student in Tromsø, Norway.
I'm now 29 years old, and have one year left of the studies to become a MSc (a 5 year program). I have worked part time as software developer while studying for the last three years, and right now I'm about to start in a new job where I might work full time when I'm done with the degree.
Later I started programming some C++, still as a hobby, before I became a Computer Science student in Tromsø, Norway.
I'm now 29 years old, and have one year left of the studies to become a MSc (a 5 year program). I have worked part time as software developer while studying for the last three years, and right now I'm about to start in a new job where I might work full time when I'm done with the degree.
I also started as a young boy, but I went from Commodore 128 to plain-old BASIC on a CP/M (Z80) and shortly thereafter GWBASIC on DOS (8088). I got interested because my father was in the business. Shortly after I hit the limits of BASIC (I was linking in too much assembly language I figured I'd just ditch the BASIC and use the assembler by itself...) and my dad gave me a copy of Turbo Pascal 4.0 and the manual and my life was altered.
I've done some professional work, but mostly I am a hobbyist. (I plan to teach high-school mathematics for a profession.)
I'd like to take a moment to reiterate what Faldrax said.
Always remember that programming is not sitting at the keyboard and typing stuff in. It isn't compiling and debugging.
It is
1) figuring out how to solve a problem, step by step, yourself, then
2) expressing that solution in terms the computer can understand (since computers are too stupid to know the difference)
Good programmers start out with a piece of construction paper and crayons, or a note editor, and some raw data, and a drawing table, etc. --whatever is necessary to work out the problem in their own heads.
Then they sit down and organize it into a process (much like writing a paper).
Then they tell the computer all about it.
(There are other steps, but those are the big ones.) You can't do it in any other order.
After a while, much like with differentiation, you begin to recognize certain patterns so you can easily apply them to different tasks (sometimes with the construction paper existing only in your head), but the process must always remain the same.
Some people live by their debugger (and there is nothing wrong with it --it is a great tool), but personally I've never had much need for one. If you start out right, you can check that the source does what it is supposed to, instead of not being quite sure what it is supposed to and checking the symptoms of the disease. :-)
I just hope you don't mind having your job farmed out to someone grateful to get paid pennies for work that should pay him much more. (For those of you making the pennies, enjoy it while you can, before it happens to you!)
/end rant
I've done some professional work, but mostly I am a hobbyist. (I plan to teach high-school mathematics for a profession.)
I'd like to take a moment to reiterate what Faldrax said.
Always remember that programming is not sitting at the keyboard and typing stuff in. It isn't compiling and debugging.
It is
1) figuring out how to solve a problem, step by step, yourself, then
2) expressing that solution in terms the computer can understand (since computers are too stupid to know the difference)
Good programmers start out with a piece of construction paper and crayons, or a note editor, and some raw data, and a drawing table, etc. --whatever is necessary to work out the problem in their own heads.
Then they sit down and organize it into a process (much like writing a paper).
Then they tell the computer all about it.
(There are other steps, but those are the big ones.) You can't do it in any other order.
After a while, much like with differentiation, you begin to recognize certain patterns so you can easily apply them to different tasks (sometimes with the construction paper existing only in your head), but the process must always remain the same.
Some people live by their debugger (and there is nothing wrong with it --it is a great tool), but personally I've never had much need for one. If you start out right, you can check that the source does what it is supposed to, instead of not being quite sure what it is supposed to and checking the symptoms of the disease. :-)
I just hope you don't mind having your job farmed out to someone grateful to get paid pennies for work that should pay him much more. (For those of you making the pennies, enjoy it while you can, before it happens to you!)
/end rant
I've been a software engineer for many years now, but starting out as a hardware engineer. If you're doing software engineering professionally, I would say only about 20-30% of the job is actually writing code.
I would also agree with the above comments. Get as much of what your are going to do and how you are going to do it, decided before you attempt to start writing it. Have a strategy for testing it as well, the bigger the project, the more important this is. It may seem frustrating and you may be desperate to start 'cutting code', but rushing into writing code is the mark of a someone who doesn't have deadlines to meet.
Another tip is to write a bit of code and test it, write a bit, test it. Do it in small increments. That way you are more likely to find all the bugs.
I would also agree with the above comments. Get as much of what your are going to do and how you are going to do it, decided before you attempt to start writing it. Have a strategy for testing it as well, the bigger the project, the more important this is. It may seem frustrating and you may be desperate to start 'cutting code', but rushing into writing code is the mark of a someone who doesn't have deadlines to meet.
Another tip is to write a bit of code and test it, write a bit, test it. Do it in small increments. That way you are more likely to find all the bugs.
Duoas: I think you under-estimate the importance of the debugger. While you can plan your solution out 100%, there is always going to be something in the implementation of it that requires some debugging. Especially in C++. Memory leaks are a classic one. I always run Profiling software after each iteration of development to validate against memory leaks and to ensure I have not created some stupid bottleneck code.
benbertha: I think you have it backwards "write code, test"... nooooo :P "write test, code". Test-Driven Development :)
benbertha: I think you have it backwards "write code, test"... nooooo :P "write test, code". Test-Driven Development :)
So you write the test, code it but don't actually run the test :)
Ok then compromise, write test, write code, test code, but still in small increments.
Ok then compromise, write test, write code, test code, but still in small increments.
I didn't say a debugger wasn't important, just that you can minimize its use.
I got a good chuckle though... terms like the following come to mind:
Waterfall Model
Evolutionary Development
Component-based Engineering
Spiral Development
RUP
ack. The list never ends. :-P
I got a good chuckle though... terms like the following come to mind:
Waterfall Model
Evolutionary Development
Component-based Engineering
Spiral Development
RUP
ack. The list never ends. :-P
Bnbertha: agreed :D
Duoas: Some methodologies are pure crap, and they are often adopted by large companies with delusional managers. However, some of them definitely do have their place in the SW world.
Waterfall Model - An old methodology, however due to it's simplicity it's probably the most widely used to this day. Requirements, Design, Develop, Test, Implement, Maintain. Not the best way to do things, but because so few managers actually understand alternative methodologies it's the de-facto.
Evolutionary Dev - I quite like this, as this one fits in with the agile methodology quite well. Small iterations from the beginning offering new functionality each time. This fits almost the same as Component-base Engineering.
In a perfect world. I would always be developing in C++, as an agile developer doing Test-Driven Development, or incorporating Unit Tests after each iteration.
Unfortunately, Management has little-to-no understanding of development methodologies so I (like most devs) have to live with doing different methods for different projects/companies.
Duoas: Some methodologies are pure crap, and they are often adopted by large companies with delusional managers. However, some of them definitely do have their place in the SW world.
Waterfall Model - An old methodology, however due to it's simplicity it's probably the most widely used to this day. Requirements, Design, Develop, Test, Implement, Maintain. Not the best way to do things, but because so few managers actually understand alternative methodologies it's the de-facto.
Evolutionary Dev - I quite like this, as this one fits in with the agile methodology quite well. Small iterations from the beginning offering new functionality each time. This fits almost the same as Component-base Engineering.
In a perfect world. I would always be developing in C++, as an agile developer doing Test-Driven Development, or incorporating Unit Tests after each iteration.
Unfortunately, Management has little-to-no understanding of development methodologies so I (like most devs) have to live with doing different methods for different projects/companies.
Agreed. The loops and nonsense to fit a "scheme" ofttimes occlude the requirements process.
I think (good) programmers like to do things the right way to begin with and ignore extraneous cruft, while (bad) programmers like to schmooze and get promoted. I hate dealing with schmooze, hence my "hobbyist" status... (and the rest have to figure out how to do it right while pretending to do it wrong).
Suits like clocks that tick the same way for every project. It deludes them with a sense of order. Not to be harsh or anything... :-P
I think (good) programmers like to do things the right way to begin with and ignore extraneous cruft, while (bad) programmers like to schmooze and get promoted. I hate dealing with schmooze, hence my "hobbyist" status... (and the rest have to figure out how to do it right while pretending to do it wrong).
Suits like clocks that tick the same way for every project. It deludes them with a sense of order. Not to be harsh or anything... :-P
That's exactly how it is (esp the schmoozers). Unfortunately, alot of the time you will be forced into a project that doesn't allow you the freedom to do the extra best-practice things (Unit Testing for example). Many projects don't even allocate time for a developer to do ANY documentation. That is really how out-of-touch most managers are with software development.
To be fair, market pressures are often the root cause for over-tight schedules. We are inundated with quickly-written software that mostly works well. Anyone who sits on their hands doing it perfect looses the sale to those who don't mind producing inadequately proven software.
Case in point: ATI. Great hardware. Software not worth the bits used to store it.
Lately ZoneAlarm has been crashing my XP every 12 hours.
Etc.
Even industries that require fault-free software for critical systems (nuclear power plants, NASA, etc) aren't immune to over-zealous deployment schedules.
Alas.
Case in point: ATI. Great hardware. Software not worth the bits used to store it.
Lately ZoneAlarm has been crashing my XP every 12 hours.
Etc.
Even industries that require fault-free software for critical systems (nuclear power plants, NASA, etc) aren't immune to over-zealous deployment schedules.
Alas.
Indeed. I am fortunate that I am working for a company where I currently don't have a development manager (have to love skill-shortages in IT atm). Which means I can estimate time, and go forward my own way in development.
I am able to provide the results of something like Unit Tests to the project managers and thus far they have been very happy with the results and software. So going forward (I should be involved in hiring of my boss) I should be able to keep this style of development. Schedules are pretty laxed here too which is definitely a nice change.
I am able to provide the results of something like Unit Tests to the project managers and thus far they have been very happy with the results and software. So going forward (I should be involved in hiring of my boss) I should be able to keep this style of development. Schedules are pretty laxed here too which is definitely a nice change.
I'm not sure whether I should be grateful that it's not just the UK that suffers inept (or yes we can do 2 weeks work in 2 days) management, or saddened that no-one seems to be able address the problem of these people getting promoted into positions of control.
Although with the emergence of the likes of CMMI and ISO 15504 managers are getting dragged kicking and screaming into having to be more software aware, so ignorance is (VERY) slowly being overcome. Unfortunately even CMMI and SPICE can't beat pure ineptitude :P
Although with the emergence of the likes of CMMI and ISO 15504 managers are getting dragged kicking and screaming into having to be more software aware, so ignorance is (VERY) slowly being overcome. Unfortunately even CMMI and SPICE can't beat pure ineptitude :P
closed account (z05DSL3A)
It has been good reading this thread (haven't participated as of yet because of the different time zone, thing seem to be nicely rounded of by the time I get up ;0) )
My first computer was a ZX81! When I left school I trained as a luthier and just 'messed around' with computers. I ended up going to university as a mature student and undertook an undergraduate degree it computer Science (with as much programming as possible).
I work in an R&D department (the only programmer) and get to do all sorts of development from squeezing code in to micro controllers up to services for servers. Evolutionary Development seems to fit nicely with how I like to work, doesnt fit with the QA managers vision of ISO 9000 but I'm working on that ;0). The QA documents are written from a purely physical engineering stand point, they know nothing of software development.
My first computer was a ZX81! When I left school I trained as a luthier and just 'messed around' with computers. I ended up going to university as a mature student and undertook an undergraduate degree it computer Science (with as much programming as possible).
I work in an R&D department (the only programmer) and get to do all sorts of development from squeezing code in to micro controllers up to services for servers. Evolutionary Development seems to fit nicely with how I like to work, doesnt fit with the QA managers vision of ISO 9000 but I'm working on that ;0). The QA documents are written from a purely physical engineering stand point, they know nothing of software development.
Thank you everyone for posting in this thread. I'm enjoying the insight. So I'm figuring I'll major in Computer Science with programming/software engineering? I'm happy that this thread is so popular, so please continue posting. Thanks everybody.
Thank you everyone for posting in this thread. I'm enjoying the insight. So I'm figuring I'll major in Computer Science with programming/software engineering? I'm happy that this thread is so popular, so please continue posting. Thanks everybody.
@bnbertha: Unfortunately, I think software development methodologies will evolve faster than management learns. This is going to be a forever continual problem in SW dev until programmers start taking up management positions. Unfortunately, programmers don't much fancy working in management.
@Grey Wolf: You will be in a situation similar to me. While it's good to have such freedom, working as the sole developer can be quite difficult because you don't have anyone skilled enough to use as a sounding board. But you get to read al ot of articles and play with new tech/methods which is definitely nice.
@Grey Wolf: You will be in a situation similar to me. While it's good to have such freedom, working as the sole developer can be quite difficult because you don't have anyone skilled enough to use as a sounding board. But you get to read al ot of articles and play with new tech/methods which is definitely nice.
Pages: 12