This is the third part of the series: How to survive and thrive – a series for new developers to become better at their jobs. You can read the first two parts here and here.
In military, there is a term of “uphill battle”. That when you have to fight your way up a hill, when you enemy controls the top. It’s a very difficult fight and your chance of success is low. Any experienced military leader knows uphill battles are something you should avoid until there are no other options.
That also applies with any jobs. Including programming.
The truth is, you shouldn’t fight the battles you can’t win.
There is nothing wrong with trying something you don’t know, or don’t know well – it’s always a learning process. But you have to know your limits. Don’t be Don Quixote fighting the windmill.
Again, there is nothing wrong with losing a battle. A good working environment is a place where failures are accepted as a part of the job. But a string of failures will nonetheless questionable. It’s not just about you looking bad, it will undoubtedly affect your morale. It might also slow the whole team down when you become the bottleneck.
Of course you can be exceptional and you can impress your boss and your colleagues by doing the impossible. But in most of the cases, we are not exceptional. We can be good, very good even, but exceptional is rare. To be effective, we have to accept who we are, and what we can do, and what we cannot.
It’s also nothing wrong with retreating from a battle. As they always said – live to fight another day. Learn when you have to ask for help, or to walk away from a task.
The way I used to do it is when I’m interested in a work item, but I have no idea on doing it (completely new to me, or not in my areas of expertise), and my first try fails miserably, I will back down, and change to watch mode instead. I will come back later when someone took that work item and did it. I can just review the code to see how they did it, and if there is something I don’t understand, I can ask them to explain to me, briefly. That way, I don’t slow anyone down, yet I can learn something useful about the stuff I didn’t know, or didn’t know well, so I can do something on my own the next time.
That did not come easy. I had to learn to swallow my pride, and know the line between what I can do, and cannot, at least not without help.
My best advice to you is to start with small things, learn fast, stand on the shoulder of the ones more experienced than you, and watch how they work/think.
Some might argue that in such cases, pair programming can be a solution. Pair programming can be a very good way for knowledge transfer, but it does not always work well for me. If we already know what we are going to build, and have fairly good idea how to build it, pair programming can work pretty well. But if we are deep in the unknown, we don’t even know what is wrong, then pair programming can really slow me down. I find it’s hard to think, try that thought, and explain that thought, all at the same time. It works much better if we discuss the solution before hand, one of us does it themselves, and we come back for a review. Your mileage might vary, as always. There is no one thing that fits all sizes.
