devopsy.kinsta.cloud

Tag: application developers

  • A Developer’s Guide to Building Healthy Teams

    A Developer’s Guide to Building Healthy Teams

    To build a great software product, teamwork must extend across developers, managers and executives. Everyone needs to understand each role’s value–you can’t have an effective team without a good coach and vice versa. It takes a culture built on empathy, trust and shared responsibility with the right amount of ambition and personal connection to make the dream work.

    It isn’t easy to achieve this balance, but here are some tips to help your team become healthier and more effective.

    Watch out for Knowledge Silos 

    When too much unique knowledge is stored in one person’s brain, your ability to get things done depends on their capacity, which can jeopardize the team and the entire organization. Some silos can be good, but only when everyone on the team knows what’s in each one and how to access the information. 

    Knowledge silos can take several forms: 

    • Technical skills, like being the only one on the team to know Go or Python.
    • Ancillary knowledge in some field, like a background in statistics.
    • Historical knowledge, like a developer who has been there from the beginning and knows the whole codebase. 
    • Institutional knowledge, like understanding larger business and project strategy and the history of the company. 

    There are some great hacks for overcoming knowledge silos. Simple awareness of who is good at what–or what background everyone has–is a great place to start. Leaders can then think creatively about team collaboration like pair programming or assigning pull requests based on each individual’s knowledge. Pushing each developer to assess their own silos can help set the team up for better knowledge sharing during impromptu sessions or scheduled meetings. Prioritizing documentation is a good way to ensure developers share what they know. Additionally, using brown bags and demos can help your developers hone their teaching skills. These strategies are a great way of investing in your team’s future velocity.

    Focus on the Individuals That Make up the Team

    Fast Company published a great article about the different personality types that make up a great team:

    • The brain pushes others to take action in pursuit of a goal.
    • The voice gets the big picture and motivates the team.
    • The sharp eye focuses on details to get things done the right way.
    • The heart promotes community, consensus and collaboration.

    Thinking about these four very different traits and identifying who plays each role on your team can help you build a harmonious group—while ensuring the strengths of each individual are emphasized and appreciated. 

    Foster Empathy and Build Trust

    Having empathy for your team often means finding a balance between the desire to win or hit certain goals and understanding the different needs of each teammate. As a manager, you should push yourself to ask thoughtful questions that put you in your developers’ shoes. 

    Empathy builds trust. So does:

    • Supporting developers at their unique levels.
    • Nurturing a culture of healthy sprints and personal well-being.
    • Using data–and not just a gut feeling–as a starting point for improvement
    • Clearing roadblocks to productivity so that teams don’t feel overloaded.
    • Granting autonomy to individual contributors.
    • Consistently accomplishing goals as a team.
    • Being transparent with challenges the team is facing.
    • Sharing data across the organization.

    Things that tend to erode trust include:

    • Stack-ranking developers based on lines of code.
    • Rallying around ambitious deadlines at the expense of burnout. 
    • Using data to demean your team members. 
    • Enforcing a productivity quota.
    • Managing with a top-down perspective.
    • Limiting data to leadership.

    These tips help teams avoid burnout, which is a surefire way to wreck a team. The World Health Organization (WHO) defines burnout as “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed.” So this isn’t just an individual’s personal problem–burnout is a sign that something is wrong within your organization. 

    Understanding knowledge silos, emphasizing individual strengths, cultivating empathy and building trust are the foundations of a strong developer team. Once you have those covered, you’ll be on your way to healthier, more effective teams.

  • One-Third of Developers Seeking New Job

    One-Third of Developers Seeking New Job

    With the relentless pace of enterprise digital transformation efforts, even in this softening economy, developers still face an enviable job market. The number of open job positions in computer occupations is greater than 804,000, according to National Foundation for American Policy (NFAP) analysis and, at 326,000 vacancies, software developers have by far the largest number of job openings available to them.

    US Developers Are Less Confident About Job Prospects

    Still, according to a new report from OutSystems, Developer Engagement Report: Are Your Developers Happy or Halfway Out The Door?, slightly more U.S. developers are seriously considering changing companies right now (33% U.S. versus 31% globally) and they feel less confident about their prospects. Only 25% of U.S. developers strongly agreed that there are many opportunities to easily get a better position right now, compared to 42% of global respondents.

    Still, not many developers are thrilled with their current jobs. According to the survey, only 49% of U.S. developers love their jobs and only 37% are very satisfied with the work they do every day. Outside the U.S., developers are a bit more optimistic. Globally, 64% reported that they love their jobs and 46% said that they are very satisfied with their day-to-day work.

    Interestingly, when it came to work-life balance, it was U.S. developers who felt more optimistic than their global counterparts. While 50% of all respondents strongly agreed that they need more work-life balance, only 38% of U.S. developers agreed on the same.

    Finally, while 48% of developers said that they would definitely be with their current employer within a year, when that timeframe was extended to two years, that figure fell to 29%. And U.S. developers are itchier to move, with only 38% saying that they would definitely be with their current employer in a year and 18% said they would remain there in two years.

    Most Low-Code Developers Also Traditional Coders

    The report also examined so-called low-code developers. As a subset of the broader population of developers, 59% of low-code developers reported being very satisfied with both team productivity and 57% were satisfied with the quality of tools they use at work. Only 41% of traditional developers felt the same toward team productivity, and only 36% of traditional developers are very satisfied with the quality of the tools they use.

    Interestingly, 71% of low-code developers reported that they can keep their workweek to the standard 40 hours, while only 44% of traditional developers said the same. While 63% of low-code developers said that they are happy with their salary and benefits, only 40% of traditional developers agreed. Further, low-code developers claimed an average of 3.5 job promotions at their current company while traditional developers said they’ve been promoted two times.

  • Alleviating Developer Workflow Headaches by Moving to the Cloud

    Alleviating Developer Workflow Headaches by Moving to the Cloud

    Leaders in tech make one common mistake when it comes to serverless and cloud computing: They want to migrate their current environment exactly as it is to the cloud. That’s about as limiting as planning a flight path along the road network and deciding the route based on street-level traffic. You can do it, but everyone’s going to look at you like you’re crazy.

    Keeping that ‘lift and shift’ mindset prevents developers from seeing the real ROI of cloud computing and serverless technology. Instead, we have to challenge our traditional ways of thinking.

    Redefining How we Think About Software Development

    The traditional definition of software is anything that makes the hardware do what we want it to. We use operating systems to control internal functions as well as peripherals. We use application software to direct our computers to execute commands. So we tend to think of software as programmatic, needing specialized programming languages to develop. But the most popular functional programming language isn’t Erlang or Haskell or Lisp. It’s Microsoft Excel, if you can believe it, with over 750 million users.

    Every Excel spreadsheet represents someone’s software; it makes their hardware process data in a way that’s valuable to them. In a similar way, the “systems” we build on the information technology side are just more software. And cloud computing gives us a new range of powerful tools so we can build bigger systems faster than before.

    What are Cloud Computing and Serverless Computing?

    Cloud computing largely references data centers and data storage. Serverless computing is one piece of cloud computing. It lets developers create software without managing infrastructure. In the end, it increases productivity, speeds up product delivery, optimizes resources and keeps developers focused on the end product rather than infrastructure maintenance.

    Once deployed, serverless apps respond to demand, scaling up or down as needed. So when a serverless function sits idle, it costs nothing.

    Key Benefits of Cloud Computing and Serverless Computing

    There are many benefits of cloud computing and serverless frameworks. By far, the one leaders are most excited about is cost control and increased ROI. It’s also one that leaders most often miss.

    Increase ROI With Cloud Computing and Serverless

    The number-one way to increase ROI with serverless frameworks and cloud computing is to avoid building anything from scratch. Invest in open-minded research. Sometimes you need to build something yourself, but often there’s a way to shift some of the burden away from your team. 

    An easy example is functions. The first thing most developers think of when they hear “serverless” is functions. But the functions running code are just a tiny piece of the puzzle. Serverless technology allows development teams to hand off as much work as they can to cloud platforms like Azure, Amazon Web Services (AWS) and Google Cloud Platform (GCP). 

    Just like someone wouldn’t buy a field, till it, plant wheat, water it, thresh the wheat into flour, bake bread and toast it to make a piece of toast, developers shouldn’t write their own code when the building blocks already exist in their cloud platform. Take, for example, Azure’s Durable Functions feature. This feature manages stateful workflows so teams don’t need to explicitly create, store and retrieve the progress through your data’s workflow in some other place. This process is so common to the systems that teams build that the cloud providers made it available without needing us to write lines of code. It’s like instant toast delivered to your door!

    The more a team can leverage already-made code, the more time they get back on their schedules and the more money goes back into the team’s budget, something we can all appreciate!

  • Eradicating Developer Burnout With a Flexible Workforce

    Eradicating Developer Burnout With a Flexible Workforce

    Burnout can affect people no matter what their job role, but software developers are particularly vulnerable. Too often, businesses chase profits by chronically relying on heavy workloads delivered by employees in short turnaround times. Developers often undertake intense work and find themselves pushed to meet deadlines under great pressure over and over again. But without proper care, burnout is almost inevitable. After all, developers are humans first before they are developers.

    Programming is a cognitively stressful job that requires individuals to constantly solve complex problems. Working for hours on end day after day with no break is tough for anyone, and this pattern over a period of weeks is all too familiar for developers. 

    But slowly, the face of the workplace is changing. We are seeing a post-pandemic focus on employee well-being, and the current job market conditions mean that professionals have choices and the right to demand better care or even explore self-employment or non-traditional job paths (thanks, Great Resignation!). In this context, businesses are also thinking differently about how they work with talent to use workers more efficiently.  There is an opportunity here to lower the burnout risk facing developers for the benefit of employees and employers.

    Organizations Can’t Afford Burnout

    Developers are key to most digital transformation projects, so organizations can ill afford for their developer teams to suffer from burnout. This can significantly delay the rollout of new products, features or apps and slow down DevOps initiatives, which can’t progress without the tech teams responsible working consistently and productively. 

    This risk to developers is particularly high in the wake of the pandemic, with technical staff under additional pressure to play catch-up and deliver projects that might have stalled. During this period, there has been little consideration for employee well-being; a 2021 study found that 83% of software developers were experiencing burnout. It’s not just about writing code—technology teams also struggle with inefficient engineering processes, backlog and technical debt  and are more likely to encounter friction when trying to deliver work quickly, leading to a greater risk of burnout. 

    Low quality in-house software is also a point of frustration for development teams, with 83% of engineers reporting being concerned about software reliability in their organisation. Prioritizing the right tools for these teams is one way that businesses can help ensure projects run more smoothly. It’s a simple fix, but one that is frequently overlooked, though empowering technical teams is increasingly top-of-mind for businesses.

    Developers Aren’t Easy to Replace

    Great developers come with years of experience, learning their trade through practical problem-solving. They’ve never been easy to replace, but the state of the current global job market means it is more difficult than ever. This is inherently linked to developer well-being; some are changing jobs and moving to other companies in search of better working conditions while others are creating their own. For example, many are switching to freelance roles to gain independence and control of their own workloads. 

    However, freelancing can be lonely and admin heavy. Despite the improved flexibility, the lack of support can also lead to burnout. Talent clouds offer a potential solution to this through closed communities offering structured work for freelancers and regular interaction with peers. They have seen a surge in membership and have driven wider uptake of self-employment. In fact, 11.2% of developers were freelancing in 2021, up from 9.5% in 2020, as they sought to balance the freedom of freelancing and some of the perks of permanent work. 

    And that’s crucial. For a role that’s considered ‘always on’, the flexibility of freelancing to decide when or where developers work could be crucial to delivering quality, secure code. Without wasting hours a day commuting—that could otherwise be spent working or, crucially, decompressing from their intense workload—it’s been the option of choice for overworked developers all over the world. IT is the foundation on which modern businesses are built—giving the architects of these businesses some of this flexibility is a small price to pay to ensure their well-being. And, as a result, the timely delivery of products, projects, features and apps that accelerate digital transformation initiatives.

    It’s a Two-Way Street

    We’ve already seen how the increased workplace flexibility afforded to freelancers translates into better productivity and lowers the risk of burnout. Equally, 31% of developers worry about unclear goals and processes, so there is also something to be said for improving project management of digital initiatives to ease the burden on technical staff. In fact, 58% of devs feel that burnout is not inevitable, and that better working practices and management are key tools to its prevention.

    For businesses wanting to deliver projects quickly, harnessing on-demand workers from the increasing pool of freelancers means they can engage specialists depending on the type of work or coding language being used, but also that they are fresh to tackle each new challenge—a key concern among developers who have experienced burnout. Doing so via a private talent cloud also ensures that the burden of managing and vetting freelancers is taken away from the organisation and nixing potential concerns about bringing in external talent. 

    Eradicating Burnout

    Well-being is in the public eye more than ever. On one hand, developers should not have to face the high risk of burnout; on the other, businesses can’t afford to lose the talent fuelling their digital future. 

    Both parties can help solve the issue. Developers are taking professional well-being into their own hands by exploring freelance careers that give them flexibility. On their end, businesses need to consider creative ways to access talent. In part, this is about ensuring internal technical teams have the right support in place so they do not become overworked. It’s not easy to find this support in the current job market, but with developers flocking to freelancing, there is an opportunity to rapidly engage highly skilled workers on an on-demand basis at pinch points. After all, a well-managed workload significantly reduces the risk of burnout.

    We have the resources and available skills to eradicate burnout among developers—we just need to arrange them in the right way. 

  • There are Few Enough Silver Bullets

    There are Few Enough Silver Bullets

    I was working through this week’s blog this morning, and it was laser-focused on a narrow topic. I had examples of why too much of a good thing is bad, how absolutism about methodology is hurting the majority of organizations out there, and how to get past this issue to keep improving what IT does for the organization.

    And I was nearly done when I decided that there are far too many areas of IT that suffer from absolutism, so I’d offer general symptoms and steps that work to get out of any of them.

    What do I mean by ‘absolutism’? Well, it used to be—and, in a couple of areas, still is—true that people would say, “We are an X shop.” And mean it. If you were a Cisco shop in the 1990s or 2000s, that is all you bought. Competitors were not allowed; nor was consideration of competitors. This applies to methodologies as well as product categories. In fact, today it applies to various methodologies more than products.

    And it’s bad for the organization, no matter where it comes from. While with vendors, it streamlines purchasing and offers the (in)famous “single throat to choke”, it also causes inefficiencies in costs (from your perspective, they are a monopoly, and some large vendors gained infamy by trying to take advantage of that fact), and causes people to do things in the least efficient way because that’s what the chosen methodology/solution requires.

    Sometimes, we manage to do the dance and avoid “One True Way”—take the move to cloud and continuation to multi-cloud, for example. While cloud vendors do not offer customers much leeway in pricing or priority (we customers are all cattle, not kittens), multi-cloud still offers us the opportunity to use the cheapest or best-suited cloud vendor without much drama.

    Many times, we are not so effective at avoiding the idea of a silver bullet. Take Agile. If there was a One True Ring of this decade in IT, I’d want it to be containers, but it would actually be Agile. Most IT departments zealously guard that Agile is the One True Way. Early-stage new product development is astoundingly well suited to Agile, and we needed it—if just for that part. Late-stage product maintenance, where changes are not feature-laden monuments to systems complexity, are also really well-suited to Agile and we should be happy to have it. In between? Large updates that can span data centers—or even continents—with a geographically dispersed workforce and hundreds (or more) of hours of development to get one sub-feature completed? Not really a great fit for Agile, and while many of us have said that for years, here is hoping things are changing. As I’ve said before, as maligned as waterfall was, it did the job for decades and handles large complex projects well. Maybe we need a replacement more in line with the times; one that incorporates what we’ve learned from Agile. I’d love that, actually. But what we don’t need is “We’re an Agile shop.” It is less useful than when it was said about products (at least if you only chose a single product, you got single sourcing and streamlined purchasing. With methodologies, you don’t even get that).

    Note: Agile is an example, not the point of the post. Avoid “One True Way” across your organization. Root it out and examine it. Sometimes, a single solution with a single specialized skillset is the perfect answer—at least for now. Far too often, “We are an X shop” is someone’s preference codified into corporate policy.

    To get past One True Way, you have to be there showing its weaknesses to management. There is some skill overlap when allowing multiple approaches or products, but if management starts prattling about that, simply point out the number of development and/or CI/CD environments the org is currently supporting. To show the overhead, track hours spent. Staff shortages have been endemic to IT for years. Make certain you know how much time is spent in overhead for the product or process, and try to map that to what could have been achieved with that time. It’s not perfect, but it will be illustrative. And don’t stop. Do your work, but point out every time that One True Way makes the job harder or more expensive.

    You are nailing it. Don’t let things like Agile keep you from churning out great apps for the company. I’ve been on teams where the time spent in process overhead was dragging down the ability to deliver quality. Fight that. Keep kicking it, and use the best tools/processes for the job.

  • Self-Service Helps Devs Solve Cloud Security and Compliance

    Self-Service Helps Devs Solve Cloud Security and Compliance

    Organizations that need compliance must follow a growing number of security standards—PCI, HIPAA, SOC 2 and GDPR just to name a few. Every new standard gives rise to an exhaustive list of hard-to-implement security controls.

    Cloud providers like AWS have tried to help, but there is still a lot left for developers to do to secure their infrastructure. Cloud providers give you the raw materials necessary to remain compliant, but you’ll have to learn how to use them.

    It may be easier to envision the scale of the compliance challenge by working through an example. PCI DSS is a typical security standard. When moving to the cloud, you’ll have to figure out how to take your compliant infrastructure and implement it using cloud technologies.

    PCI has several requirements regarding network architecture and firewall barriers. For example, specification 1.1.4 calls for a “firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.”

    Segmentation is the goal. Your network can’t allow traffic to move freely to wherever it wants. You need to set up rules and carefully guard sensitive areas of the system.

    In AWS, we’d suggest implementing this requirement using a mixture of services. Testing, staging and production regions of your application should each be in their own VPC. You’ll also need intelligent use of Security Groups, identity and access management (IAM) and instance profiles. Lock everything down and only open the necessary ports. A web application firewall (WAF) should protect the perimeter.

    IaaS services like RDS and Elasticsearch should be isolated via security group. Platform services like Dynamo, S3, SQS and Secrets Manager should be isolated via IAM. Lambda has one leg in the security group and another in IAM.

    PCI control 6.1 states that you must have a mechanism in place to identify security vulnerabilities within your compliant systems. How can you accomplish this in AWS?

    Automation is your best friend in application security. As the speed of development increases, security must keep up. And while there will always be a place for humans to dig into applications through penetration testing to find tricky vulnerabilities, automation will help you find the low-hanging fruit.

    AWS Inspector is an API-based service that will proactively scan and assess your application for vulnerabilities and warn you about them. This is an automatic process once it is set up, but it requires an administrator to choose what to test.

    Other tools exist to automate application security, such as Wazuh. As with AWS Inspector, there is effort involved in setting it up, initially. But once you complete the configuration, you’ll have a constant security scan running to find vulnerabilities before they reach production. And should some slip in, the scans will continue to search and find vulnerabilities before attackers exploit them.

    PCI Requirement 7 states that you must “restrict access to cardholder data by business need to know.” You’ll need to know who has access to what within your application and when they can access it.

    Restricting access in a cloud environment can be challenging because you require administrators to configure the services that your application needs to work. How can you limit access while allowing the admins to do their jobs?

    Orchestrating access control will require careful use of AWS Security Groups, IAM and federated tokens. Give your admins a token for access that expires quickly. Whitelist trusted IPs for access only to the areas of your environment that are necessary for the user’s role.

    The whitelist of IPs and the security groups will need to be kept up-to-date to make sure no holes open when personnel changes. Keep a tight grip on access control in your cloud environment.

    PCI Requirement 10 outlines the need to track and monitor all access to network resources and cardholder data. As your cloud environment grows, you’ll need more help to keep tabs on changes and user activity.

    AWS CloudTrail can be used to track user activity and API usage. But you’ll have to make sure that CloudTrail can’t be disabled without your knowledge to hide someone’s illicit activity. AWS IAM and Config services can be used to make sure CloudTrail can’t be disabled and to alert you if it is.

    CloudTrail can cover user activity, but what about infrastructure changes? You may need to bring in another tool, such as ELK, to track changes to your infrastructure. You can then marry the data from CloudTrail and ELK into a single SIEM for dashboarding.

    From this example and just these few requirements, you can see that the cloud is not a “push-button” solution.

    And this is only one example. Remaining compliant with SOC 2, HIPAA, GDPR, NIST and a host of other standards will require the same careful planning and execution.

    Planning for Compliance

    First, your team must stitch together many different software tools that help with compliance. Second, you must run periodic scans on your infrastructure and security controls after you provision your resources which essentially place Band-Aids on top of the holes you’ve created. Instead, applying controls during the provisioning process places a secure foundation under your developers’ code.

    DevOps teams try to maintain control over infrastructure and application deployment processes to avoid any mistakes from developers. Suddenly, developing software in the cloud begins to look the same as developing on-premises—delays, disappointment and frustration.

    Three things lead to successful cloud compliance:

    1. Careful planning and execution
    2. Automation to provision the necessary controls while you build your infrastructure
    3. Ongoing maintenance to adapt to changing regulations and standards

    You can help developers unlock the power and agility of cloud development while remaining compliant. But you must enable self-service for them as much as possible while maintaining security and compliance. The only way is to give them control of doing things they want while hiding low-level details that can get them in trouble.