Software Engineering with Go

This course is about software engineering with Go, not programming with Go. If this course were about programming with Go, you could write a solution to each lab, submit it and be done. You would have learnt how to program in Go to complete that lab, and at the end you could call yourself a Go programmer.

But this course is about software engineering, not just programming. This means you write code that:

• is clear, consistent and readable,
• has unit tests,
• others can review without needing to know what you were thinking when you wrote it,
• has an issue or ticket describing what the change is to do and why,
• is well factored into small commits where each commit does one thing only,
• has good descriptive commit messages on each commit that explain the "why" of the change, not just the "what",
• follows practices that are idiomatic to Go and not some other language you may be comfortable with.

It also means you do not just write software, but you also review the software written by others. Coding and review are both practices that a software engineer needs to do, not just coding.

One goal of this Go course is to bootstrap Go development at the bank - to start it at a high standard and maintain that standard. It can be very hard to raise the standard when existing code and practices are of a low standard, so we want to start with a high standard that is the product of good software engineering.

This is the reason the Go course reviewers can sometimes seem to be rather nit-picky about elements of your code, commit, PR or issue that does not seem all that important for a lab exercise. These are more than lab exercises to teach programming Go - they are trying to teach good software engineering practices when programming with Go.