One of the most beneficial classes I had in college was an Object Oriented programming class that used a book written by the professor, and taught the fundamentals of Object Oriented programming through C++ and Java...at the same time. We didn't learn Visual Studio IDE, Eclipse, EJB, or whatever...we learned command line compilation and JIT, and we learned how these technologies made a difference. When I got out into the real world, I had to learn an IDE and apply my knowledge taken from this class and apply it to Microsoft and Mac kernels.
Since I chose to go with C++ out of college, no one looking for Java programmers want to talk to me. But it's the same thing. I can debug Java just as easily as I can C++.
The problem is obvious by reading some of the comments for this post. The people that you have to impress want you to have experience with specific tools. To impress and test yourself, it's better to have a full understanding of why this tool exists in the first place, so that you will be able to use it to it's full potential. If you want to teach multimedia, then teach multimedia. The tools are there to make their lives easier. If you want to teach tools, then unfortunately, it sounds like you'll have to make a better case for getting the tools to the suits in charge.
But with a Computer Engineering degree from a ranked school. I wanted to develop FPGAs, but there were no jobs for B.S.'s with low GPAs, so I had to make myself marketable and have a good time doing it. Most of the jobs where I was living (due to finances) only hired M$ programmers (vomits on shirt), so I learned how. I learned VC++, C#, VB (vomits again), the registry, the messaging stack, etc. I did most of this on my own through reading books and trying things, but I'm still learning. That's the point. I'm at my third job, and this one I'm going to stay at because I like it. The difference between when I started and now is my confidence. Even if you don't know how to "program" or whatever, you should understand that with the education and experience you have, you will not have a difficult time changing that.
So, now, when I'm asked if I can do something, I always say "yes", because I can...even if I don't know what I'm doing at first. Getting your masters will help you land a "sweeter" job, but I'm making more money than any of the masters kids with the same experience as me because I'm not specialized, I can do what they do (maybe not as well), but I can also do things that don't involve programming like (ZOMG) talking with customers and writing requirements that suit their needs.
No programmer is perfect in their code, and they're all learning new things. Books, groups.google.com, peers who wrote an application you liked, OSS, etc...use all of these resources to go where you want. It just takes time and (for me) a positive attitude towards it. Good luck!
Pre-college...the coolest thing I ever built was a guitar. It was a kit, and it worked...I felt like a God, but then I realized I was a little boy with no real experience in life. So I went to college.
Everything I built in college was very cool at the time, be it a compiler from scratch, a uC in VHDL burned on an FPGA, or that synthesizer that used new sound generating algorithms and used 1/4 of the memory of production digital synths, and was just as fast.
However, the coolest thing(s) I've built have to be things that happened after graduation. I made a machine that opened and closed car doors an average of 7 times a minute for 7 days straight. I had a plethora of sensors, and reporting software, etc. It's being used a major auto test facility for durability testing. At the same job, I designed and built a battery charger/discharger that could charge or discharge at 4A at 50V for an unlimited amount of time....POWER was put into this thing, it was great.
I'm working on something right now, that I would love to talk about, but unfortunately cannot.
Ok, my ideas may be a little juvinile, but specific programming instructions that will work in the testing phase:
1. Find the error message possiblities with every function you call and handle them with try/catch. 2. Implement a timer that will send a message every x seconds after you start it. Start it before every loop, and stop it after the loop completes. If the loop turns into an infinite loop, your timer will throw an error message (with should be handled) in the function body of that loop. 3. To keep all of your modules seperate, either use managed code, or just write an if statement checking for its existance. If it's not there, let the user know so they can fix the issue.
If you can program in these three things, it will be up to the user to respond to problems, rather than the programmer. Once you've tested this application, you'll probably have a good understanding of what responses the user still has to make on a regular basis, and program those in as well.
It's all about making sure you know all of your specifications, making designs that will work within the design, as well as work without. If you can test all design modules to a point where the programmer and user will agree on its functionality, you should be in a good place to sandwich test with another couple modules.
Checkout IEEE software engineering docuements for help with design and testing ideas.
Slashdot Mirror
One of the most beneficial classes I had in college was an Object Oriented programming class that used a book written by the professor, and taught the fundamentals of Object Oriented programming through C++ and Java...at the same time. We didn't learn Visual Studio IDE, Eclipse, EJB, or whatever...we learned command line compilation and JIT, and we learned how these technologies made a difference. When I got out into the real world, I had to learn an IDE and apply my knowledge taken from this class and apply it to Microsoft and Mac kernels. Since I chose to go with C++ out of college, no one looking for Java programmers want to talk to me. But it's the same thing. I can debug Java just as easily as I can C++. The problem is obvious by reading some of the comments for this post. The people that you have to impress want you to have experience with specific tools. To impress and test yourself, it's better to have a full understanding of why this tool exists in the first place, so that you will be able to use it to it's full potential. If you want to teach multimedia, then teach multimedia. The tools are there to make their lives easier. If you want to teach tools, then unfortunately, it sounds like you'll have to make a better case for getting the tools to the suits in charge.
But with a Computer Engineering degree from a ranked school. I wanted to develop FPGAs, but there were no jobs for B.S.'s with low GPAs, so I had to make myself marketable and have a good time doing it. Most of the jobs where I was living (due to finances) only hired M$ programmers (vomits on shirt), so I learned how. I learned VC++, C#, VB (vomits again), the registry, the messaging stack, etc. I did most of this on my own through reading books and trying things, but I'm still learning. That's the point. I'm at my third job, and this one I'm going to stay at because I like it. The difference between when I started and now is my confidence. Even if you don't know how to "program" or whatever, you should understand that with the education and experience you have, you will not have a difficult time changing that. So, now, when I'm asked if I can do something, I always say "yes", because I can...even if I don't know what I'm doing at first. Getting your masters will help you land a "sweeter" job, but I'm making more money than any of the masters kids with the same experience as me because I'm not specialized, I can do what they do (maybe not as well), but I can also do things that don't involve programming like (ZOMG) talking with customers and writing requirements that suit their needs. No programmer is perfect in their code, and they're all learning new things. Books, groups.google.com, peers who wrote an application you liked, OSS, etc...use all of these resources to go where you want. It just takes time and (for me) a positive attitude towards it. Good luck!
Pre-college...the coolest thing I ever built was a guitar. It was a kit, and it worked...I felt like a God, but then I realized I was a little boy with no real experience in life. So I went to college. Everything I built in college was very cool at the time, be it a compiler from scratch, a uC in VHDL burned on an FPGA, or that synthesizer that used new sound generating algorithms and used 1/4 of the memory of production digital synths, and was just as fast. However, the coolest thing(s) I've built have to be things that happened after graduation. I made a machine that opened and closed car doors an average of 7 times a minute for 7 days straight. I had a plethora of sensors, and reporting software, etc. It's being used a major auto test facility for durability testing. At the same job, I designed and built a battery charger/discharger that could charge or discharge at 4A at 50V for an unlimited amount of time....POWER was put into this thing, it was great. I'm working on something right now, that I would love to talk about, but unfortunately cannot.
Ok, my ideas may be a little juvinile, but specific programming instructions that will work in the testing phase:
1. Find the error message possiblities with every function you call and handle them with try/catch.
2. Implement a timer that will send a message every x seconds after you start it. Start it before every loop, and stop it after the loop completes. If the loop turns into an infinite loop, your timer will throw an error message (with should be handled) in the function body of that loop.
3. To keep all of your modules seperate, either use managed code, or just write an if statement checking for its existance. If it's not there, let the user know so they can fix the issue.
If you can program in these three things, it will be up to the user to respond to problems, rather than the programmer. Once you've tested this application, you'll probably have a good understanding of what responses the user still has to make on a regular basis, and program those in as well.
It's all about making sure you know all of your specifications, making designs that will work within the design, as well as work without. If you can test all design modules to a point where the programmer and user will agree on its functionality, you should be in a good place to sandwich test with another couple modules.
Checkout IEEE software engineering docuements for help with design and testing ideas.