What is engineering culture in a software team today?
When you work in a software team, you should follow team standards. How your team works and communicates is called engineering culture. Let us give you some indicators of good engineering culture in software development.
Nowadays, soft skills are required for every software developer position.
Here is a simple context that shows the importance of soft skills for a developer. Imagine a business requested to develop a distributed application. Every distributed application can’t be developed by a single developer. A software project requires a team of developers, or several teams, divided by their roles. Hence, a developer needs to communicate within a team or with other teams to get the project done on time.
That’s why soft skills are required for engineering positions. A developer needs to deal with work breakdown to follow CI/CD processes designed in a team and strive to do incremental delivery. He or she needs to escalate blockers, delays, and cost ballooning to managers or product owners to solve problems. Everyone in an organization should be on the same page if there are work dependencies between people.
The team cares about incremental delivery
You should think about incremental delivery once you create or maintain software. It’s unfortunate if you are scared to deploy your code to production. It means that the development team is not confident enough about its changes. It can be a lack of tests in the project and the lack of delivery strategy.
Software engineers can write tests and increase coverage, and they need a CI system to automate tests running. It’s a bad idea to run tests on developer’s machines or even do not have tests for your projects.
Once you have chosen a CI/CD system from various options like Circle CI, Travis CI, GitLab CI, and even Jenkins you can use it to set up pipelines. It will give you feedback on what’s going wrong with your changes.
Software teams who use CI/CD in their workflow are more productive because this approach helps them to automate routine tasks and automatically run the following instruments:
- Linters are necessary to ensure that the whole team follows a chosen language style guide. Also, some linters can help you prevent security issues and conduct static code analysis. The reason to have them on your CI/CD pipeline is to have feedback on what goes wrong with code quality.
- Test runners. In my opinion, it must have been in your pipeline. Test runners can save you a lot of time during development
- Build Docker images and automatically upload them to a private or self-hosted docker registry of your choice
- Deployment is a procedure for staging/production environments, based on your git-flow.
A configured pipeline is a great helper for a code review because a lot of things are already automated.
In conclusion, CI/CD pipelines are one of the main indicators for building a Great Engineering Culture in your team. It’s excellent for you if you have it and maintain it, good if you strive to have it and bad if you do not care about it - same thing with a code review.
Design-first approach and documentation
Knowledge management and documentation culture
The more mature the team becomes, the more attention it pays to knowledge sharing. The team tries to document everything useful for the project: incident reports, useful oneliners for the chosen toolchain, architecture maps to understand communication between services, technology stack, and working processes. Clear documentation has these benefits:
- It reduces the time for a new employee's onboarding. A team can delegate it to the documentation. It is unnecessary to talk about company culture, work processes, or work schedules. It’s already documented if you use the knowledge-sharing approach at the organizational scale. For an engineering team, you can reduce the time spent by lead developers to tell about deployment strategy, stack used, and a communication protocol between services with the help of documentation.
- It reduces the time-to-market metric. Once the development team finishes with the project and is ready to deploy it to production, a simple readme file with documentation will be enough. Docker and docker-compose will be helpful too. An ops team will easily deploy it to production with those files.
- It decreases questions to the team, hence saves time to make more valuable work.
It is excellent when developers share their knowledge and keep documentation updated within a team, good if they strive to and bad if they do not care.
Design first approach
Every service begins with API design. A dead service has no API. Competent software engineers strive to document API in the very beginning and share it with other teams. Therefore, other teams will not be dependent on their team. They can generate stub servers to continue their work. It’s good that we have swagger and gRPC for these purposes. Developer teams can have a design meeting, discuss and create API design for a new service. They start to work independently of each other until they reach the integration moment.
This approach helps to speed up development, but it’s too hard to design API on the first try. You should have the following flow to change API design:
- Discuss changes with the team and make sure s they will work (benefit) for you
- Add changes to documentation (swagger or proto file) because you need an approved artifact of your changes.
- Continue to work
The Design-first approach is an optional point in my article, yet from my experience, it speeds up development time (See documentation).
Monitoring and observability
In simple words, observability is your way to see the application’s guts. It’s an important thing when your application goes to production because you need to have “eyes on production” to understand what’s going wrong with your application. Imagine, that you have an outage and you don’t have logs, metrics and you need to figure out what’s going wrong and fix things as soon as possible. It will be really hard for you to achieve it without logs, metrics, and monitoring.
What will make your server observable?
- Proper logs. Logs should give you enough information to figure out what’s going wrong. You can use Elasticsearch + Logstash + Kibana to gather logs from apps in your service.
- Error capturing. One needs to know what errors users face in production and fix them if they exist.
- System metrics. You need to get information about CPU/Network/RAM/Disk usage from the production environment
Also, you can gather application-specific and business metrics. It depends on your domain and programming language. You can find recommendations for your application here.
It’s excellent if the team cares about monitoring and improves the observability of their systems.
Economic thinking
A way of looking at and analyzing the way the world works by comparing the cost of an action with the benefit generated. The study of economics is the process of economic thinking about issues related to the scarcity problem.
The main responsibility of an engineering management team is to deliver value as fast as they can. It means that every member of an engineering team understands the importance of weighting cost and value in decision-making. A single engineer can’t make his own decision about the technological stack used for the application without communicating it within a team. Sometimes it needs to be communicated within a business team or a customer.
Every software team member should clearly understand the value he will deliver while working on the task assigned to him in a chosen issue tracker. If he faces ambiguity he will communicate with responsible persons. It can be a senior engineer, team lead, manager, customer, or business team.
It’s excellent if your team has economic thinking and open communication within a team and between other teams.
Conclusion
I think that the list of indicators was useful for you and I believe that tech companies who have these areas in their engineering team culture are more productive than those who do not. They have a clear vision of what problem they solve, they control the quality of the product, they have open and blameless communication within the team, and they have enough information to understand what’s going wrong with their application on production.
