Having to do both CRA (Canadian Revenue Agency) and IRS/Indiana DoR filings, I find that whole 'Paperwork Reduction Act' thing is quite ironic.

The first couple of years I had to do US tax filings (through an LLC), it took me a month or so to get the accounting the way I needed it, and to figure out through the massive maze of forms which ones I had to fill out and how I had to fill them out.

Now, with the exception of filing to get my withholding tax back, it takes about an hour after I've got my accounting all in order. I've got it down to a system of completing electronic PDF forms (6 forms for the IRS, and another 5 or 6 for Indiana), printing them out, and then signing two of them. So, now it's mostly stress more than anything. But good God man...why so many forms? And lengthy ones at that.

CRA's are mostly a couple of pages...the odd one might be three.

I would tend to agree with dcw3, based on my limited exposure to the industry. I worked in an aerospace company for a few years, and the code I worked on was some of the buggiest code I've ever encountered. The push was to get more features thrown into the software, rather than writing code properly and fixing the existing code. When I first started at the company, the software was crashing every 2 or 3 minutes and often every time the software tried to start up. By the time I left, we finally had it down to every 6 to 48 hours. However, for the environment this software was supposed to be deployed in, even every 48 hours was crashing too often. The code often reminded me of Chuck Forsberg's xmodem, ymodem, and zmodem code, but it actually makes his code look spectacular. Gotos were liberally sprinkled throughout the code, null pointers passed around like they were going out of style, and globals and statics were the cool thing to use in multithreaded code.

The more you communicate to your superiors before the meetings, the less time spent in meetings, too.

One way to achieve this is to make sure every time you commit code that you check it in against a ticket. If there isn't a ticket to check it in against, create one, and then check it in against the newly created ticket. This gives you transparency and accountability. Both of which managers love. This can all be achieved with various ticketing systems, but the one I find that is integrated with a versioning system quite well is Trac. It integrates well with subversion, git, and mercurial.

Just keep in mind that not all communication is necessarily verbal.

>No IIS servers I installed got hit by code red >because - gasp - the default install was not >done. If the exploitable software isn't >installed, guess what happens? Your server >doesn't get compromised! What a revelation.

On IIS 4.0 (NT Option Pack 4), I believe this was probably true. However, on IIS 5 (Win2K Server), indexing service gets installed by default.

However, Microsoft also makes the indexing service sound necessary when you read the description for it on the install. A lot of people would install it, regardless of whether they need it or not. Most of the Microsoft server farms I've seen are using it, around town.

I think that in order to become an MCSE, people should be forced to take a short course in security. Security is by and large part of the course content in learning UNIX, but for some reason it doesn't seem to be stressed for Windows administration.

Windows administration culture also needs to change; not just the installation semantics.