At Clarabridge, we are committed to cultivating a diverse community. For that reason, we wholeheartedly support the mission of HackYourFuture Belgium, the coding school for refugees and newcomers in Belgium.

In April the Clarabridge frontend development team supported students from HackYourFuture in their quest to learn React. A band of volunteer Clarabridge frontend developers Thomas, CΓ©dric, Ben, Jens and Albert helped out the students with software bugs, questions, and advice throughout the week.

πŸ‘¨πŸ½β€πŸŽ“ Clarabridge learned

"When one teaches, two learn." - Robert Heinlein

At the start, we mainly expected questions or struggles with the higher-level concepts. Although we sometimes struggled with higher-level concepts, students hit a wall more often on practical problems. They had an old software version installed, a rogue plugin in the editor introducing issues, or trouble understanding a vague error message. We will take this insight into account throughout what we develop as a team and don't assume a thing is "easy". We don't want to make something for experts but for everyone.

Controlled failure is a good thing. Failure and problems are a way for people to learn and understand how to improve things. Don't try to achieve perfection but go for progression over time. A practical example here is not to force a concept like Redux on students without showing them the difficulty of state management in React first. Failing to manage the lifecycle of an app correctly is a great learning opportunity.

Mentoring is a skill a lot of developers like to learn, but how do you get started? A project like this, with short-term one-on-one coaching, is excellent. It is a safe space with a limited scope. How do I motivate someone? How do I explain a concept in layman's terms? These skills need practice, and this was an excellent opportunity for us to practice.

πŸ’° Students benefited

By getting to know people within the industry, students can grow their network. After this short term project is over, the connection remains, and students know who to reach out to for career advice or questions. Many students took the opportunity to ask questions like, "What should I learn after React?", "What are essential skills to have if I want to do what you do?".

Most of the Clarabridge developers did pair-programming sessions together with the students. Most of them expressed that it was very insightful seeing how experienced developers tackle a problem, seeing that we use StackOverflow for many things. It puts things into perspective and shows them that what they are learning is valuable.

🀝 Conclusion

The Clarabridge development considers this experiment a great success, and we are looking forward to collaborating with HackYourFuture Belgium again to do more pro bono mentoring for these talented newcomers who are finding their way into the tech world. To the students, may we meet again!

Tags:

In our team, we have discussions all the time. It's a very useful way to get everyone on the same page, or to make decisions that will stick for some time. Here are some strategies that I use to get more out of a discussion.

⚽️ πŸ₯… State your goals

In my experience, the most effective discussions are those that happen because everybody knows why they're there. They know the goal of the discussion before they start thinking and talking. They have a big picture overview. So, when starting a discussion always try to make clear what the problem is, and what the goal is that you want to achieve. This avoids people derailing the conversation on accident because they don't know what you want to achieve. Some examples:

I'd like to discuss the ContentFormatter. We don't think it will stand the test of time.

Okay. Let's assume "the ContentFormatter" is a well-known concept. The discussion can still go all directions. People might start taking out all frustrations they have about this piece of code. This might result in a huge refactor that's not needed. It's not clear what we're trying to achieve with this discussion. Let's try again:

I'd like to talk about the problem we noticed in the ContentFormatter. Every service we support implements their own way of formatting images. I would like to see if we should have a general system for formatting images, or if there is another way of dealing with this so we don't get into problems during the upcoming Project X that will completely change how images are handled in the ContentFormatter.

πŸ•΅οΈβ€β™‚οΈ πŸ“š Be prepared

If you know up front that a discussion is going to take place, it's always useful to prepare yourself a bit. You don't have to know everything. Not everyone taking part will know all details, and the more people know about something, the easier it is to get on the same page. It's harder to come to useful conclusions when nobody knows the details of the problem.

We're thinking about replacing our generator for unique ids because of problems discussed earlier. Does anyone know any good alternatives?

From the get-go, the chances of ending this discussion with a productive solution and within a limited timeframe are low. Nobody is prepared, maybe some people know about all options, but they probably don't know the details from the top of their head. If a decision is made chances are that we missed some crucial information. It might be good to postpone the decision and look up some more information first.

We're thinking about replacing our generator for unique ids because of problems discussed earlier. I did some research and found out there are several options: option a with pros and cons x, option b with pros and cons y and option c with pros and cons z. How do we find out what the best solution is?

In this example there's something to work with. People can consider options because someone listed the pros and cons for them. They can talk about which strategy is best to evaluate options. Even though they might need more info, the chances of making a good decision on the spot are higher.

πŸ‘©β€πŸ« πŸ“ˆ Visualize the problem

There's multiple reasons why this is a crucial tactic:

  • When in a conversation, it often happens that people are talking to each other and they think they agree about a given problem. All parties think they understand. However, the moment you make a visualization (drawing, Miro board, etc...) the discussion intensifies because people don't agree on some details of the drawing. At that point, you found a part of the problem to focus on more.
  • A discussion with just audio is hard to stay concentrated on. People can concentrate much better if they have something relevant to look at. Even seeing the face of the person they're talking to (yes, we're working remotely...) can already help a lot. Now imagine the thing you're looking at also helps you understand the problem at hand! 🀯
  • Just drawing something might sometimes already make a problem glaringly obvious. You have a bottleneck somewhere but don't know where? Draw some dependency lines between involved components and see which component has the most. There are countless problems that become really obvious when you make them visual like this.

😭 🍰 Split Problem and Solution

As I said before, you will come to a better conclusion if the problem at hand is well understood. Therefore, it's important that the problem is discussed, and that all people involved know what they're talking about. In many discussions, people start talking about the solution right away, but forget to define what it actually solves. This is confusing, but also takes away learning opportunities for people who don't know about the problem yet, and it takes away opportunities to get a shared mental model of the problem first. Try to make it very clear that you're trying to find out more about the problem first, and that talking about the solution will be step two.

🌐 🧠 Abuse Cunningham's Law

Cunningham's Law states:

The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer.

You can use this to your advantage if you don't know what the right solution to something is. Just propose a solution that you know will be wrong. This often triggers people with other ideas to bring them up, and thus proposing a good solution. It's definitely a good strategy when trying to get to a shared understanding of a problem as well: draw something that's obviously wrong, and let other people correct you. I think this is why e.g. whiteboarding in a group, and Event Storming work so well.

πŸ‘Ή πŸ‘©β€βš–οΈ Be the Devil's Advocate

Similar to how you might use Cunningham's Law to your advantage, you can also try to play devil's advocate in discussions. It's sometimes very hard for people to express why they think a given solution is better than another one. That's where this tactic comes into play.

πŸ‘¨β€πŸ’»: Let's use Library A, I've often used it in the past and it's just what we need.

πŸ‘Ή: Why, Library B is well-known too and it does the same things as Library A.

πŸ‘¨β€πŸ’»: Yes that's true, but there's a bigger user base for Library A, and its test suite is quite extensive as well.

πŸ‘Ή: To me the code in Library B looks better tested and more robust...

πŸ‘¨β€πŸ’»: Library A has better documentation, though, and it also allows us to do things in parallel, improving performance. The performance will be a crucial factor once we scale this feature up to all our users.

πŸ‘Ή ➑️ πŸ‘©β€πŸ’»: Aha! I didn't think performance would be a problem. It seems you're right about the fact that Library B will struggle on that front. Okay, so if we pick A we have better documentation and tests, a big community if we have any questions, and better performance once we scale up. That sounds great!

As you can see in this simulated conversation, πŸ‘Ή the person playing devil's advocate actually doesn't have a preference for Library B, they just don't see why the other person πŸ‘¨β€πŸ’» is so keen on using Library A. By us presenting another option, the other people are pushed a little bit to come up with good reasons why Library A is the better choice here. Like this everyone participating knows why a given decision will be made.

A note of caution here, playing devil's advocate can be too pushy for some people, causing them to let go of their standpoint because they don't immediately find the words to explain the why of their choice. If you notice this (be quick about it) let everyone know you're playing this devil's advocate role to find out the why, and that you're not trying to convince them of your own standpoint. In some groups of people, you can just do it up front:

πŸ‘©β€πŸ’» ➑️ πŸ‘Ή: I'm going to play devil's advocate for a second... Why aren't we picking library B?

πŸ‘₯ πŸ’¬ Practice Paraphrasing

A very commonly cited strategy for better understanding what someone means is to paraphrase what they said, even if you think you understood correctly.

πŸ‘±β€β™€οΈ : I think we'll have to shut down our data collection systems for that upgrade

πŸ§”: Do you mean that to be able to do the Elasticsearch upgrade, we'll have to stop fetching Facebook data?

πŸ‘±β€β™€οΈ : I was talking about the MySQL upgrade. The Elasticsearch upgrade is planned for next week.

πŸ§”: Okay, I forgot about that. So to upgrade MySQL we'll stop fetching Facebook data?

πŸ‘±β€β™€οΈ : Yes, in fact, we only have to stop processing the webhooks queue for Twitter and Facebook. We can keep receiving them and they'll just be waiting to be processed later.

By simply paraphrasing what was said, we resolved two or three misunderstandings. The power of this is immense, but it's sometimes hard to do. You'll need to be a very active listener, and try to put your assumptions on the side. Also, obviously, you'll have to speak up if you're not sure about something that was said.

That said, I see similarities between paraphrasing, Cunningham's Law, and the "making things visual" strategies. They all try to achieve the common goal of having a better shared understanding of something.

⏱ πŸ’¬ Postpone decisions

I said it earlier, but this is a very valuable tactic in many situations. Even during programming, you can use this so that you can think about one problem at a time. You build something, and instead of worrying about e.g. the storage mechanism you're going to use, you program against an interface. That way, you can later decide how to implement the storage interface when you know more.

The same thing is true in discussions. If you want to decide on something, you can make assumptions, document them, and make the decision based on that. You can verify your assumptions later and reevaluate where needed. What you can also do is to "decide" that you need more background information to make an actual decision, and plan a follow-up discussion after everyone has had the time to look things up.

This is something I learnt when I was studying to become a teacher. Nobody expects you to know everything, so you can just admit that you need to look things up and then postpone the decision. This will highly likely lead to more sound decisions than making them on the spot without having enough information available.

πŸ™Š 🀫 Activate silent people

Meetings often end up in a few people talking, and other people silently following along. In theory this is no problem for the actual discussion, but in practice, I find that the silent people often do have an opinion and just aren't vocalizing it. It might be because they're not feeling safe, they're not experts in the thing that's discussed or that they just don't think their "crazy" opinion is worth exploring. I do think that all people need to be heard. To help them, you can ask everybody for their opinion explicitly.

πŸ§”: Do you agree that using Library A would be better than Library B, Tania πŸ‘©?

πŸ‘©: I think the performance impact is indeed the crucial factor in this decision, so yes

πŸ§”: What about you, George πŸ‘¨β€πŸ¦°? You're frowning, is there something we forgot?

If Tania πŸ‘© and George πŸ‘¨β€πŸ¦° were silent for some time, you could try to involve them like this. Most of the time this works, and if you do this often, people will start to participate more without help, because they know their opinion is valued.

Another word of caution here: just like "playing the devil's advocate", this might be a bit pushy for some people, and they'll feel like they're put on the spot. In any discussion it's beneficial to have a safe environment where people aren't punished for what they say. When it's okay to change your opinion, make mistakes, and try things, we'll come to much better conclusions in the end.

πŸ—£ πŸ“ Document what was said

When the discussion is over, try to document what was said. It doesn't need to be word-for-word texts, but just something to look back on 2 weeks later and remember what was said, if decisions were made, and why they were made like this. There are multiple ways of doing this, but one of the most interesting things is ADRs. If that's too formal for you, don't worry. Anything will do really. Just write something down to look back on. By the way, this is another opportunity to get feedback by paraphrasing!

πŸ–– πŸ™‡β€β™‚οΈ Outro

That's it for this post, thanks for reading all the way through to the end! I'm definitely not an expert in leading conversations and I have my flaws (some of them have remedies listed in this post). All of us have a lot to learn, and hopefully these strategies help you to get the most out of your discussions! See you in the next post! πŸ‘‹

Tags: