devopsy.kinsta.cloud

Tag: developer experience

  • Optimizing the Developer Experience in 2023

    Optimizing the Developer Experience in 2023

    2022 was a banner year for innovation, but not only in the traditional “churning out new features” way. Many organizations started thinking about their processes and how to amplify them to maximize efficiency and employee retention. And when they started digging, companies realized that the developer experience was a major pain point that could be rectified–and a ripple effect of positive gains would result.

    Companies started looking more closely at how the tools and processes developers use support and enhance their work. Great tools and thoughtful processes boost developer happiness and satisfaction. And when those levels rise, guess what else increased? Productivity, efficiency and employee retention rates.

    We saw this trend of developer support take hold last year, but with more work to be done across many companies, we’ll see it continue in 2023 and beyond, impacting just about every facet of tech in new ways. Many companies have realized what does work by trying what doesn’t work and are making big changes from there.

    Shifting Results

    A major player in the changing developer experience has been the shift left approach that’s taken hold in recent years. About 80% of organizations have said they are adopting this idea of moving more of the responsibility for security and compliance to the front of the pipeline to avoid a compliance scramble at the point of delivery. The result, however, is a compliance process that ends up being more complex and less efficient, putting additional burdens on developers.

    Involving more people creates more opportunities for security breaches and slows down the entire software delivery life cycle. It also shifts security responsibilities to developers and requires them to do significantly more than is listed in their job description. In fact, 60% of those shifting left said their development team is bearing the burden of the change. Rather than focusing on writing code, developers have been called on to understand regulatory policies, build regulatory controls into their applications or pipelines, inspect massive log files generated by more and more diagnostic tools for security info and spend more time in meetings to discuss audits. That’s not a recipe for fulfilled developers; it’s the path to a loss of innovation.

    Stop Paying the Compliance Tax

    When developers–or anyone on your team–are tied up in compliance tasks, they aren’t spending that time in profit-earning efforts. This “compliance tax” costs companies an estimated 15% each year–that’s 15% of their time spent managing compliance instead of innovating or providing services that add value. That’s not to say that compliance isn’t important–it’s essential, in fact–but limiting the burden of compliance improves the overall experience of developers.

    When developers aren’t innovating, they’re not happy. They want to be writing great code, not translating regulatory governance policies. In today’s culture of quiet quitting, companies simply can’t afford to turn over compliance tasks to developers. It’s a waste of their talent and a surefire way to lose great developers and the chance to attract new ones.

    Shift Left, but Do it Right

    The good news is the compliance tax is largely avoidable. Instead of shifting responsibilities left, shift compliance everywhere. No one person or group, including developers, should be in charge of these tasks–that approach just isn’t comprehensive enough to ensure security and compliance throughout the software delivery life cycle.

    Instead, security and compliance should be moved away from a point-in-time part of the cycle to a continuous process built into every step of the life cycle. CI/CD reduces the burden on any one person or group and is proven to be more efficient at catching anything that is non-compliant. When the tools are doing the heavy lifting, the people aren’t making as many mistakes and non-compliant code isn’t slipping through.

    Baking in compliance allows developers to spend more time doing what they do best: Creating amazing features. This, more than anything, will boost the developer experience. Developers want to create and, when they experience the right environment and the right resources, innovation tends to happen.

    Beyond the Developer Experience

    Focusing on the developer experience pays off in more ways than just creating happy employees (though that alone is reason enough to make a change). Innovative developers are the backbone of leading tech companies. When they’re churning out new features that are getting public recognition and are touting a culture with a positive developer experience, companies attract more talented developers and the innovation loop continues.

    So, if you’re looking for more innovation in 2023, start where you’ve always started: Your developers. Set them up for success by automating what can be automated and baking in the mundane – yet essential – tasks to truly optimize the developer experience. Then sit back and watch what incredible capabilities your developers can generate.

  • Looking to the Future of Developer Experience

    Looking to the Future of Developer Experience

    Developer experience is where it’s at! Developer experience (DX) means taking a user experience approach to the developer journey. DX (also abbreviated as DevEx) is commonly applied to areas like documentation, sandbox environments, SDK ergonomics and more. By improving a developer’s experience with a tool, software providers can increase stickiness and retain more users.

    Nowadays, having a sleek developer experience is a competitive advantage—especially since developers often have the discretion to purchase new tools. And amid an ongoing skills gap, maintaining quality DX for internal software ecosystems is also important to retaining happy engineers and avoiding burnout. All these factors mean developer experience is becoming a C-suite objective. So, where is DX heading? How will the developer workflow change in the near future?

    I recently met with Ash Arnwine, director of developer relations, Nylas, to ponder what’s on the near horizon regarding developer experience. According to Arnwine, DX is still a very new concept. Yet, it has become an integral aspect of positioning modern software, especially for public-facing SaaS, and will undoubtedly drive purchasing decisions in the year ahead. Below, we’ll share some predictions of how DX will evolve within four general categories: onboarding, building, deploying, and maintaining.

    State of Developer Experience

    First off, what is the state of developer experience within the tech world at large? Well, Arnwine is quick to note that the concept is still relatively nascent. “Developer experience was something that we didn’t talk about that long ago.” Yet, the idea is growing in mindshare as developers exercise greater control over the software life cycle.

    In fact, the 2022 StackOverflow survey found that 66% of professional developers have at least some influence over their organization’s purchases of new technologies, up from 56% in 2020. Furthermore, the way developers learn is changing. The new generation of programmers is primarily self-taught, relying on coding bootcamps or other online resources. An impressive 70% of developers learned how to code from online resources.

    What we end up with, said Arnwine, is a growing developer population with a much wider range of skills than in the past. And since no one is there to hand-hold them, the technology itself must be usable and intuitive—the onus is on the software provider to craft frictionless self-service workflows. And with developers’ growing influence in purchasing, DX becomes a competitive advantage and an executive talking point, said Arnwine.

    Onboarding

    Developer experience is a broad topic, but it’s most often associated with the time it takes to get started with a tool. This is often referred to as ‘Time to First Hello World.’ But although it’s an important step, the metric might doesn’t always carry much significance. Time to value, on the other hand, said Arnwine, takes this a step further and is a better gauge of success.

    For example, onboarding to a web API would likely involve the signup process, creating an account, getting API keys and perusing the documentation—all before a first call is sent. According to Arnwine, there are techniques to apply at this stage to help developers move faster throughout the onboarding process to reach value sooner.

    Here are some ways in which developer onboarding is becoming more streamlined:

    • Automatically generating keys upon signup.
    • Providing a terminal within the developer dashboard to test sample code.
    • Handing developers the code they need to be customized to their specific stack.
    • Using specifications as a single source of truth for documentation.

    Building

    What can SaaS companies do to help improve DX while building? Well, one way is to enable auto-complete within IDEs. When developers onboard with a new tool, they are often handed an SDK and reference documentation. But, it doesn’t add value to send programmers back and forth between a browser to look up method names. Instead, Arnwine believes developer tools should be “baked into the IDE in a way a modern developer would expect.”

    One example of auto-complete on steroids is Fig, a next-gen command line that supports auto-complete for over 500+ popular CLI tools. Taking this a step further is GitHub Copilot, an AI assistant that can take natural language prompts and generate pretty complex code suggestions. The industry appears to be heading toward more AI-fueled low-code software development—a trend that could significantly improve a developer’s experience during the construction process.

    However, one potential downside of increased software development automation is ensuring the AI suggests correct code snippets. Thus, Arnwine said he anticipated possible troubleshooting and debugging problems. Furthermore, SaaS providers will have to vet systems that generate glue code to ensure it’s accurate and up-to-date with the latest versions. His advice to SaaS providers is to meet developers where they are, but do their best to maintain a quality experience that they can control.

    Deploying

    For a long period of software development history, IT administrators were the only ones able to deploy software. The old-school method required getting a hosting provider, installing Ubuntu and plenty of other legwork. Nowadays, however, software deployment has become far more drag-and-drop. DevOps has become more democratized in recent years, and we will likely see greater usability emerge in the years ahead.

    One way to increase developer experience for deployments is through more custom automated routines via GitHub Actions or similar event-based systems. And plug-and-play pre-built actions could reduce the barrier to using such systems. Such connectivity is necessary to enable a docs-as-code approach, said Arnwine.

    Maintaining

    Another area that could use a serious developer experience upgrade is dependency management. Software dependencies go through a life cycle. They are versioned, updated, retired and sometimes replaced outright. As such, keeping track of an evolving surface area of third-party dependencies can be a headache. To make matters worse, software supply chain threats have complicated the integrity of many open source dependencies consumed by most applications.

    Although it’s imperative for organizations to maintain parity with dependencies, a single person is rarely tasked with continuously checking dependencies and monitoring for security threats. Therefore, more automation for dependency management and security monitoring is necessary. For example, Arnwine uses Snyk, which sends a weekly report on the state of his dependencies.

    Final Thoughts

    Assuming you have the killer functionality to back it up, an investment into developer experience can help a developer tool stick out in a crowded marketplace. But of course, improving the DX means many different things depending on your context. It could be a subtle user interface tweak, adding relevant code samples or making your documentation more intuitive.

    On the other hand, a negative developer experience can turn away potential users and cause frustration throughout the application support life cycle. This can instill a poor reputation among programmers.

    To review, in the near future, we’ll likely witness the developer experience evolve in the following areas:

    • Enhanced methods that streamline the signup process.
    • Auto-complete and AI-driven code suggestions that understand a developer’s stack and meet them where they work.
    • More intuitive, automated deployment models.
    • Increased automation around the maintenance of dependencies.

    While developer experience is a growing concern, it shouldn’t be the only measurement of a SaaS — the ongoing value it brings developer consumers and end users is just as (if not more) important to consider.

  • Understanding the Importance of Developer Experience

    Understanding the Importance of Developer Experience

    If you’re creating a developer tool, you’re bound to run into this dilemma—you know the inner workings of it really well, but others don’t. And without solid documentation and samples to follow, it can be challenging for another person to get started. Friction with the tools we use can contribute to burnout, inhibit creativity and slow down innovation.

    Developer experience (DX) is becoming integral for any software company to consider. I recently met with Christine Spang, CTO and co-founder of Nylas, to consider the benefits of investing in developer experience. Below, we’ll take a look at what exactly DX is and consider some best practices for implementing it.

    What is Developer Experience?

    Developer experience (DX) is similar to user experience but for developer-facing tools. DX considers the developer’s journey while developing with a certain framework, language or platform. “Developer experience is the amount of friction a developer experiences between having clarity on what they want to implement and getting to the point where you have created that thing,” said Spang.

    For example, consider integrating with an API to solve a common use case like payments integration. There are many steps involved here, from reading the reference documentation to getting an API key, testing calls and understanding how the service responds. After developers initially integrate the API into their application, they may also have to make continual updates as the service versions. Throughout this journey, DX can be thought of as “how hard it is to figure out how to translate from idea to output,” said Spang.

    It’s also important to note that DX isn’t only relegated to public-facing platforms. Having a quality developer experience is just as crucial for internal software. The urgency to improve internal developer experience is increasing with the surge of APIs being developed, especially since the majority of them (58%) are private APIs, according to Postman’s 2022 State of API Report. Depending on the size of a company, internal DX can encompass many areas.

    Best Practices for Investing in Developer Experience

    So, what are some methods to improve developer experience across the board? Well, having up-to-date documentation, code samples, better examples and standardized documentation rank high as positive developer experience traits. Spang also shared some helpful best practices to improve DX:

    Provide scaffolding for the most common cases. Measure patterns around the kind of things people are building with the platform and offer scaffolding to support the common use cases. This might equate to a getting started guide for a common scenario.

    Offer sample code libraries. It’s a lot easier to edit code than write it from scratch. With that in mind, create pre-baked environments where developers can play around. Offering working apps, use case templates and glue code can be a practical means to help developers get going more seamlessly.

    Start with the reference manual. Walkthroughs and sample code should never replace a complete reference manual. It’s essential to have up-to-date documentation to cater to advanced users from the get-go. From here, you can generate Postman Collections or interactive sandboxes built around the reference specification.

    Measure DX success and iterate. One way to monitor developer experience metrics is to record the onboarding flow and measure conversion rates. Where APIs are concerned, this can be tracked by asking how many people get through to making calls? What is the mean time it takes to make the first call? Knowing such metrics can inform how effective your tool’s self-service features are.

    One point that’s important for DX is walking the fine line between too much custom work and focusing on the core project. On that note, Spang recommended “making sure whatever you’re building maps to the overall vision of the company.” In essence, if you’re not a consulting shop but a product company, you should stay true to that objective.

    “You want to make the path for what people commonly want to do very easy,” said Spang. “Yet, you don’t want advanced users to feel constrained by the platform.”

    Examples of Quality Developer Experiences

    For those creating developer-facing services, it’s helpful to have a framework to model. So, what are some examples of quality developer experiences?

    Well, top public APIs are great examples of where the bar is set for developer expectations these days, said Spang—services like Twilio or Stripe demonstrate relatively seamless developer journeys. Spang also pointed to companies with a strong DevOps and CI/CD background, like Etsy, who have for years invested in usable backend infrastructure that accelerates internal development.

    For other sources of quality developer experience, consider the high-ranking developer-favorite technologies from the latest 2022 Stack Overflow survey. Engineers love working with technologies such as PostgreSQL, AWS, Phoneix and Docker. The newer, trending languages tend to be increasingly usable, too. For example, 86% of developers said they love working with Rust while 76.65% dread working with Objective-C.

    The Overall Benefits of DX

    An investment into developer experience can help improve agility and developer satisfaction, said Spang. For one, an easier path for development increases the velocity in how you ship and evolve projects over time. Secondly, developer experience equates to less burnout and less turnover, both of which can have real business impacts.

    The software development industry is growing like wildfire, bringing in waves of entry-level developers each year. Interestingly, the average experience level is decreasing, increasing the need for more abstracted tools and toolkits, said Spang. In this environment, developer experience undoubtedly shines as a competitive advantage.

    So, if you’re creating developer-facing tools, consider the experience others will have when using them. Increasing developer experience may just be a defining factor in the project’s success and the long-term happiness of your developer community.

  • Internal Developer Portal: What it Is and Why You Need One

    Internal Developer Portal: What it Is and Why You Need One

    One main advantage of the cloud is that it offers developers flexibility and a self-service solution. Instead of having to contact the central infrastructure team whenever a dev team needs a new server or a cluster, the dev team can do it themselves through a simple web UI. This change drastically improves productivity. But there’s a caveat: Most companies don’t actually want to use the default portals provided by cloud providers. There are a few reasons for this: Security, simplicity or the need for custom, company-specific options, to name a few. That’s why we now see a move toward internal developer portals. In this post, you’ll learn what internal developer portals are and how they can make your developers’ lives easier. 

    What is an Internal Developer Portal?

    An internal developer portal is a self-service application and data store that lets developers and managers track and organize everything their engineering teams build and operate.

    Imagine that you need to create a new microservice. Your developers will first need to provision infrastructure for it; for that, they’ll use a cloud provider portal. Next, they’ll need to create new CI/CD pipelines or modify existing ones. Then, they’ll probably need to implement some changes to existing components like the API gateway and database. Lastly, they’ll probably need to add some documentation or make their new microservice visible to the rest of the company.

    Overall, they’ll need to touch a few different UIs or portals. Now, imagine they can do all of that from one place. That’s what we call an internal developer portal. It’s a self-service portal that lets developers catalog and understand relationships, ownership, resources, external service data and anything else they need to understand and operate their software.

     Why Does an Internal Developer Portal Matter?

    Now that we know what an internal developer portal is, let’s take a step back and discuss why internal developer platforms (IDPs) are on the rise. The main reason is because of the increased complexity of both software and infrastructure. Especially when we’re talking about cloud-based microservices environments, it’s challenging even for senior engineers to keep track of all dependencies and things that must happen every time changes are needed. Microservices architectures are heavily decentralized. Although you’ll still see the typical three-tier software architecture, in most cases, it’s no longer easy to tell by looking at a random component where it fits in the bigger picture just by its name or server location.

    Natural Evolution

    The second reason is that it’s simply a natural next step in the evolutionary process for self-service portals. Old-school, on-premises-based environments barely had any self-service capabilities. Do you remember how difficult that was? To request a new server, you had to email the central infrastructure team. If you were lucky, you’d get what you needed in a matter of hours or days. But more often than not, it took a week or two. And if you made some mistake in the initial request, that would cost you an extra week (or more) of waiting. More advanced companies? Even when they created some custom self-service solutions, these were limited. Often, it wasn’t much more than an online form to be processed by the infrastructure team which often became a bottleneck for all dev teams.

    When most companies started moving to the cloud, they began to see the benefits of self-service platforms. The ability to create servers ad hoc within a matter of minutes led to increased developer productivity, faster time-to-market and better quality software. But again, cloud-provider platforms are suitable for managing cloud infrastructure; you need more than that for a complete solution. Your developers can be more effective at creating and changing cloud infrastructure, but everything else was still done separately. And that’s how we naturally evolved into the demand for internal developer portals. To bring even more flexibility and clarity while increasing your dev teams’ productivity, you need to take the next step in the self-service platform evolution and combine all the things developers need into one internal developer portal.

    Clarity 

    Also, from a business perspective, internal developer portals bring clarity and offer a good overview of all your infrastructure and software development efforts. Even if you’re in the cloud and your dev teams can manage the infrastructure as they choose, you still need some control and oversight—for example, to avoid wasting money on test servers that developers forgot to delete. Sure, you can get simple reporting from your standard cloud-provider portal, but what if you’re using multiple cloud providers or have a hybrid-cloud environment? An internal developer portal can benefit both developers and their managers. Long story short: IDP portals are the future of software development.

    What Can an IDP Actually Do?

    How do you create an IDP for your company? You can build your own from scratch, use some OSS offerings or go for ready-to-use products.

    Build Your Own

    The first option would give you the most flexibility and ability to perfectly tailor the solution to your needs and the needs of your developers. However, building your own IDP from scratch is almost like building your own operating system from scratch. It requires a lot of work which could negate the main benefits that IDP is supposed to bring. You want to implement IDP to increase developer productivity and decrease time-to-market, but it would take you months to build it and years to maintain it to keep it working properly with constantly changing cloud APIs.

    Open Source IDP

    The next option is open source IDPs. Since IDPs are, in general, quite complicated pieces of software, there aren’t many options to choose from. The two most popular are Backstage and Gimlet. Backstage is more of a DIY platform for building developer portals, which means you’ll still need to spend quite a lot of time creating something that actually benefits your company. Gimlet is quite popular, too, but it focuses on Kubernetes-based environments. Both are great tools—don’t get me wrong—but if you’re looking for something ready to use and feature-rich, consider the third option.

    Ready-to-Use Solutions

    The last option is to use a ready-to-use product. Ready-to-use solutions combine the IDP functionality with incident response capabilities as well as metrics, dependencies visualization and filtering across multiple clouds.

    Internal developer portals are gaining popularity for good reason. In fact, many companies have been trying to build IDPs for years without even knowing the solution had a name. This is because an IDP-like solution will naturally evolve in any company that cares about developer experience and moving faster. The problem is that it usually takes years to come up with a single solution that fulfills all their needs. Another problem is that most of these organically created internal developer portals focus only on the tech side and skip the business needs. That’s why a purpose-built tool can be much easier and faster to implement while also doing its job much better.

  • GitLab Adds Fourth DORA Metric API to CI/CD Platform

    GitLab Adds Fourth DORA Metric API to CI/CD Platform

    The latest update to GitLab’s namesake continuous integration/continuous delivery (CI/CD) platform has added support for the application programming interface (API) for measuring change failure rates. This addition supports the fourth metric as defined in the DevOps Research and Assessment (DORA) framework.

    Version 14.10 of GitLab also expands the GitLab Runner Operator for Kubernetes to any distribution of the open source platform in addition to making it possible to manually trigger incident responses when needed.

    Finally, a compliance report that surfaces every individual merge request violation has been added along with a tool for setting up streaming audit events.

    Brendan O’Leary, staff developer evangelist for GitLab, said that as DevOps processes continue to mature, DORA metrics make it simple for IT leaders to measure overall progress. While it’s not likely that any single set of DevOps practices will be universally implemented across an entire enterprise, O’Leary noted it’s important for DevOps teams to keep track of key performance indicators (KPIs) that enable teams to identify areas for ongoing improvement. For example, it’s not uncommon for technical debt to accumulate in the absence of metrics that track the progress of builds, he added.

    In general, a transition to microservices-based applications is increasing the need for CI/CD platforms that make it simpler to build them. Each of these applications is constructed using microservices that are typically built independently of one another. The challenge is that each microservice has dependencies on other microservices, so the need for DevOps workflows to optimally manage that development process is becoming more widespread, noted O’Leary.

    In some cases, organizations are deploying a CI/CD platform for the first time to build these applications. In other cases, they are looking to replace a CI/CD platform that was adopted to build legacy monolithic applications. Regardless of the type of application, there is a need to continuously refine and improve software engineering practices to increase developer productivity.

    It’s not clear to what degree developers are voting with their feet to work for one organization versus another based on the overall quality of developer experience. Organizations that do have a consistent approach to software engineering, however, make it easier for developers to spend more time writing code rather than managing the build process. The challenge is to make sure the DevOps platform itself does not become a bottleneck that hinders the rate at which developers can build code. It’s also not clear whether organizations are building applications faster than they can secure it and ensure overall quality. The only way to know for sure is, of course, to track metrics.

    Naturally, not every developer is a fan of metrics. Application development is still as much art as it is science. There is, however, a general appreciation that the amount of code that needs to be written far exceeds the available talent to write it; any effort to make software engineering more efficient benefits everyone involved. As such, given all the code that needs to be written, a software engineer is often today the best friend a developer can have.

  • GitLab Updates CI/CD Platform to Improve Dev Productivity

    GitLab Updates CI/CD Platform to Improve Dev Productivity

    GitLab has made available a 14.9 update to its namesake continuous integration/continuous delivery (CI/CD) platform that adds epic-linking, integrated security training, rule mode for scanning result policies and a revamped design, among other capabilities. The updated environment makes it easier to discover the state of the application development projects, GitLab said.

    Cindy Blake, director of product marketing at GitLab, said these updates are part of an ongoing effort to embed technologies within the CI/CD platform that will make applications both more secure and compliant with various mandates before they are deployed in a production environment.

    For example, DevOps teams can now take advantage of a user interface through which they can use a rule mode to design and edit policies without the need to access YAML files directly.

    GitLab has also partnered with Kontra and Secure Code Warrior to provide content that will drive security training functionality. This content can be accessed via the GitLab platform whenever a vulnerability is discovered.

    The overall goal is to make it simpler for organizations to shift left because expecting every developer to become a security expert is not especially realistic, noted Blake. The ability to automate many of the security tasks that developers face is a way of showing empathy for the daunting challenges they face.

    In general, as application development becomes more complex, GitLab is moving toward making its CI/CD platform more accessible to a wider range of organizations, including those that might only be starting to embrace DevOps best practices. The epic-linking capability, for example, makes it easier to identify “related”, “blocking,” or “blocked” relationships to better track and manage epic dependencies across GitLab groups.

    The two biggest challenges organizations face today are securing their software supply chains and improving the overall productivity of the developers. In most cases, those two goals are tightly coupled; every minute a developer spends on security is one less minute they spend writing code. In fact, many organizations are finding that, in addition to salary and benefits, many developers are using the level of friction they will encounter when building and deploying applications as a guide to decide which organizations they want to work for. As a result, many organizations are now looking to modernize their application development and deployment environments with an eye toward attracting the best developer talent.

    At the same time, of course, organizations are looking to improve the productivity of the developers they do have. In the age of digital business transformation, there are many more application development initiatives being launched. The challenge organizations face is that hiring and retaining developers remains a major challenge.

    It’s not clear how eager organizations are to replace their existing CI/CD platforms. However, the pressure to improve the overall developer experience is mounting at a time when organizations are increasingly dependent on software. Arguably, going forward, the ability of any organization to compete will be dependent on the productivity of application development teams. Platforms and tools that get in the way of enabling organizations to build and deploy more secure software faster will be discarded.

  • Will Devs Return to the Office?

    Will Devs Return to the Office?

    Charlene O’Hanlon and Michael Davis, CRO at Rollbar, discuss findings from a recent developer survey exploring how devs feel about the return to the workplace. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Hey, everybody. Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I’m here now with Michael Davis, who is the CRO at Rollbar. Michael, thank you so much for joining me. I appreciate it.

    Michael Davis: Thank you, Charlene. Great to be here.

    O’Hanlon: Well it’s great to have you here. I am really fascinated about a recent developer survey that you guys came out with regarding their attitudes toward going back into the office, and that’s always a hot topic among organizations no matter what they do. A lot of companies are grappling with just the aftermath, if you will, of the pandemic and the return to the workplace. If you rewind about 12 months ago, we were hearing stories about companies deciding that they were never going to have their employees come back and they were going to work remotely 100 percent all the time.

    And a lot of organizations, or a lot of employees I should say, kind of took those cues and decided that they just were going to go and move wherever they wanted to. And so now a year later companies are saying, “Well maybe we should come back into the office at least part time.”

    Davis: Yeah. Right.

    O’Hanlon: So there have been a lot of kind of ping-ponging I guess, for lack of a better term, and I truly believe that the rest of this year there’s going to be a lot of fallout from organizations dealing with employees who are no longer able to come into the office because of their location. But I’m interested in finding out what you guys found in your survey regarding that and some of the other findings that maybe surprised you.

    Davis: Yeah. That’s a great intro, although I might push us back even before COVID. I think this is especially relevant for a lot of the software development teams that we work with. If you go back before COVID, we had customers where their entire teams of developers didn’t even own a laptop. They were literally in the office all the time, every day. And so not only are companies now wrestling with this transition post COVID, but they had a huge transition they went through pre COVID, right? And that certainly put a lot of stress and strain on the companies, but more importantly on the actual developers themselves.

    And so here we are now coming to the end of this, as you’re describing, and we’re going through another transition. And I agree, I think what the survey starts to show is that this is not going to be black or white type of thing. It’s not going to be all of one or the other for many of the reasons you already mentioned. The survey was very clear in that first off it said 77 percent of developers were definitely significantly impacted by COVID and what this meant for them, and now as you start to interview folks and do the surveys you find that it’s a real mixed bag. You have folks who’ve enjoyed the freedom, enjoyed that flexibility, and have started to adjust to that to some extent.

    But I think one of the most interesting findings is that they’re missing that face-to-face component of their work. And if you think about developers and what they do, this is a team sport, right?

    O’Hanlon: Right, right.

    Davis: They’re really missing that day-to-day, face-to-face interaction, and especially given the sort of raised stakes, which is another thing that came out of this survey. What we found was sort of this external pressure on development was even raised higher. Why? Well, because customers are needing to interact with companies through software. So there’s even more pressure on building more software faster. So these are some interesting things that we saw sort of pulling against each other.

    O’Hanlon: So what do you think is the answer here? I understand that developers crave that face-to-face. I also see people who are now dealing with a level of social anxiety that maybe they never had dealt with before in their life. If you’re a year away from somebody or large groups of people it can be tough to reintegrate yourself into that environment. And as much as we all say I can’t wait for things to get back the way that they used to, we can go to concerts, we can go shopping and not have to worry about wearing a mask or whatever, you put people in some of these situations and it’s difficult for them. Some more than others.

    Some are just like, yeah, whatever, you know, let’s just go back and it’ll be fine the way that it was. But I’m not sure when people say I want to work with all these people, I want to get back into the scrum, I want to do this and do that, I’m just not sure when they actually do it that that’s really what they wanted. Do you think that there’s going to be maybe buyer’s remorse if you know what I mean?

    Davis: Yeah, there could be. My guess – and again, it’s based on some of the survey data we’re seeing – you do have this mixed feeling about your sort of life balance isn’t necessarily all you thought it would be by being home all the time. But I think you’re going to see the same thing. If we went back full time in the office people would be feeling that same kind of pressure around the commute and the things that go with that. So my gut says that now that companies have adjusted and people have adjusted more to being away, we’re going to see this hybrid environment.

    You’re going to see more of an environment where people are going to be in the office at certain times, but they’re going to have the ability to work from home at certain times, which again, carries its own set of things. We’ve seen lots of investment in tools, Zoom being one of them we’re on right now, but there’s a long way to go. Because the other thing the survey showed was that by having these distances it’s harder to get those answers, let’s say, as a developer that you might need in the moment. When someone’s not two cubicles away from you, you have to hope that they’re on Slack. And if they’re not, then you’ve got a delay and a problem.

    So I think the next thing we’re seeing is we’re seeing more investment in additional tools, in additional types of processes that help this hybrid environment more.

    O’Hanlon: Do you think that we’re going to see an increase in these distributed workforces on a full-time basis either as a direct result of the mass exodus during the pandemic or just because they can, that they’re recognizing that maybe we don’t have to be in the office all the time? Or Joe left and he can do it full time, so I’m going to do the same thing and what are they going to do?

    Davis: Right.[Laughs]

    O’Hanlon: Take away my birthday? It’s going to be one of these – I think there’s going to be this push-pull. And so I’m wondering do you agree with me? Is this something that very might happen? And what do you kind of see? How can organizations – how do you expect them to react to that?

    Davis: Yeah. And I would add to the points you made one other thing, which is companies I think have learned that once you remove this need for everyone to be in the office all the time this also starts to free up your ability to recruit more broadly and it gives you flexibility to bring on the type of people you want wherever they sit, right?

    O’Hanlon: Right.

    Davis: So I think that’s going to play in as well, and that’s why I think it really will be this hybrid environment. So what can they do about it? Well, they’ve got to be really mindful about how people work and they’ve got to be investing. Companies have to be investing in the right kind of tools. I’ll toot our horn a little bit here. Rollbar is about this sort of platform that gives you visibility across your teams on specific errors that you have in your code.

    That’s one example. If companies have tools like that in place, now you don’t have to be sitting two cubicles away. You’ve got the data you need right in front of you, real time, to be able to make those kind of decisions. That’s one example. There’s many, many more, but it’s going to be thinking about these workflows somewhat differently and making sure you have the right processes and data so people can operate more efficiently.

    O’Hanlon: Yeah. It’s going to be an interesting year I think as we do kind of transition back to life post COVID or even the final throes of COVID, because so much happened over the last 12 years and it was a lot for all of us to process. And now for us to kind of quote/unquote go back to the way things were I just don’t think it’s ever going to happen. I don’t think that we’re ever going to be back the way things were before COVID, and so that means a lot of changes within organizations and among employees and their understanding of work and how they approach it on a day-to-day basis. I think there’s going to have to be a lot of giving in, if you will for companies, that they’re going to have to take a brand new tack when it comes to hiring and retaining their employees.

    But employees also need to kind of understand that at the end of the day there’s a job that needs to be done and sometimes the best way to go about doing that job is to maybe be in the office or be face to face. So there is no one-size-fits-all solution here. Michael, great results. Were there any other things that popped out of the survey regarding developers and how they view work or work/life balance or salary or anything like that that you guys covered in this survey?

    Davis: We didn’t really touch on salary so much. I think the big takeaway points were just how pervasive the impact was on developers and what they were trying to do. That was the first thing. The second thing then was this notion that a lot of that sort of stress and strain that was associated with this was, one, just a normal transition, but also this higher demand for software, which I don’t think necessarily any of us really predicted, and that is added to what’s already software in the world. Every company is a software company kind of thing, right? So that’s the challenge, and that’s the challenge that Rollbar and other companies are working to help this community with, because it’s tough. It’s a tough job.

    O’Hanlon: Yeah. And to your point, I don’t think anybody expected it, but do you think that it’s going to be sustainable? I mean, is this something that’s going to be kind of the new normal, if you will? At least not may necessarily from a product – well, even from a productivity standpoint, but do you think the demand is going to remain as high as it has been over the last 18 months or so?

    Davis: I just have no doubt about that. I mean, there was already an incredible pressure on the system. These teams are already feeling lots of external pressure about being able to deliver features and functionality faster, right? We’re all hearing about iteration speed. And so I don’t have any question now that – again, I think companies have learned that maybe they don’t need the same kind of retail presence to serve their customer base. Which again, puts just more pressure on the need for software.

    So yeah, this all feeds into I think even a more challenging environment, but certainly a rewarding environment because these people are at the center of the epicenter right now of everything.

    O’Hanlon: Yeah. But I do worry about burnout. I do worry about the fact that – I think a lot of people really rose to the occasion at the beginning of the pandemic and all throughout it because they did recognize that there was a value to it. They could actually see how their work was impacting their company. And I’m not sure that once we go back to kind of whatever, whatever we’re going to call it, that that is going to sustain, and it’s really going to give developers and other employees for that matter kind of the push that they need. And it does concern me that we may very well see mass burnout among developers, and that could be bad for everybody.

    Davis: You’ve given me a great transition to one thing I wanted to mention, which is the next thing we’re going to be working on is some analysis around developer productivity. So I think you’re right on, spot on. I think that’s the next concern. I mean, it’s already a concern, but now it’s even more accentuated. DevOps was already a mixed bag in terms of developer productivity. I won’t spill anything, but we’re going to do a deep dive there and hopefully we’ll have some more great data for you.

    O’Hanlon: Well, come back and have the conversation with me when that’s ready, because I would love to continue this conversation. There’s a lot going on in the space right now and it’s got so much more to do with just business, the business side of things. There’s a real human element to all of this and I think it’s very important that organizations keep that in mind at the end of the day and so much more. But Michael, thanks for talking to me about this survey and the results of this one.

    Fascinating stuff, and it’ll be interesting to see how the rest of the year plays out in terms of everything that we’ve discussed today. So thanks again for your time. I appreciate you being here.

    Davis: Thank you. Thanks for the chance to talk to you. Bye-bye.

    O’Hanlon: Alright. Alright, everybody. Please stick around. We’ve got lots more TechStrong TV coming up, so stay tuned.

    [End of Audio]

  • No Matter How Things Change, Have a Plan

    No Matter How Things Change, Have a Plan

    Had enough change yet? It is almost amusing that I and some other tech people had that conversation a decade ago, and since then, nothing has slowed down. Our conclusion was that, for the near future, change would be constant. That conclusion was right; I’d have to ping everyone else to see what they think, but “near future” turned out to be longer than I expected.

    Inevitably, though, change requires taking a breather at times. It appeared that high-tech was finally ready to admit that burning out your staff was not a viable long-term business model, and was slowing down … and then, COVID-19 hit. Now I’m hearing rumblings about going back to non-stop change as if the last couple of years were a vacation and staff is all rested up and ready to replace massive chunks of the infrastructure.

    The reason that change requires intermissions, though, is not 100% about staff and burnout. That only shows up when you’re making a ton of change non-stop. Before staff burnout becomes an issue, recovery and business continuity plans become outdated. At the rate we’ve been running, I’d go so far as to say they are likely useless.

    Yes, all this change has brought us some cool stuff. While we are busier, some of the busywork is far easier, or even non-existent now—but that doesn’t change the fact that you need to breathe. This is a perfect time to go over plans to keep the business on its feet in case of IT catastrophe—or at least some major systems catastrophe. Saying “We’ll just deploy a new version” is cool, but it only works in some scenarios. I touched on this and discussed one case where it doesn’t work in October 2021. But there are a ton more. Every environment is different, but hardware failures have not disappeared and destructive writes still occur, as just two more examples. Your infosec team can give you a few more examples.

    Knowing what you’re going to do when the worst-case scenario happens is huge. And for those who’ve never been through it, knowing before people are stressed and asking you for a timeline will save you a lot of headaches.

    For those who’ve never had a DR or business continuity plan, consider it. At least have a basic DR plan that lists critical systems, things most likely to go wrong and what the steps are to recover it and get things moving again. The process of making such a list will often uncover things that should be done but aren’t—like backups or backup verifications.

    For those with a DR or business continuity plan, I’ll take a wild shot and say, “It’s out of date.” Organizations tend to create them and then forget about them. These plans should involve a bit of each project, so it’s taken care of in bite-sized chunks, but—probably because the first implementation of DR or BC is normally a massive project—it tends to be set aside and revisited every few years. Don’t do that.

    As I’ve said before, you and yours have built the heart of the modern enterprise. Don’t forget to protect it. It doesn’t take much to use some of these sweet new technology advances to put in DR procedures. Tack DR review/updates onto each major initiative, be it a new product or a big change to existing software. And keep rocking it. If you have a say in your organization, consider slowing the pace down for a bit and even updating DR. If you don’t have a say, may your employer be wise enough to do so.

  • Bridging the Developer Experience (DevX) Gap

    Bridging the Developer Experience (DevX) Gap

    They say our past experiences have an impact on how we view life and our general outlook. Routine behaviours and patterns become a program that we follow day in, day out. We stop using our minds to their fullest potential and become trapped in unquestioning, continual cycles of process and emotion.

    The same could be said of our experiences in the present—our worlds shaped by the environments around us. The people, practices, tools and culture. Only by challenging these accepted patterns can we start to think about changing our mindsets.

    DevOps is a mindset; a way of forming an agile relationship between development and operations teams to speed up delivery of software to support business operations and improve customer experience. By and large, it has been successful. Companies react to change more effectively; software is developed and deployed swiftly. It has become a necessity across most organizations.

    There are challenges, as we all know, however. The State of DevOps Report 2021 found that 83% of organizations are implementing DevOps practices, but most are still failing to scale adoption. It’s a situation that hasn’t changed for four years. Why? Among other things, the report states there are too many silos, not enough skilled people, a saturated market with too many tools—and a culture that prohibits scale.

    Given that the end goal of DevOps is to generate untrammelled innovation across an organization, getting the culture right is critical. Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

    Above all, it’s about creating the best possible developer experience (DevX) in which to thrive.

    The Developer Experience Gap

    Stephen O’Grady at Red Monk, the developer-focused analyst firm, originally wrote about a DevX (developer experience) gap in this post back in October 2020.

    Stephen likened the experience you get from an iPhone to the expectations of developers. The iPhone’s closed SDK created an environment that allows all developers to work in a consistent way. Functions are tightly integrated so that, for example, it would be easy to ensure the music volume lowers when you receive a call. A basic function, but one that we expect to work seamlessly with any app we install.

    Since then, developers have been served a vast array of tools and services with more and more software arriving on a daily basis. The challenge is that, where the phone and music player teams were controlled in a way that would make them work well together, modern development infrastructure doesn’t have that capability. In most cases, the toolchain is a “patchwork quilt” of products and services from different suppliers. And it is up to developers to build and maintain that quilt.

    This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

    In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

    Delivering the DevX Factor

    Attracting the best people is about showing that the experience they will have in your organization is both rewarding and liberating, so expecting developers to spend the bulk of their time not developing is clearly not an optimal experience. Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

    Where to start? Well, contrary to popular belief, you don’t need an army of DevOps engineers to reach your goals. Instead, you need to empower your existing teams to reach their full DevOps potential, supporting their progress with the right tools and training for their experience and role.

    As with any work culture (remote or hybrid), the importance of knowing where to find what you need and how to collaborate with other teams has never been so important. Tooling is a good place to start. DevX is affected by the tools they use, so organizing them in a way that helps with the culture is a step forward. In a multi-cloud, multi-vendor environment, there isn’t going to be one tool that does it all so the key is to allow teams to use the tools they love and automate as much as possible to remove the repetitive tasks.

    Automation is also a critical element in the race to reduce time-to-market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on developers. Having access to testing automation in a consistent way will improve the overall experience for DevOps teams.

    And finally, think about starting your DevX journey by using a self-service platform, where information, tooling and automation can be centralized and made available to developers on demand. For overworked specialists, access to a platform that connects to any tool and creates an on demand environment that automates much of the repetitive work will create more time for them to do what they were originally employed to do: Develop.

  • How to Build Healthy Engineering Teams

    How to Build Healthy Engineering Teams

    A common challenge today for engineering teams is the increasing complexity of their jobs and figuring out how to make it both productive and enjoyable without burning out.

    Over the last 10 years, the role of a software engineer has evolved drastically. Software continues to reach unprecedented scale, it is becoming more complex and customer expectations are higher than ever. Organizations from all industries are now becoming software companies and, with the pandemic, everyone is feeling the effects of burnout.

    There are close to a million unfilled IT jobs in the United States. To ensure organizations are able to continue innovating, the industry needs the tools, state of mind and reliable practices to make this career sustainable.

    Creating an industry with healthy productivity is paramount. But too much of a focus on going faster without addressing burnout is a recipe for disaster. Engineering managers need to constantly balance both. Here are some things they should keep in mind:

    Invest in Engineering Productivity

    Companies are increasingly hiring for roles focused on engineering productivity—there are currently hundreds of open job postings from organizations looking for these skills. These jobs are aimed at making developers and engineers’ lives and work easier by focusing on streamlining how things are done within the engineering organization—including improving developer workflow processes, execution efficiency and product quality. They are often responsible for building internal tools that support cross-functional and developer workflows. Even with a relatively small engineering team, organizations can start thinking about bringing on a team member dedicated to making engineers’ roles within the company easier.

    Focusing on Healthy Productivity

    Productivity is, and will always be, extremely important, but potential burnout should also be seriously considered in the process. Remote work during the quarantine and the pandemic has brought this front and center. When people don’t have enough deep work time, they often work longer hours which can eventually lead to burnout. An average employee has 11 minutes to focus between distractions at work and then, after an interruption, it can take around 23 minutes to return to the original task. In addition, the average worker attends 15 meetings per week.

    There are many questions about how workers’ productivity has been impacted since early 2020, and research has found that developer productivity isn’t a problem—but burnout is. From March to December 2020 the study found:

    • Deep work time—a two-hour period of uninterrupted work—decreased by 22% between March and December 2020.
    • Average time in meetings went up by 67% from March to December 2020.
    • Pre-pandemic, 10% of developers were showing “always-on” behaviors at work, but that percentage went up to 15% and then to 20% by the end of the year.

    Focusing on driving healthy productivity—where developers are productive but not overworked—is key to keeping your employees.

    Strengthening Engineering Managers

    Managers play a key role in keeping engineering burnout in check. Ensuring that managers ‘manage well’ is not a new idea, but today there are particular complexities that make the engineering manager role both uniquely challenging and especially important.

    It is now widely acknowledged that culture is a considerable part of what gets employees to stick around. But culture isn’t only employee benefits like trendy offices, great snacks and other relatively superficial—though still important—benefits. What really matters is identifying and building teams that really care about one another on a personal level and making sure that incoming employees feel the same.

    With engineering teams, there is a tendency to focus primarily on the technology being created rather than the people who are creating it. While this approach can absolutely result in successful products, it is often the default management style for managers who don’t have the tools to do otherwise. Moving from software engineer to manager requires a whole new skill set that involves different communication styles, time management, organization, tools and software, scoping work, learning how to effectively delegate and identifying the right people to complete the team.

    As challenges continue to evolve, organizations need to ensure that engineering managers are able to support each individual on their team. It is so important to make sure that people feel aligned with a mission they care about and that their career interests and goals are being met. Not all of those can be measured with data, so managers have an all-important role in keeping up with the pulse of the team.

    Building Helpful Tools and Growing Developer Communities

    In the last decade, the speed of innovation in enterprise technology has skyrocketed and the amount of code and tools developers need to master has increased. At the same time, the number of unfilled job openings continues to grow. There are a lot of great trends that are helping to close this gap including low-code and no-code tools as well as a massive increase in community resources.

    No-code/low-code tools: As both technical and non-technical organizations hire an increasing number of developers, low-code and no-code have become more prevalent. With frameworks that allow even those without a technical background to deploy software, no-code tools open development capabilities to an increasingly diverse subset of people. While these tools will not replace developers, they will make it possible for more people to enter the field of software development and help companies continue to innovate.

    Developer community: The amount of resources available to new and existing developers has also skyrocketed in the last several years from open source communities to Stack Overflow to the ability to simply Google how to do something in code. The Linux Foundation’s extensive training catalog is one example; even Medium has a wealth of basic technical info, how-tos and deep dives available. If you’re looking to adopt a new tool, one of your main priorities should be to look at the size of the community so that you can easily troubleshoot problems if they arise. Having access to resources from community members that have gone through the exact same problems you encounter is priceless.

    The above are all just a start. Teams can go even further by finding and adopting analytics tools to dive deeper into specific productivity metrics. These can give managers and executive teams the hard data they need to make educated decisions that will help them keep their teams and drive innovation. It is worth investing the time and the tools to maintain your engineering resources. By doing these things, organizations can reach and maintain healthy productivity.