devopsy.kinsta.cloud

Tag: developer experience

  • How LinkedIn is Investing in Developer Productivity and Satisfaction

    How LinkedIn is Investing in Developer Productivity and Satisfaction

    More and more companies are beginning to examine the role developer experience has in improving engineering productivity and morale. And one company often referenced as a model for developer productivity engineering is LinkedIn—its engineering leadership has invested heavily into reducing time-consuming developer tasks and constructing an internal platform to gauge developer satisfaction on the tools they use.

    Engineers at LinkedIn recently shared how the company has invested in measuring developer productivity and happiness as well as their strategies for automatically cherry-picking commits. I also met with LinkedIn engineering leadership for a closer look at how the organization is working to improve the developer experience across its internal platform.

    Below, we’ll take an inside look at LinkedIn Engineering’s efforts to enhance developer happiness. We’ll explore their approach to improving their internal software development trends and consider the benefits LinkedIn has gained throughout the process.

    A Look at LinkedIn Internal Developer Solutions

    Productivity is challenging to measure, said Jared Green, VP of engineering, head of developer productivity and happiness at LinkedIn. So, the company opted to take a different approach by including happiness as a variable in the equation. Thus, they measure not only how fast a workflow is but continually monitor how enjoyable the process is to ensure developers have a delightful experience.

    “We don’t just strive for productivity, but for productivity and happiness,” said Green. And to his point, on-the-job satisfaction can have real-world results—on average, happy workers are 13% more productive, according to a University of Oxford study.

    LinkedIn now oversees a custom-built internal platform for evaluating the sentiment of developer tools. The platform, known as iHub, is a holistic listening channel to gauge developer satisfaction across various tools. It collects real-time qualitative feedback from users and correlates it with objective quantitative telemetry. It then surfaces this data in a UI dashboard for team leads and individual contributors to view.

    But there’s an art to engendering the trust required to collect accurate feedback, says Max Kanat-Alexander, principal staff software engineer at LinkedIn. For example, individual contributors need to be sure the data won’t be used for performance reviews. Once that trust is established, folks are more willing to give genuine feedback, he said.

    Benefits of Investing in Developer Enablement

    The benefit of centralizing developer experience metrics with a shared platform means that tech leads can make data-backed decisions on how to improve their DevOps processes. “It’s really about thinking about giving people insights versus giving them data,” said Green. The idea is that frontline engineers can rapidly investigate any metric to expose problems and see trends. “The optics have given leaders ways to improve various parts of developer experience,” he said.

    Through their investment into developer experience, LinkedIn Engineering has discovered and streamlined hangups in the Git flow, exposed inefficiencies in their code review processes, and fixed specific developer build times. LinkedIn Engineering reported it has reduced time spent on certain time-consuming developer tasks by 99.6%.

    To construct iHub, LinkedIn Engineering wrote its own front end. The hub pre-computes data dimensions and stores them in an offline data store, increasing speed, said Kanat-Alexander. The system uses a sophisticated survey technology to collect the data and hides the complexity of manual collection in a sleek dashboard.

    LinkedIn managers have already leveraged iHub data to identify macro trends and resolve specific points of friction. For example, Kanat-Alexander describes how one director noticed that developer build time was worsening in their organization. They were able to isolate it to a single developer who wasn’t using remote development, which was spiking the metric. Leaders then assisted in unblocking them.

    Takeaways For Your Organization

    Most companies could benefit from a UI like iHub, explained Kanat-Alexander. But, you really must have a large engineering organization to see the benefits of the work. Plus, up to 80% of the legwork is simply data integrations—this involves hooking into systems, cleaning up data and deciding how to measure certain metrics. “Whatever you can measure, you can improve,” said Green.

    LinkedIn Engineering has flirted with the idea of open sourcing iHub, but it’s a bit too custom to LinkedIn to be valuable to other enterprises. “There’s a lot of variance in build technologies nowadays, and large-scale engineering systems are bespoke,” said Green. Implementing such a dashboard also requires a deep understanding of developer personas and how people work, which can be entirely unique for each organization.

    Although other organizations can’t fork LinkedIn’s efforts, there are some takeaways that could help others invest in their internal DX. First, Green recommended starting with the fundamentals. “Having a core of understanding about what you’re trying to move the needle on is important, as is coming up with ways to talk about it consistently.” This forethought should help establish what you want to measure.

    Turning DX Metrics Into Action

    Studies indicate that more companies are seeking to implement platform engineering or similar developer productivity engineering initiatives. The end result of these efforts should be to empower people and ensure they are satisfied with their work and not just a cog in the system.

    On that note, it’s critical that there are mechanisms for action to happen on the data that is collected, said Kanat-Alexander. Someone needs to monitor the insights and make changes to improve the metrics over time. “Then you can win hearts and minds.”

  • Breaking Down Silos: Applying Open Source Practices in the Workplace

    Breaking Down Silos: Applying Open Source Practices in the Workplace

    DevOps plays a prominent role in mainstream technology and companies’ ability to deliver results. While the definition of DevOps encompasses the complete range of characteristics it covers, in practice, current tech culture tends to focus solely on the tooling aspect, neglecting the equally essential focus on the people and process critical in delivering value to end users. While cultures are difficult to change and redefine, a transformation is needed to fully capitalize on the potential DevOps has to accelerate software development.

    Conway’s law–the concept that organizations ship software based on their organizational structure–outlines the need for visibility. This law revolves around the idea that in order for a software product to successfully operate, its developers must have established open pathways of communication to ensure each component works as a whole rather than as individual pieces. Unfortunately, today, many organizations still run into problems with how their teams operate when individuals own limited pieces of development.

    Take a retail platform, for example. In the development of the platform, there will likely be several sub-teams that focus on individual components of the design. Perhaps there’s a team for the shopping cart service, another for the catalog service, a team for the underlying data platform and one for user account services. The list goes on. Typically, those teams do not have visibility into each other’s work and operate in their own silo. As soon as teams start thinking about ‘their’ component or ‘their’ microservice, a dangerous tunnel-vision takes hold. In some cases, there may be standup meetings across teams for coordination efforts, but this takes time, energy and steals focus from the important task: Delivering value to end users.

    Alternatively, think about your favorite open source project. The inner workings were likely  designed asynchronously, openly, remotely and at a global scale. Given the remote nature of open source innovation, developer teams don’t need to be co-located in the same workspace. While physically operating separately, open source developers have mastered alternative methods to operate with transparency in such a way that external contributions aren’t just welcome, but encouraged.

    This same idea applies to proprietary software development, or InnerSource, a modern engineering approach that applies open source practices inside your organization to proprietary code. While a technological shift in practice, InnerSourcing is also a cultural revolution toward collaboration.

    Companies of all types can benefit from implementing InnerSource practices. Some enterprise organizations that operate using InnerSource methodologies today include 3M, Ford, KPMG, Mercedes-Benz, Nubank, Spotify and more.    

    A critical component in making this change is prioritizing team visibility. If other teams in your organization are unable to see what you’re working on, you’re inherently (intentionally or not) creating silos and limiting efficient collaboration. In practice, there will be scenarios where company-wide visibility may not be feasible due to external regulations, highly secure environments or sensitive projects; however, these moments of limited project visibility should be the exception rather than the default.

    When approaching InnerSource through an open source mindset, you will find that many DevOps principles still hold true. Here are a few strategies for implementing a collaborative open source culture when developing proprietary code:

    1. Use existing resources: When problem solving, using the existing materials available within your organization is a great place to start—it is possible someone has already tackled the issue you are addressing. If you find the right fit, you can reuse prior work and, if it has not been started, this is an opportunity to add value to your organization by creating a project that could help others in the future. When building upon someone’s work or starting a project, prioritizing visibility by providing an explanation of any technical requirements of the change will allow future project maintainers to determine whether it’s in the project scope, already a proposed change, on the backlog, or not a prioritized piece of work. This use of existing resources will help develop a collaborative culture over time.
    2. Documentation of work: Documentation is critical. Keeping track of the expected standards of the project and which tools or dependencies are required to build the project for local testing will help others in your organization know what to contribute. When in the early stages of contributing code to a project, documenting proposed changes without directly impacting the production version will allow you to receive feedback early on from the project maintainer about the direction you should take as they will be able to see your steps clearly outlined. To contribute code to a project, you can propose changes as a pull request, which doesn’t impact the production version but means you can get valuable feedback on the direction the project should take. Handling contributions by a pull request also ensures that branch protection rules apply and continuous integration practices are required.

    While implementing these practices may not result in immediate changes, over time they will result in a significant cultural shift. And while cultural transformations require continued conscious efforts, embracing modern software engineering practices–learned from the open source community–will enable teams to break barriers for organizational collaboration.

  • Things We Should Acknowledge, Part Three: Remotely Good

    Things We Should Acknowledge, Part Three: Remotely Good

    This installment of my off-and-on “Things We Should Acknowledge” series is going to focus on an area that most DevOps teams are skirting, but increasingly will not be able to: Remote work.

    For background, I have worked remotely for decades; my experience spans Fortune 100s, publishing companies and startups—and that’s just full-time work. I’ve worked for a ton of vendors and publications as a contractor, too.

    I will start by making clear my stance on remote work—a stance I’ve happily talked with people about since long before COVID-19 measures made remote work a regular thing. You either thrive working remotely or you wither. There is a small group in the center that can make it work with some effort, but inevitably that effort becomes routine and those in the middle become part of one of the two groups.

    Because people drift toward one of two camps, we get the currently popular stance on, well, everything, which is polarization. But we shouldn’t. Just like positions and people that should/should not be in meetings to resolve problems or people who should/should not have direct reports, we should consider positions and people that remote work is best for.

    And post-pandemic, the vast majority of DevOps roles can be performed effectively in a remote position. That leaves us with the people question. Mostly. Note: There are organizations and roles that need to be local; those are not a topic of this blog. The 99% of other roles/orgs are.

    This topic gets really ugly, pretty quick. If a significant portion of every organization goes remote, city centers in several metropolises will die. That is not conjecture; you can go look into commercial real estate in any information worker hub. It is in a massive slump (and calling it a ‘slump’ is being nice), with occupancy circling the drain and property values plummeting. That is largely because formerly high-demand real-estate is not needed in the volume it was.

    That should not be the concern of any given corporation. It is the corporation’s responsibility to see to shareholder value, not the real estate market (unless they are invested in real estate, which many large organizations are). But if orgs are keeping any offices downtown, it becomes an issue about safety. In other words, it’s about if the collapse of the market means the offices become less safe for workers, regardless of investment. This is not a decision-making bullet point, but it does inform actions. I have a ton more to say on this topic, but it’s a side bit, so for now, this is enough.

    For people who thrive working remotely—and a lot more people now know that about themselves than knew that five years ago—being forced into the office is a non-starter. I have been offered astounding positions at organizations on both coasts over the years, but the ones that came with the “…and you have to move here” demand—I immediately turned down. More people are doing that; some of them truly great employees.

    So, like it or not, DevOps teams are going to have to consider whether all being in the same building is more important than hiring the most qualified co-workers. That is a team/management/corporate decision and always has been. I consider any “We all do this one thing” stance—from “We’re an X shop” to “We don’t do remote” to be a negative, but I don’t have to make these decisions for an organization.

    It does need to be part of the conversation, though. Because the work environment is unlikely to return to pre-pandemic standards, no matter how much some want it to. The more organizations are willing to work with both remote and on-site employees, the more options those employees—your potential coworkers—have. That changes the dynamic, even in light of recent layoffs, because the new job hunt is not tied to “local” anymore.

  • Atlassian Embeds Generative AI Across Cloud App Portfolio

    Atlassian Embeds Generative AI Across Cloud App Portfolio

    At its Team 23 conference today, Atlassian announced it is adding an artificial intelligence (AI) capability to the enterprise editions of its cloud portfolio to automate a wide range of routine tasks.

    Sherif Mansour, distinguished product manager for Atlassian, said Atlassian Intelligence uses natural language to drive a virtual agent that resolves routine help desk issues from within Slack or Microsoft Teams. Atlassian Intelligence can also identify incidents that have been previously resolved along with issues that are related to one another.

    In addition, IT teams can also leverage Atlassian Intelligence to create summaries for projects being tracked using the company’s Jira project management software, noted Mansour.

    The overall goal is to streamline incident management processes while also making it simpler for application stakeholders to collaboratively participate in software development, he added.

    Generative AI capabilities are likely to be infused into almost every imaginable application going forward, but Atlassian is clearly at the forefront of an effort to leverage AI to improve productivity. For example, instead of spending time handling routine issues that increase the amount of daily toil, IT teams should be able to spend more time resolving more complex issues, noted Mansour.

    The cumulative effect of AI should result in a significant decrease in the backlog of tasks that many IT teams would otherwise have to manually perform, he noted.

    It’s not clear just yet how much generative AI will impact the way software is developed and how IT is managed, but it’s already apparent that fundamental change is on the way. The Atlassian Intelligence approach is intended to augment the capabilities of IT teams so they can do more with the same number of or fewer personnel.

    The challenge IT teams will face is identifying tasks they couldn’t previously accomplish simply because there wasn’t enough time available.

    Fundamentally, generative AI changes the way humans interact with machines. Instead of requiring a developer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. That makes it possible for anyone to make use of large language models used to create generative AI platforms to, for example, automate a routine task or, one day soon, create code.

    At this point, like it or not, the generative AI genie is out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of IT organizations, the ultimate impact should involve less drudgery as many of the tasks that make managing IT tedious are eliminated.

    Hopefully, as IT continues to evolve, there will still be plenty of demand for human expertise. For better or worse, the nature of the expertise required, however, will undoubtedly be at a much higher level than it has been for the past four decades or more.

  • How Platform Engineering Makes Software Sustainable

    How Platform Engineering Makes Software Sustainable

    The world is constantly becoming more and more aware of the importance of sustainability in every aspect of our daily lives from buying groceries to traveling, and the IT world is no exception. Indeed, sustainability is already gaining importance in software development. For example, in the latest version of Thoughtworks’ Technology Radar, “carbon efficiency as an architectural characteristic” is one of the new techniques of interest. Moreover, in its research “Predicts 2023: Environmental Sustainability Is Now an IT Sourcing Imperative,” Gartner states that “by 2026, 75% of organizations will increase business with IT vendors that have demonstrable sustainability goals and timelines, and will seek to replace vendors that do not.”

    This shows that there is a growing need for sustainability. How is the software development industry responding to this need? Many great initiatives are arising, but platform engineering, in particular, helps make software more sustainable.

    What is Platform Engineering?

    According to Gartner’s definition, platform engineering is “the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management.” This trend has gained momentum in the last few years, and an increasing number of organizations are adopting internal developer platforms (IDPs) to scale their development process. IDPs allow developers to self-service the technology they need, whether it is infrastructure, runtime resources or ready-to-use services. This helps speed up the development process and ensures higher-quality software.

    Platform engineering is becoming more and more popular and foundational. According to Gartner, “by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery.” Therefore, given the expected widespread adoption of IDPs in the next few years, sustainability emerges as a requirement. Ignoring or underestimating the importance of sustainability may cause organizations to waste all the benefits ensured by an internal developer platform.

    Platform Engineering for Economically Sustainable Software

    To survive and operate properly in the market, a company has to be economically sustainable and therefore stable. Usually, software is an asset that contributes to revenue generation for the company, but it still has maintenance costs. To make software economically sustainable, the total cost of ownership (TCO) needs to be lower than the generated income.

    An internal developer platform can lower software product costs, making them more sustainable. How so? In a nutshell, by sharing resources that can serve multiple products and can be reused across multiple projects. Such resources include, but are not limited to, capabilities, processes, infrastructure, configuration, etc. Since the platform at scale manages shared capabilities, there product teams won’t waste time and effort replicating it every time. While lowering the TCO, this characteristic of platforms also contributes to reducing the software’s time to market.

    Moreover, platform costs are shared across the whole organization and are not part of the TCO of each software product. This helps software to be more sustainable from an economic point of view.

    Platform Engineering for Environmentally Sustainable Software

    When talking about sustainability, most people usually think about the environment. While respecting the environment is one of the most important factors, it is important to note that sustainability is not limited to this aspect.

    An internal developer platform can help software be more sustainable on two levels.

    • Observability: The platform should collect and easily expose metrics on the environmental impact of the software. Such metrics can include hardware resource usage, energy consumption and CO2 footprint.
    • Optimization: The platform should foster the adoption of sustainable patterns, like the ones provided by the Green Software Foundation. It should also include solutions that actively help reduce energy consumption, such as kube-green.

    It is important that both of these capabilities are present and implemented in the platform. Observability without optimization is useless, and optimization without observability cannot be done.

    Platform Engineering for Socially Sustainable Software

    When speaking about sustainability, social responsibility cannot be forgotten. The first social responsibility of each organization is toward its members and employees. Does developer self-service also have social implications? Yes, it does; mainly by improving the developer experience.

    Indeed, an internal developer platform helps organizations’ members to:

    • Reduce friction between teams: Since everyone can have everything they need right when they need it, there will no longer be bottlenecks and misunderstandings between different teams. This contributes to a better working environment where everyone feels welcome and more productive.
    • Decrease repetitive tasks and cognitive load for developers: Since the platform will manage and automate interactions with infrastructure and runtime, developers will no longer need to waste time and energy on such out-of-scope secondary tasks. This way, developers are more focused on their actual job of developing new features and they will feel more satisfied.
    • Enable work from anywhere at anytime: Since the platform can provide all technology and capabilities whenever a developer needs them, it will no longer be required that people work together in the same location and at the same time. In other words, IDPs enable remote and asynchronous ways of working. This allows organizations to offer remote working and to create distributed teams, ensuring a better work-life balance for the team members.

    All of this brings happier employees that will be more productive and satisfied with their work, which will reduce turnover.

    Conclusion

    The need for a more sustainable world is gaining momentum and involves every industry, including software development. No wonder Gartner included sustainable technology in the “Top 10 Strategic Technology Trends for 2023,” along with platform engineering. As platform engineering is being adopted by more and more organizations to accelerate software development, sustainability has to be addressed.

    An internal developer platform can help developers build more sustainable software. Platform engineering can help in all of these aspects, improving not only the developer experience but also the organization and the environment. This is just the beginning of the sustainable path platforms should follow, but the outlook is very encouraging.

  • Creating a Growth Loop for Your Open Source Project

    Creating a Growth Loop for Your Open Source Project

    Every open source project hopes to achieve escape velocity, attracting enough users and contributors to become a successful, sustainable project that expands over time. But how do you attract developers and create the cycle of adoption that can lead to a thriving ecosystem?

    It obviously starts with building a great product that developers love to use, and there’s an element of luck in finding this sweet spot and breaking through. But there’s also a lot that you can control. I was fortunate to have helped create an open source project, Streamlit, that expanded quickly and our company was acquired last year. I wanted to share what worked for me in the hope that it also can be helpful for you.

    My guiding principle is to meet developers where they are and make it as simple as possible, at every step in the journey, to discover your project, learn how to use it and build great products. Depending on the type of open source project you’re creating, providing a simple way to share artifacts and use cases built from your code—in our case, this was applications—can also be a powerful way to raise awareness.

    I think about this in terms of a “growth loop” with multiple points of entry where developers can get interested and get started. These entry points include developer forums, source repositories, your documentation page, learning assets, your website and more. The point is to eliminate friction at every point in this loop and make it as easy and fun as possible to start building and sharing with your code.

    For organizations trying to get their open source project off the ground, here are some key learnings about what worked for my company in building this growth loop and some tips for driving continued adoption and innovation.

    Be Visible in the Open Source Community

    We made it a point to go where developers are already at, including forums like Reddit and Stack Overflow and conferences like ODSC and FOSDEM. Engaging with developers to understand what they really need from your project and how to reduce points of friction is key. We were always grateful when people gave us feedback and we reached out to any developer who engaged with our product, whether they had 10 followers or 10,000. I’ve found that developers really appreciate it when you “show up,” and you learn an incredible amount that can help your project succeed.

    Give Developers What They Need

    Don’t hold back features or functionality that developers will find useful. Developers should have access to everything they need and feel confident that they won’t run into a significant paywall that prevents them from scaling. Building a successful open source project is a bottom-up process, and that means eliminating barriers to entry and making your code as easy to use as possible.

    Where developers go, enterprises typically follow. If you can build a tool that developers love so much they’re coding with it in their free time, they’re likely to take it into the workplace. If your goal is monetization, this is where you’re most likely to have an opportunity to recoup your investment.

    Enterprises require particular features around security, access management, IT support, scaling, service level objectives (SLOs) and other areas—capabilities they are often willing to pay for. So, consider a model where you give developers everything they need to become super users and look for adjacent areas where you can charge for enterprise-type features or enterprise implementations that businesses need.

    Make Sharing Incredibly Easy

    If developers build great things with your code, it’s helpful if they can share those things with the community to show what’s possible and drive interest. You can think of this as a type of advertising. Most developers aren’t won over by traditional ads, but discovering cool things that other developers have done with your code can be a great way to attract new users and fuel the cycle of discovery and adoption.

    So think about the natural output from your project that developers could share with the community. Can they put code on GitHub? Share an app or visualization they built? Post a speed comparison? What can they put on Twitter if they love your project and want to show what they’ve achieved with it?

    Our project is for building data apps, so early on, we added a feature that allowed people to take a screen recording and share their work on Twitter so others could see it in action. Later on, we added a free cloud offering so they could directly share apps with the community. Think about what works for your project and how you could make sharing easy.

    Create Amazing How-Tos and Tutorials.

    These can be important entry points on your growth loop, and it’s best to provide them through developers’ preferred channels. YouTube is a go-to for tutorials of all types, and you can also leverage Coursera, Educative and other e-learning platforms. Someone on my team created a Coursera course for our project that has more than 20,000 enrollees, and one of our Code Camp videos has been viewed over a million times.

    Get creative. If your project is starting to see traction among students, think about providing educational materials that professors can use in the classroom. Online interactive courses are not only a great way to learn programming, they make it easier for educators to manage coursework and see who’s keeping up. This is an excellent way to promote your project and capture new developers.

    Documentation is another important entry point. Our documentation page is starting to look like an e-learning course itself, with guides for getting started, sample code and sample apps. Documentation pages can be listed by search engines, and we found it was worth the engineering time to make this happen.

    Contribute to Other Open Source Projects

    Giving back to the community is a good practice for anyone who cares about software, but it can also benefit your project: Contributing to open source projects helps ensure that your software will be compatible with the tools your target developers use. As well as ensuring interoperability, this can help raise awareness of your project in relevant developer communities.

    Reaching critical mass with an open source project is about understanding what your target developers need, being smart with your resources and removing friction wherever you can. This concept of a growth loop worked for our project, and I hope it helps you to achieve success with yours.

  • How Developer Productivity Engineering (DPE) Enhances Software Delivery

    How Developer Productivity Engineering (DPE) Enhances Software Delivery

    Developer experience (DX) is in the zeitgeist, and for a good reason. Digital demands are increasing, yet the market faces cautious IT budgeting, workplace burnout, and high resignations. The idea is that quality developer experience can help keep the remaining talent happy and increase productivity. And organizations are considering many strategies for increasing DX, such as creating more usable interface interfaces, maintaining intuitive documentation and abstracting complexity with more automation and low-code.

    Another way to increase productivity is by slimming down the time it takes to test and deliver software. There are many potential hurdles in the way of deploying new code, and a cumbersome pipeline can easily take a programmer out of the flow. The practice of streamlining this toolchain is known by some as Developer Productivity Engineering (DPE). DPE focuses on improving developer productivity through accelerating DevOps processes, like CI/CD pipelines.

    I recently met with Hans Dockter, founder and CEO of Gradle, to understand the core tenants behind DPE. According to Dockter, the dialogue with the toolchain is a developer’s bread and butter, and optimizing this exchange is vital for quickly validating new ideas. Below, we’ll seek to understand what DPE is and how it might increase the pace of software delivery. We’ll also consider some methods for implementing DPE in practice.

    Roadblocks in the Development Toolchain

    Engineers are always experimenting with new feature development. “A developer needs to have a dialogue with their toolchain to see if their hypothesis makes sense,” explained Dockter. Yet, there are many potential barriers to instant feedback. For example, a toolchain may be comprised of code compilation, static code analysis, unit testing, performance testing, security testing and other checks. Running new changes through a CI/CD pipeline can take anywhere from a few seconds to minutes or hours. In his work, Dockter has even encountered teams that deal with a 24-hour feedback cycle time.

    Long wait times can be taxing as they demand users to switch contexts. Neuroscientists say that multitasking depletes glucose in the brain and leads to exhaustion. Similarly, Dockter argued that long waiting periods with the toolchain can take developers out of the flow and slow down the pace of software delivery. “You cannot have a good developer experience without good productivity.”

    Furthermore, he added that engineers often encounter untrustworthy signals from their toolchains. If testing suites produce too many false positives, for example, you can lose faith in the tooling altogether. This equates to a bad experience and may result in developers overlooking important signals that do matter.

    Understanding Developer Productivity Engineering (DPE)

    DPE is all about improving developer efficiency. And quickening the feedback cycle is one method to enhance developer productivity. According to Dockter, DPE applies a few strategies to streamline this feedback loop and shorten the timeframe:

    • Optimizing which tests are run: First, Dockter recommended only running tests relevant to the change at hand. Optimizing test selection can reduce bulky builds and significantly reduce the time it takes.
    • Caching: Caching is integral to any web application, so why not apply similar heuristics for the development pipeline? This could involve caching code that is not changed. “Changes are often incremental from one feedback cycle to the next. A lot of output is produced that can be reused,” said Dockter.
    • Predictive test selection: To automate test optimizations, Dockter recommended predictive test selection to understand which tests are sensitive to which areas of code. This would utilize an AI trained on release mechanics to help pinpoint what components the changes modify and, thus, what tests to run.
    • Test distribution: Another way to accelerate the pipeline is by distributing testing processing. Using multiple machines to test different areas simultaneously could greatly speed up the routine. Test distribution “is a modern approach to test parallelism that accelerates test execution by taking existing test suites and distributing them across remote agents to execute them faster,” wrote Marc Philipp and Hans Dockter in The Developer Productivity Engineering Handbook.
    • Monitor the toolchain: Lastly, it’s good to continuously monitor failure analytics to discover where the toolchain itself is causing trouble, said Dockter. On the side, CI/CD pipelines are not immune to security vulnerabilities and should be treated with the same security standards as other infrastructure.

    DPE principles have already been applied at DoorDash, LinkedIn, Netflix and other organizations.

    Benefits of Developer Productivity Engineering

    In the last few years, DX has moved from niche to mainstream, said Dockter. In fact, DX has even entered the C-suite, as certain companies have embraced the role of chief developer experience officer CDX). And with the emerging discipline of platform engineering, we’re seeing an even greater focus on streamlining internal DevOps workflows.

    And although platform roles may have been viewed as second-class engineers in the past, said Dockter, they are held in high esteem nowadays. “It’s as important as the other engineering work we’re doing,” he said. Developer productivity engineering seems to align with these principles, helping organizations manage the effects of an exponentially expanding code base. In the end, an investment in DPE, like platform engineering, could bring more satisfactory working conditions and accelerate the pace of software development.

    “DX is a transformative opportunity, but most companies invest incrementally. The economic benefits are transformative for companies developing infrastructure to get more output from their developers.”

  • Day in the Life of a Chief Developer Experience Officer (CDXO)

    Day in the Life of a Chief Developer Experience Officer (CDXO)

    Developer experience (DX) has become essential to modern enterprise software development. As more companies become software companies, more are opening up their software both for internal reuse and externalized consumption. As part of this process, making developer-facing tools consumable and friction-free becomes more necessary to both perform well and stand out in the market.

    To oversee developer experience quality within an organization, an entire new role is beginning to emerge — the chief developer experience officer (CDXO). A CDXO is in charge of ensuring the intuitiveness of developer-facing toolsets and being an advocate for engineering needs. Such a focus could improve internal platform usability, like within platform engineering initiatives. Or, it may involve improving the developer experience for public or partner APIs through quality documentation, SDKs, libraries, forums, tutorials and more. A CDXO might interface with many departments to monitor and improve DX across the organization.

    Since the role is in its very early stages, few CDXOs exist. But I tracked down a few to gather insights on the emerging position—I had the unique opportunity to sync with Alessandro Cauduro, chief developer experience officer at Azion and Ivan Burazin, chief developer experience officer at Infobip. They both shared some fantastic insights on why DX is so important these days and what qualities make a good developer experience leader. Below, I’ll distill their wisdom and take a peek into the life of a CDXO.

    Why DX is Important

    First, it’s good to reiterate that developer experience is increasingly important for several reasons. Organizations want to build and ship applications faster and more securely. Yet, it can be difficult for programmers to keep up with new technology trends. “Technology is always changing, and developers are always having to try new things,” said Cauduro. “As a result, you rarely become an expert on a single platform.”

    Developer experience helps you get up and running quickly with new tools. The mindset is similar to user experience (UX) but more applicable to different interaction points like APIs, CLIs, SDKs, VSCode plugins, libraries or other developer-facing technologies. Improving usability for these packages helps ease the daily grind, increases productivity and can be a competitive advantage, said Cauduro. He added that a benchmark of great developer experience is when you don’t even have to read the documentation to understand what you have to do.

    “I think that developers are the lifeblood of innovation,” said Burazin. “They are the ones creating solutions and implementing transformative technologies. Yet, they are often let down when it comes to the tools they use to achieve this innovation, so providing a great developer experience is paramount if we want to foster that innovation as much as possible.”

    CDXO Roles and Activities

    So, what does a day in the life of a CDXO officer look like? What are some of their roles and responsibilities? According to Cauduro, the overarching goal is to put himself in the developer’s shoes—he constantly thinks about common developer workflows and considers how to create a seamless experience throughout the entire development life cycle.

    Next is spreading awareness throughout the company about DX principles and how to increase DX within their offerings. A CDXO will likely answer directly to executive leadership but might interface with many departments. A CDXO may direct teams to construct developer-specific tools, like libraries, documentation, SDKs and self-service environments. “DX is a mindset,” said Cauduro. “The whole company needs to be engaged in it.”

    “As with any C-level position, your job is on the one hand to make your team’s life easier in any way you can,” said Burazin. “And on the other to convey the developers’ issues or ideas to the company in hopes of nudging the company in the correct direction.”

    A CDXO may also oversee developer relations efforts, which focus on fostering a developer community. There are many ways to interface with partners and clients to exchange ideas on how to build against the platform, Cauduro explained. This includes promoting open source projects, encouraging user meetings or interacting on Discord and forums to provide answers to community questions.

    Qualities That Make a Good CDXO

    The CDXO position isn’t for everyone. So, what personality traits make a good candidate for the role? Here are some of the necessary qualifications for the type of work:

    • Experience as a programmer. A CDXO should have past experience as a professional developer. Engineering knowledge will help them understand the persona and empathize with their needs.
    • Leadership qualities. The role also requires leadership expertise, as a CDXO must have the ability to coordinate and influence many different areas of the company.
    • Creativity. Since the role is pretty nascent without a written path, it will require creativity. Having the ability to experiment, accept feedback and reiterate is also important, said Cauduro.
    • Empathy. Communication skills and empathy also go a long way. “Deep engineering knowledge crossed with great people skills is the mix you would need for such a task,” said Burazin.

    Developer Experience in Practice

    At Azion, Cauduro is interested in how its tools can help developers move solutions from the cloud to the edge more seamlessly. To that end, they’ve found that Jamstack fits well with the needs of edge computing. Thus, some of his efforts focus on making the process of deploying a Jamstack app to the edge as seamless as possible for engineers.

    While DX efforts have helped address development bottlenecks at Azion, the role of CDXO may not be necessary within all companies, admitted Cauduro. It’s more of a fit for API-first or SaaS companies that target developers as a primary consumer base. That being said, other companies can still benefit from a developer experience focus to enhance their internal IT platforms.

    At InfoBip, Burazin explained that developer experience efforts center around helping external developers consume the InfoBip API, an API for all communication channels, such as SMS, voice, WebRTC and more. Sitting under the CTO, Burazin helps run three teams and DX has its own department. Impressively, he reports revenue on self-service APIs has increased fivefold in the past two years.

    Burazin, also the co-founder of Codeanywhere, explained that his role is to “convey the worries or needs of the developer customers to management and help steer the ship in the right direction.” To discover those needs, he recommends ‘dogfooding’ what the customer is experiencing and streamlining the onboarding process to be as self-service as possible. He also recommends having measurable insights on metrics you can directly impact, like decreasing time from discovery to ‘hello world.’

    Final Thoughts

    Developer experience is becoming a unique selling point for technology companies—so much so that it’s entered the C-suite. “Whoever has the better DX will have the leading edge,” said Cauduro. For him, it’s about finding small things to optimize that remove pain points from the developer’s process.

    To summarize, the role of CDXO is still evolving and not set in stone. And, granted, many different labels are being applied to describe similar objectives. But to get an idea of what the CDXO role entails, some common activities include:

    • Considering the perspective of the developer.
    • Engaging the entire company to prioritize DX.
    • Overseeing the construction of DX-related assets and resources such as tutorials, documentation and guides.
    • Collecting feedback and reiterating platforms.
    • Overseeing developer relations and advocacy teams.

    Looking to the future, developer experience will likely become more of a necessity as developer-driven purchasing habits become a real revenue driver. “This bottom-up go-to-market motion will help awareness and increase sales,” said Burazin. And, to helm this movement, more companies may adopt DX within a C-suite title. But of course, the role may look different from company to company as DX is applied in different ways.

    “If we look at the largest technology companies, almost all of them have a developer experience department in their organization. And this is due to the fact that so much of a developer’s productivity is directly linked to their experience while working,” said Burazin. Things like internal developer portals and standard cloud deployments will help improve developer experience and help them focus on what they do best, which is coding, he said.

  • Platforming the Developer Experience

    Platforming the Developer Experience

    This article is part three of three on the boom in platform engineering and its role in supporting a streamlined, positive developer experience.

    In a perfect world, the developer experience would be on that is completely free of obstacles. In the previous articles in this series, I argued that supporting and improving the developer experience is a critical business requirement. To continuously improve and keep up with the constant change that typifies the cloud-native development landscape, platform engineering is–at least for now–the golden path to reducing developer toil and increasing productivity.

    I’ve also countered the controversial idea that DevOps is on life support because centralized developer platforms eliminate the need for DevOps. If anything, DevOps and developers share a symbiotic relationship, and the developer platform is where their functions converge. In this third and final article of the series, I will explore this relationship, examining the considerations for how the developer experience is “platformed” and by whom.

    Optimizing Developer Experience: The Circular Economy of the Developer Platform

    Let’s put it this way: The more relevant and useful the developer platform, the likelier the developer is to use it. If it reduces toil, cognitive load and makes shipping software easier, the developer has more time to focus on their core task: Developing features. With intuitive, self-service workflows and all the tools developers need, they rarely, if ever, have to think about ‘the how’ of getting their software into the hands of users. And this works if and when an organization does at least a couple of things right:

    • The organization prioritizes the developer experience and empowers other parts of the organization to answer the question, How can we create the optimal developer experience?
    • The organization puts resources behind understanding and building the best developer experience–and that’s where both the developer platform and DevOps teams as “fixers” ideas emerge.

    Does this mean the “optimal experience” can’t be optimized? Does that mean developers cannot have input into their own (or more general) developer experience(s)? No. In fact, part of what makes the developer platform idea compelling is that developers don’t have to weigh in or make decisions on the platform or tooling. Still, it’s possible to let them have that freedom if the team or organization wants to. Bottom line: There is no one-size-fits-all developer platform any more than there is a single developer experience. This is why DevOps, along with PlatformOps, is an ideal complement to facilitating the “circular economy” of the developer platform. The platform is unlikely to stay static. And to keep it dynamic and responsive to the changing needs of the developer teams using it, the DevOps teams of the future can proactively remove, recycle, repurpose and restructure the way the platform runs and what tools are available in it, automating and evaluating … almost like a feedback loop on the platform itself.

    Your Developer Platform is the Golden Path to Developer Productivity

    The developer experience is built around the tools and workflows developers use and, in the case of a developer platform, the tools and processes you define and provide, i.e., a “golden path” to productivity.

    Whatever that platform includes, it will demand that you answer questions about what tools, processes and best practices will be most effective for delivering the optimal developer experience. For example, what and how much should you build yourself? How should the platform be assembled to best serve the needs of your developer team? What is the most effective configuration? How much freedom can or should be given to your developers, depending on your business goals and the security, stability and scalability requirements of your organization and products?

    Boiling down the route to the golden path, there are three critical points to help guide the creation of an effective internal developer platform:

    • Treat your platform as a product. This is key to reducing cognitive load and paving the way to shipping software fast and safely. This also means that you are guaranteed to have an MVP and alpha, beta, etc. version of the product–and subsequent versions serve their purpose temporarily but are always works in progress.
    • Realize you can’t have good DevX without good UX and develop accordingly.
    • Focus on workflows and tooling interoperability; that is, a developer(-led) control plane. What is going to work for developers in practice to ensure that they can focus on key deliverables? How will you gather intelligence to discover when it’s time to make changes to the platform? Who will be responsible for this?

    Paving and Using the Golden Path Developer Platform Simultaneously

    Developer platforms can significantly improve developer productivity and the overall developer experience. But you can’t just build a platform and hope for the best without seeking developer input or understanding how developers work. Nor can you build a platform and decide it’s finished and forget about maintenance, enhancements and inevitable change. Developer platforms don’t exist as one-and-done items on a checklist and are themselves productivity tools that are in a constant state of flux.

    Misunderstanding why you would platform the developer experience in the first place defeats the purpose.

  • 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.