3 minute read

What is zanshin?

Zanshin (残心) is a Japanese term related with marial arts meaning constant attention and steady concentration even after a competition has ended. Good explanation in this article. Zanshin has wider meaning: it is an attitude that can be even applied to professional life: “(It means) acting with purpose rather than mindlessly falling victim to whatever comes your way.” In software development, a programmer should have an initiative and boldly encounter various situations, not limited to simple coding activity.

Software development zanshin

A developer should assume a responsibility for whole process of software development.

His or her task does not finish with the coding part. Obviously, one shall test the code is working locally and on development / test environment. It should also pass all tests and build correctly. The application should boot and have stable behaviour. See Standing Operating Procedures in development for detailed explanation. But it is not everything.

A conscious developer is also responsible for:

  • checkout from a proper branch or tag and preparing pull request to a proper version / release
  • business analysis knowledge and understanding business context
  • perception of an impact on other services (microservices), pipelines, processes
  • comprehension of data-related issues: database connection and , data migration, data consistency, transactions, database efficiency
  • overall and detailed performance

When dealing with some complex task, it is worth to share gained experience and knowledge with others:

  • list use cases or describe bug reproduction
  • design mindful test cases for the attention of QA team
  • predict edge cases, corner cases, security threads

If there is a blocker, implementation is growing or impact is spreading, and it potentially affects not predicted earlier areas, we should keep tech lead updated. Also inform others through proper channels (but the message should be strict and concise, properly ilustrated and easily noted). Same thing should be done when your work would be prolonged or a risk or impediment appears.

Now, code review. It is a great opportunity to learn and share opinions. It is a good way to be up-to-date with the latest changes in the code base. We can follow what is currently on in the project and where are we going. Not to mention security improvement and bug prevention. I am willing to spend my time to review code prepared by colleagues and vice versa. I expect my code to be reviewed. If I have any doubts, I can ping my colleagues about to advise. If it takes too much time, I am to find out why. It is up to me to overlook the progress.

The same thing for testing. We are responsible for taking care of the story even if somebody else is testing the code. Update the status and communicate it. So be sure the tests have started. Provide any help to the QA. Conduct constant, even informal, communication. Do not play ping-pong with QA pasting multiple comments under the story description at Jira nor to the main channel. It is faster to talk through private channel or even make a quick call. Be a reactive programmer and fix your bugs immediately without redundant formalities. Do not waste time of yours and others! The time is the only non-renewable asset in the Universe (so far). On the contrary, programmer’s ego is infinite and may recover quickly, so do not regret it. You can survive loss of your ego but not the loss of your time.

Last but not least, remember about documentation update.

But even here your story has not finished yet. Bugs still may appear. Something can be broken down. Deploy may fail. There may be fire in the production environment.

Conclusion

So as a Japanese proverb says:

勝って兜の緒を締めよ

Katte Kabuto no o wo shime yo

“When the battle seems to be won, rather tighten the strings of your helmet”

In other words, do not be lazy, be eager in the process of software development. Passive stance is an enemy of constant improvement, active stance means a state of relaxed alertness.