During code review, triage, early stages of sprint development we are so focused on the deliverables that we often forget that our commits, communication, teamwork, and ownership are more than simple roles and responsibilities… they are all part of our development culture.
-
I will ABC (Always Be Collaborative).Do not build in isolation. Collaborate with other developers working on an application, the end user, and the testers. -
I will seek business requirement clarity.Don’t imagine and build. If there is a lack of clarity – discuss, record then build towards the exact business requirement for acceptance. -
I will document my code, for myself and my peers.Self documenting code is a myth. The best developers clearly and thoroughly explain each step of functionality, inputs, outputs, side effects, parameters, and often the reason why the functionality was introduced. -
I will remain focused.Working on various applications in parallel is a sure fire way to become overwhelmed, and potentially introduce one size fits all solutions that don't scale. Tackle development serially in small, achievable blocks of time and code. Break larger tasks into smaller more manageable tasks whenever possible. -
I will avoid shortcuts.Shortcuts have proven overtime to create defect pile-ups. While tasks may take longer, require more code, files, thought, collaboration - doing it immediately with tenacity will spare yourself and your peers from unneeded and unwanted cycle waste. -
I will support the code that I author.As a project grows by feature, fix or, refactor, a developer should take pride in the ownership of the code introduced, and support changes if a peer has difficulty achieving a desired result or if the code introduced requires enhancement. -
I will author code with performance in mind.All of the lazy loading, dynamic invocation, tree-shaking in the world will not convert a slow application into a fast one. Understand the common performance concerns of the architecture, framework, and language and code with these in mind. -
I will code defensively.Remember Murphy's Law : "Anything that can go wrong will go wrong". Programming languages attempt to protect developers from mistakes, and ease complex implementations - but this is happy path. The opposite and or edge cases will happen. -
I will unit test my code.Unit testing builds confidence for refactoring, maintenance, bug fixing, feature introduction, and can do all this locally prior to deployment. When issues are found, write unit tests for those cases as well. Remember, the tests are your safety net. -
I will refactor my code.Refactoring is one of the best practices that all developers must have. Code in most cases can be improved after the first iteration. Upon completion of a deliverable, take the time to analyze what improvements can be made in the next iteration. -
I will be an expert on the fundamentals.Knowing the latest and greatest is fashionable, and adds more tooling to your problem solving arsenal. However, knowledge of the fundamentals often negates the use of a new approach or framework - for something much simpler. -
I will be honest.I don't know everything. My code is not perfect. I need to learn more. I just don't get "this". I think we could collaborate better as a team. There were some issues with your last merge request. I feel that I am not performing at the same level as my peers. I'm awesome! It is healthy to be honest with yourself, your peers, and your leadership. It is just as healthy to accept honesty. -
I will raise awareness to problematic areas in a codebase.Defects and bugs found during sanity testing and or in higher environments are often created by anti-patterns, lack of documentation, happy path programming, indecipherable lengthy implementation, etc. Notify the original / last commit author, team, mark the offending areas with a //TODO:, and create a backlog item. -
I will write clean, readable code.Code is written for humans to read and understand. It is compiled for computers to understand. Taking shortcuts in the code to save a few characters or new lines is an anti-pattern that makes it more difficult for the next developer to read and maintain. "the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...Therefore, making it easy to read makes it easier to write." - Robert C. Martin
