ITT's SAP -- Acceptable/Useful?greenspun.com : LUSENET : Joel on Software : One Thread
I'm a power computer user fresh out of high school and entering ITT Technical Institute's Software Applications and Programming class in 10 days. As my career goal is to be a programmer, I thought I'd ask you guys.
Based on the curriculum that covers 2 years/8 quarters, how.. I suppose the word is 'marketable' will I be? I've already had a little programming experience and understand the logic of it well. Will I reach, or at least move towards, my goal?
-- Anonymous, June 09, 2001
Since ITT is not a four-year college, some companies might be filter out your resume. That will be their loss, but it is also reality. My brother went to Heald and he felt short-changed. I don't know how Heald's program compares to ITT's. However, the ITT curriculum you listed looks pretty thorough.
My advice is: network, network, network! I don't mean "computer networks", I mean making real-world contacts. :-) Since ITT is a "professional" school, some students might already have real-world work experience and are looking to upgrade their skills or to get a degree to make their knowledge "official". Try to befriend these students and work together with them on your programming projects!! You'll learn technical details in your classes, but you'll learn what's real-world skills from students with work experience!
I would also highly recommend finding a programming internship, if possible. Remember your fellow students that already have jobs or real-world experience? Ask them about internships or jobs at their company! They already know you're a good student, so they might give you a good recommendation. An internship is like a really long job interview. It lets you get your foot in the door and show them your skills. Many companies offer their student interns full-time jobs after they graduate.
Friends with jobs = foot in the door for internship, Internship = foot in the door for job!
I would also recommend reading programming books outside of class. I *highly* recommend Steve McConnell's book "Code Complete: A Practical Handbook of Software Construction", which covers the fundamentals of programming. His other books are not as groundbreaking, but his book "Rapid Development: Taming Wild Software Schedules" is good detailed look at the management of software projects. Both of these books are huge intimidating tomes, but they are filled with tons of real-world help.
If you have good programming skills, but have trouble finding a developer job after you graduate, you should consider working as a programmer in a testing or QA (quality assurance) group. Without much programming experience, I used a QA programming job as a stepping stone to a development job.
Good luck! Chris
-- Anonymous, June 10, 2001
I forgot to mention Steve Maguire's book "Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs". This book won't teach you how to program in C/C++. Rather, this book is about writing professional-quality C code, with good design and testing. I would say this book is "required reading" for anyone doing C/C++ programming! :-)
-- Anonymous, June 10, 2001
Argh! I take issue w/"Writing Solid Code". Many of the examples are anything but. In fact, use of asserts should be ruled illegal. Any checks should be done inline in release builds (unless one can test every possible usage scenario of the software :-).
One could easily argue that many security exploits and random crashes are due, in no small part, to this book.
-- Anonymous, June 19, 2001
Do explain how could any security exploit be traced to this book. With an example of such exploit if possible.
-- Anonymous, June 20, 2001
The Linux kernel contains security exploits, yet Linus is well-known for shunning asserts and kernel debuggers. So avoiding asserts is not sufficient to avoid security exploits. I believe most security exploits are from buffer overruns, which have nothing to do with asserts.
If a programmer is using asserts to check for valid runtime errors, then the programmer did not read "Writing Solid Code" well enough. Asserts are only to detect "programmer errors".
-- Anonymous, June 21, 2001
I know this is ancient, but all security exploitations are due to someone else's assumption. Assuming X is a static variable but having it in a Text segment (oh compilers do that too, sometimes the assumptions made are beyond your control), assuming that the tradeoff of having a suitably huge buffer size is better than checking variable bounds at runtime, etc, etc.
Assertions are clumsy but they can be made useful by wrapping them in your own handler which also generates a log. Then again asserts are there because the programmer made the assumption it wouldn't be hit, otherwise the error recovery should be engineered in.
-- Anonymous, August 06, 2001