Whenever I’m mentoring a more junior member of the software development team, there are always two primary traits that I encourage them to learn. These are traits that transcend programming language, methodology, technical stack or anything else that may be relevant to their role. These are structure and dilligence. Both of these should permeate through everything they do in their every day work. Being mindful of these will help them become better as software developers. I will explain why these traits are so important to the software developer.
Approaching your work with a structured mindset allows you to demarcate and separate out the various elements to the problem you are solving. From grouping the different areas of the requirements specification, to grouping the components and classes in the class hierarchy, to grouping the related unit tests….having structure allows you demarcate the boundaries between these different elements. Everything has a structure. The trick is to clearly define it and communicate this to the rest of the team. If you are documenting the requirements to a piece of functionality, clearly structure the document to demarcate these different areas e.g. functional requirements, non-functional requirements, UI considerations etc. If developing a new component, your class structure should clearly demarcate the different behaviours and areas of responsibility from the class structure and their interactions. Anyone reading through the code should be able to quickly determine what the different classes do and how they relate to each other from the structure you have implemented. Group similarly related elements together and enforce this in your coding standards document. Everything you do should be structured, logical, and consistent.
Approaching your work with due care and dilligence will help in eliminating mistakes and make you a better developer. Be conscientious and mindful of what you are doing at all times. Before checking in that code, make sure you do a diff, run a full rebuild and execute all dirty unit tests. This may take additional time, but it will always be quicker than the time it will take to fix a broken build. If writing a document such as a requirements specification, take the time to proof read it, check it over for spelling and grammar as well as accuracy. Work smart, not fast. Reducing the number of mistakes you make by being more dilligent will earn you a reputation as someone who is dependable, produces high quality and takes their role seriously. Don’t be that person who is known to constantly make mistakes, breaks the build or submits code that doesn’t work because they didn’t test it sufficiently enough.
By applying structure and dilligence to everything you do will have positive benefits on your work. These can be applied irrespective of your particular role (developer, tester, designer) or what tools and / or technologies you use. I would prefer to work with a developer who took these traits seriously than a developer who thinks producing more lines of code than the next developer makes them more productive. I would always pick quality over quantity. A customer is far more likely to forgive a slippage of a dealine if they eventually get something that is of high quality, rather than something delivered on time that contains bugs.
Be structured and dilligent and apply these with rigour and I can guarantee that the quality of the code produced by yourself and your team will increase.