Be a rubber ducky, find a rubber ducky
One thing that every programmer will face in their career is being stuck on a problem. This could happen once a week, once a month or one a year, but at some point, it will happen. Your first reaction is to stay at work till it's solved, you can’t go home because then you’ll just continue to think about it. You don’t really want to stay because you’ve already been at work for 10 hours, trying to finish this all day. You should leave, go home, there’s a great chance that the break you get while you’re at home will allow your mind to solve it, or think of another way to solve it. Better yet, as you sleep your brain will continue to work on the problem when you go back to it in the morning, you quite possibly could have the answer or another path to try.
These techniques work often but sometimes you’ve just been staring at the problem for too long. This is when your rubber duck comes into play. In the book the pragmatic programmer which I would highly recommend reading if you haven’t done so already. The author talks about the developer who would carry around a rubber duck, it did make the person look slightly mad but it forced them to explain line by line what their code did. This process often forces you to see your mistakes, the mistakes you make that you keep glossing over as you read over it again and again. Really you’re not reading it again and again, you’re actually skimming it, trying to find anything obvious. However, when you're forced to explain it line by line to another person or yellow duck, you pick up on the small mistakes, the silly errors which are actually causing the issues. If your rubber duck can also program that helps as well, this is great for when you talk to another developer and are forced to explain how your code works, not only do you get the benefit of explaining it line by line, but you also allow them to help you. They could quite possibly think of something that you’ve never thought of before as was the case at my job recently.
Another developer in the team was having issues with his tests, the class he was trying to mock was returning a proxy object in Java. This was really racking his brain, he was vastly more senior than I, yet was stuck for a few days on the problem, he bit the bullet and asked for help. In 30 minutes I found the issue that allowed him to move onto the next stage, it was something I’d never dealt with before but my fresh perspective with no previous knowledge of the system allowed me to perform a few quick google searches that revealed information that solved the issue. I learnt two things recently, a good senior developer won’t be afraid to ask for help and talking out your problem with someone else or letting them take a look at you’re code can solve your problem. If your team supports it you should spend some time even if it's just a code review talking through what you’ve done, how you understand the problem, how you’re going to solve it, then how you did solve it and what you’re thought process was. This will produce a greater understanding of your own code as well as others, it will reduce the number of bugs and most importantly it will give other people in your team exposure to different parts of the system so that they have some experience with it when they need to fix it.
Thanks for reading, I would highly reccomend the book I talked about above, The Pragmatic Programmer, its an easy read, but extremely helpful beneficial, I learnt a lot.
I’m always learning something new and with Pluralsight I can have unlimited access to all things programming. But hold on, it’s not just programming. There’s photoshop, visual communication, manufacturing and design. There's a whole bunch! Sign up today and get a free 10-day trial!