Collaborating as a Software Engineer

Collaborating as a Software Engineer

Software Engineering at Google draws a sharp line between "programming" and "software engineering": long-lived systems with many contributors need a code review culture, style guides, design documents, and clear ownership to stay healthy. This is about how individual engineers collaborate within and across teams to keep velocity and quality up over years, not just for the length of one project — including incident response and psychological safety.

Starting Points

• Winters, T., Manshreck, T., & Wright, H. (2020). Software Engineering at Google: Lessons Learned from Programming Over Time. O'Reilly.
• SWEBOK Guide — "Software Engineering Professional Practice" and "Software Engineering Management" chapters.
• Team collaboration and accountability

Key Points

• You explain the difference between "just writing code" and software engineering in this sense, including the impact of long-lived systems with many contributors.
• You participate effectively in code reviews: writing reviewable changes and responding constructively to feedback.
• You contribute to a design document — context, goals, non-goals, proposed design, alternatives, risks — and use it to align with teammates before implementation.
• You apply shared team practices (style guides, testing expectations, documentation norms) and can explain why they matter for scaling engineering work.
• You identify collaboration issues in a team scenario (unclear ownership, poor incident communication, conflicting conventions) and propose grounded improvements.
• You demonstrate behaviours that support psychological safety while maintaining technical rigor.