Yep, with most of the big engineering firms I've worked for, it's maybe 5% hacking and 95% documentation and packaging. If you can enjoy doing mostly the latter (finishing the last 10% of a project that ends up taking 90% of the time), then you should be able to get along fine. If you spend all of your time doing the former, then you will quickly become reviled by your co-workers :-P
Here's the junk that seemed important to engineering companies:
- ISO9001 : Is your shit documented? Do you know where the most current version of that documentation is? Most of the companies skirted the requirement by creating an unironically named "Desktop Instruction" linked from a desktop icon to a version-controlled file that basically said: "1. find problems 2. fix problems 3. document fix". BTW, you fail if you don't have a footer that says "Uncontrolled if printed" (but CS geeks never print anything anyway). And bonus if you can draw every process and procedure in flowchart form, which is actually a little bit fun :-P
- CMMI : Is your shit version controlled? Can you rebuild an exact copy of something (and its documentation) that you delivered a month or a year ago? If you use version control tools, I think that automatically gets you to CMMI level 2, and if you use automated build tools in a version-controlled build environment, then you have most of CMMI level 4. I'm afraid that puts you well ahead of most project engineering teams.
- Six Sigma (or some other Quality Management System) : Does your shit break? Your shit really shouldn't break, but if it does you ought to have some way to fix it so it doesn't break the same way again later. This might be the hardest thing to get down pat, but fortunately it's considered a "bonus" and not required by most projects. If you use a trouble ticket system, and the shit you fix stays fixed, then you're probably in good shape.
So, in summary, if you can find your way around some sort of toolchain that involves doxygen, mercurial, make/ant, cobbler, jenkins, and redmine, to the point that you can hand a junior engineering a piece of paper (oops, I meant email a link to a desktop instruction) such that the junior engineer can build their own working copy of the product by themselves with nothing but cold iron and a revision tag, then you're doing well.
But really, the real trick is to figure out how to get everyone on the project team to use the same toolchain :-P