devopsy.kinsta.cloud

Tag: continuous learning

  • Don’t Hire for Product Expertise

    Don’t Hire for Product Expertise

    We all know the jokes about talent recruitment that “requires a century of experience in AI/ML.” With the number of layoffs, no doubt this type of approach will get worse. But that is not generally a tech problem; it is an HR problem–the problem of having people hire in tech that aren’t active in or knowledgeable about tech.

    The real concern that is very much a tech problem is hiring for product and/or technology. I will say outright: Stop doing that except in very special circumstances. Hire for the ability to find information. One of the other things we all joke about is increasingly convoluted interviews where the hiring company wants you to solve their problems in a fraction of the time it would actually take them to do it. Again, if you’re a hiring company doing this, knock it off.

    IT is an ever-evolving field, more so once Agile and DevOps are taken into account. Indeed, we would not be far off if we renamed the field Continuous Evolution, because tomorrow is guaranteed to hold different solutions, no matter what. The idea that requiring experience in Grafana or mastery of Python is an indicator of long-term success is downright farcical. There are positions where this is tolerable–if a position is for maintenance of a traditional app that is not going anywhere and is not getting massive updates, then a list of what tools are desired for the role is easy to build and will be lasting. But I would argue that hiring specifically for that application’s needs is not in the best interest of the organization as a whole, because that person is not portable and adaptable. For modern development, particularly of new products that are just now being architected, the needs are going to change in the process, so claiming you want X years of experience in Spring (when it may use a different framework by deployment time) is not productive.

    As we move into belt-tightening yet again, employees who can do the job and know how to look up new information will be worth their weight in gold. Having a person who can work on existing applications and drive innovation in future applications all in one body is important. Giving them a chance to exercise that drive to learn is also important, but is a separate issue. None of the areas I cover–applications, operations and security–are standing still or even coming close to standing still. The need for people who can go find out what is needed is huge.

    And while the internet is a horrendous mix of good and bad, the ability to find information—and even solutions to problems—is undeniably better than it ever has been. Having people skilled at using that information resource is the key to moving forward.

    So, find people that can solve problems given a modern context. Hiring for technology will solve today’s problems, but problems are not restricted to today, so solve ongoing problems. Gate for basic tech knowledge and skills, then evaluate for the ability to find answers. A far better use of everyone’s time during interviews would be—using email as an example—“Hosted Exchange just went down. Walk me through your troubleshooting steps. You have a couple minutes.” Or—using development as an example—“We just discovered that an OSS library we use has unacceptable vulnerabilities. Walk me through how you would find instances of it and what steps you would take to find replacements. Compliance is breathing down our neck, you have a couple of minutes to show us.” You get to see how they approach likely problems, they get to ask about the environment. Far better than “Show us all the steps to get BGP routing configured,” or “Develop an entire B-Tree while we watch,” questions. Certainly better than any question that ends with “And don’t use the internet.” Are you kidding? Can we talk about the field and what year it is?

    As I’ve said off and on over the years, you want the best coworkers you can get or the best employees you can get. Either way, hiring for expertise with a given tech product is not the best route to that goal. You rock—so get people with you who do, too. It’s not going to get less complex, so have peeps that can keep up and carry a load, no matter what tomorrow’s technology looks like.

  • Stop Hiding the Cloud From Your Developers

    Stop Hiding the Cloud From Your Developers

    If you say a person or organization “goes to great lengths” to achieve something, it means they try very hard and perhaps do extreme things to accomplish their goal. One example I’ve seen is that of more traditional companies “going to great lengths” to “hide” the cloud from their pool of potential technical consumers doing work like development. Instead of saying, “Here it is,” they block or restrict users from direct consumption. Under this model, developers don’t directly login to Azure or AWS, they go to the “internal corporate portal” and fill out a request form for the resources they want and submit it. Then, someone eventually processes the request and creates what is needed.

    In extreme cases, organizations create “cloud teams” and staff those groups with people who build cloud resources on behalf of downstream technical consumers, like developers. Potential consumers must submit a request with a detailed design document specifying everything they want. Then, the cloud team schedules the project and delivers it at a future point. The whole process mimics the historical waterfall approach to software development or systems implementation.

    Why do things this way? It always seems to come down to four distinct drivers:

    Costs: “If we give open access, we will end up with a huge bill!”
    Compliance: “Everything built must meet our security standards.”
    Complexity: “Most users will waste time trying to figure it out.”
    Control: “Our group has always coordinated access to resources.”

    In traditional companies, the reasons for this restricted access always seem to be some variation of those on the list. And when you rebut with something like “Do you think Facebook, Twilio, Netflix, etc. restrict their developers’ cloud access?” the answer is usually something like, “Well, those are elite tech companies; we’ve always done it the way we do it now …”

    In most cases, there is no singular argument you can make to change someone’s mind, or expand the range of possibilities. But you can offer facts. So, let’s take on their arguments one at a time and see if we can rebut them.

    Costs

    Argument: “If we open up the cloud to everyone, then all the developers will endlessly create virtual machines (VMs) and associated resources and services, and we will end up with a huge bill.”

    Rebuttal: There are certainly examples of this; do a search for some variation of “unexpected cloud costs,” and they’ll pop up, especially from a few years ago when cloud adoption was just taking off. But what about today? What can be done to control costs? Even though there are lots of tips and ideas on how to control cloud costs, I’ll offer one simple possibility that directly applies to developers and development groups that is not often mentioned in many articles: implement a cloud resource quota per developer or dev group.

    In AWS, for example, you can allocate via IAM; with Azure, you can use resource groups. The upshot is that there is a way to restrict the number and amount of resources that a single user can consume. So, whether you have 10 or 1,000 developers, you can use these built-in mechanisms to limit and then estimate what your consumption will be. If I have 100 developers and I put a limit on the number of VMs, the number of GB of RAM they can allocate and the amount of storage each developer can consume, then haven’t I just created a “cap” on consumption? The quota concept gives you a path to a “predictable” bill every month.

    Compliance

    Argument: “If we open up access to everyone, they’ll create VMs that don’t adhere to all our internal security standards.”

    Rebuttal: Aren’t developers just looking for a VM (or VMs) to do dev work? We aren’t talking about building production-hardened VMs to host applications. We are talking about giving developers the proper sandbox in which to do their work. So, from this perspective, requiring that developers only create VMs that adhere to strict compliance standards reserved for production servers doesn’t make sense.

    For example, maybe one of your compliance standards is that all production servers have a monitoring agent installed on them. Fine, that makes sense; what about dev/test? In dev/test, I might be spinning up a VM or a container that only exists for a short time, maybe even less than an hour while some tests are running. Does it make sense to require that a monitoring agent be installed on a VM that will only have a one-hour shelf life? Just throwing out the term “compliance” as a catch-all is not a real solid objection. Perhaps for dev/test, there are minimum standards you would want to follow regarding OS levels, patches, etc., but the VM(s) you use in dev/test do(es)n’t necessarily need to have all the additional security requirements reserved for production servers.

    The other part of this objection we hinted at earlier is that you have to transition to “cloud thinking.” Resources that exist for the next 10 minutes in the cloud could intentionally be gone shortly after that. In the cloud, you can quickly create and destroy VMs, or entire environments of VMs. That is what makes the cloud a game-changer versus traditional on-premises methods. You can’t apply the same on-premises considerations to the cloud one-to-one. You need to come up with a new thinking model that takes into account what it means to use the cloud versus how you did it before on-premises.

    Complexity

    Argument: “It’s too hard to figure out some of these cloud architectures, and developers will waste time trying to do so versus having a central team do all the work correctly the first time.”

    Rebuttal: Without the commitment to being a “learning organization,” there can be no DevOps, no transition/migration to the cloud, no digital transformation. Check out item number six on this list of 7 Ways to Make Developers Happy. (Spoiler alert: it’s ‘promote continuous learning.’)

    If “complexity of learning” is one reason why you restrict your teams’ access to the cloud, then you are missing the point of what it means to be a technical expert. Developers partially define themselves by the depth and the range of knowledge that they have accumulated, so continuous learning is a significant component of keeping developers “happy.” Not to mention that happy developers are more engaged and tend to stick around longer at companies that keep them that way; you’re risking losing the technical talent you do have, which has a host of detriments to your organization.

    Control

    Argument: “If developers are creating their own servers, what does our team do?”

    Rebuttal: This one is the toughest of all to rebut. Many organizations have one or more infrastructure teams who are responsible for creating servers and resources and giving access to downstream consumers. These groups control the resources. Now, along comes the cloud where everything can be self-service. And the natural reaction is, “If developers are creating on their own, what do we do?”

    For many traditional companies making the transition to the cloud, there will still be many opportunities for participation. Instead of “architect,” now we need “cloud architect.” Instead of “engineer,” now we need “cloud engineer.” Also, what other higher-value work could you be doing for the company if you weren’t spending all your time provisioning and maintaining on-premises servers? Do you think all of the existing on-premises applications are going to go away overnight? Will your company become “cloud-native” in the next six months? What about all of the AIX, IBMi, Solaris and other legacy components that are in the data center? There will always be plenty of work for everyone to do. And it’s always an opportunity to learn some new skills.

    The reality is that giving developers direct access to the cloud (with controls) frees up many other corporate resources to work on things that are, strategically, more important. If your company is not cloud-native right now, then guess what? It won’t be for a long time. Maybe in the short term, you’ll be hybrid-cloud and then in the long term, cloud-native. Along the way, there will be opportunities for everyone to rethink how things get done and maybe learn something new along the way.

    If you are hiding the cloud from your internal customers, ask yourself, “Why?” Are the original reasons still relevant, or are they holdovers from a time long past? Maybe it is time to re-examine your original rationale for why developers don’t have direct access to the cloud. If the goal of your organization is to “service the customer,” “do more,” “move faster,” etc., then removing internal barriers to accessing the cloud is one way to make progress.

  • Learning ‘The Third Way’ of DevOps – Continuous Improvement

    Learning ‘The Third Way’ of DevOps – Continuous Improvement

    I refer to the third way of DevOps–continuous experimentation and learning, as simply continuous improvement. In some sense, there is no way to learn the third way of DevOps because it is, by definition, a moving target. It does make sense to discuss what is needed to create a continuous learning organization for DevOps continuous improvement that builds on mastery of the first way and second way of DevOps.

    As indicated in my blog Learning ‘The Second Way’ of DevOps – Continuous Feedback and my prior blog Learning ‘The First Way’ of DevOps – Continuous Flow, it is clear many organizations are struggling to realize well-engineered DevOps, even the first way of DevOps, continuous flow.

    The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve the higher level of benefits that continuous feedback offers, when engineered well. Once the second way of DevOps is achieved, then an organization will naturally want to master the third way of DevOps, to sustain and grow their DevOps capabilities.

    DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Improvement

    There are no training resources dedicated solely to the third way of DevOps—continuous improvement. Many of the same resources as the first way of DevOps and the second way of DevOps do have some relevant information, though. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

    Why Is Learning Continuous Improvement Important to Engineering DevOps?

    The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Retention and development of highly skilled and hard to find experienced DevOps professionals and SREs makes it important to develop skills in-house.

    How Is Learning Continuous Improvement Accomplished?

    The following are recommended engineering practices for learning continuous improvement:

    • A continuous learning culture encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
    • Mentoring is an explicit program.
    • Retrospectives are structured to thoroughly analyze significant, unexpected events and determine solutions that will prevent the events in the future.
    • An active online library of DevOps and SRE training resources is maintained that tracks the latest and most innovative approaches to DevOps and SRE.
    • DevOps and SRE teams evolve their skills and advance their careers by engaging with industry thought leaders to continuously update training content.
    • Partner with trusted education and training partners ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
    • A portion of DevOps and SRE teams time is allocated for training and education.
    • Cross-team sharing of recommended engineering practices is proactively pursued using the concepts of Yokoten—proactive sharing of practices between teams.

    What Is Needed to Implement Learning Continuous Improvement?

    The following are recommended engineering practices for implementing a learning program for continuous improvement.

    • Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist).
    • Conduct a continuous feedback DevOps skills gap assessment.
    • Define a training strategy that best address the gaps and fits the needs and priorities of the organization.
    • Define a training budget that includes expenses and time allocations per role and skill.
    • Determine which skills and roles can be covered by inexpensive self-study resources.
    • Determine which skills and roles warrant more costly commercial training.
    • Identify training goals for each role.
    • Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.
    • Create a continuous learning culture that encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
    • Build an active online library of DevOps and SRE training resources that tracks the latest and most innovative approaches to DevOps and SRE.
    • Engage with industry thought leaders to continuously update con tent for DevOps and SRE teams to evolve their skills and advance their careers.
    • Partner with trusted education and training partners to ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
    • Put in place means to make training resources visible and available.
    • Set training goals for teams and individuals.
    • Put in place incentives and recognition programs for training.
    • Track training progress.

    Some of the best sources of DevOps training resources are listed below:
    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro.
    3. Udemy.com
    4. Recorded talks and publications of IT Revolution
    5. Books such as my own Engineering DevOps, by Marc Hornbeek.

    What This Means

    The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences, and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

    Organizations must approach DevOps training strategically and continuously to leverage training resources to best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • Learning ‘The Second Way’ of DevOps – Continuous Feedback

    Learning ‘The Second Way’ of DevOps – Continuous Feedback

    As indicated in my prior blog Learning the ‘First Way’ of DevOps–Continuous Flow, many organizations are struggling to realize well-engineered DevOps, even the ‘first way’ of DevOps – continuous flow.

    The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve greater benefits that continuous feedback offers when engineered well. DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Feedback

    There are no training resources dedicated solely to the second way of DevOps—continuous feedback. Many of the same resources used to learn the first way of DevOps have some relevant information, though. DevOps monitoring, release automation and security tools publications, articles and tool vendors are a good source. A DevOps expert who is experienced with mature DevOps can select the training information that is relevant to the specific continuous feedback tools and feedback metrics used by the enterprise.

    Why This is Important to Engineering DevOps

    Continuous feedback requires a mature understanding of DevOps concepts and practices. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security.

    How Is Learning Continuous Feedback Accomplished?

    The following are recommended engineering practices for learning Continuous Feedback.

    Roles and responsibilities are assigned to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist). Continuous feedback DevOps skills gap assessments are conducted periodically. Dev and Ops training strategies are designed to address gaps and priorities of the organization for DevOps continuous feedback. A training budget that includes allocations of expenses and time allocations per role exists to support continuous feedback. Continuous Feedback goals and SLAs are defined for each role.

    Recruiting job profiles match skill requirements for DevOps skills relevant for continuous feedback. Training resources are available and visible to those that need continuous feedback training. Training goals set for teams and individuals include goals for continuous feedback. Incentives and recognition programs support Continuous Feedback training. Continuous feedback training progress is tracked and visible.

    What Is Needed to Implement Learning?

    The following are recommended engineering practices for implementing a learning program for continuous feedback.

    Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., e.g., DevOps sensei, training PM, evangelist). Conduct a continuous feedback DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

    Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training Identify training goals for each role. Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.

    Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for training. Track training progress.

    Some of the best sources of DevOps training resources are listed below:

    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
    3. Udemy.com
    4. Recorded talks and publications of IT Revolution.
    5. Books such as my own “Engineering DevOps,” by Marc Hornbeek.

    What This Means

    To accomplish the benefits of the second way of DevOps—continuous feedback requires a commitment to continuous learning and mastering skills beyond what is needed for the first way of DevOps–continuous flow. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security. Organizations need a trained workforce to succeed with DevOps. Organizations must approach DevOps training strategically and continuously to leverage training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • Learning ‘The First Way’ of DevOps – Continuous Flow

    Learning ‘The First Way’ of DevOps – Continuous Flow

    Many organizations are struggling to realize well-engineered DevOps, even ‘the first way’ of DevOps – continuous flow.

    DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Flow

    The first way of DevOps, continuous flow, is the foundation for DevOps.

    Why Is Learning Continuous Flow Important to Engineering DevOps?

    A knowledgeable, skilled workforce is needed to meet strategic objectives. Without a solid understanding of DevOps concepts and terminology, communication between people and teams is inefficient and a source of bottlenecks and misunderstandings. Developing hands-on skills for the tools and workflows is needed to understand and implement DevOps pipelines. There is an industry-wide shortage of skilled DevOps candidates. New skills foster innovation. Knowledge workers reduce production costs and reduce mistakes. Having skilled coworkers makes for a satisfying working environment. Employee retention is better. Competitive advantages are derived from knowledge.

    How Is Learning Continuous Flow Accomplished?

    The following are recommended engineering practices for learning continuous flow.

    People are encouraged to be continuous learners with an ongoing commitment to DevOps skills development. DevOps training is approached strategically to ensure DevOps training is well aligned to business goals. DevOps skills gap assessments are conducted and used to define and refine the training strategy. Leaders and cross-functional teams are encouraged to take DevOps fundamentals training. Leaders define a training strategy that best fits the needs and priorities of the organization to meet critical skills gaps.

    The training strategy considers which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly training. DevOps training has a distinct budget. Compliance to DevOps training programs are tracked. DevOps leadership training is offered to management and staff that have a role relevant to DevOps. DevOps tools training includes the recommended engineering practices for using each DevOps tool in the Service Catalog. Staff are encouraged and supported to take DevOps certifications that are relevant to their assigned roles.

    A DevOps training program is defined and includes a recommended curriculum for each role including leaders, developers, QA, Ops, and infrastructure and security staff that are operating in a DevOps environment. Recommended DevOps training resources are cataloged, and the catalog is visible for all stakeholders. Merit and recognition programs encourage employees to master DevOps skills.

    All staff is allocated time for DevOps training. DevOps mentoring programs supplement formal training. Job swapping and immersive training is encouraged and planned. People are encouraged to attend external conferences and meetups and share what they learn with other team members.

    What Is Needed to Implement Learning for Continuous Flow?

    The following are recommended engineering practices for implementing a learning program for continuous flow.
    Assign roles and responsibilities for DevOps training leadership (e.g., DevOps Sensei, Training PM, evangelist). Conduct a DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

    Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training. Identify training goals for each role. Ensure job recruiting profiles match skill requirements for DevOps skills that are most relevant to the organization strategic goals. Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for completion of training.

    Some of the best sources of DevOps training resources are listed below:

    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
    3. Udemy
    4. Recorded talks and publications available through IT Revolution
    5. Books such as my own Engineering DevOps, by Marc Hornbeek.

    What this Means

    Organizations need a trained workforce to succeed with DevOps—even ‘The First Way’ of DevOps—continuous flow. Organizations need to approach DevOps training strategically to leverage DevOps training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • Learning DevOps: All You Need Is a Browser

    Learning DevOps: All You Need Is a Browser

    One of the most exciting things about a career in IT is the constantly changing landscape, providing almost infinite opportunities for learning. But this is also one of the great challenges IT careers: It’s just so hard to stay on top of everything. Hence, it’s not uncommon for people to learn some skills, find a niche and get comfortable there. The trouble is that comfortable niches get squeezed shut over time, and the opportunities fade away. This is where upskilling becomes important—to grow new skills, find a new niche and enjoy fresh comfort.

    As DevOps has become such an important part of today’s landscape, DevOps skills are in high demand. Thankfully, the DevOps community recognizes the need to develop talent. As Dr. Richard Cook put it in the IT Revolution Symposium of Safety Culture, Lean, and DevOps, ‘’DevOps is not simply the practice of fixing problems or generating velocity. DevOps is also the practice of building a community of people who do DevOps.” There are many ways that this can work: on the job coaching and mentoring, meetups, conferences, training courses and certifications. The trouble is that many of those are difficult to scale due to demands on people’s time and places to get together, and that was before we faced the challenges imposed by social distancing.

    Thankfully, the last few years have seen the rise of interactive online training platforms that provide an easy-to-access browser-based entry point for users. Behind the scenes, the platforms harness cloud-based infrastructure or containers as a service to provide realistic environments and scalability. Course content is generally structured in markdown or similar, along with files that define flow, mini-quizzes and any challenges that students are expected to complete. This allows training to be delivered at web-scale, reaching much larger audiences than in-person workshops and at a much lower cost per student. It also provides a safe environment for students to try things out and explore away from the packaged course flow. That safety is a crucial support for the third DevOps way of continuous learning by experimentation because it allows students to try things without any concerns about messing up an environment or running up a bill with a cloud provider. It’s also worth noting that a DevOps learning journey is generally more of an iterative process in smaller pieces because the three DevOps ways of flow, feedback and continuous learning by experimentation apply as much to learning DevOps as they do to practicing DevOps.

    In some cases, course content has been open sourced, which allows an inquisitive student to see how things work behind the curtain (and maybe suggest improvements or fixes). Open source also provides an opportunity for course content to be modified and remixed to different environments and use cases.

    Sample code for environment configuration from shift left on security module

    Courses can also make use of API-based interconnectivity between systems through mechanisms including webhooks and identity tokens. That enables systems outside of the training platform, such as collaborative source control, to be incorporated into the overall experience. It also means that training environments can be customized to use the particular tools and practices adopted by an organization so that people can work in familiar ways (or get used to new ways of working).

    Web-scale online training platforms first arrived to help people learn about tools and platforms. But now the range of things that we can do with them has expanded dramatically, which means they’ve become a valuable resource for learning more about DevOps. Whether you’re just getting started with DevOps or looking to develop deeper skills, there’s likely to be something online that can help. The courses also tend to come in bite-sized modules, meaning you can run through a whole bunch if you have time on your hands, or chip away that them while waiting for a build to complete or a huge upgrade to download.

  • What the Best Developers Do to Be Great at Their Jobs

    What the Best Developers Do to Be Great at Their Jobs

    Good developers are in demand—great ones, even more so. With software development employment in the U.S. expected to grow by 21% by 2028, the need for engineers is only going to surge further.

    But this doesn’t mean that the labor landscape will become uncompetitive: Now more than ever, individuals with a passion for software are entering the field, and organizations will only be looking for the best. As the amount of people going into software development goes up—with global numbers expected to reach 27.7 million by 2023—it will become increasingly important to demonstrate your skills and dedication to the profession.

    The gap between a good developer and a great one is bigger than you may think. Here’s what the best developers do to excel at their jobs and lead in their field.

    The Best Software Developers Know How Their Skills Fit Into the Big Picture

    While a good coder handles the responsibilities they have within their role, the best coders make sure they see the big picture. They take the time to understand the foundations of how businesses work, including revenue, profit, bottlenecks and the strategies of departments other than their own. 

    This might mean investing extra time into general business self-education or holding meetings with other departments, but great programmers know it’s worth it in the long run. They recognize the importance of grasping how the cogs of an organization come together to keep things running—and exactly how they fit in.

    By having this 360 view, they can hold influence in areas outside their remit and clearly match the business’ mission to their own work. Valuable coders will use their problem-solving mindset to propose solutions to company-wide problems and put themselves in the shoes of other team members.

    Rest and Relaxation Is Vital for Productivity

    Far from the stereotype of frequently pulling caffeine-fueled all-nighters, the best developers know that, like the powerful systems they work with, they also need some downtime to recharge.

    Great coders challenge the stereotype of having a bad diet and inactive lifestyle and prioritize their own health and well-being. They recognize that as soon as you pass the threshold of 50 hours of work a week, you’re no longer productive. In fact, working too much can be counterproductive, as you’re much more likely to make mistakes.

    Great developers know when to shut down their computer and spend time with their families, do some exercise, spend time in nature and eat a healthy meal. This time to recharge is essential in order to go back to work refreshed and ready to tackle any problems with a clear and rested mind.

    Continuous Learning Is Crucial for Progression

    Ideally, all developers should be making efforts to advance their education in the field they’re in. As a developer, if you stop studying, you’re bound to get stuck at one point or another. The best coders make this a special focus in their lives, and make sure they’re always up to date with the latest developments in the technologies they work with.

    It could be a new coding language, new frameworks or a new technique. Great coders are constantly making a concerted effort to advance their own education. Ultimately, they are always asking “why,” and are unafraid to experiment using their newfound skill.

    Developers can easily find online courses to supplement formal education. Taking part in hackathons is another way to boost extra learning, as well as keeping up with technical blogs and podcasts.

    Great developers also follow other passions outside of coding. For example, the logical nature of software development allows coders to excel at learning other skills, such as languages, playing an instrument, martial arts or even flying a plane. It enables them to exercise the same part of their brain while enjoying something fun and non-work related.

    Personal Projects Show Dedication and Independent Thinking

    Coders know that the best way to learn how to build great products is through practice. Even if the project ultimately fails, building a product will always provide important lessons to apply the next time.

    Side projects that a developer might work on include personal tools, open-source libraries, a startup idea or a freelance project. These personal projects allow programmers to be in the driving seat: They are forced to solve problems independently instead of asking for help, equipping them with skills that might otherwise take longer to gain.

    Engaging in independent work also allows developers to explore and utilize the new languages and frameworks that they gain in their personal education efforts. When developers that have spent time working on their own projects try to prove themselves in the job market, they will stand out against those that have remained largely within the confines of their professional role.

    Ultimately, the vast majority of developers are in the game because they have a passion for building exciting and useful products. This makes it easier to find those who go the extra mile to really hone their existing skills and learn new ones. But, like in any profession, there will always be a certain percentage that remains a cut above the rest. Take a holistic approach to your career in software development with this advice and raise your game, and chances of landing that dream job.

    — Phil Alves

  • Automation and Its Impact on Cultures

    Automation and Its Impact on Cultures

    Let me tell you about my granddaughter. She’s 14 years old and wicked smart. For a while we did pair programming together online in Python. In the old days you took your grandkids fishing. Today we code. Go figure.

    These days, we don’t program together as much. She’s too busy preparing for math competitions. As I said, she’s wicked smart. Needless to say, my granddaughter has quite the future in front of her.

    A few weeks ago, I had the opportunity to visit her in real time and space. We sat around drinking hot chocolate and cappuccino, talking about Big Picture stuff. That’s what grandparents are supposed to do with their grandkids, talk about matters beyond the day to day. At one point during the conversation I asked her the following question, “Are you friends with anybody who has trouble reading?”

    Her reply was, no. All her friends read quite well and were interested in things that interested her. She wasn’t bragging or anything like that. It was just a matter of fact. All her friends are smart, engaged, have cell phones and know how to work a computer.

    My question came from a book I had just finished reading, “Coming Apart,” by Charles Murray. One of the key points that Murray makes is that we’re dividing into two cultures and the distance between the two is growing wider. A key way to figure out how far from that “other” culture you are is to tally up the number of friends you have who have trouble reading. One camp will have a lot. The other will have practically none.

    Back when I was my granddaughter’s age I had friends who had trouble reading. We met playing pickup basketball. The ability to read wasn’t important in that context. We based friendship on other factors. We played ball and rubbed off on each other. Some of the things that the poor readers were good at rubbed off on me. I like to think some of my better qualities rubbed off on them.

    But that was then and this is now.

    In the book, “Brave New World,” written in 1932, people are born in test tubes according to genetic recipes. Some grow to be highly intelligent, creative, analytic Alphas. Others grow up to be be Betas, people that can perform highly complex tasks such as mixing volatile chemicals, but without having an inkling of understanding as to why they are doing the task. Gammas were good at adding up numbers and thus, become bookkeepers. Deltas are the truck drivers and elevator operators. Epsilons are grown to be three feet tall and abhor the outdoors. They do the dregs of factory work, climbing in and under machines.

    Now, hold that thought while I tell you about my daughter.

    My daughter is a high school teacher. Most of her students are from what is termed, the wrong side of the tracks. They don’t read that well and are not terribly engaged in school. But, they do have cell phones and they know how to use them—mostly to text back and forth to home and with friends in classes in other parts of the building. To use the transportation analogy, for all intents and purposes they use of technology not so much to explore but to get from one place to another, something a driverless vehicle will do better than the human counterpart in the not-too-distant future.

    So, what does this have to do with DevOps?

    We in DevOps are the people who are going to drive most, if not all, the technology that will control the world. We are the Alphas. To get into our club you need to be very, very smart. Our work is complex and requires both commitment and ability to engage in continuous learning. When my granddaughter comes of age, she will mostly likely get into the club, maybe with honors. She lives in a world of increasing returns. Because she is smart, she hangs out with smart people. Because she hangs out with smart people, she will get smarter. To use an analogy: Those who know how to work GitHub have a universe of code at their disposal. Thus, they will make a lot more code for the world to use. Those who can’t do a pull request are stuck dead in their tracks. Access to opportunity provides more access to opportunity.

    Using the model in “Brave New World,” those using GitHub creatively as part of the software development life cycle can be considered Alphas. Those who can’t are Betas, Gammas, Deltas and Epsilons. The really bad news is that the work of Betas, Gammas, Delta and Epsilons is low-hanging fruit for replacement by automation and robotics. The work of Alphas is a lot more difficult to emulate with machine intelligence. Corporate employers will still need them. The Alphas will do just fine.

    Hopefully, those who are displaced by automation will be assuaged by low-cost television and cell phone plans that offer unlimited data and texting. Otherwise, they’re going to be looking around for something else to do instead of working. Hopefully there will be “something else to do” while the other culture is prospering.

    My granddaughter’s world reflects the trend that Murray and others describe. We’re dividing into two cultures and the distance between these cultures is growing. The sad part is that the experiences that used to provide a bridge between cultures are becoming less common. There are fewer common spaces in which we can rub off on each other benignly, with no other agenda than to get the ball through the hoop. If the trend continues, the cultures will grow so far apart that they will become unrecognizable to each other. Once recognition leaves the landscape, understanding and empathy are not far behind. You cannot have affinity for that which you cannot see.

    Is it possible to reverse the trend? Is it possible to have an outcome other than the very probable one on the horizon? I don’t know. But, if we don’t try, the ramifications will be dire.

    — Bob Reselman

  • Learning in the Continuous Customer Economy

    Learning in the Continuous Customer Economy

    We live in a continuous customer economy. Buyers in the 21st century are continuously discovering, adopting and discarding products and services online, telling us—very loudly and unequivocally—that value isn’t perceived in the actual product itself, but rather in our ability to change a product continuously. So, it’s now about the options to change the product, not the product options themselves.

    This utter lack and loss of brand loyalty puts companies at an insane disadvantage. They’re living with a “see you later” digital mindset, where it’s easy for consumers to say goodbye to something they know online for an opportunity with the newest, next best thing.

    Take this to the next logical business level and you see why continuous transformation of your organization is so critical. If you can’t continuously transform the way you deploy your people, processes, skills and resources, so everything is aligned with the consumer’s “see you later” mindset, there’s no way you can keep up with customers, who are continuously discovering, adopting and discarding products at what seems like warp speed.

    Obviously, this means learning and acquiring new knowledge fast.

    The same old knowledge, the knowledge of the past, just doesn’t work in the world of now. But, more profoundly, to continuously transform your organization and meet customers where they are today, you need to learn how to learn.

    Yes, sure, you have to learn from customers and gain an understanding of what they want and need. But every organization does that today. It’s no longer enough to simply grasp that insight and intelligence and run with it. No, you have to continuously improve how you learn from customers in this fluid and fast-changing world.

    Why? Because, at the end of the day, continuously improving how you learn is the only way to continuously transform your organization. And, thus, continuously improving how you learn is the only competitive advantage you have.

    Continuously Improving What—and How—You Ship

    Assume, for a moment, that you’re shipping an update of 1,000 lines of software code each week.

    That’s great.

    You’re likely using continuous delivery.

    But if you can’t continuously improve how you’re learning from customers and continuously improve the teams inside your organization, you can’t ship continuously improved products. So, you need to improve what you ship and how you ship to continuously transform your organization.

    Here’s an example of how this works.

    Let’s say your software development team senses the customer wants an improved red button that’s square instead of round. Okay, development of an improved red button proceeds and is completed in one week. But, at the same time, the team creates an automated test for the red button as well as clear metrics for determining if the red button is actually the problem. Remember, the idea that the button needed changing is a hypothesis until it has been tested with customers.

    So, in addition to shipping the new square button to some customers, the team keeps some subset of customers using the round button. The customer test is then simply whether the click rate of the square and round button differs.

    Let’s imagine that the processes are not currently in place to enable the development team to receive these metrics, as many teams are kept in splendid isolation from the results of their work. Then the establishment of this relationship, perhaps with the web operations team, is also going to be required.

    This is as much a requirement of successful deployment of these features as the features themselves. The focus on the delivery of function, as well as developing internal capability, is a core principle of continuous transformation.

    The Two-Product Principle

    This is the Two-Product Principle.

    Think of the product we ship to the customer as “Product 1.”

    Meanwhile, the internal capabilities we wish to develop—our view of what we need to improve while we build—is “Product 2.”

    To recap two critical points:

    • You always ship twice—you ship an improved product externally and you ship improved capabilities internally.
    • All of our product decisions, what to build and what to deliver, are theory until the customer actually uses the deployed product and we learn from that interaction.

    If you take these two critical points to heart, then your organization will do all it can to shorten the time to deployment and action to shorten the time to gain new learning in the market. This limits the length of the costly business guessing game, the cash-draining theory time.

    Continuously Learning at High Velocity

    The way you can do this is by continuously shipping, continuously delivering, continuously learning how to improve how you learn and deliver—continuously improving your internal capabilities and continuously transforming.

    Unfortunately, many organizations that want to increase velocity go faster without improving their ability to learn at this new speed.

    The implications of this short-sightedness are profound: When you’re leaning and looking backwards, you’re not improving how you learn from your customers in real time and, instead, you’re adding to your risk going forward because you’re so out of step, and out of touch, with what the market wants and needs.

    Every Act of Design is an Act of Feedback

    Too many companies fail to obtain crucial feedback. They throw a ball up in the air and walk away before it actually lands. We see this in software development when an organization releases a new quarterly product or feature and returns four months later; sadly, this approach doesn’t allow for much effectiveness tracking, or much learning, or much improvement.

    Which is why every single action in the continuous transformation process needs to be an act of design. The act of design is an act of feedback. And, in continuous transformation, you’re continuously getting feedback—whether you’re shipping product externally to a customer or you’re making changes inside your organization.

    The bottom line is that you need to continuously test your assumptions about the world, as well as your effectiveness in responding to those assumptions, if you want to keep up with continuously changing customers in the continuous economy of the 21st century.