What does your typical work day as a (software) developer look like?
You probably spend some time writing actual code, a lot of time integrating it with existing systems and finally spend weeks delivering it to production.
In this short post I want to emphasize the importance of unified tooling.
By “tooling” I mean everything — from debuggers to monitoring systems.
By “unified” I mean that the tooling stack is explicitly defined i.e. set as a “standard” across the company.
The working process without “unified tooling” is deplorable. At best you’ll have a long feedback loop and will not be able to scale development of your product, at worst your product quality will suffer. From my professional experience, if you are trying to build a scalable product, you definitely need a unified tooling.
Here are 5 main tips that I have.
1. Consciously spend time on tooling
Here Edmond Lau (The Effective Engineer book) quotes Bobby Jonhsohn (ex Eng.Director of Facebook), who says that the most successful engineers spend third of the time on tools. I just want to add my motto here:
If you did something manually twice — automate it!
2. Continuous integration of the code is a must
Your project is already built automatically on pushing code to the repository? That is great! But do you also run unit tests automatically? What about code linting? Do you also deploy automatically to production? You should do it all. It scales productivity and quality exponentially. Here is a rough list of tools to do CI/CD:
- Gitlab CI/CD
- Github Actions
- CircleCI
- TravisCI
- Jenkins
- Terraform
- Ansible
- many others
3. Create a unified development environment
Consider this — a new developer joins a company and has to setup her/his working environment. How does she/he do that? With a long “how-to” document or senior developer should sit together and do “pair debugging”? Newcomers ideally should be able to compile and test the whole codebase in one day without help. How is this achievable? — tooling! Even with a huge codebase it is possible to do a one-command build/test/run environments. I usually do docker-based isolated environments. Another suggestion here, store all your configuration files (compiler, linter, IDE config, etc.) in git.
4. Create and maintain an example module
To continuously incorporate “best coding” practices, I suggest to have a “golden” example module. This module should be always with up-to-date code and can be copy-pasted when a new feature is started. To advance the example module further, you can write a simple code generation that will generate a real module from this template.
5. Unify your technological stack
Do not start writing tools right away, you may need to first define and unify your stack (OS, middleware, infrastructure, compiler, external dependencies, etc.), you also can write down all those decisions into “coding” or “implementation guidelines”. Good tooling comes easy with a defined stack.
That’s all for today!
