I heard someone at the 2020 DevOps Enterprise Summit conference say that quality needs to be built in. That's something that many, or hopefully most, of us believe. Everyone ought to do quality work and build it into their daily tasks. However, the person speaking went further and defined this in a way I like:

"Building quality in means we don't pass quality issues along to others."

That's a much better definition for me. This implies that there are effects if I don't do a good enough job. If I knowingly pass along an issue, that's a problem. I haven't done quality work. I'd likely say that if I don't bother to test or evaluate my work in some way, I'm essentially doing the same thing.

We all write poor code, or do a job poorly at times. Often this comes because of ignorance, naivety, or just a lack of skill. That's understandable, and we can forgive a person not being able or ready to do a job at the same level as a more experienced person.

However, that should be a learning and teaching moment. We don't expect continuous quality issues, certainly not of the same type. A big part of the DevOps movement, and other modern software development methodologies is learning from our mistakes. Getting better. Improving the quality of our software.

Don't just get work done. Don't just close tickets or move a sticky note. Learn to do better each time you make a mistake. Learn to write better code or implement better processes. Learn to build in quality.