This is good, and I'd add on to the part about the successes. Learn to document your successes and be able to verbally communicate why anything you do is important or useful to less technical users.

If you don't have a good boss who can see that you are good at what you do, you will have to be able to speak up if you want to be paid what you are worth.

You want to be a step up from a computer janitor who needs to be told what to do, to being someone who delivers value to the business and helps people get their jobs done, and can anticipate problems before they occur.

> Learn to document your successes and be able to verbally communicate why anything you do is important or useful to less technical users.

And on the software engineer/developer side of things the same applies. This is why whenever I am given a self-assessment or asked to help with a review of myself, I go back through my git log, email, etc. looking for what I've done instead of just attempting to summarize based on memory. Then I keep a personal copy of my self-assessment. That way, I have a record of what I did, and so does my company. Wikis, file servers, and other document repositories change, and when you switch jobs, you have that available to look at to update your resume. If your company doesn't make you do at least annual and hopefully quarterly self-assessments, you should do it on your own.

I would like to add that you should be patient and kind to the developers with whom you are working. When they have product successes, they may call attention to your efforts as being tied to its success. This is a good thing; having your job tied to profit-center activity is very good. Even if attention isn't drawn to your work, smart developers know how incredibly valuable smart, communicative sysadmins are, they will work to keep you working with them.

You should be patient and kind with everyone. Although, patient and kind does not included adding untested code to production to "fix" something late on a Sunday night. Insisting on proper deployment almost always makes developers[1] irritable. It also prevents http://dougseven.com/2014/04/17/knightmare-a-devops-cautiona...

1) I have more years as a developer than system admin (11 vs 7 and 5 as something I'm still not sure).

"why" is the most important information ever.

I've been in my present position five years. Knowing where the bodies are buried (because I buried half of them) turns out to be one of my most useful functions, and whenever I am asked such a question I add the answer to the internal wiki ...

I don't think anyone knows what every single script and command does on a system. Has anyone read and audited all the init scripts for example? Never. And where would one find the time to do this? Certainly not on the job.