The basis for healthy community dynamics Reflecting back on my career so far, there are some bits of advice I wish I could tell my younger self (like to take a course on compilers š). One of them that Iāve been mulling over recently is more about social dynamics of how we write code within a team and how the code we write is as much of an interaction as a conversation. Iām sure this advice isnāt new but I have yet to find it wrapped up together like I hope to doĀ here. Donāt Break Standards Often when joining a new company, team, or project; we bring a lot of technical baggage with us. The languages we prefer, the frameworks we are comfortable with, the coding-style we like most. If youāre coming into a greenfield project, then you should definitely lay out your opinions and argue for them as your team defines itās standards. But, if you are joining a new team then you should adhere to their standards. Is the standard non-idiomatic? Have languages been chosen you believe to be sub-optimal? As long as the team is achieving its goals and the rest of the team is in agreement with the standards, you should followĀ them. Does this mean you canāt propose changes? No. Of course standards are always in flux, but be considerate. When proposing changes, ensure not to insult the teamās previous choices. Hostility toward existing standards will likely not win you any supporters. Also, itās important that you believe that any changes to the standard you propose will have a positive impact to the teamās goals/objectives. If youāre proposals donāt care true value other than ābeing the right way,ā then you are wasting your teamās time and resources. Donāt BreakĀ Patterns Every application, through itās development and growth, develops itās own patterns. They become the basis for how change is introduced and how future development is done. Always do your best to follow these patterns. Patterns are a form of communication. When we deviate from existing patterns, we are speaking a foreign language than the rest of the code. While contributing new patterns is a natural evolution, individual āsnowflakesā are like ancient Greek in the middle of a modern-day novel. They make no sense; they are confusing; and can be frustrating if forced to read, understand, orĀ change. Donāt Nit Iām guilty of this from time to time, as I think most of us are. A nit, or nitpick, is small comment when looking at someone elseās code, doing a code review, etc. Usually along the lines of āfix indentation hereā or āyou started your { on the wrongĀ line.ā Nits are distracting to meaningful code-reviews and can come across as insulting. Nits not only come across as overly-critical, but also be seen as wasting time with small fixes that do not functionally change the code. Most of all, nits should never exist in the first place. Automated formatters and linters should be employed, along with build-systems to enforce, so that developers can automate the small details and focus efforts, both during writing and reviewing, on meaningful contributions. Always Write Documentation Writing code should always be seen as a way of communicating. This means that we should strive to write clear and concise code; prefer easy to read code over ācleverā solutions. But often, for sufficiently complex or sufficiently large portions of code, that is notĀ enough. Writing documentation ensures that everyone has a shared understanding of how the code works, or at least how it work. This not only saves a lot of time when discussing changes within a group, but also eliminates some contentious moments where opinions differ there is not a shared understanding. should because I should mention that this goes for both new code that you are writing as well as old code that youāve taken the time to understand. Documentation is a way of contributing knowledge to your immediate programming community and is a kind thing to do and we all enjoy random acts of kindness, right?Ā š Always WriteĀ Tests When venturing into the unknown or not-well-known, disagreements can arise as to what a particular bit of code should. Whether it be an undocumented library function or an advanced language feature, it is important that the code does what youĀ expect. Tension here can arise in code-reviews when the reviewer may not share the same opinion of what the code is doing. By writing tests, we are able to prove to others within our group that the code does match any assumptions made. There are many reasons to write tests, this is just one more you can add to yourĀ list. Always HaveĀ Buy-In Remember to be humble. You donāt have all the answers, and you donāt haveĀ to. When making changes that will affect a number of people/teams/systems, it is important to have buy-in. That is, you need to discuss your proposed change (this means before you start coding) and get approval from everyone affected. The reason is to ensure that you arenāt forgetting a use-case that will either be broken with your change or a use-case that is not fully addressed by the change. Buy-in really just means validating our current spec (because we all right specs for our changesā¦ right? š ). Of course, this can slow you down when you will run across those who disagree with your changes. However this isnāt a bad thing, this may just mean that you do not have a shared understanding of theĀ system. Any time you encounter a co-worker that does not share your view of the world (as it relates to your code/software), it is important to discuss. It either means you have a gap in your knowledge (or perspective), or they do. Either way, it is good to discuss and get everyone on the sameĀ page. Why? As software developers, we should be striving to make an impact. To make a difference in the success of the projects we work on. Writing agreeable code ensures that we meet as little resistance as possible, meaning more time for real work; more time for meaningful contributions. Itās also important to remember that we do not write code in silos. We are part of a community, whether it be your team, your company, or open source. The code we write is an expression of ourselves and a form of communication. Agreeable code is a way of engaging in healthy dialogue within your community. It breaks down barriers, builds trust, and fosters kindness. Itās important that we support and foster our community and agreeable code is one way in which we achieve thatĀ goal. I hope youāve enjoyed this article and please leave any comments if youād like to continue discussing. You can keep up to date on the latest posts by following me, , on Medium and please š if you enjoyed theĀ post. John Murray
