How do you enable better programming culture in teams?

better programming culture in teams

Image copyright belongs to the owner.

In organizations when there are many moving pieces and teams working on a single project, it is important that the technology leadership enforces a better programming culture in teams and standardization of process that the engineering team uses. It is important that the engineering team speaks one language, this is only possible if the leadership understands the language and sets up a better programming culture in teams with supporting structures to help enable the standardization.

Good tech organizations want their teams to write code in a standardized style, they usually make their own standards based on the organizational needs and the product they are developing. This becomes critical when the teams are writing code that is going to scale and serve a large spectrum of possibilities. If the code is not written in a SMART and maintainable manner it can put the entire project in jeopardy. Hence better programming culture in teams is critical if the organization, or product wants to scale.

How can better programming culture in teams help you as an organization?

These standards make sure that the software you work on has the following benefits:


The coding standard gives a unifying appearance to the code programmed by a diverse set of programmers via, multiple teams. This improves readability of the code and reduces complexity. The code is easily reproducible and it reduces the chances of errors and helps them catch easily if any are found. It promotes sound programming practices and increases the efficiency of multiple programming teams.

Effective coding standards

Each organization has different needs for effective coding standards, the tech leadership of an organization should be able and qualified to identify this language the tech organization wants to speak and help them by building support structures around them. This needs to be a bottom-top approach, tech executives should not enforce their thoughts, this should be a very collaborative effort and the viewpoint of every developer should be taken into account.

This list below is my humble effort, of identifying some global level programming standards that I have identified while working with multiple teams. I hope this is helpful.

Usage of global variables

A global variable is a programming language construct, a variable type that is declared outside any function and is accessible to all functions throughout the program. A group of global variables is called a global state or global environment because when combined, they define various aspects of a program or the environment when the program runs.

This standard tells about which data types can and cannot be declared as global types. When a variable is declared global, there is a very high chance that someone else overwrites its value unknowingly. Hence it becomes imperative that the choice of global variables is very deliberate and kept to the very bare minimum.

Naming conventions

A naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types, functions, and other entities in source code and documentation.

Meaningful and understandable variable names help everyone to understand the reason for using it.

Have a set of rules for naming conventions as mentioned above, for example, local variables should be camel-cased and start with a lowercase letter — localVariable, a global variable should always start with an uppercase letter — GlobalVariable and constants should always be named using uppercase letters — CONSTANT.

The names of functions should always be written in camel case starting with small letters, for example — fetchData(){};

The name of the function should describe what it is supposed to do, in the example above it is supposed to fetch data.

Focus on error checking within functions. This is absolutely critical, it also, helps if you have unit test cases.


What is a function?
In programming, a named section of a program that performs a specific task. In this sense, a function is a type of procedure or routine. Some programming languages make a distinction between a function, which returns a value, and a procedure, which performs some operation but does not return a value.

The KISS principle —
The KISS principle states that most systems work best if they are kept simple rather than made complicated. Functions help us to build these systems, while the systems can be complex at times the functions written to build these systems should be simple, small, and effective. Never write lengthy functions.

Lengthy functions become quite difficult to comprehend. Therefore, always try to break a large function into smaller, mini functions. This will help reduce your code complexity and it helps in managing bugs that come out of these smaller function sets.

Any function that grows more than 10–15 lines, needs to be broken down.

DRY principle—
Functions should also be based on DRY principle, we should not be repeating a piece of code that can be reused.

Classes and functions should be small and obey the Single Responsibility Principle (SRP), meaning, functions should do one thing and one thing alone.

Documenting the code

Documentation should be an integral part of your programming, but this documentation should be on a high level and not every function should be documented. Functions keep changing based on the ever-changing landscape of the product. So your functions should be easy to read and should follow the KISS principle so it is easy to read.

Your documentation should always be living and breathing, technology keeps changing very fast and your documentation should adapt to those changes as easily and as effectively your technology does.

If your documentation keeps getting obsolete every now and then, then you are doing something wrong.

Unit test cases

Unit test cases need to be an integral part of writing code. All programmers should use unit test cases to validate and test their code. It helps when the team reviews the code and also, this helps in making reading the code much easier. It also helps, if the unit test cases are developed incrementally in parallel to programming, which will help programmers with their development journey.

Code reviews

Code reviews are an essential piece of the engineering process. It not only helps to share the knowledge between the teams but also allows the programmer to present their point of view and approach towards their solution to the problem. It also facilitates an open line of communication across the team and new perspectives towards the problem.

Asking for code review

Describe the issue you are solving.

Describe the approach you took to resolve the issue and why?

If Bit bucket/git does not display all the files then mention all the files that have been modified and why?

Approving a code review

Describe the issue that you are reviewing the code for?

Verify all files that have been modified.

Approve the changes are in the right files.

Think if there could have been a better way to solve some changes.

Look for edge cases

Make sure the task assigned is working as expected

Explicitly approve the change.

  1. Architecture
  • The code should follow the defined architecture.
  • Separation of Concerns followed multiple layers and tiers as per requirements (Presentation, Logic and Data layers).
  • The code is in sync with existing code patterns/technologies.
  • Design patterns: Use appropriate design pattern (if it helps), after completely understanding the problem and context.
  • Design patterns help us in minimizing the duplication of code and help us write effective functions.

2. Coding best practices

  • Please use variables. No hard coding, use constants/configuration values.
  • Group similar values under an enumeration (enum).
  • Comments — Write comments on why you are doing. Specify any hacks, workaround, and temporary fixes.
  • Avoid multiple if/else blocks. Avoid multiple nested loops.

3. Non-Functional requirements

  • Maintainability (Supportability) — The application should require the least amount of effort to support in the near future. It should be easy to identify and fix a defect.
  • Readability: Code should be self-explanatory. Use appropriate names for variables, functions, and classes. If you are taking more time to understand the code, then either code needs refactoring or at least comments to have to be written to make it clear.
  • Testability: The code should be easy to test. Refactor into a separate function (if required). Use interfaces while talking to other layers, as interfaces can be mocked easily. Try to avoid static functions, singleton classes as these are not easily testable by mocks.
  • Debuggability: Provide support to log the flow of control, parameter data, and exception details to find the root cause easily.
  • Configurability:Keep the configurable values in place (XML file, database table) so that no code changes are required if the data is changed frequently.
  • Reusability
    • DRY (Do not Repeat Yourself) principle: The same code should not be repeated more than twice.
    • Consider reusable services, functions, and components. Keep the code modular.
    • Consider generic functions and classes.
  • Reliability:Exception handling and cleanup
  • Extensibility:Easy to add enhancements with minimal changes to the existing code. One component should be easily replaceable by a better component.
  • Security:Authentication, authorization, input data validation against security threats such as SQL Injections and Cross-Site Scripting (XSS), encrypting the sensitive data (usernames, passwords, credit card information, etc.)
  • Performance
    • Lazy loading, asynchronous and parallel processing.
    • Caching and session/application data.
  • Scalability:Consider if it supports a large user base/data? Can this be deployed into web farms?
  • Usability:Put yourself in the shoes of an end-user and ascertain, if the user interface/API is easy to understand and use. If you are not convinced with the user interface design, then start discussing your ideas with the business analyst.

4. Object-Oriented Analysis and Design (OOAD) Principles

5. Single Responsibility Principle (SRS): Do not place more than one responsibility into a single class or function, refactor into separate classes and functions.

6. Open Closed Principle: While adding new functionality, the existing code should not be modified. New functionality should be written in new classes and functions.

  • The child class should not change the behavior (meaning) of the parent class. The child class can be used as a substitute for a base class.

7. Dependency Injection: Do not hardcode the dependencies, instead inject them.


Quality assurance can very easily become an afterthought. You must understand that true quality assurance does not start when something is ready to be tested — it starts at the conception stage.

A quality mindset must be present throughout every portion of the development cycle: requirements gathering, design, development, and deployment.

Doing the necessary planning across the team allows for smarter, faster, and less tedious product testing. Quality derives not from having certain pairs of eyes on the product for testing once it’s close to deployment — it’s about having everyone’s eyes on the product throughout the process.

Conclusion – better programming culture in teams.

There are a lot more possibilities of streamlining what practices the organization may want to use to standardize their programming practice and process. This should be a bottom-top approach with clear goals to achieve by using the practice chosen. This culture needs to be enforced by the technology executives, without any biases, but with a careful eye towards acknowledging failures and improving the process. It is not about who, but about how. Failure and success are by-products of a process. Build your process and you will build an amazing team and structure around your engineering practice. A better programming culture in teams goes a long way in improving the health of the engineering teams.

Sanksshep Mahendra

Sanksshep Mahendra is a technology executive, he holds a Master's degree from Pratt Institute and executive education from Massachusetts Institute of Technology, in AI, Robotics, and Automation.

5 comments on “How do you enable better programming culture in teams?

  1. Najcenniejszych rzeczy w zyciu nie nabywa sie za pieniadze.

  2. I jak tu nie byc optymista ?. Moi dotychczasowi wrogowie okazali sie — jak dotad — takimi swiniami, jak przewidzialem. S. Lec. Czy znasz podstawowe Techniki Manipulacji ? Thx & Regards… 🙂

  3. Gdy ktos robi Ci kazanie, wysluchaj, usmiechnij sie, skiń glowa, a potem podazaj wlasna droga. Jesli nie zyjesz po swojemu, to tak jakbys nie zyl wcale.

  4. Najlepszym wojownikiem jest ten, kto zdola wroga przemienic w najlepszego przyjaciela. P. Coelho.

Leave a Reply

Your email address will not be published. Required fields are marked *