Well isn’t this the million dollar question? I’m a firm believer that, this needs to be answered to each person in a very individual and personalized manner, there is no golden answer to this, and you should search for an answer by discussing to people who you trust and accept feedback from.
That being said, there is something that worked to a certain extent for everybody who tried it out.
Don’t jump to coding right away. This is a mistake done by many, especially at an early stage of their career. After selecting a task, they jump into carrying out the modifications as much as they can, and after that they improvise the rest, or search for help. A reason for this could be that thinking was done while looking at the code instead of a disconnected manner.
Maybe next time start a task by trying to better visualize the outcome of it. Write out the main changes you intend to do in each component, this can serve as a “checklist” later to verify if you forgot anything.
Try drawing how the information will flow between components, not full fledged UML diagrams, just some boxes and lines on a piece of paper will do.
These practices will help you in many ways, for instance
- You can discover early, which parts of the code you understand, and which parts you don’t. It is a good idea to invest some time to get a deeper understanding of the area you are about to change
- You will get help a lot easier from more experienced peers, when you reach out to them. Your questions will be more coherent, more precise, plus you will gain a lots of points from them for working out a solution, instead of simply asking, “how should I do this?”
- You will explain better. When talking to the project manager, client, even in just simple presentations, describing the issue efficiently can leave a very good impression on others. Remember if you look like a professional and sound like a professional …
Change takes time, so be patient with yourself!