content: update content message

contents/blog/micro-dollar/index.mdx

@@ -13,7 +13,7 @@ For example:
 - USD$1.23 = 1230000 micro USD
 - USD$0.01 = 10000 micro USD
 
-At Unity, we termed it the "micro-dollar," and we use this approach in almost our services, messaging, contracts as a standard for all monetary values.
+I termed it the "micro-dollar," and we use this approach in almost our services, messaging, contracts as a standard for all monetary values.
 
 ![Numbers by Mika Baumeister](./decimal.jpg)
 

contents/blog/realistic-time-estimation-for-project/index.mdx

@@ -15,11 +15,11 @@ In this blog, We're discussing an estimated project timeline to give management
 Here is some idea I use as a sensible default.
 
 - We do need to make it clear between the management level and the engineering team that, Everything we commit is not able to hit it
-- In Unity, we use a concept of P50 .In my understanding as a engineer, It means we have a 50% chance to hit it, and another 50% that we won't.
+- Using a concept of P50 .In my understanding as a engineer, It means we have a 50% chance to hit it, and another 50% that we won't.
 - P50 means a deadline date. For instance, the P50 of this project is 31 January 2023.
 - Before we determine the P50 date, engineers must first complete the technical document, conduct extensive research, and speak with stackholders as often as possible to understand what needs to be done. After that, they must divide all tasks into manageable portions, estimate each one (which is much easier and reliable than the big task estimation), and then plan a timeline for their work.
 - In particular, when working with other teams, they must consider the amount of time and effort that will be required from those teams as well as their own current capacity.
-- Engineers must understand fully that they do not spend their days coding. They attend meetings, do ad hoc work, or sometimes have incidents (In Unity, we use P0, P1, P2, etc.. as Incident Severity Levels). They might be required to assist other team members or even to work with other teams on projects. They must consider how many actual coding hours they have each day. It will greatly help to increase estimation accuracy.
+- Engineers must understand fully that they do not spend their days coding. They attend meetings, do ad hoc work, or sometimes have incidents (we can call it like P0, P1, P2, SEV1, SEV2, etc.. as Incident Severity Levels). They might be required to assist other team members or even to work with other teams on projects. They must consider how many actual coding hours they have each day. It will greatly help to increase estimation accuracy.
 - Most of the time, It can be difficult to estimate how much time we have for coding. Even though it's impractical, I do advise giving the P50 date a 15-20% buffer. To be clear, It's not a good practice or even a anti-pattern for some organizations, but it just works.
 - Finally, we determine a P50 date and commit to it with the management level, letting them know that "with P50, there is a 50% chance that we will meet the deadline and a 50% chance that we won't."