Real-world software engineering
My friend Dan is an instructor this semester for a sophomore-level software engineering course, expected to be the students' first encounter with sizeable programming projects. One of the lectures, according to the syllabus, is explicitly supposed to be a sort of exposé of the realities of a career in the field. He solicited contributions from former orkers, but alas I didn't get back to him until after the lecture in question.
But that's what LJ is for! Plus, I know quite a few software professionals, and I think it's an interesting topic. University students in CS certainly didn't get any sort of realistic view of the industry when I was in school; I got all my reality checks by working summers writing lab-automation and data-analysis software at NIST. So, all you software-industry or nearby people: any ideas what to tell the young'uns to prepare them for the real world?
What would you tell college students about real-world software engineering that they might find (a) interesting and (b) helpful in their future careers? The lecture notes left over from previous years aren't particularly useful, so this weekend I set about the task of writing a new lecture from scratch: a 30,000 foot flyover of what you might be in for if you end up working in the software industry. Release cycles, autobuilds, requirements docs and technical specs, sleeping at the office, the whole bit.
My thoughts:
Real-world software engineers spend an enormous fraction of their time not writing new code, but debugging existing code. Almost nobody teaches debugging as an engineering practice, but they should. It's vitally important.
QA/QC are not the enemy. BUGS are the enemy; QA should be your friend and ally in fighting them. Ideally someone from QA is involved directly in your project, sitting in on your engineering meetings, understanding what the product is supposed to do and planning how to test it. If QA is not involved in your engineering product except as an anonymous consumer of the final product, your engineering organization has a problem that needs to be fixed -- that kind of testing is important, but far from sufficient.
Revision control is insanely important. If you can't accurately reconstruct the state of the code last week, you will find yourself trying to guess how to un-break some crucial functionality at a most inopportune time. Perforce's $600/user license fee sounds exhorbitant to students. It isn't: it will more than pay for itself the first time anybody needs to figure out what broke Feature X.
You are not the only one who will read your code. It may well be that you are not even the person who most desperately needs to understand it. Code without explanatory comments is less valuable, inherently, than code with annotations describing what it's trying to do and why. The folks who come along a year after you leave for another job will bless you heartily if you have bothered to explain that bizarre hash function or finicky parallel-tree data structure that your application depends on. (I learned this one early: at NIST I was writing software that I knew, from Day One, would be used and maintained and updated by polymer chemists, probably for years after I had left the position.)
It's common for software people to work much more than the benchmark 40 hours a week when a deadline looms. If it's happening all the time, either you're using your job as your hobby, or your engineering management (and possibly corporate management) aren't doing their jobs right. Either way, reconsider. Don't sacrifice your personal life to your job.
If you don't trust your management, leave. It isn't worth it, and ours is an industry blessed with easy job mobility.
That's a start. Your turn.