The Battle Hardened Developer by Fiodar Sazanavets

Sandor Dargo - Oct 8 '22 - - Dev Community

The Battle Hardened Developer is a very useful book - in my opinion - not only for developers. The author, Fiodar Sazanavets, covers topics that are important for everyone who has an office job (even if it's a remote one). How to restrict social media in our days, and how to create environments where we keep getting messages that improve us are key to survival and success.

The techniques to get into the flow and defeat procrastination are very practical. Even if you already read similar books, this is a good one that will summarize the techniques, probably give some new ideas and will also enrich your reading list via its recommendations. A recommended read!

Echo chambers, friend or foe?

With the emergence of social media, it's probably even easier to find ourselves in an echo chamber where only hear opinions that are similar to ours. It's easy to think that every (sane) person thinks as we do and we end up with our view all around.

While it's dangerous, there are also two other aspects.

As the Stoic wisdom says, you become what you give your attention to. And that is what sensitisation is about. To keep bombing you with ideas that you don't agree with and probably even despise so that you become more favourable little by little. That's an artificial and very-planned modification of your views which is normally not something you want. While it's useful to see other points, you should not focus on that in your daily work life.

If you have to face opinions that you're not favourable of, especially if it's phrased in a bit aggressive way, you'll be upset, you'll use and lose your focus. That's something to avoid. Even for the cost of not being exposed to different ideas.

Last but not least, an echo chamber can be useful. If you keep yourself surrounded by positive ideas, by messages about best practices, you'll make those ideas part of yourself. You'll also learn and use those best practices, you'll become a better professional.

You should actively create such an echo chamber around yourself.

Monk mentality

Monk mentality is not about praying and religious content. It can be, but that's not the point.

Monks have a routine that plans (almost) the whole day and focuses on self-improvement in well-formed echo chambers. Their routine mostly removes mundane decisions and even improvisation as most things must be done in a specific prescribed way.

Having all the activities planned is not enough, all the items have to have a purpose. Therefore they can completely eliminate distractions that would prevent them from reaching their goals.

That's something to consider as a developer. No doubt that having a routine is useful. It's better to do something for a short time regularly than do it only once every once in a while.

The slow and steady wins the race, right?

It's better to work out every day for half an hour than to work out only once a week but for 4 hours. It's the same with almost everything. So plan your day, have a routine and remove those small tiring decisions about what to do next. You look at your schedule and you know exactly what is next. Goodbye decision fatigue.

Dedicate time to your health, dedicate time to learn, handle e-mails and do uninterrupted work...

Make sure that all these planned activities have a purpose. Like studying C++ so that you can do your job better - given that you work or want to work with C++. Studying technologies that have nothing to do with your work and you don't plan to use, has no purpose. Studying is not l'art pour l'art, it must have a purpose.

But it doesn't mean that it must be something productive. You can and should plan chill time. Time when you don't expect from yourself anything productive. You need to release the pressure and have some leisure. If you plan it, then you make sure it will happen, but also that you won't spend too much time on it.

Whenever you plan something, ask yourself if it helps you achieve your goals. If not, eliminate it. If yes, do it with all your focus.

Shisa Kanko

Shisa Kanko is a Japanese technique that translates to "Pointing and Calling". In Japan, they started to use this technique originally in manufacturing and in the railway. It aims to drastically reduce the chance of failure in repetitive manual tasks. It requires the workers to say out loud what they do and also to point at the object they are dealing with.

For example, train drivers wouldn't simply look at the speedometer and check the speed of the train. The driver would point a finger at the speedometer and would verbally describe what he or she is doing and in addition, would also announce the current speed.

The author suggests using this technique to use in software development. Of course, the idea is not to read out loud all the code that you write, but rather to use it when you write boilerplate code or when you do some mundane tasks. Don't just simply run the tests, but get used to saying "TESTS PASSING", don't simply commit, but declare loudly that "INFORMATIVE COMMIT MESSAGE WRITTEN", etc.

It's an exciting technique to consider. If you work in an office, you can either share it with your colleagues or maybe not do that so loudly.

Conclusion

The Battle Hardened Developer is a useful book both to start and to push you further on the productivity journey. Whatever you do, the techniques presented in the book, will make you a better professional. Becoming dedicated to self-improvement, surrounding ourselves with positive messages and getting more focused on our tasks cannot help anyone, right? A recommended read!

Connect deeper

If you liked this article, please

  • hit on the like button,
  • subscribe to my newsletter
  • and let's connect on Twitter! by Fiodar Sazanavets" date: 2022-X-X category: books tags: [cpp, beginners] excerpt_separator: <!--more--> --- The Battle Hardened Developer is a very useful book - in my opinion - not only for developers. The author, Fiodar Sazanavets, covers topics that are important for everyone who has an office job (even if it's a remote one). How to restrict social media from our daily work life, how to create environments where we keep getting messages that improve us are key to survive and succeed. The techniques to get into the flow and defeat procrastination are very practical. Even if you already read similar books, this is a good one that will summarize the techniques, probably give some new ideas and will also enrich your reading list via its recommendations. A recommended read!

Echo chambers, friend or foe?

With the emerge of social media, it's probably even easier to find ourselves in an echo chamber where hear only opinions that are similar to ours. It's easy think that every (sane) person thinks like we do and we end up with our opinion all around.

While it's dangerous, there are also two other aspects.

As the Stoic wisdowm says, you become what you give your attention to. And that is what sensibilisation is about. To keep bombing you with ideas that you don't agree with and probably even despise so that you become more favourable little by little. That's an artifical and very-planned modification of your views which is normally not something you want. While it's useful to see other points, you should not focus on that in your daily work life.

If you have to face opinions that you're not favourable of, espeicilally if it's phrased in a bit agressive way, you'll be upset, you'll use and lose your focus. That's something to avoid. Even for the cost of not being exposed to different ideas.

Last but not least, an echo chamber can be useful. If you keep yourself surrounded by positive ideas, by messages about best practices, you'll make those ideas part of yourself. You'll also learn and use those best practices, you'll become a better professional.

You should actively create such an echo chamber around yourself.

Monk mentality

Monk mentality is not about praying and religious content. It can be, but that's not the point.

Monks have a routine that plans (almost) the whole day and it focuses on self-improvement in well-formed echo chambers. Their routine mostly removes mundane decisions and even improvization as most things must be done in a specific prescribed day.

Having all the activities planned is not enough, all the items have to have a purpose. Therefore they can completely eliminate disctractions that would prevent them from reaching their goals.

That's something to consider as a developer. No doubt that having a routine is useful. It's better to do something for a short time regularly than doing it only once every once in a while. The slow and steady wins the race, right? It's better to work out every day for half an hour than working out only once a week but for 4 hours. It's the same with almost everything. So plan your day, have a routine and remove those small tiring decisions about what to do next. You look at your schedule and you know exactly what is next. Goodbye decision fatigue.

Dedicate time for your health, dedicate time for learning, for handling e-mails and to do uninterrupted work...

Make sure that all these planned activities have a purpose. Like studying C++ so that you can do your job better - given that you work or want to work with C++. Studying technologies that have nothing to do with your work and donyou don't plan to use, have no purpose. Studying is not l'art pour l'art, it must have a purpose.

But it doesn't mean that it must be something productive. You can and should plan chill time, time when you don't expect from yourself anything productive. You need to release the pressure and have some leisure. If you plan it, hten you make sure it will happen, but also that you won't spend too much time on it.

Whenever you plan something, ask yourself if it helps you achieveing your goals? If not, eliminate it. If yes, do it with all your focus.

Shisa Kanko

Shisa Kanko is a Japanse technique that translates to "Pointing and Calling". In Japan, they started to use this technique originally in manufacturing and in the railway. It aims to drastically reduce the chance of failure in repetitive manula tasks. It requires thw workers to saying out loud what they do and also to point at the object they are dealing with.

For exaxmple, train drivers wouldn't simply look at the speedometer and check the speed of the train. The driver would point a finger at the speedometer and would verbally describe what he or she is doing and in addition would also announce the current speed.

The author suggests using this technique to use in software development. Of course, the idea is not to read out loud all the code what you write, but rather to use it when you write boilerplate code or when you do some mundane tasks. Don't just simply run the tests, but get used to saying "TESTS PASSING", don't simply commit, but declaring loudly that "INFORMATIVE COMMIT MESSAGE WRITTEN", etc.

It's an interesting technique to consider. If you are working in an office, you can either sahre it with your colleageus or maybe not doing that so loudly.

Conclusion

The Battle Hardened Developer is a useful book both to start and to push you further on the productivity journey. Whatever you do, the techniques presented in the book will make you a better professional. Becoming dedicated to self-improvement, surrounding ourselves with positive messages and getting more focused on our tasks cannot help anyone, right? A recommended read!

Connect deeper

If you liked this article, please

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .