Globant

Being part of a huge team, an ob-boarding is mandatory to explain how everything is done, which tools are used, and how the code is documented, tested, and delivered.

Once everything is set, understanding business logic is crucial to figure out the user faculties and how they interact with the platform.

Adding new features could be risky if we don't have enough context for legacy code to detect failures before production.

Sometimes migrate legacy code to new frameworks is not always 1:1, we need to deeply understand the functionality and the purpose of the task, not just because a framework/tool is new, means we should migrate to it.

Working with both clients I realized that big projects share a large codebase, most of the code are legacy made by people that is not working in there anymore, it is our responsibility to keep documenting our code and features we developed, not only as a comments in the files, but in a common knowledge database like Confluence or wiki platform. I keep saying that it is prefered to do a readable code than a smart one. A high level programming language, like javascript, is for people to read it, not by computers.

Getting approvals from automated tests and coverage rules are just the beginning for a code review. The more we can share and give feedback, the better. Is nice to get an `LGTM` on our pull requests, but not useful at all.

In my team, we invested some time every sprint to develop our own tools to catch and prevent visual and functional failures before committing our code to production, that's why we can save even more time for new features rather than spending it debugging on every deployment.

Tickets refinement is crucial for a healthy sprint, the more we can describe and clarify doubts before assignment, the better.

Sharing our knowledge of a specific subject it's always beneficial for our team members, no matter what, we are a team, and we are there together, the more we share, the better we'll be.