11 Opportunities for Better Conversations
Whitney Meers wrote an article that produced an interesting conversation in my employer’s engineering Slack channel. The article presented a sarcastic take on “11 Things Developers Love Hearing From Non-Developer Co-Workers.” The conversation this inspired between myself and some coworkers was how could these eleven comments be addressed in more constructive ways, instead of letting them foster feelings of frustration.
Developers, You’re People Too
Something that a lot of developers seem to forget from time to time is that, they are people too. This comes out in occasional lapses in empathy, compassion, and common courtesy. Sure, building software can be hard work, but so can everything else anyone else working in your organization does. So, developers, remember that you’re a human being, and try to behave like a decent one.
Developers, They’re People Too
On the other side, Non-developers, don’t lose sight of the humanity of the developers you work with. This can come out in unrealistic expectations around work schedule, the ease of what they do, and countless other things. The work that developers do is valuable, and just as integral to your organization’s success as the hard work you put in. So, non-developers, treat your developers as human beings by being courteous in how you work with them.
Being Helpful, Instead of Annoyed
At the heart of Whitney Meers’ original article was a catalog of the kinds of comments that often annoy developers. At the heart of these comments are various kinds of misconceptions, good intentions, differing perceptions, and occasionally divergent priorities. Developers need to learn to adapt the technical work they do to the variety of non-technical stakeholders. This means that there is a need for developers to seek to be helpful, and informative instead of letting themselves get annoyed.
Below I am going to go back through each of the example comments and offer up my thoughts on how turn them into opportunities to have better conversations. The goal in every case is to avoid succumbing to being annoyed, and instead seek a shared understanding of the issues involved in order to move towards working together more effectively.
“This change shouldn’t take more than a few minutes.”
When this kind of comment comes from someone who does not work in the code involved it is an opportunity to better understand each other. In my experience when this sort of comment gets made it is because the non-developer is thinking only about how the change appears from a user perspective. There is often an assumption that if something appears simple from one vantage point it must be simple from every other perspective. With software this is rarely the case. Simplicity for an end user often requires a fair amount of complexity to achieve. But, this is only apparent from one vantage point. A great way to turn this into a productive conversation is to ask the follow-up question “what leads you to that conclusion?” It’s important in the growth of a developer to learn how to take the time to clarify the kinds of misconceptions instead of becoming frustrated by people who have a lack of necessary perspective.
“Let’s have a meeting!”
Maybe this is a horrible idea, or maybe not. If the meeting is about discussing project constraints, requirements, or anything else that would effect the developers work, then this invitation to a conversation is worth your time. Otherwise, maybe to you should ask what they would like you to be ready to contribute to the meeting. Not all meetings are bad, sometimes they are downright necessary.
“Don’t worry too much about security… it’s not like we’re going to get hacked or anything.”
Maybe the person offering this comment is right. In some circumstances, robust security measures are not primary requirements, or even secondary. But, if the a piece of software is exposed to the public Internet, in any way, there is a lack of adequate understanding that deserves gentle correction. But, as a developer there’s also a responsibility to help find the right balance of security with other priorities. Two-Factor Authentication is probably not necessary for a web site Contact Us form. So, while being mindful of security is appropriate, treating it as a higher priority than it truly is is certainly not.
“There’s no requirements doc, but I’m sure you can figure it out.”
How many times has an upfront requirements document captured the full scope of a project? In my experience, the answer is never. So, this kind of comment is an incredible opportunity. This is an invitation to an agile process with a short feedback loop, and a focus on delivering value iteratively with as little cruft as possible. This is a great time to talk with the stakeholder who has expressed confidence in the developer’s abilities about how to ensure the project gets figured out well. Identify a cadence to talk about what is needed in an incremental approach to the project, and how to keep the stakeholder involved with each step of the process. Maybe get a copy of Practices of an Agile Developer and give it a read, and include the stakeholder if possible.
“I know I’m not a developer, but I think you should use this framework my cousin mentioned…”
Maybe you should think about this framework. Part of being a developer is coming up with ways to examine technical choices, and make appropriate decisions. Sure, this person doesn’t know how to articulate the merits of the technology they are proposing; but you should be able to do that. This could also be a chance to discuss the top priorities of the project to see if they align well with this proposed technology in comparison to what you normally use. Don’t short-circuit a chance to get more insight into the project, and why someone else might have spotted something that you missed.
“I took the liberty of updating the codebase myself.”
Cool! Sit down with that person right there and go over their changes. Make sure they meet any standards of quality that exist, and if they don’t help this eager coworker bring the work up to the appropriate state. This person took initiative for some reason, and instead of guarding “your code” like some kind of maniacal troll guarding its bridge, look for a chance to show appreciation for someone helping out.
“We don’t need your input because you’re not a creative.”
This is a condescending comment, and any response needs to avoid the same kind of animosity. One way to address this line of thinking is to propose that you’re input isn’t primarily about the creative aspects of the project but the projects technical feasibility. Try to explain that the value of having a developer involved in project planning early will help ensure no promises are made to clients, or other stakeholders, that can’t be realistically met.
“The client needs this to work on IE 6.”
Good! Better to know this now than after a bunch of work has been done that is incompatible with an important technical constraint. If this comment annoys you as a developer, then you need to find something else to work on. Client constraints are meaningful, and entirely your job to accommodate. If you have the time and expertise, you might be able to look into working with the client to loosen this constraint. But, if it is a firm requirement, then thank whomever you please; namely the client, and your coworker, for telling you this critical information.
“We don’t want to pay for the software you need to license, so why don’t you just build it yourself?”
OK! This is a business constraint, and it may be unreasonable. Maybe there’s an open source solution that is good enough. Maybe, there’s an opportunity to build just what is needed for the project. Or, maybe this is revealing that the project is not realistic. As a technical resource, developers have a unique roles to play in software projects. Look for ways to adapt to this constraint, and be honest if it makes the project infeasible. Sometimes being a developer is hard, but so is the job of the accountant who may have made this call.
“I know you’ve been working on it for a year, but we’re canceling this project.”
Embrace change. Businesses change, contracts get cancelled, and sometimes projects get superseded for no good reason. As a developer you should get comfortable as soon as possible in your career with changing course as a way to respond to the needs of the business you work with. This means getting comfortable deleting your code, deleting other people’s code, and not getting to finish everything you start. The sooner you can become more flexible, the sooner you will become more valuable as a part of your organization.
“We’ve contracted you on this client project… you know ColdFusion, right?”
Assuming there is no reasonable way that the person saying this could have concluded you already had skill with ColdFusion, this is an opportunity to discuss the project. If it’s greenfield, then maybe the language is a nice-to-have, not a must-have requirement. If it’s not a greenfield effort, perhaps what you will need to do can be done without modifying existing systems, and could be developed as a complementary service. And, maybe the situation just plain sucks. In the latter case you still have options, they just become less pleasant. Maybe you could learn something by learning ColdFusion, or maybe it’s time to talk with your organization about including you in the process that leads to contracts being made on the basis of unreasonable assumptions.
At the end of the day, these comments, and others like them, are not things that should annoy developers. They are prompts for productive conversations about how we build software in a responsive way. Sometimes we need to have conversations about process, or expectations, or courtesy. But, the key is to have conversations. Software development should be a humane endeavor, and a big part of facilitating that is having conversations; especially the difficult ones.
