Friday, May 20, 2016

Lessons from Dev/Ops

I've really been enjoying the Dev/Ops role I started around the first of the year. I'm on a great team, we have interesting projects, I'm learning a lot and enjoying riding the edge of chaos.


I thought I'd share my top dozen or so early lessons, in no particular order.

1. You don't have to know everything, but you have to know how to find it. Of course you pick up techniques and patterns that you can apply to other problems, but just knowing where to find answers is probably better than remembering them all.

2. Document what you've learned. Other people might be interested & you might have to do something similar in the future. Knowledge grows in value as you share it.

3. When in doubt, try it out - and then use the error messages and logs to figure out what you did wrong. Use stubs to prove concepts before devoting a lot of time debugging complex stuff.

4. Take backups before you commit something you can't recover from (or even before you commit to something you think you can recover from.)

5. StackOverflow is your friend.

6. Making something good enough is much faster than making something perfect. Making something better is easier than making something perfect.

7. Besides, making something perfect is a waste of time, because it's probably going to be obsolete before too long.

8. Ask for help when you need it, but spend the time learning what you don't know first. You'll have more credibility and learn more if you try stuff that doesn't work before you ask questions. Also, don't spend more than a couple of hours running down rabbit holes...

9. Try stuff out in a safe environment - do it on your PC before you do it on a server. Try it in a sandbox before you try it on the development server. Test everything.

10. Automate the tedious stuff - make tools to do stuff you have to do more than once. Document the tools. 

11. When something "should" work, reality always wins. It really shouldn't work, or it would be working already... Nothing is magic. If something broke once, it will break again unless you really fix it. Be honest with yourself about this stuff.

12. Get comfortable with github. 

13. Delete something really important early in your tenure, just to get it out of the way...

Other obvious ones I missed?

No comments:

Post a Comment