Ravi is a traveler and foodie who loves to visit off-the-beaten-track places and understand the culture, history and customs behind them.
You know that feeling.
You try to implement something which appears to be simple but for some strange reason, it does not work. You try every possible solution; something works but some other thing breaks.
You try multiple workarounds and combinations but the damn thing always fails at some point or the other. You still know that you are very close to the solution and you are missing something really “small” but that minor detail eludes you and frustrates you endlessly.
At this point you are so frustrated you can no longer think about the problem clearly. What should you do at this point? Or what can you do to avoid reaching this point? it’s now been 3 hours when this should have taken you 10 minutes.
That said, to everybody out there in this world who is a non-techie, a developer’s job appears plum and sweet; sitting in plush offices, eating royal meals, and only warming the chair 8 hours a day and getting paid handsomely for it. Except that it is nothing even remotely like that. That is why they say that “behind every good developer is a frustrated developer”. And ever since I got into this programming thing, this frustration has been a part and parcel of my life.
In fact, I have a special motto for these kinds of situations; Be like 300, inspired by the valiant 300 Spartans who fought the Persians in the Battle of Thermopylae – 480 BC. As the story goes, King Leonidas and his 300 Spartans had successfully fought against a much larger Persian force for two days. The brave 300 entered the annals of military history where they are celebrated to this day.
So here is my solution; like the brave 300, I visualize the frustration like a fight and a test of courage and endurance. Even if I am unable to solve the problem then, I prepare myself to “fight another day”.
And here are some ways I use to cope up with programming frustration.
If you’re stuck with a problem, try writing that code as pseudocode down on paper. The reason is when you’re using the paper, you’re more focused on solving the problem rather than worrying about the syntax.
Pseudocode is a term that is often used in programming and algorithm-based outputs. Pseudocode, as the name suggests, is a false code or a representation of code that can be understood by even a layman with some basic programming skills.
There are many benefits of writing pseudocode.
- It gives you a chance to work on pure logic without worrying about programming constructs.
- It helps you to finish your work faster as already you have the basic logical blueprint in place. So once you start with the main code, you have your work cut out.
- The best part is that it is plain English and does not depend on any programming language. The logic you write can be used in literally any language.
- It can be shared with other developers. Once you share it with other developers, you can get multiple minds to think about the problem without worrying about the platform/language on which they are working.
Once you have your train of thought clear and the problem statement worked out in pseudocode, you get more time to work on performance optimization and code factoring aspects.
Recognize your achievements.
Another stumbling block is impostor syndrome. This occurs when developers cannot recognize their own achievements and are constantly afraid of being found out as a fraud.
The problem happens when you externalize your success, crediting other people’s poor judgment or pity for your achievements. You feel like your ability to do meaningful creative work is so transient and fragile that it could soon be gone forever. Perhaps you're not feeling confident in using the technical language or acronyms everyone else seems to be spewing out effortlessly. You feel like a misfit seeing other developers leaping ahead.
Here are some ways to battle impostor syndrome and stop it from interfering with your creative mindset.
- Embrace it — it’s okay to be scared.
- Keep a log of your achievements to remind yourself of your successes (no matter how small).
- Keep a folder of “confidence boosters” (e.g., nice comments people have left on your work)
- Document your processes to stop doubting your methods.
- Avoid Negative people but listen to constructive criticism.
On the end note; it doesn’t matter where you are; what matters is where you want to be and what you’re doing to be there. Don’t let frustration hinder your learning. Be proud of yourself and have the attitude to “challenge yourself” every single day.
Coding is 20% creativity and 80% troubleshooting.
Coding is mostly troubleshooting. Embrace it.
It's not unusual for coding to proceed in a stop-and-go fashion: you proceed full throttle for a while and then hit a roadblock and get stuck for an hour. You clear the roadblock and continue smoothly for a few minutes just to hit another problem. And this goes on and on……
No developer, however whiz kid he/she is, can ever escape troubleshooting. The very essence of good code is to run into a wall every single time.
Some ways to break the wall can be.
Test your assumptions.
Why is it not working? Why are you expecting it to work? Have you verified the assumptions between the code and the problem? Are the prerequisites missing? For example, we often get a null object error while executing SAP smart forms and most of the time the reason is the data not flowing from the form to the SAP server. Somewhere along the way, your expectations will not match the reality; find that mismatch and nail it.
This is not the most dazzling method but sometimes it does make sense to go back to basics and read through the grind to find out where we went wrong. So just take a break and dig into the documentation. You might end up getting pleasantly surprised.
Test-driven development. Test-driven development(TDD) is all about building software in small increments while testing your assumptions along the way. It's a great way to never get stuck in the first place.
Strangle your code.
Martin Fowler calls it StranglerApplication. It’s a way to “strangle” old code parts by rewriting and then, by event interception, calling the new components instead of the old code. The greatest benefit of this method is it reduces risk. You are rewriting the old application in increments while still using the functional tests of your old application because the calling code is still in the old system. So every time a piece of new functionality with good code is ready, we replace it in the old system.
Troubleshooting can feel time-consuming and cumbersome, to begin with, but in the long run, it's a major time saver.
Lastly, play team.
Programmers can be solitary creatures. Programming isn't a team sport but it is clearly a social activity.
That is why we have “teams” dedicated to a particular project. Synergizing always pays off. So it is always better to swallow your pride, shove your ego aside and ask someone. Nothing wrong with it. play the team with your team and make things work together.
And when the heat is on, the deadlines are looming and you are not able to find a way out, pair along with someone on the code. Find an associate who is willing to pair program with you. You will get done faster, with fewer defects. Your pair partner will help you hold on to your disciplines and keep you from panicking.
The quick development time of the pair often comes from an increased focus. Pairing literally is having another person looking over your shoulder all the time. People actively participating in pairing are less likely to be distracted by interruptions (e.g. checking email, mind wandering to unrelated tasks, or blankly staring at the screen for minutes on end).
Even related secondary tasks can be blocked out. The person on the keyboard can focus on just banging out the code, while the partner can worry about readability, testability, robustness, user upgrade migration, and other “big picture” issues related to the new code. Working with a pair provides positive pressure to stay on task.
The adjustment period from solo programming to collaborative programming is like eating a hot pepper. The first time you try it, you may not like it because you are not used to it. However, the more you eat it, the more you like it.
And most important of all it creates a culture of collaboration and gratitude. Next time when you see someone else who’s stuck and overwhelmed with frustration, offer to pair with them. Help them out of the hole they are in; Who knows next time you might be in the same hole!!!
As H.E Luccock has rightly said.
“No one can whistle a symphony. It takes a whole orchestra to play it.”