Today precisely we presented one of the demos that we have programmed for the client. This demo turned out to be the best so far, for the content and the way it was exposed. It consisted of the application covering 80% of the entire scope that was requested, which turned out to be much more attractive to see for the client. The other thing was that we took the client through a very friendly in-app flow that made them feel like they were a real user of the app.
This week being full of teamwork like the others, it is difficult to be putting together the changes that are made to the code without conflicts arising. One way to make this easier on GitHub is to follow the following cycle, which is to pull the base code, do merge with the Branch you are working with, commit this branch after making sure that it had no conflicts and make the pull request in GitHub.
Antifragile is something that can break like anything else, but that is capable of improving over time unlike what is brittle or robust. Something antifragile is like muscles, when exercising muscles break and lose their strength temporarily, but with due rest, they recover and become stronger than they were before. It is something that we can adopt in our way of working, make ourselves antifragile, and make our work also antifragile so that it is durable and capable of adapting to the changes that arise. We are in an industry that evolves and changes exaggeratedly fast compared to others.
In the video of "how do we heal medicine?", he says that you need a pit crew like those in formula one, it is the same in the world of software development, creating things as gigantic as the codes of some systems or websites it is very important that everyone who is working on that code at the same time is in perfect sync and with very good communication to avoid errors and repeat work that someone else is already doing.
Also:
- Ability to recognize success and failure.
- Come up with solutions to problems.
- Implement those solutions.
This week we have been using a lot of continous integration. In my opinion, it was when we stopped learning a bit and started to work with the foundations that we had developed in the previous weeks. We began to add many functionalities to the project, many daily pull requests with corrections or new things that had to be added. This meant that we were continually testing and reviewing the code among ourselves.
At the beginning of the project, I felt somewhat uncomfortable working in a code as broad as that of a project of this type, but as the days went by I was feeling more and more comfortable navigating between so many lines and so many files that make up the entire project.