I am definitely not talking about the Resilience of your code. But the biggest mental muscle that defines the difference between failure and success.
Resilience is also a very personal definition. Resilience has a very different context and behavior for a doctor versus a sports professional. For the former, it means the slow and attentive approach to treat the patient, Versus the more aggressive and fast action of the player.
I recently attended a training on Building Resilience where resilience was compared to a slinky. I thought that was so apt to what goes in the life of a programmer. There were many times early in my career when I would give up on a solution after hours of debugging a problem and go to bed resolving to ask for help the next day. But only to jump up in the bed at dawn with a brand new idea of how to solve the issue. Many times, these solutions were my best ideas. I am not saying asking for help is bad but the surge of energy and enthusiasm I have felt after solving challenges is what the fun of being a programmer is about. Don’t you agree?
So how does a programmer tone this mental muscle every day? Few things come to mind.
- The tenacity of Constant learning and implementing best practices. It needs a lot of self-discipline and tenacity to keep learning new languages and/or tools. One trick I have learned is to follow few prominent people who are constantly innovating out and look into where they were spending time.
2. Being able to see things from different viewpoints is vital to solving the problem at hand. Nothing depicts this idea more than this video. If the QA of your team cannot get the intentions right how would the end consumer or software? Strive to be concise and clear to make sure everyone understands what is being solved. Do not shy away from a second attempt at design and solving the challenge.
3. Trying to design better solutions rather than complaining about the current issues. The bigger the organization you work for, the lesser is the autonomy of the Programmer. This has been my truth not sure about exceptions out there. So even with restrictions, always try to understand the design or come up with a better one in your head/paper. This develops the muscle of thinking outside the box which is basically resilience innovating out and prepares you for the future roles.
4. Bad code is not a permanent state. Code can be refactored and repurposed. With the new tools and utilities builtin with code editors, it is amazing how a single click can take out the manual changing across multiple files which was so common a decade ago. This also helps with the constant changing of code based on feedback or peer reviews. Peer reviewing is not about critiquing each other's code but rather your backup system to eliminate honest mistakes and it is your duty to build up such a backup system in real working environments.
5. Failed code only means we get to do it again with a better outcome. Ability to honestly accept the failure of a code or project to yourself is the hardest thing to do but also the most liberating. The faster we can accept failure, the sooner we can get to the right path of solving the problem or challenge. But I am also not suggesting declaring to the world you have failed. Instead, come back with proof on a better working solution or design and that is how we bounce back from failure in the real world.
Conclusion:-
Never give up because there are hurdles to autonomy, bad code, or complex problems to solve. Be the water that flows through rocks. I will leave you with the quote below.
