Recently, in the midst of our busy work-from-home schedules, my husband and I managed to carve out some time over lunch to hang out. On this particular day, he was super frustrated. He hadn’t been sleeping very well because he was agonizing over how he and his team had to cut corners on his current project due to pressure from upper management. It was coming back to haunt him. “There needs to be a greater emphasis on the ethics of software engineering,” he said to me.

How many times have I seen this pattern of behavior in my career? And it’s not just limited to software engineering; it applies to the technology industry as a whole. This can be very frustrating, because often when people try to do the right thing, they’re accused of being naïve, with condescending speeches from senior leadership that begin with, “Well, in the real world…” Nails. On. Chalkboard.

I am absolutely unapologetic about striving to make our technology systems better overall. I know that perfection can never be attained; however, it doesn’t mean that we shouldn’t strive to build good software systems. It doesn’t mean that we shouldn’t do right by our teams and our organizations. And it certainly doesn’t mean that we should exclude quality-of-life from the equation for those building and maintaining our systems.

The more my husband and I talked about this, the more I started thinking about examples in my career that were low on the ethics-o-meter. I would like to share some of these, along with some advice on how we can all do better.

Don’t commoditize your developers

One of the things that I’ve found frustrating over the past twenty years is the increasing commoditization of developers. They are treated as disposable “resources” that can be replaced with other equally disposable “resources”. 

When I first started my career, the company I worked at started all the juniors off as developers. We were expected to pay our dues in the trenches, and then we were rewarded by being promoted to manager within five years.

I’m sorry to say this, but some people have no business touching code, and that’s okay. Similarly some people have no business being managers. Also okay. Different people have different skills and interests. Thinking that you can just turn everyone into a developer is nonsense. Similarly, thinking that you can simply replace one developer with another and expect the same results is nonsense. Remember that developers are individuals. We’re not clones of each other. We think differently, approach problems differently, and have different strengths and weaknesses.

Don’t build the final solution as an extension of the proof-of-concept (POC)

I can’t tell you how many times I’ve seen teams build a proof-of-concept (POC) for something, and get the go-ahead to build the full solution with the caveat that, in order to save on time, the full solution must be an extension of the POC. 

This is never, ever a good idea. POCs are meant to show that an idea works. Which means that when the POC was built, code was quickly thrown together, simplifying assumptions were made, and corners were cut on purpose. Use the POC to learn what went well and what needs improvement, and build a new solution from those learnings. You’ll not only have a more solid product, you’ll also save yourself hours of headaches from having to patch or refactor bad code.

Don’t be afraid to reset

Many years ago, I was managing a small feature release. One of my senior engineers who was tasked with delivering this feature was having a lot of trouble getting it right. He didn’t understand the requirements, and his code didn’t do what it was supposed to do. The demo to the business was embarrassing, to say the least.

After a couple of weeks of this, I decided that we should cut our losses. I pulled him off of the work, and gave the task to a more junior engineer who actually understood what we were building. The next day, my boss reversed my decision, because he was afraid of losing face in front of the business. His decision cost us dearly, as we had to spend twice as much time trying to patch this bad code, than if we’d just gutted it and re-started from scratch. 

The moral of the story: sometimes you have to move backwards in order to move forwards.

Embrace the paradigm shift

I once worked in a company where operations (ops) team members constantly monitored emails after-hours to check if production systems were down. Not because they were on-call, but because they relied on the fact that certain systems went down regularly. They were making so much money in overtime from restarting servers for these flaky systems, that there was no incentive for them to work towards making the underlying systems more resilient. 

What’s worse is that management did nothing about it, because they wanted to “protect their people” by letting them continue with the status quo. Their idea of protection was letting their engineers do the same old thing over and over again because it was in their comfort zone. As a result, they did not innovate, they did not grow, and they did not learn. 

As leaders, we must help guide folks to a better way of doing things.

Take ownership of your code

Software engineers need to take ownership of their own code. It’s no longer okay to just throw your code over the wall to ops and be done with it. Taking ownership of one’s code encourages accountability and encourages developers to up the quality game with their code.

Liz Fong-Jones of Honeycomb put it perfectly in Episode 1 of the On-Call Me Maybe Podcast, when she urged engineers to write their own tests, their own comments, and their own instrumentation. As developers, we know our code best, and are therefore best suited for these tasks. Putting a little tender loving care into your code goes a long way.

Create a safe space

My daughter has to take French as part of her high school curriculum, despite not being particularly fond of learning languages. She was really dreading taking French this year, because her experience with French teachers over the years has been quite negative. She feels frustrated when they insist on speaking only in French in class, especially when she doesn’t know what’s going on.

This year, however, she told me that French is her second-favorite subject. Why? Because her French teacher is open and honest. She takes the time to explain things in English and French, so that the students are not confused. She also confessed to the class that while she had taught French in the past, she hadn’t done so in a while, so they’re on a learning journey together.

I absolutely loved this. By being vulnerable with her students, she created a safe space for learning and a sense of mutual respect, making what would normally be a challenging subject for my daughter, a much more enjoyable experience. 

Our industry could benefit from building similarly safe spaces for engineers to learn new skills without judgment, and by teaching and mentoring junior engineers with greater humility.

Be kind

Systems fail. It’s as inevitable as death and taxes. So when systems fail, resist the urge to start pointing fingers. Attack the issue, not the person. Try to understand why. And most importantly, don’t add more stress to an already stressful situation. This doesn’t help anyone, and it certainly doesn’t help the poor folks trying to bring your systems back online. 

We could all learn a lesson from a hobby of mine: bouldering, a type of rock climbing. I’ve been bouldering for 14 years and I love it because it tests my strength and problem-solving skills. But I also love it because of the amazing, kind, and inclusive bouldering community.

You can go to a bouldering gym just about anywhere, and experience the magic of being encouraged by perfect strangers as you work through a problem on the wall. Even professional boulderers on the world circuit are friends, despite being competitors, and despite being from different countries and cultures. When someone wins, their rivals always congratulate them with great, big heartfelt hugs. I think we could benefit from bringing more of that kindness and love into the tech world.

Don’t let pride get in your way

About eight years ago, I was managing the support team for an in-house application. I was getting frustrated, because developers were pushing poor quality code to production, and my team was the one that was constantly getting called on to fix someone else’s buggy code. This got really annoying after a while, and really affected my team’s morale.

I decided to call a meeting with my manager and his counterpart on the business side, and politely explained that our system was broken, and that we needed to right the ship. I even provided suggestions on how to fix it. This did not go well. They both took offense, because they did not want to admit that things were hobbling along. I thought for sure that I was going to get fired over this, but fortunately, I wasn’t. For all the blowback I got from this, I still don’t regret what I did. I saw a problem, and I wanted to help fix it. 

It’s hard to hear, much less admit that things aren’t going well, but it means that someone cares enough to tell you, and wants to make it better. Listen to them.

Reflections

All this is well and good, but let’s face it. Management, and even our own peers will sometimes push back on us trying to do the right thing. This means that some battles will be won, and some battles will be lost. But for me personally, that won’t stop me from always defaulting to trying to do the right thing. 

If we have enough of us in the industry trying to do the right thing, then maybe, just maybe, we’ll get to a place where “the right thing” is the default behavior. Isn’t that worth fighting for?