Skip to main content

Software Engineering Principles

We work in multi-disciplinary, cross-functional, and empowered technology teams. This sometimes means we follow slightly different approaches to delivering value day-to-day. This is great, but as software engineers it's important to have fundamental principles that we can all look to when thinking about how we want to deliver software consistently.

Here are some guiding principles that have been developed by software engineers:

Write simple, high-quality code

It’s ultimately what we’re here to do.

Example: When implementing new features, focus on writing code that is easy to understand and maintain. Avoid unnecessary complexity and adhere to established coding standards.

Prioritise supporter value

Every line of code we write should be with value to the supporter at the forefront of our minds.

Example: Before starting development, consider how your work will impact supporters. Ensure that features align with user needs and provide genuine value.

Embrace collective responsibility

We succeed, fail, and learn with our teams.

Example: Collaborate with team members, share knowledge, and support each other in overcoming challenges.

Mistakes are okay if you learn from them

We should be working in safe spaces, where mistakes are ways of learning.

Example: If an error occurs, conduct a blameless retrospective to understand the root cause and implement improvements.

Seek to improve by trying new things

There will always be a better way of improving your coding ability.

Example: Explore new technologies or methodologies that could enhance your work. Attend workshops or engage in continuous learning opportunities.

Challenge your peers, and prepare to be challenged

We learn from each other when we challenge each other with good intent.

Example: Provide constructive feedback during code reviews and be open to discussions that question existing approaches.

Following these principles isn't mandatory, and most teams are following some or all already. But they should be broad enough to fit into any team without disruption.