Developer Pride
My development manager recently asked us for input on building an engineering culture at work. I semi-coined a new term: developer pride. The term has gotten bad rep in the past, but I want to reclaim it in the same way the LGBT rights movement transformed the word pride from the negative connotations of being a deadly sin to the antidote to shame. So what does developer pride mean to me?
Developer pride manifests itself through three beliefs:
- I recognize the importance of my work because software underpins the backbone of the organisation.
- I take pride in delivering the best solution I can to realize business value.
- I appreciate my fellow developers as the best technical resource I have. I succeed when they succeed.
How does developer pride translate into practices?
- I take time to ensure my work is correct. “It compiles on my machine” is no longer good enough.
- Are there automated tests? (xUnit, Postman, Selenium)
- Did I manual test it if there are no integration tests?
- Written in a way that other devs can understand? (following code standards)
- Is it documented? (descriptive commit message, Confluence entries, useful comments)
- I put developer ego aside in order to deliver business value.
- I recognize that “good enough”1 code is sufficient as long as it doesn’t create technical debt. There’s no need for an over-architected solution or spending 4 hours reducing a 10-line method down to a one-line statement just so I can demonstrate my code-fu.
- Humans make mistakes. Let’s get on with fixing the problem instead of trying to find someone to blame.
- I am happy to have my code reviewed by my peers, and I will happily do the same for them.
- Code reviews let me see my code from a different viewpoint. I welcome challenges as it may expose a blind spot.
- I do code reviews because I want to learn how other developers approach problems. It is not a fault-finding exercise!
- We review code, not the coder.
- I devote time for continuous personal growth.
- I explore new toolsets and technologies because even the best knives need sharpening.
- I take the chance to observe how the business runs because it provides a level of visibility that Kanban/Scrum backlog stories do not. This helps me deliver better business value.
- I communicate with my colleagues with respect2 because I recognize them as the best in the industry. This is especially pertinent during disagreements, which is common when many smart minds work on the same problem.
1: “good enough” will be defined by agreed design patterns and coding standards. We can fit an entire program into a single procedural Main() method which works but is probably not good enough by our standards.
2: A fantastic model for verbal communication can be found in Crucial Conversations, which I will blog about soon.
I don’t know if the term developer pride will be adopted by the team, but that is how I intend to carry myself. Do you have pride?