Inspired by @patio11@RachelTobac@HydeNS33k@holman@sehurlburt here is a list "Quick Things Many People Find Too Obvious To Have Told You Already" aka "Things I wish someone had told me earlier"
I've often heard that #DevOps is all about #empathy and I agree.
As an operations person, the most helpful empathetic developers I ever saw were the ones that were told: "20% of your bonus depends on a rating of you from the Operations people"
I didn't believe this for a long time but you can 100% start a blog, write interesting posts and get people to pay you money to tell you more about what's in those blog posts.
Put another way: there are videos of people putting together Duplo on YouTube with MILLIONS of views.
There are people who will a. love something about you b. put that something to use in their benefit and then c. grow to hate you because they are now dependent on you for their success.
As a young person that can be very confusing so learn to spot these people early.
At every firm I've worked at, from startups to BigBank to HFT, it's been amazing how much positive impact tools written with basic vanilla frameworks can have. e.g. LAMP or #Flask + #CSS + #JavaScript can save hundreds of hours of work.
Interesting categories I've seen hiring managers fall into:
a. Oh, you have 10 years of perl, we only do python here
VERSUS
b. Oh, you were an elementary school teacher? Great, you will fit in perfectly at our biz that organizes CEO events.
"Your software will look like your organization" is a quote that is 100% true. The number of people who are affected by that quote but understand it fully is much closer to 0% than 100% in my experience.
Many firms have the idea that QA is less (in terms of pay/skills etc) than Development and Operations. They then wonder why the QA people who are good developers become Devs and the QA people who are good Operations people become Ops. Simple answer: treat your QA people better.
If you are in TechOps and you report to the head of Development, you are going to have a bad time. A better situation, have head of Ops be == head of Dev. The best, have Ops be part of the business.
ood software systems cost X. You can spend 90% of X on Dev and 10% on Support and get great software that is easy to support. Or, you can spend 10% on Dev and 90% on Support and get bad software with great support. Spending less than X will get you terrible outcomes all around.
My father got one of the biggest opportunities of his life because an external recruiter offered it first to one of his employees and said employee said: "I think this job is too big for me, you should talk to my boss." Moral: have great relationships with your employees.
Biggest job I ever had was b/c past co-worker recommended me to my boss. Co-worker never finished college & his family owned pizza parlors. Said "you gave me great advice over the years, it was the least I could do". Help people b/c you never know how it may help in the future.
That's it for now. If people find this interesting, I'm happy to expand on the items above or add new ones.
If you liked this thread, here is a meta thread of my other threads:
GitHub has a talk from 2013 where the Ops guy says:
"We don't have dashboards. If something goes wrong, the alerting system generates a chart showing the error, screenshots it and then drops it in the ops channel"
I think about this quote every time I see a dashboard.