Best Academic Practices:
Entry page   Employment portfolios   Coding style suggestions   Making a presentation   Research presentations   Mr. Bruey on F-1 issues   Corliss on Teamwork   Recommended reading   Communication rubrics   Research interests		Expectations for scholarship   Intellectual property - School vs. work   We expect good English   English style suggestions   Nick's 20 rules of software engineering   Why take a Corliss class?   Thesis outline   MLA Manual of Style, Purdue University   Academic policies College of Engineering See Table of contents or Index A - Z
Events

Nick Wesselman, a former student, writes:

I felt inspired this morning to share the lessons I've learned. All are important, but some are contradictory. It's finding the middle ground that's key.

1. Software engineering is art.
2. "It works" is never enough.
3. "Good enough" is never enough.
4. Be reasonable and realistic.
5. Plan, plan, plan.
6. Abstract, abstract, abstract.
7. Reuse, reuse, reuse.
8. Refactor, refactor, refactor.
9. TEST, TEST, TEST.
10. Always consider the WHOLE SYSTEM.
11. Separate your concerns.
12. Remember your patterns.
13. THROW AWAY your prototype code.
14. Use the tools at your disposal.
15. Someone’s done it before.
16. You can do it better.
17. Be part of the software community and use it to your advantage.
18. Google is your best friend.
19. Never work in a bubble.
20. If it can go wrong, it will.
21. Your clients don't know what they really want until you've made a prototype they hate.