DEV Community: Geoff Stevens

How has development changed over the course of the pandemic?

Geoff Stevens — Tue, 09 May 2023 20:48:50 +0000

Today, we're excited to announce the release of the 2023 Future of Work Report.

Our team has spent the past few months analyzing data from more than 400K software developers over the past three years. And in analyzing that data, we uncovered three key insights into how software development has changed, and what that means for the future of work.

Those insights are summarized below, but we hope that you will check out the full report, which includes stats on burnout, work-life balance, AI trends, the tradeoffs between remote and office work, and more.

What we found

We found that the developer experience has improved over the last three years, while productivity remains relatively unchanged. Developers are spending less time coding nights and weekends, reclaiming time from interruptions, and making better use of commute times. They are feeling less burnt out. While they are spending slightly less time coding, they are getting more efficient with their time, automating away repetitive tasks with AI and automation tools.

These are a few of the indicators we've seen that the shift to remote work has been, overall, a net positive for the global development community.

1. Developer experience is improving

With more flexible schedules, more work is getting done between 9am and 5pm (+5%). Developers are coding 9% more during morning commutes and less work is being pushed to late nights (-11%) and weekends (-9%). As a result of a better work-life balance, developers are feeling less burnt out.

2. Productivity is unchanged

While developers are spending marginally less time coding per day — 59.9 minutes in 2023 compared to 64.2 minutes in 2020 (-7%) — this change has been offset by a small improvement in efficiency. Keystrokes per minute coded, a proxy for focused work, increased by 4%. At the same time, an increasing number of repetitive tasks are being automated away with code completion and AI tools.

3. The effects of automation and AI are increasing

With the rapid adoption of AI and automation tools, like GitHub Copilot, developers are writing and editing code at a faster rate than ever before. From 2020 to 2023, the average number of characters inserted per keystroke increased by 41% and lines of code edited per minute increased by 39% — indicators of the increased usage of generative AI and code completion tools. The long-term impact of these tools on productivity and code quality remains unknown.

What has the impact been for you?

Global trends, however, are not indicative of every company. Even within engineering organizations, there can be radical differences between teams, projects, and locations. Most companies have only scratched the surface of understanding the long-term impact of remote work.

What has your team's experience been with remote or hybrid work over the last few years? We'd love to hear more stories from the community:

How has remote work impacted your work-life balance?
Are you more productive working from home or at the office?
Do you use generative AI tools, like GitHub Copilot?

If you're interested in this type of data, I'd recommend checking out our full findings, which includes more stats on AI-powered automation, improvements to work-life balance, and the shifting contributors to burnout.

Frequent, less painful deployments

Geoff Stevens — Wed, 28 Sep 2022 23:13:54 +0000

If you're an engineer and you're reading this, chances are you've felt pain around deploying changes to production. Deployments cause stress and anxiety for everyone involved, especially when they're an infrequent occurrence.

First, let's look at how a hypothetical team working on a financial app at a large company deploys code to production:

The team schedules a release for the end of the month, followed by a two-week code freeze.
After scheduling the release, they kick off a formal change approval process, which requires coordination across multiple teams and departments. The app has a wide range of dependencies since it integrates with other core systems.
During the release process, they uncover several features that are not production-ready. These features are delayed until the next release. They identify one critical feature that must go into the release this month, so the team works overtime and cuts a few corners to finish it.
They deploy a release candidate to a staging environment for testing. Environments are frequently in contention, so the team is blocked while they wait on servers.
After they validate that the release meets all functional and non-functional requirements, they start a manual deployment process, which means taking the application down for a few hours.
The first manual deployment fails, so they have to start over. After the deployment is successful, they monitor the release.

Now, let's say they discover performance issues with the release. They can either manually provision more resources to handle the increased load, perform a hotfix, or roll back the release entirely. Rolling back the release is a lengthy, manual process, and the SLA to provision new infrastructure is too long, so multiple engineers work on a hotfix over the weekend. Those engineers end up working a 12-day workweek. The release is tacked onto a history of failed releases, which erodes trust with management. More manual approval steps are added to catch bad deployments, which will slow down future releases.

Now, let's look at how deployments work for a hypothetical high-performing team working on a Ruby on Rails app:

A developer plans a release and coordinates with the approval of a peer. Releases are continuous, so developers are empowered to release their changes on-demand.
Since the team makes frequent use of feature flags, the mainline is always releasable. The developer is not blocked by any merged features that are not production-ready.
They spin up a staging environment and run automated tests. Environment creation and teardown is automated with Kubernetes and scripted GitHub Actions.
After all tests pass and they validate their changes, they deploy to production. Promoting the release to production is instantaneous and fully-automated.
They can automatically roll back the release in seconds if anything goes wrong. In the case of performance spikes, Kubernetes nodes automatically scale to meet the demand.

When it comes to release schedules, teams fall along a spectrum. While some apps benefit from moving at a slower pace for stability, faster is generally better for both not only the business, but also the psychological safety of engineers. In its 2020 Big Code Report, Sourcegraph found that 88% of software development teams feel anxiety during every release.

There is an irony behind the first hypothetical team working on a financial app. To enforce stability, more steps were added to the release process, which actually make it harder to deploy, and as a result, deployments happen less frequently. These large, backed-up deployments pose a greater risk for production incidents, and developers feel that pain. Things get scarier when they're less frequent.

Source: FrequencyReducesDifficulty by Martin Fowler

By making deployments mundane and doing them more often, teams can minimize the fear and difficulty of releasing to production. As Martin Fowler puts it: "By integrating every day, the pain of integration almost vanishes. It did hurt, so you did it more often, and now it no longer hurts."

Ways to minimize deployment pain

By aiming to make deployments faster and more frequent, teams can minimize the pain they feel when pushing their changes live.

Frequent deployments require less coordination between teams trying to get their changes into production, making releases safer and less complex. In turn, when deployments are safer and simpler, teams feel comfortable deploying more frequently. Unlocking this feedback loop is the key to achieving continuous deployment.

Measure deployments

Teams can benchmark their performance against industry standards and against themselves. The important thing is to constantly gather data and feed it back into the system to drive continuous learning.

Most teams now set up agents to monitor applications and infrastructure, using tools like DataDog, New Relic, and Sentry. These are table stakes for teams who need real-time data on any possible bugs or issues after a release.

Teams can augment their existing analytics instrumentation by measuring how changes move through their CI/CD pipelines. They can measure:

Deployment Frequency: how frequently changes are deployed to production
Age of Unmerged Changes: average time since a pull request has been open, but not yet deployed
Deployment Batch Size: average number of code changes per deployment
Deployment Success Rate: number of successful deployments vs. the total over time

By measuring the Age of Unmerged Changes, or how long changes are in a "Ready to Deploy" state, teams can stay on top of how much time has passed between deployments and better manage their release backlog.

Deployment Batch Size also helps teams keep track of how big the backlog is getting. Deployments should be small if they are frequent, and introducing fewer changes in each deployment helps decrease the risk of errors.

Developers working on automation and scripting can also track Deployment Success Rate and aim for a success rate above 99% for deployments to production.

Automate deployments

Fast releases require teams to remove as much manual work as possible when deploying. Engineers shouldn't need to fiddle with scripts or commands every time they want to release their changes. It slows them down and opens the door to human error. Nick Moore of Sourcegraph argues that "without automation, you're reliant on the heroics of individual engineers, which isn't scalable."

Releases should be predictable, safe, and repeatable — in other words, uneventful. Most teams are familiar with a baseline of automation. The rise of automated CI/CD tools — from Vercel to Jenkins to GitLab — has made packaging your team's changes and deploying them dead-simple.

As teams scale, they should look to take their abilities further. One option is to lean into a principle known as "Everything as Code," which requires as much of their deployment tooling to be codified as possible. GitLab enshrines this idea in their company handbook:

Deployment tooling, including pipelines, infrastructure, environments, and monitoring tools, are constantly evolving. If they can be stored as code and version-controlled, it will enable organizations to more effectively collaborate and avoid costly mistakes.

When deployments are described in code, they can be managed, replicated, and built upon by every developer on a team. It also sets the foundation for building out an internal developer platform — think self-service library of toolchains, workflows, and infrastructure — which allows teams to spin up and tear down environments on their own.

Reduce co-dependencies

When changes to a codebase require a lot of handoffs and coordination, it makes it harder to deploy even small updates. Deployments are also slowed when they impact many different parts of a codebase. Decoupling architectures and making ownership of services clear can help reduce these co-dependencies.

A loosely-coupled architecture, according to The DevOps Handbook, is one in which "services can update in production independently, without having to update other services." Microservices are one way to decouple architecture, as long as services are independent of each other. But microservices can sometimes introduce more complexity and slow things down, making it important to measure Deployment Frequency. Some teams choose to break off only a few services from their monolith to get the best of both worlds.

Some teams have reduced ambiguity by introducing a developer portal, like OpsLevel or Backstage. These tools create a catalog of services by pulling together the tools and documentation needed to use them.

Follow your code

When developers hand off their changes to deployment teams, they miss out on an important feedback loop. They can't see how their changes are working or if there were any hiccups when deploying them.

It also leads to badly aligned incentives. Without any communication between them, developers try to push code through as quickly as possible, while Ops teams try to keep the lights on. Development thinks there's a speed problem, but Ops thinks there's a quality problem.

One solution is for developers to follow their changes all the way through to production. Teams can set up notifications in Slack to alert authors when their pull request is being released to production, so they can validate and watch their changes go live. The status of merged pull requests -- and whether they are deployed or not -- can also be made visible to everyone. Developers should also have access to test suites in the deployment pipeline, monitors in production environments, and feature flags.

Deployments should be the opposite of a black box. When developers can see how their code flows through CI/CD pipelines, they can take those learnings back to the beginning when they start writing their next line of new code.

Make deployments progressive

Big releases can be stressful when they push out changes to many customers at once or make changes to vital systems, like a database or API.

By using progressive delivery techniques, such as feature flags, canary release, and rolling deployments, teams can lower the stakes of every deployment. These strategies reduce anxiety during releases by gradually introducing new changes into a production environment, giving teams time to make sure everything works as expected.

The DevOps Handbook describes progressive deployments as an important way to fight fear:

Instead of firefighting for days or weeks to make the new functionality work, we merely change a feature toggle or configuration setting. This small change makes the new feature visible to ever-larger segments of customers, automatically rolling back if something goes wrong. As a result, our releases are controlled, predictable, reversible, and low stress.

Using feature flags ensures that the main branch is always releasable. Teams can put work behind a feature flag until it's ready to release, which allows them to test their work in their continuous integration pipeline without blocking a deployment. During a release, they can turn on the new feature for progressively larger groups of users, gaining confidence at each step that their changes work properly.

Orchestrate an automatic release process

If releases feel chaotic or stressful, teams can try coordinating them with some lightweight automation. In Slack, they can notify authors when a PR is queued up for a release or if checks fail during a deployment. Most CI/CD tools offer Slack integrations — such as Jenkins CI, CircleCI, and Travis CI — to automatically add context.

Once changes have been deployed, monitoring gives developers confidence that a release can be undone if there is a catastrophic issue in production. If teams detect any problems, the ability to perform automatic rollbacks, fast forward fixes, or environment freezes also enables organizations to be more in control.

For example, the Slack engineering team schedules its deploys at regular intervals and puts a team member in charge to make sure everything runs smoothly:

Every day, we do about 12 scheduled deploys. During each deploy, an engineer is designated as the deploy commander in charge of rolling out the new build to production. This is a multistep process that ensures builds are rolled out slowly so that we can detect errors before they affect everyone. These builds can be rolled back if there is a spike in errors and easily hotfixed if we detect a problem after release.

Core to Slack's playbook is the ability to find problems early and take action quickly. If teams can see issues with a deployment, but can't rollback or hotfix it, they're stuck on a runaway train. Conversely, if they can quickly push out fixes, but can't spot an issue until it's affecting a lot of users, much of the damage has already been done.

Keep experimenting

Like with code reviews, there are many experiments teams can run to see what works best for their deployment process. With modern tools like GitHub Actions and CircleCI, teams have more control over how and when they deploy.

What tools does your team use for faster, safer deployments? What workflows have improved them the most?

What's the longest build time you've experienced?

Geoff Stevens — Mon, 02 May 2022 22:30:33 +0000

The most successful engineering teams typically keep their workflow durations between five to ten minutes on average, according to CircleCI's 2022 State of Software Delivery. The median is 3.7 minutes.

Looking at our team's slowest GitHub Actions using our GitHub App, our longest workflow is just under 13 minutes. This excludes local builds and workflows.

But it's not unusual to see build times measured in hours, depending on the stack you're using.

LinkedIn's engineering org previously wrote about the steps they took to decrease build times from 60 minutes to 15 minutes for their largest microservice, improving productivity and team happiness.

What's the longest build or workflow time you've ever encountered? What tools were you using / could you fix it?

DevSecOps and Shift Left Security: A Guide

Geoff Stevens — Mon, 10 Jan 2022 20:35:46 +0000

What is DevSecOps methodology?

DevSecOps—short for development, security, and operations—adds security-first thinking into every phase of the software development pipeline, helping engineering teams deliver secure software with speed and at scale.

Previously, development teams performed security testing after the development cycle, meaning they handed work over to separate QA and security teams for final inspection. As software development teams adopted DevOps practices, particularly continuous integration and deployment, security reviews created costly bottlenecks by backloading important work at the final stages of the delivery pipelines. Teams only uncovered issues after features had been built, meaning they were costlier and more difficult to debug and fix.

DevSecOps integrates security into every stage of the development pipeline, providing teams with tools and resources at each phase to create safe and secure code. As a result, DevSecOps helps teams address security issues earlier and faster without slowing their organization's software delivery.

By adopting principles of DevSecOps, teams can benefit from:

Faster and more efficient software delivery
More secure codebase and proactive security
Continuous feedback and faster security vulnerability patching
Highly automated, standardized, and predictable security practices

How does shift-left security fit into DevSecOps?

Before DevSecOps, engineering teams structured their development cycles to be highly sequential, which meant completing all testing and security reviews after the planning, implementation, and integration phases.

Once changes reach the end of the development cycle, they are often more complex to debug, forcing teams to disentangle several factors all at once, such as performance, integration, and more. As a result, uncovering significant issues late in the cycle requires large amounts of rework for development teams. After receiving a long list of complex defects from testers, developers need to design and apply multiple fixes all at once and across thousands of lines of code.

Security testing late in the development life cycle creates especially painful bottlenecks throughout the delivery pipeline:

Insufficient resource planning. By failing to include testers early in the planning phases, teams may not properly allocate resources later in the development cycle.
Less time and more debt. Cramming testing at the end of the cycle increases the likelihood of teams skipping testing altogether, increasing technical debt, and deferring problems to later versions.
Wasted development time. Engineers may continue to work on defective features or changes before receiving any feedback, leading to wasted energy and effort.
Complex debugging. Systems become more complex later in the development cycle, making testing more challenging and burdensome.

Shifting left means performing testing earlier in the development cycle. In other words, testing is moved to the left on the project timeline.

Importantly, the goal is not to shift security to the left as a discrete phase; instead, teams should integrate security into every phase of development—design, implementation, verification, and so on. Many of these improvements can be introduced by automating security tests, particularly as a part of the continuous integration and deployment pipeline.

According to W. Edwards Deming, an American engineer famous for his key principles on transforming business effectiveness, engineering teams should design more secure products from the moment they start building:

Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

Why shift left?

The benefits of earlier intervention include faster development speed and improved security throughout the organization's DevOps capabilities. Ultimately, the goal of shift-left security and DevSecOps should be to avoid critical bugs and security defects during the deployment phase, while preserving the fast flow of work.

Greater transparency

Implementing security measures throughout the value stream improves visibility into security coverage, including the number of defects discovered and any potential security blind spots.

The consistent monitoring of threats in the delivery pipeline also introduces a high degree of traceability and auditability, which helps teams iterate and improve their security controls after incidents.

More secure codebase

Shift-left security increases test coverage by encouraging more security testing during the development phase. Additionally, shift-left security enables distributed security, where more team members involved in the development process are responsible for building secure software.

Shift-left security also inspires better software design, instead of a culture of patching and hotfixes, by making teams more aware of security requirements. Teams can code with security in mind from the outset of a project, avoiding ad-hoc and clumsy fixes in the later stages of development.

Lower production costs

Shift-left security reduces the cost of development by resolving issues before introducing additional dependencies. According to IBM researchers, fixing defects is 15 times more expensive to fix during the testing phase than during the design phase. Worse, that number jumps to 100 times more expensive when defects are fixed during the maintenance phase.

Fixing security issues earlier requires less effort and rework than if teams wait until after implementation.

Organizational learning

Shift-left security introduces key security practices to development teams and equips them with tools that provide fast feedback on their work. These insights help spread knowledge about security best practices throughout the organization, creating a more security-conscious culture.

Improved response time

Better collaboration between development and security means issues can be discovered faster and fixed sooner. When coupled with continuous integration, shift-left security helps teams patch newly identified security vulnerabilities in faster release cycles, decreasing the time threat actors can take advantage of them.

Standardization and automation

DevSecOps encourages teams to adopt highly repeatable and predictable security workflows. They can apply security controls consistently across environments, including containers, databases, serverless functions, and more. Such standardization prevents security issues from accidentally slipping through security controls due to human error.

Shift-left security also introduces a high degree of automation into the software development life cycle, shortening feedback loops and eliminating handoffs. Teams can continuously decrease the workload of manual testers by iteratively and incrementally offloading routine testing to automated tooling.

Decreased time to market

Overall, shift-left security can increase delivery speed. Optimized security workflows and automation mean less wait time for developers and fewer bottlenecks when shipping new features.

How to shift left in DevSecOps

Adopting shift-left security is not a linear, binary outcome with a strict timeline; instead, it is a continuous process of security improvements over the long-term.

Define a strategy

Before changing any security workflows, engineering and security teams must first agree on standards and expectations for their shift-left initiatives. It's important they decide what shift-left security looks like at their organization, creating a roadmap of iterative, long-term improvements.

They can also perform a risk-based analysis to decide where to start implementing testing and tooling, balancing potential risk to the organization's security and resources required to implement new workflows. Incident history and can provide a list of high-priority and high-impact areas for improvement.

Understand the flow of work in your organization

Next, teams need to understand the flow of work through the software delivery pipeline. The goal is to provide context to security teams about the tools and environments used by developers. They can then create a unified test strategy outlining the tests, tools, and data required for each new security requirement.

They can also identify opportunities to improve existing workflows so they are more compatible with shift-left security. For example, teams can adopt trunk-based development to streamline automated security tests.

Implement security guardrails

When adding security guardrails, the goal is to make security a seamless part of daily work. Teams can introduce these changes into the development pipeline by:

De-emphasizing acceptance and system level testing, while refocusing on unit testing and integration testing.
Reducing toolchain complexity with pre-approved tools.
Introducing testing automation, including security workflows directly into continuous integration pipelines.
Hardening continuous integration systems with checklists to ensure teams follow best practices.

Continuously train and improve

Shift-left security requires continuous improvement to respond to the ever-changing needs of development and security teams. As part of the ongoing shift left, security teams can be more involved in the early phases of design, reviewing implementation details to advise on potential testing requirements, architecture considerations, and security considerations.

Development teams can also be kept up to date on the OWASP Top 10, testing best practices, and other security trends.

Shift left security best practices

Shift-left security needs to be implemented with careful consideration for its impact on the development process. Like all DevOps capabilities, it works best when combined with visibility, monitoring, and continuous improvement.

Optimize test environments

Security testing should also follow the test pyramid to provide the most valuable feedback to developers at the right time. It's important to implement smaller, faster tests earlier, such as static code analysis, unit tests, and smoke tests. By starting with these smaller tests, developers avoid the need to create full builds to reveal certain security issues.

Teams should run more comprehensive test suites—such as API, integration, and cross-browser testing—later in the development pipeline. These test suites should be designed to fail fast, stopping builds early if they uncover catastrophic issues.

Teams should also consider using short-lived testing environments. Long-running environments can quickly become obsolete or require significant upkeep, while temporary environments avoid maintenance costs and outdated data. For example, containers for smoking tests can be created and destroyed quickly according to predefined configurations.

Monitor pipeline performance

Shift-left security should be highly automated, with tools and tests added directly to the build process. Teams will need to maintain security tests and plan for their upkeep each development cycle.

As a result, an important part of shift-left security is consistently monitoring pipeline performance. Teams should highlight slow pipelines and jobs, as well as their success rates. The goal is to fine tune their configuration to eliminate false positives, increase speed, or flag outdated tests. They can also identify recurring security weaknesses that require additional tooling earlier in the development cycle.

Security teams involved in design

Requesting feedback from security teams during the design phase helps teams flag potential issues and highlight areas of focus during implementation. Security teams can help teams prevent complex security issues before developers have a chance to build them into the codebase.

Increase pre-approved tools

Standardization and pre-approval for dependencies, packages, toolchains, libraries encourages their use and avoids rework. Overall, it decreases the surface area for security issues by eliminating vulnerable toolchains before they're added into the codebase.

Develop a culture of visibility

Above all, teams should improve visibility into their organization's shift-left security practices. They should make it easy for all team members to understand their organization's security posture, including its strengths and areas for improvements.

Measuring shift left security

To measure the effectiveness of shift-left security, teams should improve visibility into:

Security review time. The goal should be to decrease the time required for security reviews so they do not slow the development process.
Percentage of security requirements integrated into automated testing. Teams should increase the coverage of security requirements performed as part of test automation, which provide faster feedback to developers.
Percentage of development tools in use that have been pre-approved. Teams should increase their approval coverage until most or all tools used by development teams have been pre-approved by security teams.

Shift left security tools

Organizations can implement several different types of tools to help developers shift security to the left. The four main security testing methods include:

Static Application System Testing (SAST) involves scanning source code for vulnerabilities. It's typically fast and cheap because it does not require code to compile or run.
Dynamic Application Security Testing (DAST) involves black-boxing testing, exposing an application to common attacks.
Interactive Application Security Testing (IAST), a hybrid of SAST and DAST, analyzes running applications and watches behaviors initiated by both manual and automated tests.
Runtime Application Self Protection (RASP) integrates with an application to prevent attacks during runtime, blocking or preventing execution based on traffic and user behavior. Two popular tools include OpenRASP and Sqreen.

Teams can also implement security practices to further secure the software supply chain:

Secrets detection: Teams can use tools to scan code for secrets, like API keys, encryption keys, and credentials, to prevent accidental exposure.
Dependency scanning: Tools like WhiteSource and FOSSA scan dependencies and open source projects for security issues or identify outdated packages.

Start small, start today

As teams work in increasingly complex development environments—relying on more dependencies, tools, and open source technology—security is more important than ever. With widespread security scares, such as Log4j and SolarWinds, creating a resilient and security-focused organization can be a daunting task. In 2021 alone, the US-CERT Vulnerability database recorded more than 18,000 vulnerabilities, breaking previous records.

In spite of these challenges, DevSecOps and shift-left security testing offers teams a way to confidently and consistently write more secure code and build safer software. With small, continuous improvements, any engineering team can inspire a culture that prioritizes better security.

Is hyperautomation the future of development?

Geoff Stevens — Wed, 05 Jan 2022 21:18:36 +0000

I recently read about Gartner's 12 technology trends for 2022. One of the predictions that stood out to me was the idea of hyperautomation:

The hyperautomation playbook yields benefits for enterprise leaders in the year ahead. This strategy seeks to rapidly identify, vet and automate as many processes as possible.

In the world of software development, there's a lot of discussion about automation. Automated workflows impact so many different parts of the software development life cycle — CI/CD pipelines, testing, code suggestions, code scaffolding, and even writing documentation.

What do you think? Will hyperautomation will be a key trend in software development in 2022? What things can or can't be automated?

Psychological Safety at Work: Does Trust Drive Innovation?

Geoff Stevens — Thu, 16 Dec 2021 22:21:06 +0000

Psychological safety refers to the cultural and social dynamics of a team that enable members to feel safe taking risks and being vulnerable around each other. On teams with a high degree of psychological safety, employees work freely without unfair punishment, ridicule, or embarrassment. They value curiosity over blame and learning over shame.

Recent research conducted over the last few years shows that psychological safety serves as the engine of high-performing teams. It is a key driver of organizational learning, innovation, creativity, resiliency, and, ultimately, effectiveness.

Without psychological safety, engineering teams resort to fear, shame, and retribution—an environment that leads team members to retreat from conflict, communicate less effectively, and engage less with team efforts to improve the status quo. When engineers do not feel comfortable expressing their views, they face a heightened risk of burnout and their wellbeing suffers. In the long term, poor psychological safety and burnout lead to high turnover, dissatisfaction, and unhealthy employees.

In today's fast-paced world of software development, engineering organizations that fail to support their most important knowledge workers will struggle in the marketplace against their competitors. They will lose both their customers and best talent to the highest performing, most innovative companies.

By embracing the principles behind psychological safety, teams and organizations can reach their full potential—experimenting, learning, and building faster and more efficiently.

What is psychological safety?

Many of the modern ideas behind psychological safety emerged from parallel concepts about physical worker safety in the world of manufacturing.

Between 1950 and 1970, leaders at Toyota introduced the Toyota Production System, a socio-technical system emphasizing both continuous improvement and mutual respect as important contributors to team performance. The company also created the Andon Cord, a mechanism allowing any worker to immediately stop production if they noticed quality or processing problems on the factory floor.

During the 1990s, Alcoa, an aluminum industrial corporation, quintupled revenue under CEO Paul O'Neill by emphasizing worker safety. At the start of his reign, O'Neill famously proclaimed his intention to "make Alcoa the safest company in America." By galvanizing deeper inspection of their manufacturing processes, Alcoa created a long-lasting culture of improvement and transformation.

Today manufacturing employs less than 10% of the U.S. workforce, but many of the same principles of worker safety have been carried over to the technology industry. With the growth of knowledge work in the last few decades, researchers have recently begun to focus on psychological safety, rather than physical safety, as the key driver of team effectiveness.

In 2012, Google embarked on Project Aristotle, a research project to uncover the secrets of high performing teams. After analyzing 180 teams over two years at Google, researchers discovered that psychological safety—not team members' tenure, seniority, or extraversion—is the team trait most highly associated with strong performance.

According to organizational behavioral scientist Amy Edmondson, psychological safety is "a shared belief held by members of a team that the team is safe for interpersonal risk taking."

Google, in its research on psychological safety, provides a more expansive definition:

Psychological safety refers to an individual's perception of the consequences of taking an interpersonal risk or a belief that a team is safe for risk taking in the face of being seen as ignorant, incompetent, negative, or disruptive. In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.

The goal of psychological safety is to overcome natural tendencies to exclude, punish, or marginalize other team members. When individuals face a perceived threat at work, they often attempt to reestablish fairness within their group—an instinctive reflex rooted in primitive fight or flight responses. For example, an individual may unfairly reject a team member's idea simply because that team member previously disagreed with one of their ideas in another meeting.

Such unsafe conditions create a domino effect, passing frustration and stress from one team to another. If engineers feel they have been unfairly blamed for a recent outage, they're more likely to reassert fairness by shaming the team they hold responsible, making fewer changes to the codebase to avoid conflict, and deflecting criticism to others in the future.

On the contrary, psychological safety seeks to prioritize curiosity and learning over blame and shame. It is known as an "enabling mechanism" because it fosters positive group dynamics and team learning.

Psychological safety, however, does not require team members to always agree with or coddle their teammates. Instead, it requires them to embrace and manage conflicts or disagreements in a respectful, inclusive, and constructive manner. By creating a culture of psychological safety, teams ensure everyone leaves each conversation feeling they achieved something meaningful for their team as a whole.

Stages of psychological safety

Psychological safety is not a binary outcome; instead, teams fall somewhere on a spectrum of safety. Each step meets different individual needs on the path to creating a truly psychologically safe workplace.

According to Dr. Timothy Clark, founder and CEO of a global leadership consulting and training organization known as LeaderFactor, the four requirements are inclusion, learner, contributor, and challenger safety.

Stage 1: Inclusion safety. Team members feel included on a team and accepted for their true self. They have a shared identity with their team members. Inclusion safety satisfies the need to connect and belong.

Stage 2: Learner safety. Team members feel safe to ask questions, experiment, and make mistakes. They give and receive fair feedback without fear of embarrassment. Learner safety satisfies the need to learn and grow.

Stage 3: Contributor safety. Team members feel safe to contribute. They feel empowered to use their skills and talents to create value for their team. Contributor safety satisfies the need to make a difference and have an impact.

Stage 4: Challenger safety. Team members feel safe to challenge the status quo. They embrace candor and honesty when discussing things that need to change without fear of retribution. Challenger safety satisfies the need to make things better.

How does psychological safety impact performance and innovation?

Psychological safety is considered the engine of team performance. Teams with better psychological safety benefit from:

Enhanced creativity: Teams encourage solution-finding and divergent thinking, which are both critical for creative work.
Increased open-mindedness: Team members embrace and explore new ideas. They are more willing to acknowledge potential weaknesses, take risks, and experiment.
Increased resiliency: Teams bounce back faster and learn from failure when they feel safe to raise issues with other individuals and find solutions.
Higher engagement: Team members are more engaged with their work, driving organizational effectiveness.
Faster learning: Teams enjoy experimenting with new ideas, allowing teams to test and debate more ideas. They are more likely to share those learnings across the organization as a catalyst for other teams to experiment.
Improved knowledge sharing: Learnings from failures are shared throughout an organization, transforming individual and team learning into organizational learning.

Collectively, the positive outcomes of psychological safety improve how well companies innovate by increasing the rate of change and decreasing time to market. In other words, psychological safety helps teams surface more ideas faster and implement them more rapidly.

Psychological safety, however, is not a silver bullet for organizational performance. It must be combined with other 'fuels' of performance—powerful developer tools, a world-class developer experience, effective communication, long-term investments in team growth, and so on.

In particular, psychological safety works best when paired with team accountability. On teams with high psychological safety and high accountability, individuals understand what is expected of their team and have the safety to meet those expectations.

Adapted from How Psychological Safety Affects Team Performance

Teams without psychological safety consistently push team members into fight or flight responses, creating an organization driven by fear rather than collaborative improvement. As a result, teams with low psychological safety suffer from:

Lack of diversity of thought: When team members fear sharing new ideas, teams tend to defer to the most popular or least divisive ideas. They attract like-minded individuals who prefer to uphold the status quo.
Unequipped to prevent failure: Teams do not have the communication habits needed to raise potential issues before they cause damage. They do not share learnings from past mistakes and are more likely to repeat those mistakes.
Knowledge silos: Individual or team learning is never translated into organizational learning when people cannot freely share their findings.
Indifference and disengagement: Individuals take a defensive stance by retreating from disagreements and protecting themselves against future conflict.

Despite the importance of psychological safety to innovation, most employees work at companies without psychologically safe cultures. Only 47% of employees across the world describe their workplaces as psychologically safe and healthy, according to a global survey conducted by Ipsos.

How to measure psychological safety

Psychological safety is a measurable concept. Similar to other DevOps metrics, such as lead time and change failure rate, it is an important metric that teams should track and improve. To measure psychological safety, teams can use:

Surveys
One-on-one feedback
DevOps data

Edmonson supported her research with a survey-based approach to measuring psychological safety. Team members score the following statements on a Likert scale of 1 (strongly disagree) to 7 (strongly agree):

When someone makes a mistake in this team, it is often held against him or her.
In this team, it is easy to discuss difficult issues and problems.
In this team, people are sometimes rejected for being different.
It is completely safe to take a risk on this team.
It is difficult to ask other members of this team for help.
Members of this team value and respect each others' contributions.

To get your final score, subtract your score on question 1 from 8 and subtract your score on question 4 from 8, then add those numbers to your scores from questions 2, 3, and 5.

A final score of 15 or less means your team is psychologically unsafe, while a score above 30 means your team enjoys a high degree of psychological safety. A score between 15 and 30 indicates room for improvement.

Managers and engineers can also gauge psychological safety by conducting one on one conversations. During these discussions, leaders should analyze not just the what of their communication, but also the how:

How is my delivery?
How is my feedback?
How well do I ask questions?
How well do I include everyone in the conversation?

Teams can also use other DevOps metrics to identify potential issues with psychological safety. Poor psychological safety can create bottlenecks and slowdowns in the development pipeline:

Delivery throughput: Engineers are afraid to make changes to the codebase, so they ship fewer features.
Mean time to recovery: Teams are afraid of being blamed for downtime, so they communicate less during outages.
Change failure rate: Teams do not feel comfortable sharing their learnings from previous failures, so they are more likely to repeat mistakes.
Review time: Teams do not feel comfortable sharing feedback with others, so they avoid code reviews and pair programming.

Many DevOps metrics can be indicators of communication challenges within an organization. Metrics can be impacted by many other factors—such as automation, testing strategies, tooling, and CI/CD maturity—but it's important to remember that one of the factors impacting team performance could be non-technical and cultural.

Tips for driving psychological safety in the workplace

Fostering psychological safety requires teams to overcome imbalances in workplace incentives: members must think more about the positive impact of sharing an idea than the potential negative consequences.

According to Edmondson, there are three key things leaders can do to fix these imbalances and improve psychological safety:

Frame work as a learning problem, not an execution problem
Acknowledge your own fallibility
Model curiosity and ask lots of questions

To achieve these goals, teams should:

Establish clear rules of engagement
Embrace conflict as a source of innovation
Reframe negativity as a learning experience
Create space for open communication
Measure consistently for long-term improvement
Invest in DevOps
Consider the context

Establish rules of engagement

Teams should first focus on creating ground rules and expectations for better and more productive group discussions. A code of conduct can include ideas such as:

Challenge ideas, not people
Avoid blame or speculation
Take responsibility for the quality of the discussion

Many of these guidelines are designed to help teams be more empathetic in their communication by listening more, praising others, and expressing gratitude when someone shares. By codifying these rules, leaders communicate the importance of psychological safety and empathy as key objectives and expectations for their team.

Embrace conflict as a source of innovation

A core tenet of psychological safety is that conflict and tension should be viewed as a source of new and better ideas. In a psychologically safe workplace, team members should feel comfortable discussing ideas objectively, disagreeing with others, and building on existing ideas.

To make conflict productive, leaders should focus on using generative language—structuring questions and discussions to create new ideas rather than destroy them. They should ask open-ended questions, embrace half-finished thoughts, and welcome naive questions as a launchpad for further discussion.

To ease the pressure on other participants, leaders should introduce opposing viewpoints and facilitate everyone speaking up. They can even deliberately suggest controversial ideas or ask 'dumb' questions to jumpstart conversations.

Most importantly, individuals should seek clarity before criticism. Asking deeper questions often unearths better ideas.

Reframe negativity as a learning experience

Teams should reinforce a blameless culture that prioritizes learning over shame. Leaders need to establish norms for failure by setting an example for their team. They should admit mistakes, share their failures, and ask for help when faced with a difficult task.

Teams should also seek unity in both their accomplishments and mistakes. Teams celebrate product launches and feature releases, but often neglect to rally as a team around their failures. As with sports teams, people prefer to say "we" when describing victories, but choose to say "they" when talking about defeats. When teams fail, they should celebrate the lessons they have learned as a group and the positive impact it will have on their team in the future.

Create space for open communication

Consistent communication is key for enabling continuous feedback and improvement between team members. Without channels for open communication, individuals have no clear or sanctioned way to express their opinions and ideas.

Teams should be deliberate in creating space to improve communication, surface issues faster, and spark discussions between team members. These can be regular one-on-one conversations, happy hours, randomized meetings, and watercooler Slack channels.

Measure consistently for long-term improvements

To improve team performance, psychological safety must be an explicit and transparent team goal. All team members should understand how well their team is doing and how they can improve; the goal is to remove ambiguity, create a shared understanding of reality, and help surface issues faster.

When psychological safety is a clear goal, teams emphasize the importance of strong communication as a part of organizational expectations. As a result, psychological safety itself becomes a focus of team learning. In the event of a team failure, self-reflection activities such as retrospectives and post-mortems should analyze both technical challenges and cultural shortcomings around psychological safety.

Invest in DevOps

To improve psychological safety, teams can adopt DevOps practices that reduce the time to uncover failures, reduce the cost of failures, and amplify the lessons learned from failures.

It's important to remember that high-performing teams fail more often than low-performing teams. While the best teams experience lower failure rates, they deliver more software in less time. The result is a greater absolute number of failures; however, teams with high psychological safety recover, learn, and grow from those failures faster, too.

The key DevOps tactics to improve psychological safety include creating guardrails, improving resiliency, and reducing the stigma of failure.

Guardrails help teams prevent changes from breaking their systems before they reach production environments. They include practices such as shift-left testing and security, automated CI/CD pipelines, and feature flags or canary releases. They provide engineers with the safety needed to experiment and try new things without fear of serious outages or downtime. Guardrails also reduce anxiety and stress during the development life cycle so teams can code free from fear or toil.

When considering which guardrails to implement and how to do so, DevOps teams should look to enable innovation by providing "buoys not boundaries," according to Ralph Loura in The DevOps Handbook:

Instead of drawing hard boundaries that everyone has to stay within, we put buoys that indicate deep areas of the channel where you're safe and supported. You can go past the buoys as long as you follow the organizational principles. After all, how are we ever going to see the next innovation that helps us win if we're not exploring and testing at the edges? As leaders, we need to navigate the channel, mark the channel, and allow people to explore past it.

In addition to guardrails, teams can improve their resilience to help them fix issues quickly when they do occur. Erik Hollnagel defines resiliency engineering as:

The intrinsic ability of a system to adjust its functioning prior to, during, or following changes and disturbances, so that it can sustain required operations under both expected and unexpected conditions.

Teams can invest in self-healing systems and decoupled architecture to mitigate and contain damage in the event of a failure. With safer failures, teams can reduce stressful deployments and constant firefighting.

Lastly, teams can reduce the stigma of failure. Even high-performing teams are not able to catch every mistake. In fact, if they did, they wouldn't be high-performing teams because they would lack valuable feedback loops and learning opportunities.

To reduce the stigma of failure, teams should view post-mortems and retrospectives as a learning opportunity. Organizations are only able to strengthen their engineering performance when individuals can discuss their challenges openly and without fear of embarrassment.

Consider the context

Psychological safety does not exist in a vacuum. According to Google's research, after psychological safety, teams needed four additional team dynamics to be successful:

Dependability: Team completes quality work on time.
Structure and clarity: Teams have clear expectations for their work.
Meaning: Teams have a sense of purpose.
Impact: Individuals feel they are making a difference for their team.

Leaders should work to create a culture with each of these dimensions to support their team's psychological safety.

How to drive psychological safety in a virtual workplace

Psychological safety requires the same communication principles regardless of whether teams are working at the office or working remotely; however, how teams tactically implement psychological safety can look very different depending on their workplace environment.

Remote calls, for example, are especially challenging for individuals because they tend to restrict conversation to just a few people. Leaders can avoid this problem by relying on breakout rooms, hand-raising, and polls.

Asynchronous can also be challenging. When working remotely, team members can often feel overlooked in the deluges of Slack messages and Zoom calls. Leaders must make a conscious effort to include others in their discussions and be transparent in their decision making by documenting and sharing the outcomes of important team conversations.

With the cover of asynchronous communication, individuals may prefer to disengage from their team when facing failure. Instead, leaders should create cultural norms around sharing failures and asking for help. For example, they can share post-mortems in public Slack channels or improve documentation after an outage.

Team-building exercises, coffee chats, and happy hours can also make remote teams more resilient in the long-term. Group events help team members get to know each other as people; when failure does happen, they're able to talk more freely and openly.

What to do in a psychologically unsafe workplace as an employee

In the worst case scenario, individuals should consider leaving an organization that fails to provide psychological safety. In the long-term, the lack of psychological safety leads to burnout, unhappiness, and dissatisfaction.

Most teams, however, start with a solid foundation for psychological safety they can build upon. They already focus on output metrics and objectives—such as features released and revenue targets. Team leaders should make the case for also measuring inputs—like psychological safety—to the development pipeline. Armed with a better understanding of the entire development life cycle, teams can better identify their most serious bottlenecks and constraints.

Most importantly, leaders and individuals can lead by example. They should express vulnerability, listen intently to their coworkers, and ask deeper questions.

Context Switching is Killing Your Productivity

Geoff Stevens — Wed, 17 Nov 2021 19:58:28 +0000

What is context switching?

Context switching is a form of multitasking requiring developers to switch between unrelated tasks.

Frequent context switching reduces productivity, decreases energy and creativity, and negatively impacts quality of work. Minimizing context switching can help developers better focus on their highest priority tasks, avoid mental fatigue, and reduce the risk of burnout.

The concept of context switching originated in computer science. When computers switch between tasks, they need to carry out several intermediary tasks to stop the previous task and begin the new task. Each switch costs time and energy:

[Context switching] refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of an interrupt, such as when a task needs to access disk storage, freeing up CPU time for other tasks...The process of context switching can have a negative impact on system performance.

Similar to computers, the human brain needs time to adjust focus from one task to another. It must unload and reload context—costing developers energy and mental resources—when switching between tasks.

Unlike computers, humans experience context switching hangovers—the lasting effect of the mind being unable to completely forget a previous train of thought in favor of a new one. These hangovers decrease cognitive performance long after switching tasks.

Engineering teams who create a culture that reduces overall context switching can benefit from happier and more productive developers. They can also improve development speed and product quality by allowing teams to focus on their most important tasks free from disruptions, delays, and firefighting.

What causes developers to context switch?

Context switches are often caused by distractions and disruptions—brief interruptions that divert attention and break flow.

Disruptions, like Slack messages and emails, shift developers' attention away from their current tasks. Shoulder taps, meetings, and noisy open offices interfere with valuable focus time.

Importantly, not all context switches are a result of distractions. Context switching often happens between important tasks, as developers intentionally jump between them. Developers might stop coding due to an upcoming project planning meeting or they might pause a code review to help fix an outage with their team. They might even jump back and forth between multiple tickets during the workday because of impending deadlines.

Engineering teams should watch for frequent and abrupt context switches, which will have an outsized impact on their daily work. A few key causes of context switching:

Too much work in progress. A lack of clear priorities and an oversized backlog of tasks can force developers to multitask, rather than finishing the most important task and then moving on to the next one.
Highly fragmented schedules. Too many meetings and obligations fragment calendars and reduce the amount of time that developers have to focus on their most important tasks.
Information overload. Many of the tools that developers use on a daily basis are designed to engage and catch our attention—such as Slack bots, monitoring, alerts, and more. When improperly configured or managed, these tools can inundate teams with information that distracts them from their immediate tasks.
Poor workplace incentives. Developers often feel pressure to be online and responsive in Slack. When conversations happen quickly and without warning, many people will frequently check Slack to avoid missing out on important discussions. Especially in remote-first and work-from-home workplaces, there's a widespread fear of missing out that drives team members to constantly check and respond to notifications.

DevOps practices also play an important role in how often engineering teams need to context switch. Suboptimal processes and a lack of automated or standardized workflows can increase the likelihood of context switching. Two indicators that teams should focus on improving their DevOps performance to reduce context switching:

Frequent firefighting. Fragile systems that require developers to constantly put out fires and respond to emergencies are more susceptible to frequent context switching. Such systems often lack sufficient telemetry to quickly debug and restore service. They may also lack shift-left testing or CI/CD automation to prevent breaking code changes from finding their way into production environments.
Disjointed or slow workflows. Unwieldy and manual workflows often lead to abrupt context switches, especially if they require developers to create multiple tickets or lack automation, like testing and environment provisioning. Change approval boards and slow code reviews also increase wait time, opening up developers to distractions and context switches.

What is the cost of context switching in development?

Context switching can lower productivity, increase fatigue, and, ultimately, lead to developer burnout. Switching tasks requires energy and each switch depletes mental focus needed for high cognitive performance. Over an entire workday, too many context switches can leave developers feeling exhausted and drained.

The impact of context switching lingers even after switching tasks. Cognitive function declines when the mind remains fixated on previous tasks, a phenomenon known as attention residue. According to Sophie Leroy, an Associate Professor of Management at the University of Washington Bothell School of Business who specializes in the study of attention:

Attention residue is when thoughts about a task persist and intrude while performing another task

Attention residue consumes cognitive processing power, making it more difficult to achieve a new task even after switching away from a previous one.

At the team level, context switching is a source of engineering friction within the development pipeline. Left unchecked, rampant context switching across an entire team can increase the time it takes to release new features or recover from failure.

Context switching also incentivizes teams to tackle short and easy tasks (i.e. low hanging fruit), instead of the most important ones. In disruptive environments, engineers lack confidence that they'll have the time, energy, or focus to complete an important task. With less time to focus, they prioritize fast wins over meaningful work.

Tips for avoiding context switching

Context switching is inevitable, but teams can take actionable steps to minimize its impact. Here are some tips to reduce context switching.

Schedule focus blocks and thematic days

Mastering your calendar is key to avoiding context switches. By better planning the tasks you hope to complete and when you want to work on them, you can reduce the likelihood of context switching and optimize your mental focus.

One trick to prevent context switching is to create time blocks on your calendar for focus time. Reserve time slots for specific tasks that you want to complete without distractions or disruptions.

Many developers also use the Pomodoro technique to stay focused during their focus blocks. The Pomodoro technique recommends you break your workday into 25-minute chunks separated by five-minute breaks.

You can also bundle together related tasks and projects. Many people use thematic days—e.g. Tuesday is reserved for interviews—to minimize the number of context switches each day. It's cognitively easier to shift from one coding task to another than it is to jump from a coding task to an email backlog. By grouping similar tasks, you maximize cognitive overlap between your various responsibilities each day, reducing the magnitude of your context switches.

Force rank priorities

Frequent context switching is often a sign that you need to clarify your tasks and prioritize them. After prioritization, you can focus on the most pressing tasks without wasting mental energy worrying about secondary responsibilities.

One helpful prioritization method is the Eisenhower Matrix, which forces you to rank tasks by both urgency and importance. Urgent and important tasks get done first, while other tasks are scheduled, delegated, or deleted based on where they are located in the matrix. Team or company Objective Key Results (OKRs) can also help you prioritize.

Build strong atomic habits

An atomic habit is a regular practice that is simple and easy to do; when done repeatedly, atomic habits help you unlock the power of compound growth through consistent, incremental improvement.

According to James Clear, author of Atomic Habits:

You do not rise to the level of your goals. You fall to the level of your systems.

Atomic habits can help you create a more effective system of daily work, one that makes it easier to regain control of your work hours and get more done in less time. Four habits development teams can adopt to reduce context switching:

When possible, finish a task before starting a new one to prevent your mind from unintentionally multitasking.
Be mindful of when you're switching tasks so you can better understand your personal habits—and find areas for improvement.
Declutter digital apps by removing them from main screens and reducing notifications.
Take breaks between tasks and take time to recharge so you are better able to focus when you are in flow. Add buffers and micro-breaks to your schedule to make context switching smoother.

Protect and defend flow

Flow is the wellspring of impactful work. It provides you with the focus, concentration, and immersion you need to sustain your productivity.

To preserve flow, it's important to proactively eliminate distractions. Use Do Not Disturb mode, silence notifications, set Slack to away, and hide your phone out of sight. Even small disruptions, like email notifications, can unintentionally lead to context switching. It's far easier to preserve your flow state than it is to regain it.

Even if you're briefly blocked by another task, try to avoid switching to a completely new task. It can be tempting to fill idle time with small todos or quick social media breaks, but doing so can negatively affect your productivity in the long-term by increasing attention residue.

Manage the flow of information

Teams should control the flow of information and communicate thoughtfully to avoid frequent disruptions and interruptions.

For remote teams, asynchronous communication across an entire organization can be a boon for deep work and focus. Creating a culture of thoughtful collaboration provides workers with ample time to respond to messages and feel included in online discussions. By eliminating the fear of missing important conversations, teams can encourage their members to confidently protect their focus times.

Even on teams with strong asynchronous communication, notifications and messages from automated systems, like application performance monitoring, can interfere with valuable focus time. Teams should deliberate in deciding who receives alerts at certain times and through what channels they will be notified. Teams should strive to avoid duplicate messages, false alarms, and notifying too many engineers.

Reduce firefighting

Emergencies and downtime pull developers away from their work and break flow. To reduce firefighting, teams need to provide guardrails to identify issues earlier in the value stream and provide tools to quickly find and fix issues that make their way into production environments.

Automated testing reduces the number of catastrophic changes that get merged into production. Furthermore, testing in production-like environments avoids surprises when changes are finally pushed.

If issues arise in production environments causing downtime or loss of service to customers, telemetry and version control provide fast ways to shorten time spent firefighting. Ample telemetry in production helps teams quickly identify and root cause issues, while version control enables fast rollbacks. Feature flag tools, like Optimizely, also make it easier for teams to turn off problematic features without needing to do complex rollbacks or hasty forward fixes.

Improve tooling and automation

Context switching happens more frequently when teams face long wait times or delays. To minimize context switching, teams should enable fast feedback through automated and self-service workflows when possible.

Continuous integration and continuous deployment prevent code from becoming stale on branches or inducing time-consuming merge conflicts, all while providing fast feedback to developers. Automated testing and automated test data management helps teams fix issues in a matter of hours, rather than days or weeks.

Moreover, self-service tooling prevents both Dev and Ops teams from context switching by eliminating handoffs: developers don't need to file requests or message team members to get what they need, and operations teams don't need to find time in their schedule to provision it.

Investing in the developer experience

Teams should aim to improve the developer experience at their organization by helping engineers get their work done—efficiently and without frustration.

According to The DevOps Handbook, "the improvement of daily work is more important than daily work itself." Dedicating time, resources, and manpower to reduce context switching and enable the fast flow of work sets a strong foundation for organizational success.

Achieving Great Work-Life Balance

Geoff Stevens — Wed, 10 Nov 2021 17:53:14 +0000

What is work-life balance?

Work-life balance means finding a healthy balance between your working and personal life. It means creating clear boundaries between work hours and non-work hours that allow you to achieve both your professional and personal goals.

Many companies abide by the traditional 9am to 5pm work hours as a way to uphold work-life balance for their employees. With the shift to remote work, freelancing, and the gig economy, teams are increasingly responsible for ensuring they maintain a healthy work-life balance in less traditional workplaces.

The stakes are high. Improving work-life balance can boost happiness and productivity, while preventing burnout. Ignoring work-life balance can create innovation zombies—companies that overwork their employees to increase output, but ultimately sabotage their organization's ability to compete in the marketplace.

What are the consequences of poor work-life balance?

Consequences of poor work-life balance manifest at both the individual and team levels.

Individuals can experience decreased productivity, lower satisfaction at work, and growing frustration with their current role and responsibilities. Without sufficient time outside of work to explore their own interests, individuals are also more vulnerable to negative changes to their self-image when it is tied too closely to their performance at work.

Over the long-term, poor work-life balance can lead to burnout and chronic stress.

Burnout is a severe form of mental and physical exhaustion. One common cause of burnout is overworking for extended periods of time without opportunities to rest, recharge, or pursue interests outside of work. Symptoms of burnout can be mental—negativism, cynicism, and detachment—as well as physical—headaches, fatigue, and sleeplessness.

Left unchecked, burnout can negatively impact a team's ability to achieve their goals. Teams can experience drops in long-term productivity, growing dissatisfaction, and, ultimately, higher turnover.

Can you use data sources and metrics to measure work-life balance?

Engineers can measure time spent working during and outside their working hours. They can also measure code day length---essentially the time between their first and last line of code each day. Together, code time and code day length can provide insight into how long you are 'online' and at what hours you are connected to work.

It's important to remember that different people work according to different schedules based on personal preferences. Unusual coding hours, such as night coding, may not necessarily indicate a poor work-life balance, especially now that more people are working remotely.

For engineers with flexible schedules, they should be watching for aberrations from their long-term trends. Spikes in weekend coding or code day length can indicate changes to your work schedule that may be unsustainable.

How to promote a good work-life balance for development teams

Promoting a good work-life balance requires a strong culture of planning, resilience, and development flow.

First, teams should work to avoid crunch time—cramming changes and fixes at the last minute to meet deadlines. Crunch time leads to poor work-life balance by requiring developers to work long, arduous hours in a high-stress environment. Reducing crunch time with more consistent and predictable development cycles can greatly reduce big fluctuations in work hours.

Predictable development cycles require accurate estimations of the time and effort needed to complete sprints and projects. Most importantly, they require the intentional carving out of time for testing, refactoring, and paying down technical debt.

Second, teams should invest resources into creating self-healing systems and processes. Organizational resilience stems from regularly improving your team's ability to respond to and resolve production failures. Teams can also reduce the chance or severity of failures by adding guardrails, such as shift-left testing, automated CI/CD pipelines, and feature flags. Over the long-term, greater resiliency means less time spent in firefighting mode with fewer emergency calls made to teams to restore service outside work hours.

Netflix infamously built and deployed Chaos Monkey, a tool that randomly terminates virtual machine instances in production. By exposing engineers to such random failures, Netflix created a culture of resilience that helped them avoid production downtime and team burnout.

Third, teams should enable the fast flow of work and fearlessly cut bureaucracy. The goal is to improve daily work so development teams are able to complete their tasks without needing to take time away from their personal lives.

Identify issues by making work visible. Understand bottlenecks in your organization's flow of work to see where to invest in DevOps and better tooling.
Provide developers with time to focus during work and complete tasks during work hours. Reaching flow state and staying in flow is key to getting work done. Try to eliminate unnecessary meetings and disruptions.
Decrease time spent waiting by removing or shrinking change approval boards and investing in self-service tooling, like automated environments and test data. Wait time works against team velocity and delays productive work, leaving developers feeling they need to "catch up" outside work hours.

Top tips for striking a work-life balance as a software engineer

Software engineers can improve work-life balance by setting aside time for personal interests and disconnecting completely when stepping away from work.

Schedule time for hobbies and activities outside of work. It's easier to step away from work when you have planned events that are just as visible as meetings on your calendar.
Plan vacations, both long and short. You need both long weekends and week-long getaways to fully recharge.
When offline, stay offline. Although it's tempting to check emails and notifications while taking time off, staying offline helps create clearer boundaries between life and work.

Why finding a work-life balance could make you a better developer

By prioritizing work-life balance, engineering teams benefit from happier and more productive team members. They are more likely to report being satisfied with their role and less likely to leave their organization.

Strong work-life balance also enables teams to be more agile and responsive to changes in workload. In exceptional situations and for brief periods of time, agile teams are able to temporarily ramp up their team's effort to meet deadlines, without burning out their team in the long-run. Emergencies happen, and teams with poor work-life balance won't have the resources or bandwidth to respond effectively.

At the individual level, a strong work-life balance boosts energy, productivity, and creativity. By maintaining a strong work-life balance, developers can avoid one of the main risk factors for burnout. They are able to optimize for their long-term goals—career and personal development—rather than sprinting to achieve immediate, but potentially draining, short-term goals.

Developers can also build valuable personal skills outside of work, which often translate into well-rounded employees who bring fresh ideas and new perspectives into the organization. A richer and more meaningful life outside of work creates a more diverse and engaging workplace for everyone.

Developer Burnout — Signs, Impact, and Prevention

Geoff Stevens — Tue, 02 Nov 2021 16:58:14 +0000

What is burnout?

Burnout is an increasingly widespread and destructive mental health challenge for knowledge workers across professions and industries. Left unchecked, it is a silent killer of productivity, happiness, and team success.

Unlike other types of stress, burnout is typically chronic and workplace-related. It is a result of unresolved and persistent stress that leaves workers feeling drained and unable to reach their full potential. According to the World Health Organization:

Burn-out is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed."

Burnout manifests in different ways for different people. For many workers, burnout is often associated with feelings of tiredness, helplessness, cynicism, and a drop in performance and motivation.

The World Health Organization's definition of burnout specifies three key dimensions of burnout:

feelings of energy depletion or exhaustion;
increased mental distance from one's job, or feelings of negativism or cynicism related to one's job; and
reduced professional efficacy.

How common is software engineer burnout?

Burnout is an especially prevalent challenge for engineering teams and tech workers. Developers frequently navigate fast-paced and high-growth work environments, building mission-critical software—often without the systems, processes, and culture needed to support their work.

Recent Gallup surveys reveal most workers, about 76%, experience burnout. More specifically, 28% of workers responded that they experience burnout very often or always. Less than a quarter of workers feel they rarely or never experience burnout.

In certain industries, such as game development, engineers are expected to work long hours and against strict deadlines. They often need to make last-minute changes before launch during a frenzied period of work infamously dubbed "crunch time." In one example at Rockstar Games, management admits to perpetuating a culture of burnout and hardship. According to Time:

The chief executive of Rockstar Games, publisher of the hugely popular Red Dead Redemption 2, bragged in an interview last year that people there were working 100-hour weeks to finish that game in time for its scheduled release date.

Chaotic release schedules and deployment setbacks are surprisingly prevalent across the world of software development. Companies rely heavily on engineers to ship code faster and provide value to customers, but often lack the DevOps practices to support them. Instead, developers often face delays, deployment pains, and organizational fear and mistrust that disrupt their team's flow.

Such recurring organizational hurdles lead to chronic frustration—and ultimately developer burnout.

What causes software engineer burnout?

Burnout often arises from issues within the organization, rather than the individual. Many engineering teams fail to sufficiently address the causes of burnout because they focus on fixing people and not the systems that support them—or fail to support them.

According to Accelerate, a research-backed guide to building high performing technology teams, the six main organizational risk factors for developer burnout are work overload, lack of control, insufficient rewards, breakdown of community, absence of fairness, and value conflicts.

Work overload arises from unrealistic expectations about the quantity or quality of work developers need to satisfy. Impossible deadlines, poor project timeline estimates, and insufficient planning push developers to work beyond what is physically and mentally sustainable. Developers who work long hours, nights, and weekends are more likely to burn out than those with better work-life balance.

Workload, however, is not the only risk factor for burnout. Contrary to popular belief, teams with balanced workloads can still experience serious developer burnout. Developers can burn out working 100 hours per week, but they can also burn out working just 20 or 30 hours per week.

In situations with manageable workloads but poor workplace culture, other organizational risk factors can lead to chronic stress and create unpleasant work environments. These risk factors disrupt an individual or team's development flow, making work consistently and unnecessarily difficult or challenging.

Lack of control in decision making processes leads to detachment from an organization's mission. When developers feel an inability to influence or contribute to decisions that affect them and their work, it breeds mistrust and creates distance between workers and managers.

For example, developers are sometimes forced to use tools they find ineffective. Developers can be at the mercy of slow workflows across the stack, from change approval boards to code reviews to data requests. In some organizations, development and operations may be making decisions about team practices without input from each other, creating organizational tension.

A breakdown of community also leads to an unsupportive, hypercompetitive, and stressful workplace. Moreover, harassment and bullying leave developers feeling isolated and fearful. Without community support or unbiased feedback, developers must grapple with additional stressors that detract from their quality of life.

Absence of fairness (a lack of fairness in decision making) and insufficient rewards, (a lack of positive reinforcement and feedback) also leave developers feeling not in control of their work and outcomes.

Cultures that rely on blame—not organizational learning—perpetuate a lack of fairness and recognition. Rather than solving underlying system weaknesses, organizations sometimes blame and shame developers for engineering challenges, such as buggy code, change failures, or missed deadlines.

Lastly, value conflicts that result in a mismatch between organization, team, and individual values create chronic stress. For example, a developer who values individual privacy working on ad tracking software can be worn down by the constant internal tug-of-war between her personal values and her company's mission.

What is the cost of developer burnout?

Stanford researchers estimate burnout leads to nearly $190 billion in healthcare costs each year and contributes to more than 120,000 deaths.

In addition to healthcare costs, burnout leads to lost productivity, sick time, costly disabilities, and turnover. It's estimated that workplace stress costs the U.S. economy more than $500 billion per year. Researchers believe nearly 550 million work days each year are lost due to stress and burnout.

For engineering teams, developer burnout leads to slower delivery speed, lower quality code, poorer project outcomes, and higher turnover. In the long run, burnout can also stifle innovation, creativity, and organizational learning.

How can managers spot signs of developer burnout?

It's important to understand that people react differently to burnout. Workers can experience several symptoms all at once, or just one or two at a time. Some workers experience mostly mental symptoms, while others experience physical and bodily changes.

It's also important to remember that burnout is not a binary state. Instead, workers move up and down a 'burnout gradient' depending on their changing environment and workload.

Mental and emotional symptoms of burnout include:

Tiredness or exhaustion: You feel too emotionally drained to engage fully with your work or coworkers.
Cynicism or negativism: You view your role as increasingly stressful and frustrating.
Detachment and alienation: You feel distant from coworkers and the company mission. You feel "numb" about your work.
Reduced performance or productivity: You are less effective at completing tasks on time. Your quality of work noticeably decreases.

Physical symptoms are also common. Developers experiencing burnout may notice that they are more fatigued and exhausted than normal, yet may also suffer from sleeplessness. They may also be experiencing frequent headaches, loss of appetite, gastrointestinal issues, or dizziness.

Can you detect burnout through metrics and data sources?

By looking more closely at their DevOps metrics, teams can spot early signs of burnout, developer frustration, and deployment pain.

Teams should watch for indicators that their work is needlessly challenging or painful to complete. They should watch for signs that their engineering systems—i.e. organizational workflows and processes—are ineffective at providing developers with fast feedback, avoiding delays, and preventing toil.

Long lead time, low delivery frequency, and low code volume can reveal friction during the development process. In such scenarios, engineers are likely experiencing roadblocks and bottlenecks disrupting their development flow.

At the DevOps Enterprise Summit 2014, David Ashman, former Chief Architect at Blackboard, recalls how his engineering organization became less agile and stagnant due to mounting technical debt. Ashman's red flag was a significant change in the number of code commits.

[The codebase] is growing at such a pace that is becoming this enormous product with so much complexity, so much insurmountable debt that we were running into problems both in development and operations of significant failures in releases and problems with developers taking far too long for these products to get built out.

Such challenges can leave developers struggling to achieve their goals, fighting against the system, and potentially working longer hours to overcome it.

An example of developers fighting the system, David Ashman

Teams should also watch for signs of high workloads and disruptive schedules. High meeting time can pull developers away from meaningful work and fragment their day, leading to dissatisfaction with daily work. Spending less time in flow during the workday and more time coding on nights and weekends puts teams at risk of burnout and poor work-life balance.

Operating above 100% of team capacity for too long—without breaks or downtime—can wear down even the most productive team. Code volume, measured by pull requests and commits, can be one approximation for workload.

Similar to other engineering metrics, context matters. It's important to understand teams and individuals in their day-to-day life to attain a clearer understanding of the situation. There is no single 'burnout' metric. Instead, teams should rely on several indicators of team frustration and pain.

How to prevent developer burnout

Avoiding burnout requires teams to reduce firefighting, hardship, and toil. The goal should be to alleviate deployment pain and enable the fast flow of work from code to production, as well as to create a culture of learning, psychological safety, and fairness.

It starts with improving the organization's DevOps practices. According to Accelerate:

Burnout can be prevented or reversed, and DevOps can help. Organizations can fix the conditions that lead to burnout by fostering a supportive work environment, by ensuring work is meaningful, and ensuring employees understand how their own work ties to strategic objectives.

Investments in DevOps strengthen the organization's developer experience, improving daily work. Over the long-term, better DevOps minimize several key risk factors for developer burnout.

To prevent burnout, teams should first embrace the principle of continuous improvement. Continuous improvement is a core idea in Lean methodology that advocates for incremental improvement in an organization's performance through continuous measuring, learning, and experimentation. It creates a culture that measures and improves daily work, identifying potential development pains and prioritizing their fixes.

Second, teams should create an environment that prioritizes psychological safety. They should provide engineers with the safety needed to experiment and learn from mistakes, instead of resorting to blame or finger pointing. Developers must be a part of the decision making process when it directly affects their work.

Third, teams must invest in the developer experience. Doing so requires teams to enable fast feedback, minimize thrash, and reduce fear.

In particular, organizations can reduce chronic stress by providing guardrails that improve the flow of work and remove fear and pain from deployments. Developers can quickly and confidently make changes to code when they have automated tests and environments, telemetry for performance visibility, loosely coupled architecture to isolate failures, and version control for fast rollbacks. Teams can also tackle technical debt on a recurring basis to avoid development stagnation and fear.

Can hybrid or remote work help prevent burnout?

Workplaces are quickly changing as the world grapples with a shift from office to remote or hybrid work. Such a seismic shift will likely change how teams identify and prevent burnout.

Remote work reduces time spent commuting and provides workers with greater control over their schedules. They benefit from more flexibility, which allows them to spend more time with family and friends or pursue activities outside of work.

Remote work can also lead to fewer distractions and more time spent in flow to work on meaningful tasks. Developers are interrupted less frequently by shoulder taps and open offices.

While remote and hybrid workplaces can remove certain stressors, they can also create new ones. Workers may face unfamiliar challenges, such as a lack of face time with coworkers and less rigid work-life boundaries. Without cultural changes to grapple with their new work environment, newly remote teams increase their risk for burnout.

Engineering teams switching to remote work can also face DevOps issues during their transition. They need to grapple with new requirements, particularly around hardware and team communication.

For a successful transition, teams should monitor for changes in the development process to ensure their tools and practices still work well in their new workplace. If not, they should adopt new ones that cater better to asynchronous communication and remote development.

Community showcase: automated home setup to stay in flow

Geoff Stevens — Thu, 20 May 2021 13:09:44 +0000

Code Time, Software’s extension for code editors and IDEs, helps you protect valuable code time with Flow Mode—a set of automations that makes it easy to eliminate distractions, mute notifications, and stay focused when you’re in flow.

Once connected to a Slack workspace, Flow Mode enables Slack’s Do Not Disturb mode, sets a custom status message, and adds a purple icon to your status. In some editors and IDEs, like Visual Studio Code, you can also choose to enable Zen mode or enter fullscreen with Flow Mode. Flow Mode can be triggered manually, via a button in the sidebar or status bar, or automatically, based on your coding activity.

Shane Lawrence, a member of the Software community and senior software developer, saw an opportunity to make Flow Mode even more powerful.

He extended Flow Mode to automate his entire workspace setup:

Change ambient lighting in his workspace to purple
Silence notifications on his phone
Set a custom Do Not Disturb status on his home system

Here’s a short demo of Shane’s custom Flow Mode in action:

Overview of the flow automation stack

Shane’s setup uses a few different automation tools and APIs:

Code Time to detect when he’s in flow and update his Slack status
Slack Events API to monitor his status and trigger his home automations
Home Assistant for connecting and controlling his devices
Philips Hue bulb for his desk light, Hue lightstrips and Nanoleaf Aurora for accent lighting on the wall
Tasker and the AutoRemote plugin to set his Android phone to Do Not Disturb

Shane wrote a small watcher script in Node.js that checks for changes to his Slack status using the Slack Events API (@slack/events-api). If a new status includes Flow Mode’s purple emoji, 🟣, Shane’s bot sends a custom ‘begin_flow’ or ‘end_flow’ event to his Home Assistant, a popular open source home automation hub.

Home Assistant then sets a custom Do Not Disturb mode for his home automation system, triggers his workspace lighting, and sends a notification to his phone.

Home Assistant comes with powerful connections out-of-the-box. It integrates directly with Philips smart bulbs and Nanoleaf lights, as well as more than 1,500 other smart devices. To control his phone, Shane uses AutoRemote to listen for notifications from Home Assistant. Tasker then changes his phone’s settings.

In his next iteration, Shane is considering how he might trigger Digital Wellbeing’s Focus Mode to disable all distracting apps on his Android phone. He is also exploring how he could integrate with Spotify to start playing newly recommended songs from Music Time when he’s in flow.

Why defending flow matters

Developers constantly battle meetings, interrupts, and inertia—the ‘enemies’ of developer flow—that interfere with valuable code time. Impromptu Zoom calls and relentless Slack messages make work feel disjointed and chaotic.

Protecting flow helps us silence these distractions and make the most of each workday. From Shane:

“As someone who’s deeply passionate about the work I do, being in flow is the part of my day where I’m immersed and energized in what I really love most: working on challenging problems and helping online communities be a safer place for everyone to connect.

While I’m fortunate to have been able to keep my job through the pandemic, working from home has introduced its own set of challenges, such as staying focused on days when other distractions want to drag my attention away from important tasks, making it difficult to always sink my teeth into a solid coding session.

Code Time’s flow feature combined with my smart home integration helps me quickly tune out all of the distractions at once, helping me focus faster and reduce the chatter of apps and chat messages all competing for my attention.”

If you’re interested in automation tech, you can find Shane on Twitch, where he’s currently building a bot service that helps streamers let their viewers redeem channel points to change their smart light colors. He streams Wednesdays at 6pm PT and Saturdays at 7pm PT. Shane’s streams are open to all, coders and non-coders alike.

Track your 100 Days of Code. Get a Software certificate.

Geoff Stevens — Fri, 07 Aug 2020 18:43:06 +0000

🚀 Check out our launch on Product Hunt!

The 100 Days of Code Challenge

100 Days of Code is a coding challenge created by Alexander Kallaway to encourage people to learn new coding skills. The challenge follows two simple rules:

Code for at least an hour each day for 100 consecutive days.
Share your progress each day.

Tens of thousands of developers from around the world have taken on this challenge. Whether you are learning to code or an experienced developer, everyone, regardless of their skill level, can participate in the 100 Days of Code challenge. You can learn more on the official 100 Days of Code website.

The 100 Days of Code Extension

Software’s 100 Days of Code extension is a free, open source plugin for Visual Studio Code to track your 100 Days of Code progress. With the 100 Days of Code extension, you can create logs and share your progress all within Visual Studio Code. You can also earn rewards throughout the challenge with unlockable milestones that you can share with your friends.

The 100 Days of Code plugin is built on Code Time, our powerful time tracking extension backed by the Software community.

You can learn more or install the extension from the Visual Studio Code Marketplace.

Log your progress

Tracking your progress during the 100 Days of Code challenge with a personal journal helps you focus on your goals and keeps a record of your accomplishments for you to reflect on and share with others. Logging your progress each day will help build good coding habits and allow you to successfully complete the challenge.

The 100 Days of Code extension offers an in-editor log page where you can keep a record of your projects, bookmarks, and coding activity.

To create a log for the day, open the Code Time view in your Activity Bar. Click the View Logs button in the 100 Days of Code section to open your Logs view. At the top of the opened page click the Add Log button. Simply add a title, description, and links relevant to your coding projects.

Each new log is automatically updated with your coding metrics for that day, such as hours coded. You can see these values while writing your log entry.

When you submit a log, it is then added to your personal Logs page where you can view details about each log—including title, description, links, code metrics, and milestones for that day. Each day's metrics are compared to your average metrics calculated from all your log entries throughout the challenge.

If you forget to create a log for a day that you worked, don’t worry! The 100 Days of Code extension automatically creates a log for you with your coding metrics. You can edit these logs at any time with additional information.

Collect badges

Milestones are fun, collectable badges to help motivate you through the 100 Days of Code challenge.

You can earn milestones by completing coding tasks and progressing through the 100 Days of Code. For example, you can earn badges by coding for 10 total hours, programming in a new language, or even sharing your progress on Twitter.

There are over 50 unlockable milestones, divided into six levels of difficulty, for you to earn throughout the challenge. How many can you collect in 100 days?

Share your progress and milestones

Sharing your progress with the community is important to stay motivated throughout the challenge.

With the 100 Days of Code extension, you can share log entries, unlocked milestones, and your personal coding dashboard to Twitter right from VS Code.

To join the community on Twitter, use the hashtag #100DaysOfCode and publicly commit to the challenge. Every small step matters, so we encourage you to share something every day.

Don’t forget to tweet @software_hq! We would love to see all your progress towards your 100 Days of Code.

Earn your certificate

After completing your 100th day, you will unlock the official Software 100 Days of Code certificate.

To claim your certificate, open the 100 Days of Code dashboard in VS Code and click the gold button that appears at the top of your dashboard. You can view, download, and share your certificate right from VS Code.

Getting started

Whether you are a newbie or have 10 years of development experience, it only takes a moment to begin your 100 Days of Code journey with Software.

Install Visual Studio Code.
Get Software’s 100 Days of Code extension.
Sign up for a free Software account from your editor.
Start coding!

We’re excited to see your tweets and progress during the 100 Days and beyond. Good luck!

Check out the discussion on Product Hunt or let us know what you think below!

How to set up your own personal website for 100 Days of Code

Geoff Stevens — Mon, 22 Jun 2020 23:31:03 +0000

➡️ If you just want to get the template for your personal 100 Days of Code website, go here and fork the repo. See a preview here. If you want to learn how it all works, keep reading.

100 Days of Code website built using Gatsby.

Overview

In this post, we’ll walk through how to create your own personal website for 100 Days of Code. You'll use a pre-built website template that takes just a few steps to set up. No knowledge or coding experience is required, but will be helpful (I'll do my best to outline some of the basics in each section).

100 Days of Code starter template, built using Gatsby. Fork it.

If you’re new to 100 Days of Code, it is a self-directed commitment by developers to build strong and consistent coding habits. The challenge uses social accountability, transparency, and deep reflection to form healthy developer habits.

The ultimate goal of the 100 Days of Code challenge is to become a better developer and to build coding as a habit. If you hope to become a more versatile, disciplined, and skilled developer, you should consider joining the challenge.

Building a site to showcase your progress during 100 Days of Code is a great way to stay motivated and share what you learned with others. Alexander Kallaway, creator of the challenge, suggests keeping a log like this one. Creating a log is also helpful for memorializing your accomplishment after you finish the challenge.

To build your site, we'll use:

Gatsby: a free, open source framework based on React that lets you build static websites and apps.
Netlify: a free hosting platform that lets you quickly deploy your app to the web, without running or managing any servers.
GitHub: a free and popular service to store and edit your code.

You might have heard of Wordpress before—it’s a content management system with a large ecosystem of plugins and templates you can use to set up your site. We're not going to be building a Wordpress site, which is a dynamic site and executes code running on a backend server. Instead, we’ll be building a static site, can run entirely on a client-side machine using a Jamstack architecture.

The Jamstack is a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup. Coined by Netlify CEO Mathias Biilmann, the Jamstack underpins the modern static website.

Static sites offer many benefits over dynamic sites, such as faster performance, cheaper hosting, and ease of development. Static sites are also ideal for mobile-first indexing and page speed—two top ranking criteria for search engine optimization and top of mind for any frontend web developer.
Now let's dive into how we built the site template and how you can deploy your own version.

Designing the template

Before writing any code, it's important to start by designing what you are going to build. Figma is a free tool that you can use to create prototypes of your website. It has become the most widely-used design tool in the market today.

Website design using Figma, a free design tool.

Here is the template in Figma. Note: my brother Brett built the site. He didn't build the site exactly to his original design, but it is still important to get the layout and structure of the site down before building anything. It will save you time.

Set up your Node environment

Gatsby is built with Node.js, a popular Javascript runtime environment with an extensive ecosystem of packages—third-party modules built by other developers that you can use in your projects.

A prerequisite to running Gatsby is setting up your Node development environment. You can follow this tutorial. I prefer to use nvm to manage Node:

Download the nvm install script via curl: curl -o- [<https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh>](<https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh>) | bash
Install the latest stable version of Node: nvm install --lts

Set up Git and GitHub

You'll also need to have Git and a GitHub account. If you're new to these tools, Git is an open source tool that lets you manage versions of your code by tracking changes with commits and branches.

Once you've set up Git, you're going to link it to your GitHub account. GitHub is a remote hosting provider for Git repositories that allows you to share your code with the world and collaborate with other developers.

Here is a guide to set up Git and link it to your GitHub account.

Developing a Gatsby site

Now that the site is designed, Node is installed, and we've set up Git and GitHub, let's cover Gatsby. Initially, to set up the site, we followed the quick start guide. Here were the steps to set up our site:

Create a new Gatsby site by running gatsby new 100-days-of-code
Make changes to the starter template
Commit all of our changes to Git
Push everything to GitHub

You won't need to do these steps, since we've already set up the repo for you. Instead, you'll just need to run these commands:

Clone your forked GitHub repo to your machine: git clone <link to your forked repo> (you can get this link from your forked repo on GitHub).
Navigate to the directory you just cloned: cd <link to your forked repo>
Install the Gatsby CLI globally: npm install -g gatsby-cli
Install dependencies: npm install
Run the site using gatsby develop.
Visit localhost:8000 in your browser to see a version of your website running locally

Set up your package manager (optional)

There are several different ways to install Node packages in your project, the two most popular being npm and yarn.

By default, Gatsby works with npm, which comes installed with it. I prefer to use yarn, so here's how to set that up.

To edit your Gatsby config to use yarn, edit this file on your local machine:

// .config/gatsby/config.json
{
    "telemetry": {
        "enabled": true,
        "machineId": "895568d5-3051-4ba4-9563-0a4dc4b3638b"
    },
    "cli": {
        "packageManager": "yarn"
    }
}

Now, you can add new packages to your Gatsby repo using yarn add. This will add a package to your package.json file and create a yarn.lock file in your repo. You can delete the package.lock file if it exists, since you should only use one package manager. Anyone else working in your repo will have to run yarn before they run gatsby develop.

Some packages that I used when creating this site:

The plugins for Material UI core, styles, and icons: yarn add @material-ui/core
The markdown plugin: yarn add gatsby-transformer-remark
The remark images plugin: yarn add gatsby-remark-images

These packages are automatically installed when you run yarn.

The template we’ve built uses Material UI, a React implementation of Google's Material design framework. They have premade components that you can leverage, such as buttons, dialogs, and navigation. I encourage you to browse their site to get an understanding for the types of components you can leverage from any React component library (others include Ant, Fluent, and Grommet).

Site structure

Before adding any content of your own, let's go over the anatomy of the site structure. In your /src folder, you have these subfolders:

components - contains the components rendered on your site, such as layout.js and header.js components.
pages - contains all of your markdown files, as well as any other pages on your site. Gatsby automatically creates a new page for each Javascript file you had to this folder.
images - image assets for your site. This is where you'll put your post thumbnails.
theme - this is where you can customize the Material UI theme. You can also edit layout.css to customize the raw CSS.

Outside of the /src folder, there are also a set of files that use the Gatsby API. These include gatsby-config.js, which is used to manage your site data and plugins. You don't really need to worry about the other files if you're just getting started, but you can read more here if you'd like.

Add your own posts

The Gatsby site works by reading in your posts in markdown and converting them into HTML on your website using the markdown remark plugin. The markdown remark plugin also allows us to easily query for all of the markdown content in our repo using GraphQL.

What is GraphQL? It's a query language that allows you to fetch data in a flexible way. Compared to REST APIs, GraphQL gives you the power to get exactly the data you need (instead of having a predefined set of data in a set of API endpoints). You can see your data and build queries using the GraphQL explorer available at localhost:8000/__graphql.

To add your own posts, create a new .md file in the /pages folder. Each post has frontmatter, which is the metadata attached to your post. This is where, for instance, you can set the day number (e.g. Day 5) and the path to the image you want to display on your page for that day. Posts are ordered by day when they are organized in the paginated layout, so be sure to add day to the frontmatter of your posts.

Once you've added your post, commit it to Git! If you don't know Git yet, the commands you need to know are:

git init - initializes a new Git repository in a folder on your machine (you don’t need to run this if you cloned your repo from GitHub)
git add -A - adds all of the files you’ve modified to your staged changes
git commit -m "some message" - commits your staged changes to Git
git push origin <branch name> - lets you push your changes to your remote repository on GitHub

Deploying the template

Now that you've set up your local development environment, it's time to build and deploy your site to Netlify.

First, create a free Netlify account. Click "Create a new site from Git", authorize the Netlify app to be installed in your GitHub account, and choose your GitHub repository.

Leave all of the settings as-is and click to deploy your site. Make sure to set the production branch to the correct branch of your choice in the Netlify deploy contexts.

Netlify will give you your own unique Netlify domain (e.g. https://bretts-100-days-of-code.netlify.app/), but you can configure your own custom domain using your hosting provider of your choice.

When you deploy your site, your React code is compiled and deployed to Netlify's servers. Netlify hooks into your GitHub account to allow your site to be deployed automatically. Every time you make a new commit, a new build of your site is triggered, and then your site is deployed (as long as the build succeeds).

That's it!

You've created your own 100 Days of Code site. Check out this guide for more resources on completing the challenge.

Geoff Stevens for Software.com

Feb 26 '20

Essential Guide to the 100 Days of Code Challenge

#100daysofcode #productivity

181

Comments 2

19 min read

👉 Join the waitlist to try out our 100 Days of Code extension for VS Code here.