Category: DevOps Culture

  • How’s Facebook Work? They Don’t Know! | Cali. Pay Law | NASA RISC-V Launch

    How’s Facebook Work? They Don’t Know! | Cali. Pay Law | NASA RISC-V Launch

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

    This week: Facebook engineers admit they’ve no idea what Meta stores (or where), California requires job ads quote salaries, and RISC-V will power future NASA spacecraft. (more…)

  • Focus on What You Can Do

    Focus on What You Can Do

    Here we are in the second half of 2022 and the writing is on the wall. No matter how much budget you have had in the last few years, be it large or small, it is going to shrink. This is cyclical, and should not be a surprise. The amount of budget shrinkage may be larger, but budgets have fluctuated since before any of us were born. I would argue that they fluctuate in IT more than any other part of the business, simply because much of IT is still viewed as overhead and, honestly, we’re expensive. Our salaries, our equipment, our software and our SaaS cost a lot, making them juicy targets when corporate belts have to tighten.

    So let’s talk about what to do for the next year (or five) while things finish sinking and then start to recover. New projects will be few and far between but improving what an organization already has deployed costs little. And the “Do it now” mentality of Agile and DevOps has helped in a ton of ways, but honestly leaves a trail of “could be better” implementations behind. Implementations that you can use iterations to improve. My “Look at me! I’m a pundit too!” recommendations would be:

    1. Review
    2. Consolidate
    3. Evaluate
    4. Iterate

    Review what you have across the entirety of the org. I’ve made this recommendation before—possibly even as recently as six months or so ago—but it bears repeating. We had a phase where teams and even individual developers made choices for a product or product line. This created a lot of overlap. List tools used at each step of the DevOps chain; for each project/DevOps toolchain.

    Consolidate. In the short term, costs need to go down and be sustainable once they do. Better to eliminate software or SaaS redundancy than that other kind of redundancy. This step also means simplifying the corporate DevOps infrastructure. So compare products doing the same job and choose one. This isn’t as easy as pundits make it sound; each product brings something unique to the table. But you have to make the hard choices and reduce maintenance costs and hours.

    Evaluate. This is not hard to believe for anyone who has worked at multiple organizations, but in case anyone missed it, no environment is perfect. They all have strengths and weaknesses. The best staff in the world, given unlimited time and budget, will do at least one dumb thing. Then after a year, a lot of the smart things they did look dumb too—because the market and/or the technology have moved on. Look at each step of your environment—from which libraries/modules are included to the deployment steps and run-time monitoring. Figure out what could be better and then organize by cost and schedule them out.

    Iterate. Start back at the review stage and do it again, because if you think you got it all the first time, you’re wrong. Or you are a heck of a lot smarter and more thorough than the rest of us, one of the two.

    This will keep the team improving the corporate IT environment while outside factors keep budgeting down. This cycle is different from others because it is unclear how IT staffing will be impacted. While it is looking more and more like IT will have the same impacts as usual, at the start of this downturn that wasn’t at all clear. Either way, improving the environment without million dollar projects is useful in hard economic times. My company is currently reconsidering our choice of frameworks and how we’re still using a test tool as DevOps management tool, for example.

    Keep the lights on, keep rocking the servers and apps running the org and focus improvements around factors you can’t change. But keep making it better, no matter what’s going on around you.

     

  • Solving the DevOps Labor Deficiency

    Solving the DevOps Labor Deficiency

    We all know there’s a chronic imbalance when it comes to DevOps talent: High demand and limited supply. Look no further than a 2021 DevOps Institute report which found that while 60% of organizations are hiring for such roles, 64% of IT leaders have a tough time finding skilled DevOps professionals. And it’s not just the typical pandemic staff shortages that you’ve heard about. The shift to remote practices has fast-tracked digital transformation across industries, spiking demand for developers.

    So what exactly is the state of the DevOps labor market? Is it only tough for companies, or for candidates too–and can automation help? In honor of Labor Day, we asked a few IT leaders about this classic labor conundrum.

    Labor Barriers on Both Sides

    Elisa Hebert, vice president of engineering operations at Fairwinds, observed that DevOps hiring is difficult for both the hiring company and the candidate. “Teams have been chronically short-staffed for the last couple of years due to the COVID-19 pandemic, which resulted in companies wanting to hire senior DevOps professionals who can operate more autonomously,” she explained. “If you toss in a need for specialization–we work exclusively with Kubernetes, for example–finding that level of domain knowledge combined with senior-level experience is really tough.”

    On the flip side, she said the industry practice of requiring years of experience for junior-level positions makes it difficult for inexperienced talent to get hired: “It’s an impossible wheel that needs to stop.”

    Automation to the Rescue … Or Not

    You might be thinking, “Well, why isn’t automation helping with these shortages?” It’s true that DevOps automation can lighten developer workloads. Efficient collaboration between development and operations teams can reduce friction; faster feedback loops can accelerate deployment. Leaders can reduce the number of staff needed for tedious tasks while their engineers can focus on more fulfilling work.

    All of this can help retention efforts by preventing burnout and promoting a healthier workplace. As Balakrishnan Viswanathan, vice president of cloud operations at Demandbase, said, “DevOps straddles two important pillars: Increasing development velocity and increasing release quality. Automation is key because otherwise, burnout is very high.”

    So it’s no surprise that DevOps Institute’s Upskilling 2021: Enterprise DevOps Skills Report respondents rated automation as the most important skill domain. They ranked proficiency in automating continuous integration, continuous delivery, continuous deployment, continuous operation and support and DevSecOps as the most valuable knowledge.

    But here’s where the automation solution runs into the DevOps labor problem: The need for DevOps practitioners skilled in automation vastly outweighs the availability. “From a DevOps perspective, there are very few people across the tech space who have operated production systems at scale and enabled automation to reduce the toil, making these skillsets extremely valuable in today’s market,” said Viswanathan.

    DevOps Recruiting, Hiring, Retaining: What’s the Solution?

    Given these challenges, how can companies improve automation and relieve their overworked engineers? Hebert said IT leaders should “create scaffolding.”

    “Fairwinds has an engineering leadership team that is cross-functional (dev, platform, SRE, R&D, services, UI/UX) and plans strategy and tactical execution together,” she said. “We’re greater than the sum of our parts, so while departures are a mix of sad and happy, it doesn’t break us.” She also advised companies to revise their job descriptions and “take all the extra stuff out that isn’t actually critical to the job,” pointing out that women typically don’t apply for jobs unless they meet every criteria listed.

    Marcus Merrell, vice president of technology strategy at Sauce Labs, mentioned Historically Black Colleges and Universities (HBCUs) as a talent source, reminding leaders that “an excellent, under-utilized resource for recruiting is HBCUs and non-profit organizations that focus on CS education for girls and people of color. These organizations produce thousands of graduates every year who uniformly have trouble getting hired.”

    Viswanathan recommended that organizations provide more automation guidance. “One thing companies can start doing immediately is establishing thought leadership in an effort to showcase all the automation work that their DevOps teams are doing by developing content, whether blogs, articles or white papers.”

     Finding the Right DevOps Opportunity

    There’s no silver bullet for a beleaguered DevOps job seeker, but Merrell encouraged candidates to apply for positions even when they don’t possess every qualification listed. “For people who identify as female and people of color, try to remember that the job requirements are usually only looking for about a 60% to 70% match,” he said. “Remember that the job description is aspirational and that no company really expects to match this 100%.”

    Hebert also advised looking beyond salary. “If a company can offer you an opportunity to grow your skills by working on interesting projects or with senior-level engineering talent that can mentor you, that’s an invaluable asset.”

    Defining DevOps Labor Solutions Differently

    Some organizations may be coming up short on both automation and adequate staffing right now, but incremental improvements can help the industry get there. And IT leaders believe we will get there. “As cloud adoption gains pace, the skill sets and labor force needed are expected to grow in lock step,” predicted Viswanathan. Until then, both the DevOps hiring manager and the DevOps candidate can take steps to meet each other in the middle.

  • Stable Diffusion Goes Public — and the Internet Freaks Out

    Stable Diffusion Goes Public — and the Internet Freaks Out

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

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

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

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others.

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

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

    SimplyHired

    Kyndryl
    Remote
    DevOps Engineer
    $95,700 – $265,200

    Monster.com

    Randstad
    Remote
    Senior Cloud SRE
    $130,000 – $150,000

    Dice.com

    Staples
    Framingham, Mass.
    Senior Software Engineer I- CICD/DevOps
    $135,000

    Indeed

    Odyssey Information Systems
    Remote
    Senior DevOps Engineer
    $117,798 – $156,338

    ZipRecruiter

    Synthego
    Redwood City, CA
    Senior DevOps Engineer
    $113,000 to $165,000

  • Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    As DevOps has matured and more organizations have adopted an infrastructure as code methodology, alongside an increased importance of security, we are seeing compliance as code and policy as code being adopted by many organizations. Progress Software’s Chef products are helping lead this trend. The video is below followed by a transcript of the conversation.

    Alan: Hey, everyone. Thanks for joining us on another TechStrong TV interview. I’m really happy to have – well, it’s the first time I’ve interviewed him here on TechStrong TV, but Charlene has had the pleasure of having Prashanth on before. Let me introduce you and I’m gonna do my best on his name, I apologize. Prashanth Nanjundappa. Is that close, Prashanth?

    Prashanth: Yes. Prashanth Nanjundappa. That’s close. 

    Alan: All right. Prashanth is with Progress Software, where he’s a VP of product, isn’t it? 

    Prashanth: That’s correct. 

    Alan: And we’re going to talk a little bit about today, we’re gonna talk a little bit about, you know, compliance’s code, you know, in this shift left kind of mode, but also the whole maturation of the DevOps space, etcetera. But you know what, Prashanth, as we spoke about off camera, this is your story to tell. Right? This is your kind of thing. Let’s, you know, talk about things that are important to you. Why don’t we, you know, tell us what what’s kind of important to you these days? 

    Prashanth: First of all, let me thank you. Thank you, Alan and TechStrong TV. This is a great opportunity to actually talk to many of the people who are using our products. Right? I am currently leading the head of product management for one of the business units in Progress, which is managing Chef line of business. We acquired Chef on board about 1.5 years ago. And this is my first foray into managing or building DevOps and SecOps tools. And that was a disadvantage, and also an advantage. 

    I got to talk to about 150-odd customers because I didn’t know much about this space. So the best way to learn about it is talking to our customers and talking to people who are experts in this domain. And that kind of got me really, really knowing about how these large enterprises are even tech companies are investing a lot in automating their day-to-day needs and adopting DevOps and their SecOps as technology practices, bringing those practices in their organization, and using tools like Chef to make just not their teams efficient, but also to increase time-to-market and reduce the risks of their business. 

    And the reason I’m talking on this, I think your target audience are the people who listen to this stuff. Your videos are the kind of practice notes that I talk day and day out all the time. They give the feedback which has helped us graph out the roadmap for years to come with Chef product line. 

    Alan: Absolutely. And you’re right. That is our audience. Right? Quite frankly, you know, when I launched DevOps dot-com eight years ago, Chef was one of the giants in the – you know, pioneer in the DevOps space, and that was our audience. But you know, over the years, we’ve seen this shift, if you want to call it shift left. It’s not necessarily a shift left, but we’ve seen an increased emphasis on security. And, you know, security’s partner in crime in many ways is compliance. 

    But as we’ve automated more, as we’ve gone faster and try to be better, faster and better, right, we’ve recognized the same way we’ve automate in DevOps deployment, we need to automate more when it comes to security and compliance. Right? And that’s been painful at times quite frankly. It’s not necessarily easy. 

    Prashanth: Oh yeah.

    Alan: Let’s talk about, you know, where the kind of hard parts are and how companies like Progress are helping us overcome that. 

    Prashanth: You’re spot on. It’s hard. It’s unnecessary evil as some people say but I think that is changing. So before that, taking a step back, why is security and compliance required? I think the need of security is well understood, but compliance data has been historically three primary reasons. Either they are regulated bodies who keep looking out who is complaint, who is not complaint. Every few months or ever few years, they publish a new set of standards, which give a perception to companies or tech companies that they need to adhere to that. 

    And that then get complemented by either the regulated sectors like banking and financial, credit card, or hospitality, healthcare, where security, privacy, all these things that are of most concern. And they look back at these regulatory bodies who have been publishing these specifications. These two kind of go hand-in-hand. And I tell you, there is a third-dimension, who are the customers who are using the products. They look at these regulatory bodies who turn out the specifications and also the regulatory. They say if I want to buy a product from you, I want it be certified. I want it to be compliant to this. 

    So these complaint as a need to operate in such industries. But I think it is moving a little from the basic necessity of, you know, being compliant to making sure that my development is fast-paced. Today, if you look at every – there are so many companies, Uber or something, Airbnb, or something, Yelp or something, and this used to be in the consumer sector, but it also coming into regular segments like banking, financials like that, Robinhood like companies have normalized trading, and they have made sure that anyone can launch a product. 

    So even tech chains, they have to adapt to this fast-paced market and bring their products not just fast into the market, but also adhere to the compliance standards, compliance specification, and make sure that whatever they launch is secure. And that is where automation comes. And that is where as a code paradigm came. You’re quite familiar with the evolution of how infrastructure as code and DevOps involved. There the codification of infrastructures have involved because they wanted to make sure that whatever gets developed is automated, and they test well in advance. 

    I think the same mindset is coming here because are there different bodies, developers, Ops team, and security teams. All of them generally speak in completely different languages, but if you want them to bring together to actuate the time-to-market, they need to speak one code, one language, and code seems to the most common, most acceptable language. And once they make a code, it falls into the DevOps sector. You can test it. You can repeat it. You can make sure there are checks and balance to make sure you flag, you audit everything. 

    But I think that mindset, and also DevOps has made compliance as code acceptable. And we are seeing more and more option. And that is ability of success for the traditional organizations to move in a fast pace. And new companies, they don’t even see other options as options. They take it as default option because this helps them past development. I don’t know if it makes sense. 

    Alan: No, it makes perfect sense. I mean it’s also a life a lot of our people are living day-to-day right now. Right? So the security person in me, and Prashanth, I was in security infosec, as we called it before, cyber sec, whenever I worry about compliance, I hear about compliance, I immediately start thinking, you know, am I dumbing down my security for compliance sake? Right? Because sometimes when we do compliance, it’s kind of, you know, I could call it least common denominator security. It’s like the lowest bar. Right? 

    Prashanth: Right.

    Alan: And a lot of people say, “Okay. I’m compliant. I must be secure too.” But they’re not. Just because you’re compliant doesn’t necessarily mean you’re secure, whether you’ve, you know. Compliance, as they say in Las Vegas, it’s a fine beginning. Right? But it’s not the mean to the end. So how do you, you know, as a compliance’s code type of provider, how do you make sure that your customers understand, okay, since you’ve done step one, but you still need to do step two and three. 

    Prashanth: Exactly. This is a very important distinction we also took a while to realize. Right? So there are three pillars: infrastructure, compliance, and security. So infrastructure is basically – I mean we can argue what is foundational, but you build your application and that’s where automation is required of infrastructure. Right? And then if you want to operate in regular tech sectors, if you want to be – not lose the competitive advantage with other players, you need to be compliant. 

    But security is something, which is fundamental. Right? You don’t realize until there is a breach, or until there is an impact on business. But, you know, these days, unfortunately, that is not very uncommon. We are seeing so many companies being exploited because of very, very basic mistakes like opening their port 80. Right? Exposing a port 80, or leaving their S3 buckets unencrypted. Right? 

    So many of these things are misconfigurations, or many of these things would have been covered or not happened if they had held to some of these standards. Two such bodies which offered a large specifications of best practices. Of course the primary takers of that is compliance. But those act as a foundation to security infrastructure. So we help our customers in obviously infrastructure and compliance, but we have started helping them in secure infrastructure as well. 

    Well, they have to look at infrastructure whenever an application passes through the CI/CD pipeline at each point in sort of just checking for the functionality using the right tools, some of the tools that we built, and some of the tools are available in their ecosystem. They can secure it. It can harden an image. For example, within Progress, there are teams which are using our Chef software to make sure that every image that gets into Artifactory, the Docker container gets into Artifactory isCIS specification, and other qualities that are specific. They don’t let it get into Artifactory without going through this. 

    So I think that is very much possible, and that is the education that we are giving and helping our customers, and that’s a two-way process. Right? Because we maturing in security. So as we engage with our customers, we are learning some of the shortcomings and the tools, and we are bringing back in the quality as code approach that we have been working in 2021 is based off this exchange, information exchange. 

    And also working with our customers, we realized that we’ve gotta go beyond infrastructure as well. Compliance and code, but two qualities a code where we help organizations define their government’s police, which is heterogenous and across organizations, sub organizations. But codify them and help them automate that process. 

    Alan: Exactly. So here’s an interesting thing from where I sit. Right? Sitting here running DevOps dot-com seven-eight years now. We can’t even have this discussion. We couldn’t have this discussion until we reached a certain level of maturity in the way we approach. Let’s forget compliance for the moment, but infrastructure as a code. 

    Prashanth: Yeah. 

    Alan: Right? Because you can’t start talking about compliance as code, and policy as code, and security as code until you got that infrastructure kind of down pat. Right? And so the fact that we are even having these discussions, right, and thinking about it, and implementing tools around it, you know, it was almost the proof on its face. Right? “Prima facie” as they say in law in school. Prima facie. That we are, we have matured, right, in the way we’re deploying our infrastructure, the way we’re automating infrastructure. So I’m calling infrastructure as code. Right? 

    Prashanth: Okay. 

    Alan: What do you think as we look ahead to 2022 and 2023, that continued maturity, what does it mean for policy as code? What’s next in other words? 

    Prashanth: I think a slight deviation from that is you said that is that you said about infrastructure expanded to DevOps methodology. Because I think that is the mindset shift that needed to happen for people to actually add up infrastructure as code, and then subsequently compliance and other paradigms, which would help them in automation. I think that is the foundation and we are seeing more and more companies seeing this as tables takes. 

    And again, they’re also – it has been a – there is a mindset shift that from where I see, it used to be a play for cost or optimization because of their bottom line. They wanted to reduce their development cost. They wanted to reduce the cost of having a breach. They wanted to reduce cost of finding a defect late in the cycle. But these days, I think is fight for spotlight because every – there is so much competition that is emerging, and there is no choice but to make your product available to your end consumer as soon as you can. 

    If you don’t do that, someone else is going to grab that opportunity for you. This makes it very, very important for organizations to take this learning that we talked about, which is a testimony that we are talking about compliance and security, but take the previous learning into their foundation. So that is what’s happening. Every new start-up that I talk about, I tell them in DevOps, these are something that they don’t even think as non-optional. Right? These are table stakes. 

    And from that point, they go on beyond, okay, I got my deployment automation. But hey, I have the security issue. I operate in a finance market. I operate in a banking sector. I operate in a hotel business. I operate in healthcare business. How can I make sure that I stay competitive? I make my data secure? This mindset of having faster time to market is making them add on these things very natural. And policy as code, whatever we are seeing, I think this is one of the common factors day one to stay competitive. 

    Alan: Got it. Excellent. All right. Prashanth, unfortunately we’re closer to 20 minutes now than we were to 15 that I told you we would do. Hey, we could continue this conversation though, but I think we’re in the right place. I think it’s something that resonates with the audience. For people wanting to get more information on Chef and Progress around this, where do they go? 

    Prashanth: Of course, we have a very vibrant community for Chef. So Chef community can be found on Slack. That is where us and other practitioners also hang out. And of course many of us are super active on LinkedIn as well. So these are the two places I think we can engage faster, and communities like this is probably the fastest to engage in Chef product, and engineering folks. 

    Alan: Okay. Hey, thanks for coming on TechStrong TV today. We’ll see you again soon. Best of luck to all the folks across Progress and Chef. 

    Prashanth: Thank you. Thanks for having me. 

    Alan: Okay. Bye-bye. All right. We’re gonna take a break. We’ll be right back. 

  • Force Me Back to the Office? Apple ‘Hasn’t Learned Anything’

    Force Me Back to the Office? Apple ‘Hasn’t Learned Anything’

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

    This week: I’m devoting my entire column to new ways of working. Whether it’s remote work, enforced hybrid working or a four-day working week, let’s triage the trends and futz with the future.

    Analysis: The Great Resignation — Not So Great

    Too many managers are stuck in their old ways. Despite the success of pandemic-era WFH, they yearn for how it used to be. But that ship has sailed.

    Mark Gurman: Apple Sets Return-to-Office Deadline

    “Pushing employees back into the office”
    The company … set a Sept. 5 deadline [and] will require employees to work from the office on Tuesdays, Thursdays and a regular third day that will be determined by individual teams. [It] has been working toward getting its employees back in the office since at least June 2021, when it first announced the three-day policy.
    …
    The iPhone maker has been one of the most stringent technology companies when it comes to pushing employees back into the office, irking some staffers. … An Apple spokesman declined to comment.


    It “Shows the Company Hasn’t Learned Anything,” cries Jason Aten:

    “Not the same thing as actual collaboration”
    Right now, every company is trying to figure out how to get its employees back to the office. Despite the fact that the world did not, in fact, come to a stop over the past two years. … Many companies—especially Apple—had their best two years ever when most of their employees were working from home.
    …
    Apple SVP of software Craig Federighi … told employees in an email … he “can’t wait to experience the special energy of having all of us back in the office together again!” … I imagine a lot of the people who work in the software organization are wondering whether that “special energy” actually makes them more productive—or if it’s just a thing managers feel as they watch employees.
    …
    If we’ve learned nothing else from the pandemic … coming to the office doesn’t make them more productive. It might make managers feel better … but that’s not the same thing as actual collaboration.


    But WFH doesn’t suit everyone. Here’s Aunty’s Kate Morgan: Why workers just won’t stop quitting

    Anthony C Klotz, a professor of management at University College London’s School of Management who coined the term “Great Resignation” [says] in addition to the original push factors … the reasons people are resigning have diversified. … Some workers are now swapping jobs that require them to be present in the workplace for remote positions. Other workers … are leaving remote jobs for ones that have a larger in-person component.


    WWSJD? quonset knows:

    Regardless of the jerk he was, Steve Jobs had grand visions which he brought to fruition. … One thing he stressed was the personal connection and serendipitous encounters.
    …
    It’s why, before he died, he was arms deep in the design of Apple’s headquarters. He wanted people to bump into each other, he wanted interaction between different groups. It’s why it’s designed the way it is. People are funneled to certain areas and have no choice but to interact with others.


    Is there an unintended brand consequence? u/Latinhypercube123 demonstrates there might be:

    Hahahaha. Apple is such a dead end company now. They’ve literally become what they ridiculed IBM of being: Corporate monolith of sameness.


    But is there a better way? You should read Evelyn Yu: Bank Says Four-Day Week Is The ‘Future of Working Life’

    “Flexible work is here to stay”
    Six months after switching to a four-day working week, the UK’s Atom Bank said it’s seen benefits from talent retention to improved productivity. … Days lost to sickness fell over the period and customer service ratings also improved.
    …
    Even as the pandemic recedes and some bosses push for a return to the office, there’s increasing evidence flexible work is here to stay. Office vacancies in central London are at the highest level in more than 15 years.


    Not just in the UK—it’s in Canada too. Here’s Sean Davidson:

    “Huge impact on employee retention”
    Ross Wainwright, CEO of Alida, said the software company implemented four-day work weeks for its 500 employees at the start of June and the two-month trial wraps up this week: … “The early results are fantastic. … The employees are clearly happier. … This is about getting better balance for our employees and helping to invest in their mental health.”
    …
    He said the trial is also having a “huge impact” on employee retention. … The most “unanticipated” result of the trial was how empowered his employees told him they felt, knowing the company trusted them to get the job done with a reduced schedule: “We empowered the employees to get the work done within their schedule.”


    Also in Toronto is u/SuperChloe:

    We had similar results at my company when we initially trialed 4-days (also not longer days, still 9-5) — overall increased output/productivity and employee satisfaction. We’ve moved to permanently having a 4 day work week.


    Meanwhile, @AnnaLovesVoting is just fine with a hybrid schedule:

    I don’t need 100% WFH, I’m willing to go to an office 1 maybe 2 days a year.


    The Moral of the Story:
    The tempter or the tempted—who sins most?


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Carles Rabada (via Unsplash; leveled and cropped)

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

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

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

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others.

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

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

    LinkedIn

    CapitalOne

    Annapolis

    Director of Software Engineering – Risk Management and Compliance

    $190,000

    Dice.com

    Nigel Frank International

    Remote

    Senior Azure DevOps Consultant

    $165,000 per year.

    Indeed.com

    ROM Technologies

    Brookfield, Conn.

    DevOps Engineer

    $120,000 per year.

    SimplyHired

    Comcast

    Philadelphia, Penn.

    Senior Engineer Cloud Infrastructure

    $109,932 – $164,898.

    Monster.com

    Target

    Remote

    Lead Engineer – High Performance Distributed Computing

    $105,800 – $190,500

  • The Advent of Intelligent Software Engineering 

    The Advent of Intelligent Software Engineering 

    Today, to maintain competitiveness, every company needs to behave like a software company and deliver new solutions with high velocity, quality and reliability. New features need to be introduced at a rapid pace, but with high-quality expectations. At the same time, deployment releases and operations are getting complex, debugging and traceability in production are increasingly difficult, security is more prominent, uptime and reliability needs have scaled up dramatically … the list goes on.

    In short, traditional software engineering is changing radically.  Some trends causing this disruption include:

    • Cloud is eating software. And that has not only changed the infrastructure where software is hosted but also how applications are architected, developed, packaged and deployed. Cloud is driving the adoption of cloud-native technologies; serverless components and containerization have changed how we build applications. The hard line between development and infrastructure team is getting fuzzy. 
    • Cybersecurity is now a boardroom concern. Rising cyberattacks and malware threats have left everyone vulnerable. Traditionally, software was released every few months, leaving enough time for security testing by specialists. Today, with the advent of very rapid release cycles, security checks need to start early in the development process.
    • AI/ML is the new electricity but is causing shocks. AI/ML-powered use cases are finding their way across platforms, and across industries. Traditional software engineers are not familiar with AI/ML and ML developers are not familiar with engineering disciplines and best practices, leaving a big divide in engineering maturity.
    • When one company raises the bar, others are expected to follow. Consumer expectations are constantly changing. They expect the same experience that they get from Amazon, Uber and Google from every application. It is expected that you provide a seamless, frictionless experience that your platform is available anytime, on any device and that it is fast and secure. 
    • APIs are fueling innovation: Innovation at speed and scale is not easy, but APIs can enable exactly that by tapping into the collective power of the crowd. Today, any developer can use platform-provided APIs to build a new, innovative solution. An API-first mindset is emerging, and the app store model (e.g., Apple App Store, Salesforce AppExchange, AWS Marketplace) has changed how we think of innovation and creating new platform extensions. 
    • Low-code/no-code platforms are quickly evolving, making it easy to develop small, situational applications without writing any code. Citizen developers are emerging. 
    • Modern architecture paradigms drive new ways of working. Modern platform architecture has evolved significantly in recent years from monolithic applications to SOA to microservices- and API-based distributed platforms. Event-driven architectures have gained prominence. Streaming architecture has become increasingly popular to support massive scalability. This has a significant impact on how engineering teams are organized and how they build, test, deploy and manage new platforms. 
    • Legacy platforms are slowing down growth. Legacy applications built 20+ years ago needs to be modernized for today’s context. Modernization is a massive exercise depending on the age, technology and the size of the application. But modernization is easier said than done. The legacy and the new worlds need to coexist for a while and need a bridge strategy from both a technology and cultural perspective.

    To meet these changing demands, engineering needs to become a lot more intelligent.  

    The Advent of Intelligent Engineering

    We can bring intelligence to engineering by using more data to manage projects, leverage AI/ML analytics to bring improve engineering productivity and predictability, leverage more automation and apply the right process to the right problem. 

    Data-driven Decision-Making in Engineering 

    Engineering teams use numerous tools in the development environment for code repository, bug tracking, code scanning, build, test, deploy, etc. Popular tools include Azure DevOps, GitHub, Atlassian and Jenkins, among others. These tools generate lot of granular data. All these data silos can be aggregated and used to track interesting metrics around:

    • Developer productivity: How much time is spent on writing how much code versus other activity; story points delivered versus committed
    • Software quality: Number of bugs generated; rate at which bugs are being fixed; number of bugs that slip into production 

    Additionally, on top of this data, one can build an intelligence layer using machine learning to draw hidden insights, highlight co-relations and conduct better root cause analysis. These insights can bring greater predictability to engineering outcomes. For example, whether or not developers can meet a release schedule, the level of quality, etc.

    Data provides evidence of how your teams are performing. It helps in removing potential roadblocks and enables better communication with all stakeholders. It can be used to better manage project performance and be leveraged for objective decision-making. Despite the availability of this data, engineering leaders are still operating in the dark. Decisions are made based on intuition and gut feel rather than on hard data. It’s time to become more intelligent by using data in project performance tracking and decision-making. 

    Elevate Productivity and Predictability of Engineering Services With AI

    AI/ML is disrupting every industry and is now finding its way into software engineering. AI/ML-enabled developer tools are emerging that can be leveraged across the software engineering life cycle. These tools can not only save time for repetitive activities but also improve software quality in large and complex tasks. 

    AI/ML-enabled tools can enhance a developer’s daily life from coding to testing. Today, AI-powered tools can scan and analyze code to provide intelligent code completion suggestions, flag any deviation from coding best practices (naming convention compliance, variable misuse, etc.), perform peer review, convert code from one language to another, find security vulnerabilities, etc. Dynamic application security testing (DAST) solutions use AI to discover potential attack vectors in milliseconds which would otherwise take a few days. AI/ML can help auto-generate HTML code from hand-drawn UI sketches. AI/ML also can help developers automatically generate unit tests from existing code and provide suggestions about improving tests.  

    In fact, testing is the biggest category that can benefit from AI/ML-based intelligence, specifically in large complex applications. QA teams who rely on manual testing are not able to keep pace with the rate at which code changes and releases are done today. AI/ML-enabled tools can help testing teams in a number of specific ways. 

    • Change impact analysis: AI/ML can help with coverage analysis and identify which tests need to run based on what has changed in the application.
    • Test creation: AI/ML can help test teams create test cases from plain English descriptions and can also learn how to improve tests over time; AI/M also can automatically heal broken tests. AI-powered tools can automatically convert manual UI tests to API tests.
    • Visual testing: AI-powered image comparison technology can enable visual testing to analyze the UI screen differences detected across tests. 
    • Test analysis: AI can analyze test cases and defect metrics to increase test coverage while reducing the number of tests.

    It’s time to become more intelligent by using AI-powered tools to augment engineering teams, improve their productivity and bring predictability. 

    Intelligent Automation: Beyond Development Processes

    Today, there are a lot of automation options in the software development life cycle. DevOps enables automation of build, test and deployment of new versions of your software. You can also automate other activities such as test automation, code scanning, performance test, etc. DevSecOps enables automation of security processes (e.g., code scanning for vulnerabilities) into the engineering life cycle. AI/ML-powered tools can further drive automation improvements (e.g., improve flow in your CI/CD pipelines.) Overall, automation enables higher team productivity and results in the rapid or on-demand release cycles required for business agility.  

    Automation is not just limited to development activities, it also applies to other parts of the engineering life cycle, for example:

    • Infrastructure-as-code (IaC) tools can automatically provision and configure cloud infrastructure environments (storage, network, etc.).
    • Monitoring tools can automate monitoring for availability, production load metrics and security problems and generate alerts. 
    • Log management: The number of logs generated in today’s ecosystem is vast and it is impractical to collect them manually. Log management tools can automatically aggregate and analyze information from logs.

    Leveraging automation aggressively and using it throughout the engineering life cycle can make software engineering much more intelligent. You should be automating repetitive tasks and low-value processes and use the saved time for higher-value activities.

    Making Agile Smarter

    There are several popular software engineering methodologies available such as Agile, Scaled Agile, the Spotify model and more. Regardless of the methodology or process you use, intelligent application of the right methods and tools to the right problems can make them more effective, efficient and intelligent. For example, traditional Agile processes were originally designed in the manufacturing space and were then adapted to develop mature software. But in today’s fast-changing market, development teams need to rapidly and continuously try new ideas either to demonstrate new business features or for technical validation of emerging technology. This is true not only in the early stages of new product development but also on existing platforms where you need to keep pace with changing market dynamics. Be ready to experiment.

    We need to get smarter about selecting the right process and tailoring it to your needs rather than let the process dictate your outcome.

    If Software is Eating the World, Complexity is Eating Software

    While product engineering has been around for a long time, modern software engineering is a lot more complex than just writing code and following Agile processes. Intelligent engineering practices can get solutions to market faster with better quality and reliability and gain more time for innovation to keep up with today’s speed of business.