Three principles that Google Software Engineer follow

Where is the information from?

An ACM tech talk entitled "Software Engineering at Google" talks about three fundamental principles for Software Engineers working at Google. The speaker was Titus Winter, a Senior Software Engineer at Google.

The three principles:

The three principles mentioned in the Talk were Time, Scale, and Tradeoffs. Some key point for Time was that software engineers should always keep in mind the software's expected lifespan since they should understand that long lifespans are rare, hard to plan for, and not well understood. Even sustainable code is capable of change, and sustainable code is hard to go. So, try to maintain software perfect now instead of making software that can stay for a decade.

The second principle, Scale is how the software work in each stage of develement. The talk mentions how important a Weekly merge meeting is; a weekly merge meeting will make long-lived dev and manage risk happen. However, the conference also noted that no merge meeting would fix merge commit and end long last dev that could be wasting money. Another critical point of Scale is that be mindful of the cost to build the software because if a software engineer maintains and good Scale and Time on the system, it will lead to cheaper and higher fidelity.

The last principle, Tradeoffs is like what between Time and Scale. Make Tradeoffs to create software with Good Time and (Scale on the left). The main tradeoff of advice is to make evidence-based decisions, Aim for sustainability, and re-evaluate as needed.

As a result, always keep in mind the Time, Scale, and Tradeoffs the software can bring when creating it. Always consider how the Time will impact the system, be mindful of the system in Scale with super-linear, and make evidence-based decisions as a tradeoff.

What I agree and am confused about

I mostly agree with the principle of Time; creating software that makes sense and is more apparent than software that can stay for a long time since the software will always fall as Time passes. For example, a lot of software is created for online shopping, but maybe a decade from now, online shopping will not be a thing anymore. I was confused about how the Scale works in the talks since I have not worked on projects that costs money to build. As the talks mentioned, weekly merge meetings have a plus and minus, but I believe weekly merge meetings will help reduce merge conflicts and reduce the Time the project takes because I have experienced a project with a small group without weekly meetings for the first few weeks it was a nightmare, the team was confused what branch to commit and commit have conflicts.

After the talks, I found being a software engineer is not just knowing how to code or build software, but you need to keep in mind the cost, time, and tradeoffs you are willing to make for the software.