Solution For College's Bad Network Policy?
I guess their is creating their IT policy. Maybe the CIO gets kickbacks.
First, if I were a student at CMU, I would complain about having a corporate trojan installed on my machine. How long before somebody reverse engineers the protocol for this 'client security agent' and turns this software into a backdoor on unsuspecting student's machines.
Second, if I were a professor, I'd ask why the IT department can't set up a faculty network separate from the student body. Do some bandwidth shaping here. Give the faculty network a separate, dedicated amount of bandwidth. (I'm imagining they do this already, but I'm answering some the responses here.)
Third, if I were a high enough ranking member of CMU's IT department, I'd be asking why we want to touch all those student computers anyway. I really don't want the department to be saddled with the help desk issues resulting from this bastard 'client security agent' malware anyway. Quarantine the non-conforming students. If these students are willing to sign waviers, put them on a separate network, firewalled from the conforming students. It's up to them to firewall their machine. Block the obvious P2P traffic (or do some intelligent bandwidth shaping). Students who wish to conform get put on the other network. Plus, by a good anti-virus solution for everybody (like Avira or NOD32). Once again, anyone who doesn't conform to this policy gets put on the quarantined network, plus they sign the waiver stating they understand the risks.
Fourth, hire me as CMU's CIO.... (Forget it, Michigan is in the toilet as a state anyway...)
What To Do Right As a New Programmer?
You can still write good code without having a CS background. Sure, if you designing an operating system, designing a compiler, or delving into some low-level code, more engineering know-how is required. However, I've found my Math/CS background only to be mildly useful when writing database apps...
Here are some things you can do to become a better programmer...
Find someone (preferable a group of people) you can talk shop with. Nobody loves solving someone elses problems, but most programmers like to discuss best practices. Pick apart other people's code. It could be an open source project or maybe just the source code to some guy's game you found online. Maintaining code allows you to see other people's mistakes. Writing good code is hard, writing maintainable code is even harder. You can learn a lot about design by being on the other end of the development process (i.e. maintanance). Sometimes mentorship is just reading good code.
Read, read, read...
All the coding in the world will get you only so far. You need to consult the wisdom of experts. Some other good books are:
Object-Oriented Software Engineering:
Practical Software Development using UML and Java
by Timothy Lethbridge and Robert Laganiere
website for book
They even have a DVD with an entire semester's worth of lectures (based on the book) available for $50 online.
Applying UML and Patterns
by Craig Larman
sample chapters here
There's a series of videos (about 3 hours in length) that describe many of the details in the book.
Anything by Martin Fowler
Martin Fowler's website
You may wish to also check out:
A seminar on the Object Oriented Design with a focus on the Unified Process (or something close to it)
Methodology, methodology, methodology
The above books will introduce you to many of the existing methodologies in software engineering. It's not so important what methodology you choose; what is important is how you implement it. While many people may disagree with me on this. Engineering methods can be taught, problem solving skills can be acquired, and math skills can be learned. You might not be the next Edsger Dijkstra, but you can learn to write very good code on schedule and under budget. It may be hard to write code at home when you've been writing code at work all day, but try working through a project from beginning to end with perfect documentation (yes, make use cases...) utilizing all the right tools (i.e. version control, bug tracking, make tools). Doing this will make you a better programmer. Learn to take a few minutes each day and write out what your going to do. I often start writing code for the day by opening up notepad and figuring out what I'm going to do in psuedo-code. After, I just flesh out the notes and spend the rest of my time testing. Some guys like to do this on paper. Many professional organizations start out a days worth of coding drawing UML (or some close approximation to it) on a white board. The key is to plan before you code. Don't just jump in front of your IDE.