I am what I guess you'd consider a junior sysadmin. I graduated in May of 2011. While it's not being a developer, all of the points stand. Read other code - s

I am what I guess you'd consider a junior sysadmin. I graduated in May of 2011. While it's not being a developer, all of the points stand. Read other code - still very important in admining. Other people write scripts, and there's a wide variety of Perl that's been written. Understand what's good and bad. 2-5 are all true. I just want to reiterate how important it is to ask questions (#4). When you start a junior position, spend time getting to know people. Set up one on one meetings with other people to get to know them and find out what they do. It's important going forward with a cohesive team. From the training side of it, if you're not asking questions I can't be sure that you understand what I'm saying. Unit testing doesn't really apply to sysadmin that much, but basically have a plan to test if something works as you're going along. If you're making 4 major updates to interdependent systems, how can you tell which of the 4 systems broke the service for the user? I ran into that recently. We had a problem that stumped 4 technical experts and two vendors for over 8 hours, when it was a relatively simple fix (once they figured out what the fix was). Systems get more complex as you add things to them, so be sure to test the individual moving parts. Refactoring is still always allowed. I feel as though you can extend this to procedures and processes. Where ever you go, there's always some "legacy" that builds up. If you ever receive the answer "That's just the way it's done" you should absolutely look into refactoring that. Odds are the decisions made back then aren't as relevant, because the base assumptions have changed. That's a major area you can show initiative on and start flexing your wings as your own person.