| Good for you for recognizing that you are not performing to the standard that you know you can. Now it's up to you to use your tools and team to improve. First of all, there is probably a style guide for your programming language at your company. Read it front to back. Your IDE may be configurable to automatically bring code up to these standards. "Look and feel" and using consistent language features are very important for others to be able to easily digest your code and be comfortable with it. Second, there are likely resources for learning your common libraries (like your RPC and presentation libraries for example). Go through those thoroughly. Make sure you understand the common patterns and how they are used in the product you are working on. Apply this learning to your design before you start writing code. Now that you have context, look at the specific feedback you've received and look for resources internally and externally for how to improve the issues that have been raised. Have you been misusing language features? Writing incorrect unit tests? Improperly using abstractions? Scoping functions incorrectly? Make sure that the feedback you've received follows the style guide and tool use cases. Come up with a plan to address the legitimate issues. As others have mentioned, writing a checklist of pre-review items and doing your own code review is indispensable, as well as learning how to make use of any integration testing environments and debuggers that you have access to. Finally, ask your team leadership for help. Have a chat with your manager. Do this after you have done the research so you have some specific examples of mistakes you've made in the context of coding practices at your company and your plans to address them, including asking for specific mentorship prior to implementation, like design review. Why to ask for management's help and not go to the devs directly? your performance is their job - where a senior dev may not realize it's their job to mentor you until the manager asks them to. Letting your team leadership know that you are being proactive to address this issue will go a long way and unlock more resources that you need. Design review could be whiteboard sessions but I personally prefer design documents describing what the feature will do, why it is needed, how it will work, and what the implementation milestones are. You bring this to the session for editing/feedback, don't go empty-handed and expect to design stuff on the fly. Regarding your velocity concerns, this will/should come up during your conversations with your manager about your skill development. One good way to improve perceived velocity is to break down features into smaller milestones and complete those at a quicker cadence. Having a design document/review will help do this. Asking how to improve is the first step. Good luck! |
Finally?
Surely the whole purpose of team leadership is to solve exactly this kind of problem. If the leadership is any good then asking for help will be regarded as positive not negative and will one to get expert, targeted, advice.
So instead of 'finally', I would recommended 'initially' or possibly 'immediately'.