aespinoza

Would you be willing to write an article comparing the results ? Or share the code you used to test? I am super interested in the results of this experiment.

I downloaded it, but I was not even able to get past `Account Set Up`. :(

Under that definition, I wonder if anybody is `creative`. We would need to assess how many of what we call `original ideas` are not rehashes of other ideas.

Greatness comes at a very high cost. But to me greatness is not about money, or economic success. Greatness is a very subjective term.

For me greatness is about mastering my craft. Creating great things. It still comes at a very high cost, because practice is not free, and it takes away time from life, especially family time.

Now, Why? Look at life this way: Humans only care about the experience of life. Experience can be focused on family, money, personal achievements, material things, etc.

What you refer to a `great` experience is not really a `great` experience for another person. So `greatness`, IMHO, refers to the experience you wanna have. My great experience is becoming a master in my craft. That is my image of greatness. To Transcend. I trade time focused on my work, for time doing other things.

Now, there could be a person that has a vision of `greatness` that refers to being the greatest dad ever. That is still greatness. So basically, what I am trying to say is that everyone looks for their version greatness, and that not necessarily matches what you define as greatness.

IMHO mono-repo vs multi-repo should be decided based on the sources of change for each component in a product. For example, the cloud components of a product usually change at the same pace and for the same reasons, it makes sense to have them in a mono-repo. Even in a microservices approach. Even in the cloud certain components can change at a different pace and for different reasons. For example if you have grpc api that talks to your mobile app and a webapi exposed to your customers.

I believe that components that move at a different pace and change for different reason should not be in the same repo. It is difficult to setup CI/CD for different ways of deployment and specially if they not changing at the same time.

Now, regarding security, it is important to keep different components of a product in different repos, this will give you the flexibility to manage a more restricted set of credentials and reduce the number of people that have access to it.

In the end it involved 3 things: 1) Sources of Change, 2) CI/CD Processes and 3) Security. You can definitely mix and match.

I haven't seen any research that has pointed to me to one or the other. I can however give you my own experience.

I have mixed feelings about this. I moved from multiple monitors to one big monitor. I do not see a considerable difference between one or the other.

Obviously this is all subjective so I cannot give you any numbers to back this up. I am however not going back to multiple monitors.