At the moment there are a lot of agile methodologies out there which you can use on your team and see if they are applicable to it. Some teams develop their own processes, which is a great way to find out what really works best for you. These kinds of teams basically experiment and they are focused on creating an environment in which they will be able to create great software. If you look closely, you can see that this approach is crucial to some of the many success stories – creating an environment in which you are able to create great software.

This approach is also applicable on a personal level. Get yourself in the mindset of creating a high-quality product, and you will probably create a high-quality product. Of course, maintaining this mindset is not an easy task to achieve. Keeping your professionalism on the high level can be exhausting. A great number of life coaches will not stop talking about continuous improvement, which is, of course, mandatory if you want to be the best professional you can be. But, they’ll never tell you how hard living with the damn thing is – especially over a long period of time.

In my opinion, the biggest problem with keeping professionalism at the high level is the lack of inspiration. For a long time, I had periods of high inspiration, usually after reading a good book, and then that inspiration faded until I found another source of inspiration that kicks me right back into the “awesome professional developer” mindset.

So I wondered whether there is a way to keep myself in that mindset and keep my inspiration at some constant and consistent level, without having to read Clean Coder over and over again.
Therefore I started using some of my other interests to remind me of what good software crafter is all about. Most of the time I focused on phrases from other books I have read, how they can be applied to software development, or what aspect of it they can remind me of. After all, one of the goals that The Pragmatic Programmer mention is:

Read nontechnical books, too.

That is how I created a bunch of small mantras from different sources, to keep my inspiration at the highest level possible. When my inspiration starts to decrease, I start using a different set of mantras to keep things interesting. “Art of War” was one of the first books I started doing this with.

Why Art of War?

“Art of War” is one of the first books that were applied in industry, even tho it is actually a military treatise dating back to the 5th century BC. It is very popular in business, and there are a lot of theories that Donald Trump may have won applying principles from this book.

But, at the moment of writing this post, there are just two blog posts about how principles from this book could be applied to software development in general. They are both great reads:

• The Art of War Applied To Software Development by Jose F. Maldonado
• The Art of War: How it Applies to Software by Dalip Mahal

You see where I am going with this, right? It appears that a lot of people have found a value in Art of War and have found a way to apply principles from this book in their profession; except us – the software developers.

Google-able stuff

“Art of War” was written by Sun Zu, the famous Chinese military strategist. It consists of 13 chapters, each of which is devoted to one aspect of warfare:

1. Detail Assessment and Planning
2. Waging War
3. Strategic Attack
4. Disposition of the Army
5. Forces
6. Weaknesses and Strengths
7. Military Maneuvers
8. Variations and Adaptability
9. Movement and Development of Troops
10. Terrain
11. The Nine Battlegrounds
12. Attacking with Fire
13. Intelligence and Espionage

The first annotated English translation was completed and published by Lionel Giles in 1910, and it has been translated in almost all world languages.

Of course, not all of the chapters have applicable information when it comes to software development. I really wouldn’t know how to apply Attack by Fire on anything in our profession, although it had a great influence on business tactics and legal strategy.

Enemy

Now, before we go further, we must consider who our enemies are. After all, we cannot apply military tactics if we don’t know who our enemies are. Well, this question cannot go further without going more into details about how a typical software developer’s job description has changed over the last couple of years.

Our job doesn’t cover just writing a code, especially not just writing a working code. Our code has to be maintainable, well designed, easily testable and covered with a number of unit tests, integrated tests, system tests, and probably some kind of tests I am not even aware of.

In addition to that, we have to have a very stable and solid knowledge of the domain, make correct abstractions and model reality in a correct way. Let’s not forget that we have to estimate our efforts, have constant communication with clients, gather feedback, make sense of that feedback and make decisions that have a direct impact on the business. Ok, maybe not as many decisions as we would hope, but definitely, we have some impact. To sum it up, we have a lot of different responsibilities, meaning we have a lot of different ‘enemies’. Some of our enemies are:

• The problem we are facing
• Estimations
• Complexity
• Technologies
• Testing
• Hardheaded client
• Ourselves

We can look at pretty much every paragraph of Art of War through different lenses for every enemy we can think of. This gives us several different interpretations of each passage and a lot of potential applications. In my opinion, this is the real power of the Art of War.

Applied Passages

There are not more than five musical notes, yet the combinations of these five give rise to more melodies than can ever be heard.
There are not more than five primary colors, yet in combination, they produce more hues than can ever be seen.
There are not more than five cardinal tastes, yet combinations of them yield more flavors than can ever be tasted.

Usually, when I mention Art of War as a method for anything, people get a bit defensive and appalled, even though Sun Tzu’s philosophy is all about obtaining and keeping balance. The word “war” is not considered good in any context. That is why I decided to start with this “hippy” passage.

Software development is as much art as it is engineering. Even more, “real” engineers are bounded by the rules of the physical world. We don’t experience that. We even invent our surroundings, our frameworks in which we will put our solutions that will in turn, somehow help other people. We create entire worlds and things in those worlds. In my opinion, that is awesome. We are being creative and useful at the same time, and that is why being a software developer is one of the best jobs out there.

He who advances without seeking fame, Who retreats without escaping blame, He whose one aim is to protect his people and serve his lord, The man is a jewel of the Realm.

Well, let’s continue with the “hippiness”. I know a lot of software developers out there that are just full of themselves, and I am sure that you know quite a few yourself. So many of us suffer from the “beginner expert syndrome”. We are not quite aware of the things that we still don’t know, and yet we consider ourselves experts.

Use this paragraph to remember that you need to calm your ego down. That will open your mind so to say, and get you more into that state where you are able to learn. Let yourself be a student for during your entire life. I know this sounds like a lot of mumbo-jumbo-new-age stuff, but it is actually a mindset that helped me a lot in my career.

Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances.

Now, once you are in a state of constant learning, you will know a great number of approaches for any kind of problem. Unfortunately, sometimes we try to use the same “hammer” for every issue. Every difficulty is specific, and if you only know one technology and one framework, you will always try to use them. What if there is something more appropriate out there? What if it can be done in a more efficient way? So yes, technologies, languages and all of those things are important, but what is also important is their application in different situations.

In war, then, let your great object be victory, not lengthy campaigns.

We use Agile methodologies to chop up our big projects into smaller and more accessible tasks. Why do we do that? Have you ever worked on one project that simply won’t be finished for a long time? Have you ever worked on a project that failed? I have worked on both. From my experience, long tasks and long projects take a toll on people. Inspiration and motivation drop drastically during lengthy missions. Plan your tasks well, and make them as small as possible; it will keep your morale up. I guess this is rooted in the fact that people like to be useful and progress is more visible on smaller tasks and assignments.

If your team is not doing some form of Agile (or even if they are), do it yourself. Measure your progress, collect data on your productivity. I personally like to work in Pomodoro cycles and use Kanban Flow to keep track of my tasks and keep them as small as I can.

It is said that if you know your enemies and know yourself, you will not be imperiled in a hundred battles; if you do not know your enemies but do know yourself, you will win one and lose one; if you do not know your enemies nor yourself, you will be imperiled in every single battle.

This one basically means that you should always do your research. One of the most important things in our profession is being aware of your clients’ needs. Go deep into what kind of solution your client actually wants and what your software will be used for. This way you will know where the “holes” in your solution are, and where you can make improvements. A lot of projects have failed because developers never asked the question: “What will this be used for exactly?”

Also, this passage applies to the necessity of self-awareness. Again, once you stop acting like a know-it-all, you will be able to learn. Know your flaws and areas in which you can get excel, and you can make a plan for filling those gaps.

Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.

This passage reminds me of two things. The first one is that we need to get good requirements from our client and the second one is that we need to test our code as much as possible. By getting good requirements, we can cover use cases, and get a good picture of what we should test. That way we can cover our black-box and some of the gray-box tests (BDD). For covering a solution from the inside out, we can apply TDD and SOLID principles and write a lot of unit tests.

This way, before our software goes into production, we can make sure that it is high-quality and robust.

Whosoever desires constant success must change his conduct with the times.

The biggest fear of every good software crafter is becoming obsolete, becoming the next Cobol programmer. It is hard to keep up with all the languages and frameworks, and there is always a question of what should be the next to learn. Lucky for us, some of the principles are the same for a lot of different technologies, languages, and frameworks.

Still, every once in a while, not just a new technology, but a new way of thinking about software will emerge and take over the industry. Sometimes this will be one of the old principles, just presented in a new light. In my opinion, keeping up with these little revolutions is crucial. If you have learned one programming language, chances are that you will learn the next one much faster, but a new way of thinking is harder to crack. Still, this will open up new horizons, and make it even easier for you to accept new technologies. This way you will always stay current.

Conclusion

In conclusion, Art of War is one cool book. Nevertheless, the real goal is to get yourself in the right mindset and make good software. Experiment and find what works best for you.

Read more posts from the author at Rubik’s Code.

This work is licensed under a Creative Commons Attribution 4.0 International License.

CodeProject