[I am a project manager on software development project]

Definitely do weekly status reports and release notes (if you have software releases - I do).

You will achieve 2 goals doing status reports and release notes:

1) communicate what you do to other people

2) improve your visibility and justify your necessity to your company.

Both should be a list of items accomplished within last week (or implemented in latest release). Separate user-facing and back-end changes in 2 separate groups - non-technical people will only be interested in user-facing changes, so if they are separate and in the first group - there is more chance people will actually pay attention.

To make it easier to do each week I recommend using some bug/issue tracking software (I use Axosoft Ontime) and if you do any coding - source control system (I use Subversion).

When including item in the list also put the number of item in your bug tracking system at the end of the line. Subversion can be configured to required comments before commit and send email notifications to interested parties after commit. I force my developers to always put descriptive comments and related bug # (if applicable). This makes it easier for me to do weekly status reports/release notes - I just go through these emails at the end of the week.

Send these not only to your boss but to other team members as well.

To find out if someone actually reads these put somewhere in the middle of the list "17) If you are reading this please reply to me with "the eagle has landed" in the subject line". Don't let the fact that only 10% (at best) will respond to discourage you - these maybe the only people that count.

[I am a project manager on software development project] Definitely do weekly status reports and release notes (if you have software releases - I do). You will achieve 2 goals doing status reports and release notes: 1) communicate what you do to other people 2) improve your visibility and justify your necessity to your company. Both should be a list of items accomplished within last week (or implemented in latest release). Separate user-facing and back-end changes in 2 separate groups - non-technical people will only be interested in user-facing changes, so if they are separate and in the first group - there is more chance people will actually pay attention. To make it easier to do each week I recommend using some bug/issue tracking software (I use Axosoft Ontime) and if you do any coding - source control system (I use Subversion). When including item in the list also put the number of item in your bug tracking system at the end of the line. Subversion can be configured to required comments before commit and send email notifications to interested parties after commit. I force my developers to always put descriptive comments and related bug # (if applicable). This makes it easier for me to do weekly status reports/release notes - I just go through these emails at the end of the week. Send these not only to your boss but to other team members as well. To find out if someone actually reads these put somewhere in the middle of the list "17) If you are reading this please reply to me with "the eagle has landed" in the subject line". Don't let the fact that only 10% (at best) will respond to discourage you - this maybe the only people that count.

CPU is not a problem. Memory is. As others mentioned, get at least 2GB (total). Also people tend to forget about hard drives. 7200rpm make a noticeable difference comparing to 5400 (I think there was also 4200rpm laptop drives, but not sure. Very often default hard drive on laptops is 5400rpm)

This is Apple's ultimate goal!

It took me 30 minutes for clean setup for x64 version on Core 2 Duo 2.1 Ghz, new SATA hard drive (relatively fast).