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?

496 Words

2017-03-24 16:48 +0000