We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.
Find plenty more from Dave on his Continuous Delivery YouTube channel: https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g
Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.
ABSTRACT How do you pick your employer? How do you get a great job in software development? Programming jobs aren’t all the same. What makes a good job in software is subjective, obviously, it depends on what you are looking for, but there are some generic characteristics that statistically predict that people working in these places will enjoy their work more and have lower rates of burn-out and improved scores in things like work/life balance. So how do you get a job in software that is more rewarding, more fun and will challenge you to get better at the things that you love? How do you find the jobs that will help you to become a better SW developer?
This probably all sounds too good to be true, but in this episode, Dave Farley, author of "Continuous Delivery" and "Modern Software Engineering”, offers his advice on how to pick great employers. He describes the things that you should explore, when looking for a new job, to decide if a potential employer is only talking a good game, rather than playing a good game.
CD TRAINING COURSES If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses https://bit.ly/DFTraining
RECOMMENDED BOOKS & LINKS You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here: https://leanpub.com/cd-pipelines Dave Farley & Jez Humble • Continuous Delivery • https://amzn.to/3ocIHwd David Farley • Modern Software Engineering • https://amzn.to/3GI468M Forsgren, Humble & Kim • Accelerate • https://amzn.to/367RI5o Daniel Pink • “The Puzzle of Motivation” • https://youtu.be/rrkrvAUbU9Y Daniel Pink • Drive • https://youtu.be/LFlvor6ZHdY DORA • State of DevOps Research • https://www.devops-research.com/research.html
https://twitter.com/GOTOcon https://www.linkedin.com/company/goto- https://www.facebook.com/GOTOConferences #GOTOxDaveFarley #Programming #SoftwareArchitecture #CD #ContinuousIntegration #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery #DORA #Accelerate
DAVE'S LINKS https://www.continuous-delivery.co.uk https://twitter.com/davefarley77 http://www.davefarley.net
Looking for a unique learning experience? Attend the next GOTO conference near you! Get your ticket at https://gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily. https://www.youtube.com/user/GotoConferences/?sub_confirmation=1
The ideas that I describe on this channel have lots of benefits. The data says that if you follow much of the advice that I offer here, you'll build better software faster, which is very nice. But it also says that you'll report a better work life balance so for much lower rates of burnout, identify more closely with your employers and so stay longer in your job. If you are a follower of this channel or if you're not but would just like to find a better job. This probably all sounds pretty good, but how do you tell if an employer. That'S trying to recruit you is any good at this stuff? How do you tell if your prospective. Employer is great or just great at. Talking a good game? Here are a few thoughts on questions. You'D like answers to that might give you some insight into that. Hi, I'm Dave Farley of Continuous Delivery. Welcome to my channel. If you haven't been here before, please do hit subscribe. And if you enjoy the content today. Hit like as well. If you'd like to know more about. How to gain the advantages that I mentioned in the introduction to this video, check out my training course Better Software. Faster, which describes the benefits of continuous. Delivery and how to practice it effectively. The only real downside that I'm aware. Of for continuous delivery is that it's. Very hard to adopt. I think that if I knew how to wave a magic wand that transformed. Any organization into a continuous delivery organization, most would want me to do it. One of the many reasons why this is true is because the people who. Work in continuous delivery organizations really like working there. One of the results of this is. That firms and teams often claim to. Be practicing continuous delivery when they're not. I read a report a few years ago that said over 60% of Fortune 500 companies were practicing continuous delivery or. Had plans to do so. Well, I don't know about the plans. But take it from me, popular and successful as this approach is, it isn't 60% of firms that are doing it yet. So let's imagine that you turn up for an interview. Sure, you've got to convince them that you're the catch of the year and they should employ you immediately. But remember that you're also interviewing them. So how can you tell if your. Prospective employer is going to be the. Place of your dreams or the source of your nightmares? How do you distinguish between the firms. That say, oh yes, we do continuous delivery and DevOps, but really mean, I'm. Sure we had a copy of Jenkins somewhere. Oh sure, we practice test driven development, but really mean we've got seven automated tests but they never pass, so we leave it all to QA. This can be a lot harder than it sounds because nearly everyone talks a good game. So how do you identify the players? I guess one place to begin in exploring this is why do you care? What are the properties of an organization that makes them a good employer? There's a book called A Drive and. An excellent Ted Talk by its author Dan Pink link in the description in it, he talks about the science of motivation what is it that motivates us. When we look into that? It's quite surprising particularly when you want. To motivate people to do more creative things more sophisticated thinking for these kinds. Of tasks, motivation matters a lot the nature of the motivators matters too whether. They are in extrinsic or intrinsic. Extrinsic motivators are external to the person. Being motivated more money, a scary boss or competing for a reward or promotion. Intrinsic motivators are internal to the person. Learning about a subject because it fascinates you or tidying up because you like a tidy work area. When it comes to work, particularly for complex tasks intrinsic motivation wins by miles over extrinsic one of the surprising findings, for example, repeated in experiment after experiment for decades is that if you pay people more you get worse results I. Am not suggesting that we should all. Look for low paid work but what. This means is that once you get. To a certain level of reward enough that people think it's fair and then. It'S enough to meet their needs paying. More is correlated with lower standards of performance, not higher you can look at. This from an employer's point of view. Or from an employee's point of view as a good employer, it makes sense. To pay enough money so that it. Isn'T an issue but then figure out. How to amplify the intrinsic motivators we'll. Come back to that. As an employee, I think that you have to be careful to think about your intrinsic motivators too it's easy to be lured into a bad job by. Lots of money or other extrinsic factors. Status, a big office with free fruit. For example when what really makes you. Happy, what really motivates you maybe something else altogether the primary intrinsic motivators that Dan Pink calls out are autonomy, mastery and purpose. I think that these are good starting points when you're looking for a good job or a good employer do you like the aims or goals of the company? Does their purpose fit with yours? Is this something that you'd be proud to tell your friends about? I've worked in a variety of different sectors over the years but in the. Last few years I've done several pieces. Of work for companies that work in the medical sector I quite like that. It feels like I'm helping people not. Just in terms of helping people to. Do a better job with software which is one of my normal intrinsic motivators but also ultimately helping sick people to get better even if incredibly indirectly your purpose doesn't need to be direct like that your purpose may be to work with particular people or to develop particular skills. But this is important stuff if we want to enjoy our work and so do a good job. Can you say why you do what you do? What is it for? This is your purpose. Mastery is about being able to get. Better and better at something that matters to you. Maybe you want to become a great programmer. Maybe you want to solve problems that no one else has solved before, to be really motivated in your work, whatever that work is, mastery matters too. In software in particular, I think that one of the ways to look for this is to think about how your employer, current or prospective, supports your learning and development. In engineering terms, software is importantly a discipline of learning. So any employer that doesn't take this. Stuff seriously is somewhat suspect to me. I don't only mean things like do they pay for training courses or support visits to conferences, though both of these are reasonable questions to ask. But more generally, more pervasively, how do they think about learning and organize for it? Do they expect you to know everything already? Or are they hiring you for your. Potential and aim to help you to develop to achieve that potential? Autonomy is about the freedom to direct our own lives. In terms of software, this is also one of the biggest predictors of high performance in software development teams. The ability of a team to make. Their own decisions without asking for permission. Or coordinating their work with others outside of the team is a strong predictor of them being able to build better software faster. Being able to build better software faster is a strong predictor of better scores. On worklife balance, job satisfaction, lower rates. Of burnout, and generally less stress. And it predicts better commercial performance in. The companies that employ teams like this. So these are definitely the places that we are looking for if we want. Great places to work. These predictions are based on the findings. Of the State of DevOps report and what I've called better software faster here. Is actually what the State of DevOps. Reports say continuous delivery delivers. So now we have two different approaches. To identifying the best employers. We can look for the technical markers of continuous delivery and we can look. For the sociological markers of motivation. There are other important things, of course. Do you like the people that interview. You, particularly if one of them will be your boss? Are these people that you can learn from, or do you think you'll have fun working with them? Is the office a nice place to work? And does the pay travel and travel make sense for you? But I'm going to concentrate on these two other scales dan pink's markers for. Effective motivation and my markers for effective continuous delivery. One more thing before we get to that. You are probably not going to get to quiz people who are interviewing you in great detail. So think of these as questions that you'd like to find the answers to, but that you may need to guess. At some of those answers based on what you can learn and infer during the recruitment process. By all means, steer the conversation to. Try and find some of these answers. But don't just reel them off as a long list. So here are a few questions that, if you could find the answer to about a prospective employer would give you. Some insight into how they think about. Autonomy, mastery and purpose. This set of questions are looking at. The learning culture in an organization. Is this place going to allow you to grow your skills in a way that interests you? It's not always as simple as yes. Equals take the job and no equals. Reject the job, but they should give you better insight. For example, not all good companies employ. People that speak at conferences or contribute. To open source, but their reaction to. The question might be interesting if it's dismissive, you can do those things in. Your own time that's telling you something important. If it's encouraging. Well, not at the moment, but we run regular brand bag sessions to help. People to develop presentation skills, and we're. Looking to release some of our own code as open source next year. That tells you a very different story. Similarly, if you ask about pair programming. And they reject it out of hand, that's very different to a response like we tried it, but we found it. Didn'T work for us. I think this second organization is wrong too, but at least they're interested in trying things to see what works for. Them and what doesn't. Try to avoid being too dogmatic in how you score their answers, but also. If you hear an answer that you. Don'T like, think carefully about what that means for you. Autonomy is vital. There are multiple angles to this, but a good thing to look for is. The ability of a development team to. Make its own choices. Autonomy is more about team scope than individual scope. To my mind. I'd prefer answers that focused on the. Team rather than on individuals. If the answer to the question who. Has responsibility is the CTO or the architects, I'd be very suspicious of topdown. Programming by remote control. This is a very common anti pattern. If the answer is that everyone has responsibility for their own components, I'd be equally suspicious of a highly siloed, disconnected development organization. I'd prefer to look for answers that talk about development teams collaborating and making their own choices. Purpose is tricky, not because it's hard to detect, but rather because it's often missing altogether. This may be more about analyzing your. Own feelings, about how they think about their goals, and you may be able. To get some hints for that about. What the company thinks their purposes from. Their website, but not always. Purposes are usually easier to detect in startups, but they aren't the only place where it matters. Detecting the signs of continuous delivery is also incredibly valuable, but not divorced from motivation. As we've already seen. It's not much use asking, do you practice continuous delivery? Because many, maybe even most organizations that. Answer yes probably don't know what it really means. We can certainly ask the question, we. Just can't always trust the answer, so we need to be a bit more circumspect. We've already asked the question, who makes decisions about design? But the answer has some bearing here too. If the answer was anyone outside of the development team, then I'm immediately suspicious that this team can't be very responsive because design changes need to be bounced up the chain, so the pace is bound to be slow. Again, this is about building a picture, not being dogmatic. But this is certainly a warning sign that this team is probably not practicing continuous delivery. Questions like how many bugs there are. Or how often you release are indirectly. Related to the Dora metrics. High performance against these measures predict the. Operation of continuous delivery and all of. Those good worklife balance and commercial success scores that I mentioned earlier. If you don't get good responses to these questions, maybe thinking about probing more deeply on the Dora scores. Not every organization has heard of the Accelerate Book or the Dora metrics, but most of the good ones that I've. Come across lately have. If you get a blank response, this. May be a good opportunity for you to show off a bit, explain why. These things matter and how good scores on these metrics help to predict good. Outcomes for the development team and business. If you do get to see a story or feature description of some kind, look to see if it's focused on. The goals and outcomes from a user's. Perspective, or is it just a detailed description of tasks or changes to be made? If the latter, then be suspicious of. This being a feature factory where the. Goal is to churn out piles and piles of features, not to have an impact on users. I would certainly want to understand any prospective employers views on testing. If they assume that this isn't a. Developer'S job, but leave it to the QA department, I'd head for the door. Unless they were hiring me to fix this problem. If they talk about wanting to get. Better at automated testing and the difficulties. Of getting development teams to take it. Seriously, then I'd be a little cautious. Of what it was that I was joining and would want to explore that in more detail. It can be difficult to change a. Development culture, and not everyone wants to take on something like that. Signs of excellence in response to these questions, to my mind, are the team. Practices test driven development and behavior driven development developers own responsibility for testing. We can help you learn if you. Haven'T worked like this before, but that's the way that we work. As I said, none of this is as simple as looking for a perfect set of answers on some kind of checklist. No doubt some good organizations will miss out on answers to some of these questions. I think that in an interview at. Heart, we're trying to mine some understanding. Out of a potential employer. Do they value learning? Do they value individuals and interactions over processes and tools? Do they think that working software is more important than comprehensive documentation? Do they believe that collaboration is more important than contracts and bureaucracy? And do they act to prioritize responding to change over following a plan? Are they going to help you to achieve mastery? And do they value the autonomy of their development teams? As I said earlier, you probably won't. Get to ask all of these questions directly, but I hope that they might help you to figure out some of the things that you'd like to learn during the recruitment process. And to be honest, if you don't get to explore these ideas or if the interviewers are not willing to listen. And respond thoughtfully to your questions, then that's sending you a signal too. Thank you very much for watching.