Category: DevOps Culture

  • Technical Debt is a Major Threat to Innovation

    Technical Debt is a Major Threat to Innovation

    A survey published today suggested that technical debt is starting to take a heavier toll as IT environments continue to become more complex to manage.

    The survey of 400 IT leaders at organizations with 1,500 employees was conducted by Foundry, the market research arm of International Data Group (IDG) on behalf of Insight Enterprises, a provider of IT services. The survey found that 86% of respondents reported their organization was impacted by technical debt over the past 12 months, with the top areas affected being the ability to innovate (43%), meet service level agreements (41%) and avoid downtime (37%).

    Technical debt is created when organizations cut corners and leave known bugs in the race to meet application delivery deadlines. Application code is often not as thoroughly tested as it should be. In some cases, it turns out that what was intended to be a minimum viable product doesn’t scale all that well. Quick fixes needed to improve performance are also frequently undocumented. Inefficient code also winds up consuming more IT infrastructure than required, which adversely impacts everything from cloud costs to the amount of carbon generated.

    Juan Orlandini, chief architect for the Cloud + Data Center Transformation (CDCT) division of Insight Enterprises, said every organization struggles with technical debt; it will never be eliminated, but it does need to be contained, he added.

    The challenge is instead of trying to keep the proverbial IT lights on during the COVID-19 era, IT teams are now being asked to innovate to advance digital business transformation initiatives, said Orlandini. A full 87% of survey respondents cited modernizing critical applications as a key success driver.

    As a result, many organizations are embracing platform engineering to bring more structure to their DevOps processes, he noted. The challenge, however, is striking a balance between a more centralized approach to DevOps and maintaining the ability of developers to innovate, said Orlandini.

    The issue, of course, is that in addition to massive technical debt, the latest generation of applications are more distributed than ever. The survey found 91% of respondents now rely on multiple public cloud providers for different workloads, with 54% of data residing on a public cloud. However, the survey also found on-premises IT environments are still relevant, with 20% planning to repatriate select public cloud workloads to an on-premises model over the next 12 months.

    Nearly three-quarters (72%) of respondents also noted data volumes are growing faster than their ability to manage them, with 64% ranking implementation of a data governance program to improve data management as their top data-related objective this year. Just over a third (35%) of the data estate is now, on average, driven by edge workloads, with 29% of respondents reporting that at least 50% of data volumes now reside on the edge. Nearly two-thirds (64%) expected that to increase in the next 12 months.

    A total of 85% of respondents also indicated their organization is using artificial intelligence (AI) to some degree to drive business insights and/or efficiencies, although only 36% reported having optimized their use of AI and machine learning (ML) across the enterprise.

    Finally, cybersecurity also remains problematic, with 51% reporting they were impacted by a cybersecurity breach over the past 12 months. Just 20% resolved their issue in one day, while 31% needed less than a week. Nearly half (49%) required one week or more to recover.

    It’s clear that IT isn’t becoming any easier to manage. IT teams need to find ways to build and deploy new applications while reducing technical debt so it doesn’t strangle future innovation.

  • DevOps Done Right: How to Succeed in DevOps From Day One

    DevOps Done Right: How to Succeed in DevOps From Day One

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

    You’ll learn:

    • DevOps best practices, processes and the tools you’ll need
    • Tips and tricks from experienced practitioners sharing their real-world experiences
    • The basics of DevOps
    • How to choose the right technologies
    • Common challenges and how to overcome them
    • The benefits of DevOps as a methodology and a career
    • And more!

    As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

    DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

    That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

    DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

    At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

    One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

    DevOps Onramp Virtual Summit - Submit your talk

    If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.

  • The Evolution of DevOps: Developer Productivity and Platforms

    The Evolution of DevOps: Developer Productivity and Platforms

    This article is part two in a series of three on the rise of platform engineering and its role in improving the developer experience. Read part one here.

    Developer experience is business-critical in organizations of all sizes and across all industries. In the first article of this series, I make the case that the cloud-native developer experience will be shaped and eased not only by platform engineering but also by the vital support of DevOps and/or PlatformOps teams. This flies in the face of the recent and somewhat controversial assertion that DevOps is facing extinction. In fact, it’s possible that DevOps is more important than ever, even if the role of DevOps has changed in the era of cloud-native development, supported by centralized developer platforms.

    Business stakeholders who depend on reliable, stable, scalable and secure software shipping fast and consistently understand the business case for an integrated DevOps team, and most developers and their teams understand the challenges of coding, shipping and running cloud-native software without the guideposts offered by a platform (and the DevOps team). The complexities of Kubernetes and microservices (and their contingencies) make getting to productivity difficult, which is why developer platforms are touted as the magic-bullet solution. But these platforms don’t build and maintain themselves, and the concept hasn’t quite reached the level of maturity at which developer platforms are available as commercial, out-of-the-box offerings.

    Developer Platforms: Who Paves the Developer Path?

    DevOps is not dead and claiming that it is ignores the need for the surrounding, supporting roles that pave the developer path. DevOps is evolving, in some cases into PlatformOps, and keeps workflows flowing and manages operations that support developers’ ability to ship their work into the world.

    Who paves the developer path? It’s actually a cooperative process between developers and DevOps/site reliability engineering (SRE) teams. In discussions with DevOps and SRE leaders about cloud-native development, one trend was a throughline: DevOps and SREs continue to play an instructive role in helping guide developers to realize the possibilities of self-service through supporting platforms.

    The level of full-service ownership this amounts to for developers varies depending on the organization and its goals. But the role of DevOps is still clear. For developers, there is a significant learning curve, and DevOps can help clear the way to the centralized developer platform. This platform, assuming all goes as planned, will not only improve the developer experience but also relieve DevOps teams of the firefighting that has been typical of their job until now. Paving the path provides an opportunity for DevOps/SREs to both develop better operational support mechanisms for developers as well as engage in more long-term and strategic operational work.

    DevOps Ways: Unlocking Developer Productivity via Developer Platforms

    Helping unlock developer productivity is one aspect of powering a positive developer experience. And the shift to a developer-first platform model reinforces the business commitment to the developer experience. It becomes defined by its optimized tools and workflows, which make up developer platforms. The platform approach also supports wider adoption of cloud-native development across larger organizations and broader industries beyond the more niche applications we’ve seen, thanks to clearer guideposts and abstractions.

    But becoming dev-first doesn’t kill off ops, which has been one recent point of contention. In fact, the three ways of DevOps continue to be critical:

    ● The First Way: Flow/Systems Thinking
    ● The Second Way: Amplify Feedback Loops
    ● The Third Way: Culture of Continual Experimentation and Learning

    Quoting industry luminary Gene Kim, “The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department—this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).” Essentially, it doesn’t matter who constructs the platform as long as they are thinking about the entire value stream, starting with customer requirements which, for an internal platform, are driven by developers.

    The Second Way is focused on creating right-to-left feedback loops. To quote Kim again, “The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.” For platforms, this hints at embedding both developers in platform teams and ops in development teams.

    The Third Way is focused on creating a culture that fosters two things: Continuous experimentation, taking risks and learning from failure and understanding that repetition and practice is the prerequisite to mastery. The platform you build today won’t be the platform you need tomorrow. This is why the ‘big bang’ approach to building platforms doesn’t work. Think big, start small and iterate fast. This is something DevOps is designed to do.

    In supporting the cloud-native paradigm, DevOps is far from dead. It’s a shifting discipline that involves a focus on centralizing workflows and infrastructure to improve the developer experience and reduce their cognitive toil. This toil stems from developer guesswork, and DevOps is best positioned to remove that obstacle. If we concede that developer experience is central to business success, and devex depends on being able to code, ship and run quickly and safely, DevOps is the fixer who enables crucial self-service access for developers and, as we will explore in the third and final part of the series, “platforms” the developer experience.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Monster.com

    AppZen
    San Jose, California
    Software Engineer
    $165,000 to $190,000

    Indeed.com

    Safeway
    Pleasanton, California
    Lead DevOps Engineer
    $147,500 to $206,600

    Dice.com

    Amazee Global Ventures, Inc.
    Broomfield, Colorado
    DevOps Engineer
    $140,000 to $150,000

    SimplyHired

    WEX, Inc.
    Remote
    DevOps Engineer
    $127,000 to $169,000

    LinkedIn

    Apple
    Newport Beach, California
    Site Reliability Engineer/DevOps
    $115,000 to $177,000

  • flox Unveils More Accessible Instance of Nix Framework

    flox Unveils More Accessible Instance of Nix Framework

    This week, flox launched a more opinionated implementation of the open source Nix framework that programmatically automates package management and system configuration.

    Fresh from raising an additional $16.5 million in funding, flox CEO Ron Efroni said the company will also make an enterprise edition of its namesake flox framework available later this year.

    The Nix framework has been available since 2003 and provides DevOps teams with a portable, fully isolated development, test and production environment along with a catalog and tools for managing software packages. There are more than 5,000 contributors to the platform, but Nix is based on a unique programming language that many DevOps teams have found challenging to master.

    The flox framework provides a higher layer of abstraction for invoking Nix, and provides a set of guardrails to make the framework more accessible to a wider range of DevOps teams, said Efroni.

    That approach will make it easier to share development environments and packages across teams, machines, individual developers and entire organizations. The framework also provides visibility into the software bill of materials (SBOM) for applications used in production environments to enable real-time vulnerability management and detection without scanning, noted Efroni. That capability makes it easier to discover dependencies spanning multiple architectures; many organizations today still try to track dependencies using spreadsheets and tools that don’t serve to make DevSecOps processes simpler to manage, he added.

    It’s not clear how many organizations are using Nix today, but Efroni said that as software development management continues to become more complex across multiple platforms and architectures, there is a clear need for a different approach to enabling portability at scale. The biggest obstacle is overcoming the psychological biases many DevOps teams have developed toward Nix over the last two decades, he noted. A more opinionated framework should reduce the overall fear factor associated with Nix, noted Efroni.

    Regardless of the frameworks employed, it’s become apparent that DevOps teams are struggling under the weight of all the code they must manage, much of it written in multiple programming languages. Many organizations that embraced DevOps early are now finding the platforms they deployed have become challenging to manage and maintain. As application environments become more complex, there is a need to modernize DevOps workflows. Less clear is whether those efforts might be focused on, for example, containers and serverless computing frameworks versus a framework such as flox that is designed to span multiple architectures and platforms.

    It might be a while before IT organizations develop a unified approach to application development and deployment, given all the preferences of individual development teams. However, with the rise of platform engineering, it’s apparent more organizations are trying to strike a balance between developer freedom and the need to reduce the total cost of DevOps. That cost continues to rise as additional software architectures and platforms are employed.

    In the meantime, flox plans to contribute to both Nix and its own more opinionated version of the framework in the hopes of one day making it easier to achieve that goal.

  • Atlassian Extends Scope of Jira Project Management Portfolio

    Atlassian Extends Scope of Jira Project Management Portfolio

    At the Atlassian Presents: Unleash event today, Atlassian announced it is adding a Jira Product Discovery application to its portfolio. Jira Product Discovery makes it easier for organizations to keep track of the ideas that drive software development initiatives.

    At the same time, Atlassian is making available Jira workflow and toolchain templates to make it simpler for software development teams to extend the scope and reach of the project management software they use to track those projects. Rather than each organization developing these templates, Atlassian is now providing them in a way that allows organizations to customize and extend them as they see fit.

    Finally, Atlassian also announced that an existing Jira Work Management tool will be made available for free through March 2024.

    Megan Cook, head of product for software teams at Atlassian, said these additions will make it easier for organizations to collaborate around software development projects that businesses increasingly depend on to drive revenue. The overall goal is to make it easier for multiple stakeholders of the projects to more easily collaborate with software developers that rely on Jira to manage those projects, she added.

    These latest offerings are part of an ongoing Atlassian effort to enable organizations to simplify collaboration and enable organizations to embrace value stream management (VSM) without having to acquire a dedicated platform. In some cases, organizations may decide to adopt a dedicated VSM platform, but a project management application should make it simpler for everyone in an organization to keep track of how software development projects are impacting the business, noted Cook.

    It’s not clear just how many businesses are aligning their internal processes around DevOps workflows, but as more of them realize how dependent they are on software, there is a clear need to collaborate more efficiently with software development teams. In fact, many organizations are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices. In some instances, updates to software are now being delivered faster than many businesses can absorb given the impact those changes have on digital processes.

    The irony is many business executives used to routinely complain about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

    The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. There may even come a day when organizations will need to restructure as the walls that once separated various fiefdoms become more porous.

    One way or another, the way organizations are managed is evolving in the digital age. Organizations are employing software to pivot more frequently as business conditions evolve. Each new idea can not only be tracked but also quickly evaluated for feasibility given the level of software development resources required, noted Cook. The challenge and the opportunity is as much about changing the culture of an organization as it is about modernizing the processes used to build and deploy software.

  • Leveraging Automation for Secure, Cost-Effective Mobile App Delivery

    Leveraging Automation for Secure, Cost-Effective Mobile App Delivery

    As businesses mobilize their customers and employees, they need to develop innovative mobile applications that safeguard user trust. But secure mobile development and manual security testing can be expensive and time-consuming—a bigger challenge in slowing economies. However, the latest innovations in security automation for mobile teams can drive down security costs by half while speeding release time, getting quality mobile apps to market faster to grow revenue faster.

    With mobile dominating all digital time spent online versus the web, businesses cannot compromise the safety of their mobile users and mobile data. Security automation integrated throughout the development process empowers developer, QA and security teams’ efficiency, enabling faster release cycles with built-in security. This approach powers success for digitally enabled businesses that depend on mobile apps to generate revenue, engage customers and tap new markets.

    A single security vulnerability within a mobile app can instantly damage a business’s financial stability, brand reputation and customer trust. Even highly respected brands like UnderArmour and British Airways experienced serious issues after their mobile apps were breached. Business leaders should consider the benefits of adding security automation directly into the development pipeline to drive quality and protect users in a cost-effective manner.

    Faster, Lower Cost Developer Cycles

    Suppose a business creates a 12-week plan to develop, test and release a mobile app software update with a labor budget of $60,000 per week. The development team creates a schedule to write the code in 10 weeks and allocates a two-week period for a manual security pentest. After developers finish writing the code, they must wait for the pentest results to point out any security issues. When testing uncovers security issues, devs, security analysts and QAs must determine which issues need to be remediated. Then the devs can fix the issue, retest to ensure it is properly fixed, then release it. Most of the time, finding any issues delays the release by weeks or months, delaying the expected revenue generation and other business benefits by weeks or months, in turn.

    Instead, businesses can take a cost-effective approach by running security automation continuously through the development life cycle. Dev teams can write code, allow security automation to run during off hours, and have tickets with built-in remediation info sent back to devs the next day. This can remove weeks of testing and remediation delays to ensure teams release on time and on budget. Businesses can cut costs further by establishing common coding, testing and remediation policies in advance and then deploying an automated policy engine to focus on just those security requirements and issues relevant to the policy to operate at the fastest pace possible.

    Integrating automated security testing into development tools enables DevSecOps teams to build, test, fix and release faster with security built in. Not only does this strategy increase the security and quality of the mobile app, it drastically lowers development costs by improving team efficiency.

    Faster, Lower Cost Security Testing Cycles

    Every organization with a mobile app has different security requirements. Those with low-risk mobile apps may outsource their security testing once or twice a year. Those in highly regulated industries like healthcare and financial services may have internal security analysts and test as often as every release and event outsource pen testing quarterly. Whether testing internally or externally, security testing costs can become a major pain point for companies looking to manage their finances efficiently.

    The average cost of a full-scope, two-week outsourced manual pentest costs around $15,000 to $20,000 per test. If an organization tests its mobile app on a quarterly basis, its pentesting costs jump to $60,000 to $80,000 per year. Internal pentesting teams can potentially be cheaper, but organizations still need to pay for analysts’ salaries and the tools and resources they need to conduct tests. Whether a business has an internal security team or relies on outsourced manual pentests, leveraging security automation can significantly reduce costs.

    Businesses with internal security teams can use automation to test builds immediately after devs release code. By continuously assessing code quality from start to finish, security teams can eliminate their testing time and speed up release cycles. Businesses that outsource security testing can use security automation to cut costs by reducing the frequency of full-scope manual pentests. Instead of testing on a biannual or quarterly basis, continuous automation can help reduce the testing frequency to once or twice a year with comparable coverage.

    The most efficient approach possible is the hybrid security automation approach of guided testing that combines daily automated security testing as mobile apps are built with periodic human security analysts for coverage of the parts of the mobile app that automation can’t cover. Guided testing starts below $20,000 per mobile app for unlimited automated security testing integrated into DevSecOps toolchain with four periodic guided tests per year, slashing outsourced quarterly pentesting costs by more than 75%.

    Mobile apps play an important role in helping businesses generate much-needed revenue, but running fast and cutting corners without security built in ultimately places the business and users at risk. So business leaders should take extra steps to keep them secure, and securing mobile apps can be achieved without breaking the bank. By incorporating security automation and innovations like guided testing into the mobile app development process, businesses can maximize the speed of delivery while simultaneously reducing costs and improving quality.

  • Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)

  • Platform Engineering: Creating a Paved Path to Reduce Developer Toil

    Platform Engineering: Creating a Paved Path to Reduce Developer Toil

    This article is part one of a series of three on the boom in platform engineering and its role in reducing cognitive load and creating a better developer experience.

    Developer toil and cognitive load in the cloud-native space is real. The complexity posed by microservices, Kubernetes, and “software-defined everything” almost necessitated that ops needed to solve many of these issues to support cloud-native development.

    Developers taking on full dev life cycle ownership and the requirement to shift left have resulted in cross-functional and operational concerns that have added even more complexity to already challenging workloads and unclear workflows.

    To fuel productivity and consistency and enable developers to build and ship apps faster and more securely, one must understand what a ‘paved path’ might look like and where responsibility for different aspects of the development life cycle resides.

    Supporting the Majority of Developers Without Alienating the Rest

    Most developers want and need paved paths, particularly as paradigms shift; the adoption of cloud-native development being one such shift. These paths must help them reach the “safety” and productivity on which they are measured in their daily output and provide focus for completing their tasks. Freedom to make choices about processes and tools is not a priority because it ends up being noise that adds to the cognitive load and, in most cases, does not serve the company’s software shipping goals. This majority needs tighter guardrails and guidelines to do their work and get their code into the world without having to figure out too many operational parameters for themselves.

    The cloud-native tooling landscape is vast, duplicative and overwhelming. Just trying to select and test tools could be a developer’s full-time job. Likewise, many organizations and developers have reported frustration—they are wasting a lot of time on repetitive work and routine tasks that deliver no business value, such as setting up environments and troubleshooting CI pipelines along with slow feedback loops in the development process.

    As organizations increase pressure to deliver more with less and do so more frequently, these responsibilities make for a poor and unproductive developer experience and a far-from-ideal use of organizational resources. Stack Overflow’s 2022 Developer Survey reported that 62% of respondents spend more than 30 minutes a day fixing problems and looking for answers, leading to somewhere between 333-651 hours of lost time per week across a team of 50 developers. This reinforces a need for upfront investment in the paved-path developer platform, which eliminates much of this frustration.

    It’s worth noting there is also a so-called 1% developer–one who wants to experiment and discover new tools on their own. Defining the developer experience within narrow guardrails ends up stifling this minority, which not only hampers their productivity but could stand in the way of innovation for organizations as a whole.

    Building quality software requires accommodating both kinds of developers. For most development teams, the goal is to give them a clear route to building apps faster and shipping safely by prescriptively paving the path. The path also must provide enough freedom for adventure, allowing developers to stray from the path (within reason and where it makes sense).

    Internal Developer Platforms: Paving Just Enough Path With Platform Engineering

    Platform engineering and internal developer platforms (IDPs) are much-touted approaches to taming the toil. It is a part of the solution, and as it gains traction, it is becoming more mature. That is, instead of developers and development teams taking on full responsibility for every phase of the software life cycle and potentially cobbling together something resembling a developer platform, the industry trend is moving toward more comprehensive, commercial out-of-the-box platforms. Whether or not this addresses the actual needs of the development organization, this shift works because developer experience is now a business-critical requirement, and a centralized developer platform facilitates that experience (with flexibility enough to house all types of developer experience and developers working across industries).

    The developer platform concept, supported by architecture, DevOps and SRE teams, contains the ingredients of transformation both for business and for developer experience. As the concept reaches critical mass and the “productifying” of developer platforms matures, one thing seems likely: By shifting to a platform model, development organizations are moving from ops-first to developer-first Kubernetes. The developer experience becomes defined by its optimized tools and workflows (and enables wider adoption of cloud-native development across larger organizations and broader industries).

    Refocusing Developer Efforts: Abstractions, not Distractions

    Cognitive toil will exist for developers regardless of the tools they’re offered. Technologies grow more complex and change frequently, and there are performance metrics that must be met. Taking the focus away from developers’ primary concerns—coding and shipping software and features—contributes to this toil without generating much return. As much as developers should be able to gain enough understanding of the way their code behaves and the consequences it can have downstream when shipping and running it, they should not need to become DevOps experts as a part of their work. This is why DevOps, despite predictions to the contrary, isn’t dead.

    The paved-path developer platform gives developers exactly that: The ability to shift left without drifting right. The platform provides much-needed abstractions and tools that enable developers to refocus on priority work without distracting or overwhelming them with too many choices.

    Becoming dev-first doesn’t kill off ops, either. Dev-first Kubernetes and a centralized developer platform elevate the importance of the developer experience while continuing to highlight the importance of DevOps in supporting and optimizing the developer experience. This is an entire topic in and of itself, which will be explored in part two of this article series.

  • OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

    OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: ChatGPT darling OpenAI wants people to write code in English, and the unintended consequences of blocking shared accounts. (more…)