DEV Community

sta
sta

Posted on

Dry Behavior

Background

The true calling of an engineer is engineering, not communication. Communication is something anyone can handle—it only needs to be concise and done as necessary. That used to suffice.

At some point, however, we transitioned into an era of teams, where social aspects like humanity, respect, and psychological safety became important. Engineers unable to adapt to these social activities found themselves overlooked. So many people demand in-person attendance or face-to-face meetings; while this may be understandable with clients, why go through so much effort for colleagues? Text communication and asynchronous methods should suffice. Don't disturb the engineers.

Recently, a new trend has emerged: Generative AI. We must seize this opportunity to bring back the era of engineers.

Overview

Dry Behavior refers to an attitude toward generative AI.

In practice, it involves engaging in text communication and asynchronous communication. You prompt, wait for a response, confirm the reply when it arrives, and then send additional prompts—repeating this cycle.

We apply this cycle to interactions with humans as well. In essence, we exhibit a somewhat dry demeanor toward machines like generative AI, and this behavior extends to our interactions with people.

Advantages

Dry Behavior can significantly reduce communication costs.

For engineers, it allows for only the bare minimum communication necessary for engineering. The saved time can be redirected back into engineering itself.

For managers, it alleviates the effort of maintaining direct communication with less communicatively adept engineers. After all, working relationships don't require personal bonds; dry interactions can suffice to carry out necessary exchanges and build trust.

Disadvantages

One of the challenges with applying Dry Behavior is identifying who it can be applied to.

Essentially, Dry Behavior might be seen as “not treating someone as human.” If you fail to carefully select whom it can be applied to, it risks being perceived as harassment.

Designing the Cycle

Dry Behavior should be designed as a cycle.

For instance, using a PDCA cycle might look like this:

  • Plan: Draft the message you'll send to the recipient
  • Do: Send the drafted message
  • Check: Upon receiving a reply, review it
  • Act: Decide if you need to draft another message or conclude the interaction

However, the PDCA cycle can be too abstract and difficult to grasp. You may find it more useful to design a cycle tailored to your needs.

For reference, I've devised a cycle that you're welcome to try.

4P Cycle

The 4P Cycle consists of the following steps:

  • 1: Prompt. Draft and deliver your message
  • 2: Polling. Wait for a response. Polling is adequate
  • 3: Proofread. Once you receive a reply, handle it as if you're proofreading
    • In other words, your counterpart will draft an initial version, and you'll take care of polishing it thereafter
  • 4: Plan. Decide whether to continue the interaction or to conclude it
 +---> Prompt ----+
 |                |
 |                V
Plan           Polling
 A                |
 |                |
 +-- proofread <--+
Enter fullscreen mode Exit fullscreen mode

While this cycle is not universally applicable, its specificity makes it easy to use.

Conclusion

We've discussed the concept of applying a “dry” attitude typically reserved for interactions with generative AI to humans as well. Reducing unnecessary communication can be beneficial in focusing (or helping others focus) on engineering. Feel free to give it a try.

Identifying whom it can be applied to is challenging, but you may explore this through one-on-one interactions. You'll likely find engineers who are open to giving it a shot. Of course, if no one is interested, it's best to quietly abandon the idea.

Until next time.

Top comments (0)