Effectively Contributing To Technical Discussions

No engineer can be truly great working alone. A software engineer can learn from tutorials and build programs, but developing expertise in the field requires sharing, reviewing, and discussing code. This is especially difficult since we talk in a different language than the code itself. Writing and editing code requires if’s, then’s, and for’s, but discussing higher level decisions and architecture goals requires intertwining our every day language with technical terms.

Apart from figuring out how to describe your code, you have to start explaining your decisions and get feedback from colleagues. That’s where you start to run into disagreement, conflict, frustration, indecisiveness, stubbornness, pride, distrust. To be effective in technical discussions, it’s important to lower the probability of those issues and concentrate on the task at hand: making reasonable engineering decisions and coming to a consensus.

The two most important skills in technical discussions should be obvious: speak well and listen well. You have to explain your ideas with structure and clarify, and you have to listen intently to your colleagues with patience and understanding. How to gain these skills isn’t always clear and simple, so here are some specific, actionable strategies to focus your development.

Finish Your Sentence

I apply this phrase metaphorically to most aspects of my life, but it is especially important in technical discussions. It’s easy to get distracted or start another thought mid-sentence as you’re brainstorming new ideas, but it can cause a disjointed, sporadic discussion. Make sure that you finish your train of thought. Make sure that you finish your sentence before moving onto the next idea. This encourages discussing distinct ideas, which will help you define which ideas are better or worse that others. An ill-defined idea of how to implement something will usually lead to muddy code.

Similarly, wait for your colleagues to finish their sentences before you jump in for a new idea, question, or rebuttal. Interrupting is the quickest way to introduce discordance and frustration. If you wouldn’t want to be interrupted, give your colleagues that same courtesy and let them finish their thought before adding your own.

Avoid Demonstratives

I’m talking about this that these those, and similarly vague words, stuff and it. It’s really easy to reason about code by referring to tables, objects, and modules without saying the name. It’s quicker and you know what you’re talking about, but others might not be following what this refers to or what it is.

Vague | “This table is associated to that one, and it’s already associated with the other table.”

Specific | “The products table is associated with the payments table, and the payments table is already associated with the users table.”

While talking with so many specific, repetitive nouns might sound odd in real life conversation, it is immensely helpful in diluting abstract ideas down to specific tables, modules, and functions.

Use The Whiteboard

If you’re only talking to each other, you’re holding representations of the data in your head and drawing virtual lines between them. It’s easy to lose track of multiple implementation options, and the drawings in your head start getting fuzzy, making any concrete decisions impossible.

Start drawing representations on a whiteboard to visually see how many components are being considered, what data is going to live on what object or table. Even if it’s just writing down the name of a module in a square, with arrows to another named module, you’re already giving yourselves a great tool to point at and annotate. When you have the physical representations of your data, you can start using this and that because you can point directly at each representation.

Avoid erasing another implementation considerations. As a rule, I only erase “typos” and mistakes. It could be that your brainstorming sessions need to refer to the previous ideas, and you want to be able to point back to it. Ideally, at the end of a session, you’d have several implementations on the board, and you can physically point to each one and discuss pros and cons. You can circle the winner and get started.

Ask Questions

If you have one person presenting an implementation idea, and everyone gives the thumbs up at the end of the presentation without questions or clarifications, you’re not having a discussion. Approving an idea because you don’t understand the implications results in a false positive. Asking questions allows you to understand the ideas deeper and make an informed decision.

There are some questions that should always be answered when throwing around ideas in a technical discussion:

• How much data are we dealing with?
• What are some of the drawbacks of this implementation?
• How complex is the engineering work?
• How far reaching would these changes be?
• Would this introduce any technical debt?

If the discussion is in response to a prepared presentation, these questions may already be answered. Don’t feel the need to ask unnecessary questions if everyone already understands the concepts and their implications, but asking smaller detail or questions can help solidify everyone’s understanding further. My favorite questions to ask and answer are rephrasing an idea and applying the idea to a concrete example:

Rephrase | “So this implementation would decouple the admin preferences from the user’s account, and instead associate a user with a particular admin account?”

Apply Example | “So if we went this route, we’d remove title, greeting, and photo from the users table, and instead throw those into an admin account table, so we’d only have about ~10 rows in the new table?”

Give Concrete Examples

One of the biggest challenges I face in technical discussions is explaining ethereal concepts. Refactoring, logic changes, and architecture reviews all tend to involve discussing abstractions instead of actionable tasks or sections of code. To bring the abstraction talk back down to earth, it is useful to insert some varying examples of the data that would be affected.

For example, if I’m talking about how to organize some database tables to represent scheduling weekly appointments between users, I’ll include some concrete instances of what we want to account for. I might bring up an example of two users in different timezones: Giles in London and Alex in California. Maybe mention two users having different availability: Mary prefers morning times and Chet prefers evening times. These concrete examples will most likely come out of defined user stories or project specifications, but even if the problem at hand is somewhat undefined, it’s still important to apply the abstract ideas to discrete examples.

This helps in scoping the problem to be solved. Your examples should fit the bounds of the problem. If you are trying to solve a problem at a level of complexity that the data doesn’t require, you may end up over-engineering and creating unnecessary overhead. In the timezone example, we know that we’ll need to consider timezone because of the Giles/Alex pairing, but there’s no example user pairs that require appointment times to carry data more specific than that.

Deliberate Objectively

When someone is reviewing your ideas, it’s easy to take any feedback as a disagreement with your thought process, that your ideas are inherently bad, that your coworkers don’t support you, and that you’re bad engineer. That may be an exaggeration, but sometimes your train of thought can progress that quickly when a discussion is not objective enough. Constructive feedback is difficult to give, but can be much easier when you use measurable metrics that are commonly used to determine code quality. You can relate the usability of an idea to run time, modularity, complexity, extensibility, memory intensiveness, implication of increased coupling.

Using those metrics to discuss ideas will help keep pride out of the conversation, allowing everyone to focus on finding the best solution, not about figuring out who has the best solution. I often hear the word feel in technical discussions, when it doesn’t have much importance or impact:

Emotional | “I feel like using constants isn’t the best way to go.”

Objective | “Using constants might be more efficient than a database lookup during runtime, but manually updating a hard-coded value in the code will require too much overhead, considering how frequently this variable’s value changes.”

To disagree with the emotional response is to disagree with that person’s feelings, whereas disagreeing with the objective response is questioning the specifications of the problem. The latter is more productive for solving the problem at hand.

Wrap It Up

If you’re talking ideas, you could be talking for hours, but engineers are busy people. Things to code, problems to solve. Not every detail of implementation needs to be discussed in the group. Especially when the discussion gets too detailed, some members can start to get bored and spawn smaller group discussions. As soon as conversation starts to diverge, take the lead and wrap it up. Summarize at a high level what you went over, what are next steps, and who’s working on what. Thank your colleagues for their time and productive feedback, and start on your robustly considered but appropriately scoped work.