Devops days slide deck
•Download as PPT, PDF•
1 like•971 views
RealGravity hired Mercedes Coyle, a new backend engineer fresh out of Hackbright Academy, to work in their devops culture. They outline their goals of teaching Mercedes their processes and instilling a devops mindset from the beginning. Mercedes discusses her reasons for choosing RealGravity, including wanting a supportive environment to get up to speed quickly. She brings a solid coding foundation from Hackbright but was less familiar with devops as a culture. Senior engineer Gary Foster mentors Mercedes and discusses responsibilities for both mentor and protégé, emphasizing patience and allowing Mercedes to take on meaningful work and learn through solving problems rather than being given answers. Mercedes discusses both challenges and successes in her new role, such as
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Devops days slide deck
Similar to Devops days slide deck (20)
Recently uploaded
Recently uploaded (20)
Devops days slide deck
- 1. Leveling up a new engineer Healthy Sustainability Gary Foster <gfoster@realgravity.com> Mercedes Coyle <mcoyle@realgravity.com>
- 2. What we’re Going to Say • New engineers are a precious commodity • Devops cultures need to be cultivated • What is a “devops culture?” • Why devops cultures are important • We have a responsibility to “pay it forward” • Mentoring is key to our success
- 3. Who Are we • Company: • RealGravity • Video Distribution • Owned by Scripps Networks • Ever heard of the “Food Network?”
- 4. Who Are we • People: • Gary: • Senior Engineer • GrizzledVeteran • Tons of bad habits • Mercedes: • New Engineer • Fresh out of Hackbright • No bad habits (yet)
- 5. Our Goals • Hire a new engineer • Teach them “our way” of doing things • Inculcate a devops mindset from the beginning • Add good practices and training to the local labor pool • “pay it forward”
- 6. Our Process • Identify our need • analytics, data and event processing • Determine our desired outcome • Strong independent engineer • devops mindset (no “ivory tower” allowed) • Identify our resources • Match a mentor to the protégé
- 7. Where is the talent? • The new “hacking” culture • Hackathons etc • Academies and bootcamps • Incubator sponsored “meet and greets”
- 8. • “meet and greet” incubator mixer • Approximately fifty attendees • We interviewed thirty candidates
- 9. HACKBRIGHT Academy • Focused developer bootcamp • We interviewed sixteen candidates
- 10. Who we Got • Mercedes Coyle <mcoyle@realgravity.com ><@benzobot> • Recent Hackbright graduate • Our newest backend engineer
- 11. What I was looking for • An environment in which I could get up to speed and be productive quickly • Lots of support and challenge, but no hand-holding • Senior engineers who were excited about helping a new engineer grow.
- 12. What I brought to the table • Willing to try new tools, ideas, and processes since I’m not yet specialized • A solid foundation in the basics after Hackbright, from “hello world” to testing and deploying applications • I had some vague ideas about devops as a role, less so as a culture
- 13. What is Devops? • Only you can prevent forest fires! (you being dev and ops)
- 14. What are my responsibilities? • Question anything I don’t understand • Avoid perfectionism • Speak up
- 15. What are a Mentor’s responsibilities? • Patience. New engineers are going to ask a lot of questions, often multiple times. • Give them the same level of responsibility as more seasoned engineers, and work on projects that will be useful and valued • Ask them for their ideas • Teach problem solving, not syntax, and don’t give away the answer.
- 16. What it’s really like • Some days: I have no idea what I’m doing. • Other days: I feel like I’m a coding machine! • Engineering is a process over product environment
- 17. What it’s really like • I might screw something up, and that’s OK. • We’re encouraged to try new things, and sometimes new things fail. Failures are learning experiences. redis production:6379> FLUSHDB OK
- 18. What it’s really like • We iterate frequently to improve our process and infrastructure • I’m encouraged to research and try out new tools and approaches • I’m responsible for being on call to fix things when they break, just like the rest of our dev team
- 19. What its really like • Weekly team demos are good motivators to GTD • “Make it work, then make it pretty”
- 20. What we Told you • New engineers are a precious commodity • Devops cultures need to be cultivated • What is a “devops culture?” • Why devops cultures are important • We have a responsibility to “pay it forward” • Mentoring is key to our success
- 21. How this applies to you • You get to train them the way you want them to be • Any bad habits are your responsibility • Got an engineer who’s afraid of the command line? • Got an engineer who creates crazy complicated stuff no mere mortal can deploy, maintain or sustain? • Only yourself to blame • Any good habits you instill helps the next team • We all want to hire good people • We all hire from the same pool
- 22. Gary Foster <gfoster@realgravity.com> Mercedes Coyle <mcoyle@realgravity.com>
Editor's Notes
- Today you are all going to hear a lot about technology. You'll attend presentations on the latest and greatest frameworks and tools and talk with your peers about doing really cool things with them. We’re not going to talk about that. We’re going to talk about something that we consider much more important. We’re going to address the care and feeding of new engineers... specifically DevOps engineers.
- Some of the things we’ll talk about today are why we believe new engineers are so important. We’ll talk about how to go about building a DevOps mindset from the outset. We’ll even touch a little bit on where you might go to find new talent. Finally, we’ll talk about how we approach mentoring at our company and why we consider a good mentoring system so vital to building quality in from the ground up.
- First, who are we and why are we giving this talk? There are two of us here today from RealGravity. We are a video company recently acquired by Scripps Network. You might have heard of them... they also own the food network, HGTV, the cooking channel and a bunch of other brands.
- I am Gary Foster. I’m a senior engineer and have been doing technology for around 30 years. Yeah, that’s a long time in this profession and believe me I feel tired sometimes trying to keep up with you guys. During that time I’ve worked at large companies like Sun, eBay and Toyota as well as small companies. I’ve worked early and late stage startups and even worked in the gaming industry. Where I am today is due, in large part, to the fact that I’ve had excellent mentors during my own career. My current protege, Mercedes Coyle, is a brand new engineer who comes to the profession by way of a solid operations background. She decided to make the leap into a full DevOps role, attended and graduated from HackBright Academy and then decided to join us at RealGravity. She’s the focus of the show today and this talk is mostly her story.
- The first step in any project is to clearly define your goals. Ours were very simple and straightforward. First, we needed a new engineer. We knew we wanted a junior engineer, not because of their skill level but instead because we wanted to make sure we didn’t have to “untrain” them first. We wanted the opportunity to teach them our way of doing things from the start and finally we felt a responsibility to pay it forward by making sure we added value to the labor pool. After all, the engineer we hire today is eventually going to to move on. It’s a simple fact of our profession, and we wanted to make sure we put the best talent and training we could back into the pool for everyone else down the road.
- At RealGravity we tend to adopt an experimental approach to nearly everything we do. That means we can’t just “wing it” and hope things turn out right. We like to have a process for doing things so we can tweak it to adjust our outcomes. You can see here our simple and straightforward process. Identify what you need. Determine your desired outcome. Identify you resources and finally set up the mentoring relationship.
- Once we have articulated our goals and outlined our process it comes down to finding the talent. We all know good talent is hard to find in the Bay Area and often, unfortunately, involves poaching from each other. In the interest of NOT poaching, we identified several key areas for recruiting that would allow us to highlight new and emerging talent. We narrowed this list down to two, rolled up our sleeves and went to work
- More and more companies are beginning to use the incubator model. We were initially at RocketSpace which provided us with a lot of valuable resources including “meet and greet” nights. We leveraged those to look for interesting prospects.
- We also are a big fan of the new developer bootcamps that are springing up and we took the time to interview quite a few members. We were extremely impressed with the talent we saw there. I cannot recommend these highly enough and wouldn’t hesitate to go back to this particular well anytime we need a new engineer.
- So now you know the what, the why and the how. This brings us to the who. Mercedes will be speaking to you next to tell you her story and her experiences as a new bright eyed and bushy tailed engineer coming up to speed in a heavily DevOps focused environment. This story is about her. I don't come from a traditional CS or engineering background, but a hacker mindset and a community of software engineers encouraged me to learn to code after spending some time in various support roles. I've had some fantastic mentors along the way. Hackbright was a good fit for me after trying to teach myself to code. It's one of many paths to learning how to be an engineer.
- "controlled" firehose - I wanted to hit the ground running Guiderails, not hand-holding - Engineers telling me how to do something without explaining or letting me figure it out won't help me learn; I didn't want to be shielded from the trenches Interesting work, rather than one-off projects that no one else wants to do Interview process: when I asked questions about culture and deployment, they asked me what I thought before answering they enthusiastically wanted me to be there I didn't initially have an interest in data and events systems, and a lot of that came from lack of knowledge. They got me excited about working with events and data. I didn't interview for a specific role - they assessed my interests and figured out if they had a role for me. everyone I talked to had some ops knowledge, and was willing to share. during the interview process, it was mentioned that one goal was to make employees better engineers for their next gig.
- bootcamp: I can learn quickly full stack: I'm not specialized, and I'm open to trying new stuff since I love learning previous devops knowledge: big dividing line between operations and engineering, thought that devops were primarily sysadmins who automated and tuned infrastructure. was looking to blur that line, since it was not an effective way of working
- Traditional mindset - "make me a sandwich" - what kind of sandwich do you want? Just make me a sandwich, and I want it quick! OK. Well, that sandwich wasn't what I wanted. In my previous experience, Developers were not encouraged or had little desire to understand what went into operations; they just wanted it to work, and infrastructure was at times an afterthought. Big dividing line between two teams made it difficult to find the best solutions. Ops and Dev need to be informed about what each is doing at all steps in the process. I didn't know it at the time, but I was looking for devops culture devops mindset - work together as a team, many have shared responsibilities, knowledge and overlapping skills; no throwing things over the fence. solving problems is a group effort. I've spent a bit of time working one on one with others in my team when services are on fire; when we're fixing things, we're thinking about tuning to make them perform better in the future.
- communicate anything I don't understand and ask for clarification It's ok to go down a rabbit hole - just ask for help before I get stuck in there. Make it work, then make it pretty code review, test, prototype often - weekly demos help me with motivation to do this Speak up - I'm asked for my thoughts on architecture, coding, procedures, troubleshooting etc - as a new engineer I may have a different perspective Check in - If I'm not getting help that I need, or want some help getting organized I should ask for that
- patience - I'm going to ask a question about something we've talked about before, and probably more than once. I also might not get something right away unless I experiment with it. Encourage prototyping and experimentation - having a couple projects at a time is conducive to this Give them work and responsibilities that the rest of the engineering team has - and don't treat them like a junior engineer by giving them work or projects that are separate from what the rest of the team is working on. We all work side by side to build our data infrastructure and tools, as well as sharing the load when things go wrong. I'm not left out of this process, nor am I given a lot of character building grunt work. side note: I've had the experience before of being new and being given grunt work and stuff that the rest of the team didn't want to do. Since others were not working on the same things, I had less success asking for help, and since I did not feel like the work was valued or depended on, I had less motivation. Teach your new engineer to fish - don't give the answer away, but let them work for it and often they will figure it out on their own. Also: ask their opinion or thought process before giving yours; they may not have the confidence to speak up if they've already heard a solution. A senior engineer has more experience, so their word should be good, right? Check in - if your new engineer looks overwhelmed, make sure they're doing OK before they spent too much time being overwhelmed. Make sure they're on the right track, and if not, what they need to do to get there.
- I get asked this question a lot, since I talk to a lot of prospective new engineers. Some days I feel as though I don't have a full grasp of the problem + solution, and feel as though I'm spinning my wheels looking for a solution. This is OK! It also happens that senior engineers also feel this way. Building software is a process, and there can be many many different ways and iterations to do one thing. After enough wheel spin, I totally get the problem and solution. Productivity is tidal - days spent churning and going down rabbit holes can eventually lead to breakthroughs. I've quickly gotten over being attached to my code, and encouraged to prototype, iterate, and rewrite often. This translates into breaking down tasks to make sense of bigger problems. I may not have the experience of senior engineers, but I do have a valuable different perspective.
- Being in two environments at the same time allowed me to mistakenly wipe out about an hour's worth of data on one of our redis servers. I immediately figured out that I was on the wrong machine (unfortunately, after I hit enter), and after a few seconds of panicking, reached out to my team mates to explain to them what I just did, how it happened, and to ask if there was anything I could do to fix it. The response: Ok, how can you avoid this in the future? (more differentiation between dev and staging). What did you learn from this? I learned there are better ways to remove test data than to flush the database directly on the server :) I didn't feel the need to hide my screw up, or brush it off; instead, I got help and a critical learning experience.
- Research doesn’t initially feel productive; sometimes I write a lot of code that doesn’t initially apply to the problem I need to solve or is solely for learning the tools. Eventually, I have a moment of clarity for how to use that tool or process within our codebase and infrastructure. Experimentation, research, and prototyping really helps me understand why we use the tools and how we tune them. Being on call - we have a weekly rotation in our team; our ops people are not solely responsible for fixing things when they break. Once we started this on call rotation, I was concerned with being able to fix a service I was unfamiliar with. To mitigate this concern, I started the “oh crap, something broke” documentation page on our internal wiki. While not complete, it’s a good starting resource for someone on call (so they don’t have to call the person with tribal knowledge to fix it). Pretty soon, I had other engineers outside of my team asking me for the page so they could model it for their teams. All of our engineers share the pager duty rotations and get notified when something breaks, even the senior ones. For example, my mentor Gary recently freaked out a little when he got over a hundred pager duty notifications within a few minutes on a system while he was out of the office. Luckily it actually turned out to be a monitoring system issue instead of a production problem. The quickest way to get an engineer to fix an ops problem is to freak them out a little and wake them up.
- Even if it’s not pretty, demoing a project or component results in constructive feedback; often good information to get me going down the right path Pat, our team lead, recently volunteered me to demo something that I was working on even though I didn’t think it was ready for a demo. I think I was coding until just before the demo; resulted in clarifying what I was working on and good feedback from the rest of the team
- So, what did we just tell you? First and foremost, the biggest message we want you to take away from our talk today is that new engineers are a precious commodity. They should be nurtured and encouraged to grow. Next, we believe that DevOps cultures don’t just “happen”. They have to be carefully cultivated. We talked a little bit about what a devops culture is and why we believe they are important. Mercedes talked about her experiences as a new engineer integrating into an existing team with a heavy bias towards a DevOps mindset. We also tried to hit the responsibility metric pretty hard. We really do believe in karma and we recognize how much of a debt we owe to the people who took the time to teach us. We absolutely believe the best way to pay that debt is to make sure we pass on what we have learned, what we know and most importantly why we know it. We completely believe in investing in the local talent pool. We hope we have managed to share some of our successful At RealGravity we have begun to think about the technology profession and how it might benefit from an old-style “trade” approach. We have had lots of interesting talks about how we might have apprentice, journeyman and master levels and what responsibilities that might place on each of us. Finally, we talked about how we look at mentoring. We gave you some examples of our ongoing efforts to “walk the walk”. We firmly believe that any truly healthy mentoring relationship is balanced... the mentor absolutely should get as much out of it as the protege. In our opinion, any person who thinks the benefits flow in only one direction should stop and take a long hard look at why they feel that way before moving forward.
- What do you all get out of this? Well, hopefully you get a lot more out of it than you put into it. By paying close attention to how you bring on new talent you can end up with a great engineer who is tightly integrated into your company culture. They will have the good habits you have taught them. Conversely, any bad habits they might pick up can generally be laid firmly on your own doorstep which can help you identify what areas you might want to think about cleaning up in your own organization. Finally, that engineer you train up will eventually be back on the market and might possibly come to work for me next and if you have trained them well I’m going to have a much easier time. I promise to send you good people in return!
- And now we’d like to open the floor for questions and short discussion. We’ll try and sort out who should answer them on the fly but if you want an answer from either of us specifically please feel free to make that clear. Any questions or feedback?