Values allows a group of people to come together and collaborate, since we humans have the ability to work together more efficiently if we feel a connection in our beliefs and values. Once this connection is established its very easy to strive towards a common goal and become a community.As engineers we work in teams, hence having shared values and passion is very important for the survival and sustainability of the teams.

In this article Dave Cheney is listing Go's core values or guiding principles as Clarity, Simplicity and Productivity.  If we think about these concepts as just principles they seem pretty clear and obvious, not just on a programming or development basis but about anything.  But bringing them in to your work when you are trying to solve a problem or create something new can become quite challenging.  Whole delivery process of the software becomes so focused on timelines and budget that sometime the end result is the only thing that matters and the way its been achieved becomes less important.

Lets think more about these concepts, and try to connect the dots between these principles and their practices. 

Clarity

The word clarity originates from latin work claritas which originated from clarus and it means clear.

When it comes to writing software keeping things clear can become a challenge because of the way the requirements are and the uncertainities around it. As an effort to make things clear common solution that is generally been followed in the industry is to surround the software with lots of documentation, which in the end becomes more of a clutter.

To have clarity about something what we need is context, and that context most of the time will be known only to few people who are closely involved in the design and development process. In an environment where teams, processes and requirements  are changing in a very fast pace, its hard to keep up with these  context changes. So how can we connect this context to the software we write so that it becomes clear and transparent that anyone looking or reading through it can easily understand its purpose?                    The programs we write should be like the books we read, they should be able to tell a story along with solving the problems they are designed to solve. In that way I believe every software engineer also has to be a writer.  

Go's flexibility may at first seem like, is working against this clarity, since its upto the engineer to take decisions around the structure of the application he/she is writing. But functionalities of the language like duck typed interfaces and error handling without exceptions will gaurd the code from having muddy heirachies and complicated mishandled error management. Still it is upto the person who is writing the software to think about the challenges his/her future self and colleagues, are going to face when they will read  and try to maintain the code that he/she is writing. 

Few things to keep in mind which might help to keep clarity in code is : 

• Naming packages, functions and variables properly with context in mind.
• Make use of interfaces as much as possible to describe the behavoiur.
• Having clear comments in the code.
• Connecting code to other sources of documentation (notes from that brainstorming session).
• Having a team or company guideline document that can be referred and quoted during code reviews.
• Being consistent.

Simplicity

We have talk by Rob Pike here in which he explains the thought process he, Robert Greismer and Ken Thompson had when they designed Go langauge. What I am trying to explore here is how we can be inspired by the way Go language is designed and write applications based on the innate simplicity it already has. 

Complexity without clarity is the  enemy of simplicity, what are the things to keep in mind when we design and write applications in Go to avoid this? First place to start is the folder structure of the application. Avoid having heirachial packages, since we have only private and public access modifiers  in Go its better to have fewer packages. Following DRY(Do not Repeat Yourself) principles to an extreme will lead to unwanted complexity, go proverb "Little copying is better than a little dependency" is something we should always keep in mind during development and code reviews. 

The passion and involvement in our work might over the time tie our identity to the code we write. This is very counter productive, and will lead to in ablility to take criticisms and corrections, which makes meetings un productive and long. People try to be clever and smart once their ego is involved, always remember "Clear is better than clever" and "You are not the code you write"

If I list down what we should keep in mind to keep applications simple and  Go's  simplicity principle in practice:

• Do not go over board with your innate drive to categorise and organise.
• Think twice before pulling in a dependency, and be ok to copy code.
• Readability and simplicity should be given prioriy over performance.
• You are not the code you write.
• Refactoring is an iterative process  and is very much part of software engineering.
• Be kind

Productivity

Developer productivity is a hot topic these days. We have a set of good practices and tools in the industry to enable productivity. But are these tools really helping? And is the practices really followed?

Since productivity is very much human related and we humans are quite unique in our own way when it comes to learning and organising it is most of the time un productive to use generalised techiniques and force them upon everyone.

 Along with our varied minds and capabilities time playes a big part in this too, a more experienced engineer might find certain things very productive which a junior might find counter productive. Main features of the language that enable an engineer are :

• Fast compilation
• Single binary creation
• Very effective dependency management
• Lots of literature around the language to help with learning
• A vibrant community