There are many things I'd do and some are dependent on the language as some things make more sense in some languages and less in others.

First thing I'd do is get all the existing documentation I can find including the end user documentation of how to use the software.

I'd next try to break the software down by modules, subroutines, functions, library routines, etc. to get an idea of what does what. I'd also try to determine variable usage, such as local vs global variables and where things are defined.

If the above is not already documented I'd work on creating the documentation so I don't have to refigure things out each time I dig into the code for something.

The code style of the previous people who worked with the code can be very important. Some languages are easier to write obscured code in then others. If the code is NOT documented or the documentation is obsolete I'd start working on the inline documentation. Anyplace that the code is very obscured or poorly written I might look into rewriting so the code is easier to document and easier to read.

Don't trust any of the documentation until you've made sure it is up to date.

At one of my jobs the package I was hired to maintain, support, and enhance had been modified on a per customer basis where some varialbes had different meanings in different versions. There where some features where the feature was implimented differently in different systems to meet different customers differing and conflicting needs. In some cases the mainline module code would look the same but the differences would be hidden in the subroutines. This was made even more complicated by being a multiuser application that did its own file locking. The original application had been single user so there was more then one method of gdoing file locking, some of which was based on what files where in which 'partition'. The system only allowed locking entire 'partitions' at one time. As customer grew to need multiple disks with multiple partitions the multiuser locking would erratically fail, corrupt data or deadlock, etc.

Look for the tools people mentioned that can help you easier figure out how things work. There were no tools for the system I worked on so I had to create my own (proprietary non-standed OS and interpreted language).. My boss complained aobut some of the time I spent working on the tools until he saw how they were saving time and helping make it easier to make changes.

Don't be afraid to look for tools to make your life easier. Don't be afraid to write your own if there is a good reason to do so.

The system I worked with was about 200 programs / customer with about 200 subroutines (sometimes unique for a customer) in each system.

Does that mean any politician in and from NC would have to register, particularly if they received any money from any foreign source? How about newspapers with readers outside the US that publish any editorial about changing/making laws?

Does this mean a community can rule the bible obscene and ban any and all mention of the bible on the net?

Best idea yet in this discussion. I'm pretty sure I could do a better job.

I'm also going to have to rewatch my Blake's 7 videos. Maybe a Blake's 7 weekend ;)

One thing no one has asked is, when were the photo's taken? They could have been taken before she was depressed. Mental illnesses I'm familiar with tend to have good days and bad days. The problem is you have little to no control over when you'll have a good day or a bad day.

Security and performance are different issues though they can overlap.

The first step for security is turn off every service not needed. For remote access use ssh, not telnet.

The first step for performance is to learn to use the various monitoring tools and how to interpret their information. Some of these are top, vmstat, sar, free, netstat, ifconfig, du, df. Depending on your flavor of os and what is installed you may have some of these. You may also have vendor specific tools as well.

Sometimes just watching the various indicator lights can give you an idea of what might be a problem, like if the disk activity light is on solid for minutes at a time.

Don't wait until you have a problem, get used to the tools, how they work, and what they display when the system is running normally.

Some problems are caused by peaks in services. The boss sends an email to everyone that includes a 1mb attachment and everyone has their mail program set to check for new mail every 10 minutes. You can have very short term problems that aren't really a problem. On the other hand, if mail is always a little slow, there could be a problem.

Throwing money at a problem won't fix it if you don't know what the real problem(s) are. Most performance issues tend to be caused more by I/O bottlenecks then by cpu. Faster disks and/or more ram tend to help more then a faster cpu in many cases.