What is flow?
The concept of flow was introduced and popularized by psychologist Mihaly Csikzentmihalyi in the 1970s.
His key insight was the idea of a “flow state”— a mental state where a person is so immersed in an activity that nothing else seems to matter.
In this state, people lose awareness of distractions, time, and people—and are completely engrossed with the task at hand.
His study showed how enhancing the time spent in flow could make people more productive and happier in their work.
Getting into a flow state
Everyone’s different, so the exact way to "get in the flow" is varies across people. However one principle is universal: eliminate distractions and blockers wherever possible. In a work context, some simple things, like putting your phone away, closing out browser tabs, and logging off of Slack or Teams (with your manager/team’s approval, perhaps!) can help you achieve this.
Sounds nice right? Unfortunately, it’s not that simple.
Take the case of a product engineer. You can’t just get rid of all the things that might slow you down from product work— at least not if you’re doing your entire job. In the software engineering world, no developer has the luxury of just ignoring all distractions so they can focus on building great products. We have multiple things to do as engineers.
It’s also crucial to recognize how the shortest distraction can have a huge impact on the rest of your work day.
One study from the University of California, Irvine shows that switching tasks can result in 40% more time needed to complete a task.
And for programming specifically, a study conducted by Georgia Tech found that on average it takes a programmer around 15 minutes after being interrupted just to get back to work. Never mind getting back into the flow state!
So it may be impossible to completely eliminate blockers in a developer's day-to-day. But perhaps we can reduce them, and make them less impactful.
Let's see how Cased can allow your developers to get back to what they do best: building great product.
Customer Support Ticket without Cased
To show how Cased can improve developer happiness and productivity in a world of blockers, let's look at some examples of common engineering scenarios with and without Cased.
Say that you've been assigned a customer support ticket that was just escalated from the support team.
The customer's logs, screenshots, and environment data wasn't enough for support to resolve the issue at hand—and so we have a common escalation to engineering.
However, more information is needed before you can even reproduce the issue— and then hopefully resolve it.
You begin by asking multiple questions to support folks in order to get a better idea of what exactly is causing this problem for the customer.
After a lot of back and forth—with valuable time passed between each message—you ask the customer to run some scripts that will retrieve diagnostics to help in resolving the issue.
Once the diagnostics are back, you can finally begin to start fixing up a solution.
Customer Support Ticket with Cased
With Cased, we can eliminate the constant back and forth between the customer, support, and engineering in collecting the information necessary to isolate and quickly resolve customer issues.
Snippets allow you to make cross-functional collaboration between engineering and support more efficient to get quicker results.
The snippets feature allows developers and support to share code snippets with one another that are stored right inside of your shell.
So with the customer support scenario we talked about above, instead of support having to go to engineering with no information, resulting in time passed and lots of back and forth, they can search right from their shell and run the diagnostic snippets necessary, and send the engineer the diagnostics.
Coupled with auto-discovery of all your hosts and one-click access to jump into the production host you need 10x faster than normal, Cased reduces the engineering effort and time to resolution for common customer escalations.
Routine production work without Cased
Let's consider an important, common workflow that developers perform: testing a failover.
This first step of this multi-step process might involve running (and maybe writing!) a query to list all active databases.
Then, there are a bunch of prechecks developers need to run: checking the standby status, checking the replication lag, and cross referencing with analytics tools to verify if the system is performant enough to even run the failover.
Then more: status check scripts to determine how long the failover will take before ultimately executing the failover. Synchronous back-and-forth chatting between teams.
Testing a failover is a time-consuming process– and a process that can and should be automated, with some light human supervision.
Routine production work with Cased
Cased makes it easier for your developers by automating long, complex production workflows and turning them into one-click runbook processes.
Instead of having to do tedious, manual work daily in order to test a failover, you can create and set up an automated runbook once for multiple uses.
This keeps your production systems up as running standardized, codified processes that are already proven to work, greatly decreases the chance of bringing production down.
The time spent for engineering goes to near zero with runbooks, as runbooks can be run safely and securely by other teams when given permission.
Conclusion
Blockers are inevitable in a developer's day-to-day. However, you don't have to let them completely slow down your product development. Keep your developers in flow with Cased.
If you're interested and want to learn more about Cased Shell, feel free to schedule a demo, read the documentation, or send us an email at team@cased.com.
