What does it mean to be a professional software developer? Does part of it mean putting one's job at risk by eventually saying no to anti-patterns that cause burnout?

I am interested in learning how other software developers answer this question. Please let me know via https://twitter.com/shaunluttin

Keep in mind that I do not often advocate saying no, that my secret job title is code butler, and that one of the tenants is, "A code butler expresses concerns and then lets go." One clear exception is unethical requests. The topic of this blog post is a second exception that relates to burnout. We should say no when...

  1. the client has a requirement that is an established anti-pattern, and
  2. replacing the anti-pattern with an industry recommendation is easy, and
  3. we have already taken steps to suggest the change to the client, and
  4. the client has resisted the change, and
  5. not implementing the change is causing burnout.

How do we know what is an anti-pattern and what the industry recommendation is? Be well read and take an evidence-based or at least industry-standard approach to software development and organization performance. Read Rapid Development, Accelerate, CleanCode, ThoughtWorks Tech Radar, StackOverflow, and related StackExchange forums. Where there is a canonical approach, scientific approach, or an approach that most software developers advocate (or industry legends), then that is the industry recommendation.

How do we know that we're experiencing burnout? The Mayo Clinic offers a good resource.

To make it concrete I will mention a scenario that has been on my mind for a few months. One of the several teams that I am working with requires these anti-patterns: a certain style of code comments, customized and manually formatted code, delayed integration and deployment, and a welter-weight change approval process. I have presented alternatives, the client has resisted change, and I am starting to feel burned out. (Please let me know if you're reading this and are interested in having me send you the research regarding these practices/patterns.)

How does a professional software developer behave in this scenario? In talking to my friends and colleagues, we have categorized four approaches: assertive, aggressive, passive-aggressive, and passive.

  • The assertive approach involves a gradual progression that sometimes ends in saying no and looking for other work all whilst maintaining an alliance with the client.
  • The aggressive approach involves flying off the handle regularly, calling the client stupid and ridiculous, and probably getting fired with cause.
  • The passive-aggressive approach involves saying yes but doing a half-assed job (or conveniently forgetting to do the job) - we get to avoid conflict, continue paying the mortgage, avoid doing the bad practice, and will probably end up getting fired, because our employer will eventually realize.
  • The (somewhat) passive approach: do what we're told - this is the path in which the code butler provides information and then lets go. It's often what I advocate, but not when it leads to burnout.

The assertive approach that I use mimics the boundary setting triangle that I learned while volunteering at the Vancouver Crisis Center. This is how I have adapted it to work as a software developer:

  1. Raise the issue in a casual way. I've noticed that we're spending a lot of time manually formatting code and debating different linting and formatting rules. Adopting opinionated and automated code formatting would increase our velocity by offloading that work to a computer. Then listen and wait. Avoid arguing the point too much. Wait a while, perhaps weeks. If that casual suggestion does not bring change, and if the anti-pattern continues to cause real difficulty, move on to step two.
  2. Write a memo. The memo lays out the evidence from the industry. It provides a link or two to research that informs the practice. After sending the memo, let go. This is hard. Avoid mentioning the issue again until step three. The client probably needs to find zer own reasons for change. This can be like asking a romantic partner to close the lid on the toilet after each use (and no, do not use a memo with a romantic partner). Wait a while (perhaps weeks/months). If that memo does not bring change, and if burnout is starting to set in, then move on to step three.
  3. Set a boundary. I know that manual, custom formatting is important to the company; it's important that I tell you that doing manual formatting is leading to burnout. I need to be using opinionated and automated formatting so that I can focus on work that involves weighing the evidence, thinking through problems, making decisions, and shipping working software. It isn't my place to try to convince you otherwise, only to let you know what is in my scope of practice, and that I have started to look for alternative work.

This third step is one that I only take if burnout is starting to impact me. Usually a single anti-pattern requirement isn't enough to do this, and by the time #3 comes up, there are several anti-patterns that the company is enforcing. At that point, I need to answer a few questions. Am I continuing to provide value to the company? Am I continuing to lead the kind of career that I aspire to lead? And as a friend mentioned, am I being true to myself?

Step 3 reminds me of a joke. A person is talking to a psychologist and says, "My spouse left me." The psychologist responds, "Was that the first symptom?" How does this joke relate to step 3? We're reducing the chance that our finding alternative work will come as a total surprise to the client.

It's worth looking to other professions for answers to these questions. Would a professional massage therapist continue to work with a client who required regular pokes in the eye? What if the massage therapist was starting to feel burned out? Would a professional plumber continue to install lead pipes during new construction? What if doing this started to impact the plumber’s family life? It's at this point that step #3 becomes valuable.

The primary challenge here is not to alienate the employer and to leave on good terms. Sometimes this isn't possible, and it's a risk that we need to take, as professionals, in order to help businesses see software developers as professionals. How do mechanics remain professional? I appreciate that you like loose bolts, but that isn't the type of work we offer. Please come back to us if you decide to do the job safely. The customer might be mildly offended but also might leave thinking, well, that mechanic is a professional and not a crook who is willing to take my money for unprofessional work.

In summary, say yes as best you can to all client requirements - even when you disagree with them, provide an alternative and then let go. When burnout starts to creep in, though, consider saying no for your own benefit.