Post-Pandemic Engineering Communication

after 2 years of transitions from WFO to WFA. Here is my take on how to maintain communication between engineers.

Background

In my current workplace (vidio.com), our engineering culture leverages the extreme programming. In my opinion, this practice works well with the WFO settings which is hard to implement in pandemic/post-pandemic situations.

Pairing, reviewing code, meeting, etc are usually done in “real-time”, means there were no lags between feedback. Remote working 100% changed the way we communicate and give feedback.

Internal and external causes such as network availability, distractions, etc are limiting our capability to maintain active communication. Asynchronous communication can also harm our productivity if not maintain properly. We need to define ways of preserving fellow engineers efficiency and productivity.

Issue

here are the most common issues:

• Slow feedback loop (thread, PR, discussions)
• Less meaningful feedback; most of the time one-way review and additional discussion could prolong the PR
• Bystander effect; some people just ignore or don’t feel obligated to check or answer

these 3 types of common issues can lead to various effect that is mostly harmful to our engineer productivity (mostly snowballed effect caused by prolonged PR discussion)

Ways of communication

3 types of engineering communication

• Extreme programming (pair programming)
• Async Pairing
• Solo programming

Pair Programming (extreme programming)

When?

• Stable internet connection
• Small scope (between 2 person only)
• Working on a feature
• Nice article on pair programming by Martin Fowler

Why?

• “Think twice work once”
• Another set of eye to ensure code quality
• Disperse knowledge and faster learning curve
• Ensure more than one person have the knowledge (avoid silo programming)
• Alongside of TDD pair programming, this promotes code ownership and increase confidence through combination of tests

Challenges on WFA

• It demands faster feedback loop
• it relies on frequent communication between pairs
• it takes longer to finish a feature but, with more coverage on cases and tests

Async Pairing (Remote friendly IMO)

When?

• unstable internet connection and other external complications
• each person working on small bite of relevant feature or backlog
• discussions requires more than 2 people (cross-team communication)

Why?

• same application with pair programming
• having more flexibility at a cost of slower feedback loop
• prioritize pairs communication (each member is responsible for their pair communication)

Challenges on WFA

• slower feedback loop on async; every thread, pull request, discussions
• need commitments from each person
• need to mention or assign specific person as PIC (read bystander effect)

Read: 5 tips for effective remote working environment

Solo Programming

When?

• Working on non-production code (docs, research, etc)
• you are team leader who is constantly has meetings
• No one to pair with *sad

Why?

• it is more flexible and faster

Challenges on WFA

• time management
• active and proactive communication with teams

Conclusion

Async pairing is most likely a solo programming with more layers to ensure communications and faster feedback loop. it can be frustrating when your code doesn’t deliver on time because of slow communication and no-one replying your pull request.

I’ll be discussing more on the communication and collaboration in the next part. Thanks