Five Ways To Make Your Thinking Visible In Engineering Collaboration

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Thinking is an essential part of being an engineer. How can you make your thinking visible to others so that you can collaborate better? We will discuss strategies to make your thinking visible and cover how to implement them effectively.

This talk has been presented at JSNation US 2024, check out the latest edition of this JavaScript Conference.

FAQ

Karen Lee is a software engineer currently working for GitHub. She has been an engineer for four and a half years and previously worked for two education technology companies. Before becoming an engineer, she was a fifth-grade teacher.

The main topic of Karen Lee's presentation is 'Five ways to make your thinking visible in engineering collaboration.'

Making thinking visible in engineering collaboration is important because thinking is an internal process, and when collaborating, sharing ideas helps generate even more great ideas.

Facilitative questions are questions that show interest not only in the answer but also in the thinking process behind it. They encourage individuals to explain their thought process, which is crucial in understanding and collaboration.

To include what they see and know in answers, one should explicitly mention the knowledge and observations they are drawing from, as these are often invisible to others.

The SAIL framework stands for Share, Ask, Ideas, and Learn. It involves a structured approach where a presenter shares their plan, the group asks questions, offers ideas for improvement, and the presenter concludes with what they've learned and potential actions.

Junior engineers can learn from senior engineers by asking facilitative questions, which help them understand the cues and patterns experienced engineers use in their decision-making process.

The leaderless discussion strategy involves using team members' questions to guide the discussion, ensuring everyone gets a chance to ask questions and engage in the conversation.

The ladder of feedback is a five-step process for giving and receiving feedback. It involves clarifying, valuing, raising questions and concerns, suggesting improvements, and showing gratitude for feedback.

To ensure everyone reviews a document using the SAIL strategy, one can link it in multiple places like Slack and remind team members to leave comments, ensuring visibility and engagement.

Karen Li
Karen Li
30 min
18 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hi, everybody. I'm a software engineer sharing five ways to make your thinking visible in engineering collaboration. One of the most effective strategies is asking facilitative questions, which show interest not only in the answer but also in the thinking process behind it. The SAIL framework is effective for collaborating in groups, involving sharing the plan, asking questions, generating ideas, and learning. Knowing your audience and their background knowledge is crucial. The ladder of feedback is a five-step process to provide constructive feedback without making the receiver feel attacked. Making thinking visible in engineering collaboration leads to greater understanding, more collaboration, and growth for the team.

1. Introduction to Making Thinking Visible

Short description:

Hi, everybody. I'm a software engineer sharing five ways to make your thinking visible in engineering collaboration. I have experience as a teacher and now as an engineer, and I've found that the thinking strategies I used in the classroom can be applied in the workplace with some adjustments. One of the most effective strategies is asking facilitative questions, which show interest not only in the answer, but also in the thinking process behind it. These questions start with 'what makes you' and encourage others to explain their thinking.

Hi, everybody. I'm so happy to see you all here. Also, hi to those of you who are joining me online. My name is Karen Lee. I'm a software engineer currently working for GitHub and today I will be sharing with you five ways to make your thinking visible in engineering collaboration.

Before we get started, let me quickly introduce myself so you know where my perspective is coming from. I have been an engineer for four and a half years and previously I worked for two education technology companies. Before becoming an engineer, I was a fifth grade teacher who taught reading, math, science, and social studies. And a fun fact about myself is that I was a pianist. I've been playing with keyboards all my life. I started off with the black and white ones and now I'm playing with the computer ones.

So let's get back to our topic for today. Ways to make our thinking visible in engineering collaboration. Why do we need that? Let's think for a second. But while you're thinking, I'm going to share with you where did I get this inspiration from? When I was teaching in the classroom, I had to implement a lot of thinking strategies to get my students to think and ask questions. And when I became an engineer, I realized that some of these strategies are also applicable in the engineering workplace as long as I make some tweaks to them. So I decided to create this presentation to share all of them with you.

Back to our question. Why do we need to make our thinking visible? We need to make our thinking visible because thinking is an internal process. It happens in our brains and others cannot see it. But when we are collaborating with others, we want to see those ideas so that we can share and generate even more great ideas. That's why we want to make our thinking visible. The number one thing I learned from teaching on how to do that is to ask facilitative questions. Facilitative questions are the kinds of questions where when you ask somebody, you're showing them that you're not only interested in how and in their answer, but also how they get to it. And this will in turn, encourage them to explain their thinking process. How does that question look like? Well, a very easy way to do it is to start your question with what makes you dot, dot, dot. The three dots represents the action that you wanted to learn more about. So say if you wanted to know why somebody said something, you can ask them what makes you say that. Or if you're reviewing PR and somebody adds a timeout somewhere, you can ask what makes you add a timeout here, etc. Facilitative questions are very helpful when you want to know more about someone's thinking process.

2. Strategies for Visible Thinking

Short description:

You can use facilitative questions to get clarification and solve problems. The second strategy is to include what you see and know, as these are invisible to others. By explaining your thinking process and including internal knowledge, others can better understand your perspective. Combining the two strategies, asking what you saw or knew, can further enhance the effectiveness of facilitative questions. This is especially useful for junior engineers to learn from more experienced team members.

You can use them when you're reviewing PRs, when you want to get clarification on someone's action, or even when you're trying to help other solve problems, you can ask this kind of questions.

Now, what if somebody asks you a facilitative question? How can you make sure that your answer, your thinking is visible in your answer? Introducing the second strategy, include what you see and know. What you see and what you know are invisible to others unless you explicitly mention them. Since thinking is an internal process, we are constantly drawing from this invisible knowledge. If you really want someone to follow your thinking process, they need to see what we see and know what we know in order for that to happen.

Now, how does that look like? Let's look at a scenario. Let's say we are a team that is trying to select a feature flagging provider. There's an engineer in charge that is tasked with researching two companies, company A and company B. This person needs to give a recommendation on which one is better. The engineer in charge says, I'm recommending company A over B for our feature flagging tool. Some team member asks, what made you choose A over B? Notice that's a facilitative question right there. How can engineer A answer this question to review their thinking? Now let me give you a bad example. A is just better. Now, can you really tell why they decided that A is better? Not really, right? So let's try again. We can do better. How about this? I see that A has most of the features we need and a much lower cost. There's also a workaround for the one missing use case. Therefore, I chose A over B. The fact that A has most of the features we need and a lower cost and the fact that also we have a workaround are all the internal knowledge that the engineer is drawing from to get to this conclusion. Others might not be aware of this. That's why when you're explaining a thinking process, you need to include these things that you know and you see. The strategy of including what you see and know is very useful in many situations. Whether or not you're answering questions, you're explaining your thought process, or even if you're giving feedback to others, you can use this strategy.

Now before we move on to the next one, I want to show you a way that we can combine the two strategies that we just learned to supercharge a facilitative question. Now, sometimes if we ask someone a facilitative question, they will explain their thought process, but they may not always include what they saw or knew that led them down a specific path. Instead of asking, what made you do that, we can ask, what did you see, or what did you know that made you do that? By combining the two strategies, we can prompt the other person to include their internal knowledge when they are explaining their thought process. That way, not only do we understand how did they get their answer, but also we learn about the cues that they refer to when they get to that answer. Do we have any junior engineers in the room here? If you're a junior engineer, this is a great question to ask your senior engineers, or really anybody on your team. Because folks on your team who are more advanced have a lot of these cues in their toolbox. They have experience and exposure in the system that they just recognize these patterns.

3. Group-Specific Strategies: SAIL Framework

Short description:

When collaborating in groups, the SAIL framework is effective. It involves sharing the plan, asking questions, generating ideas, and learning. Discussions and feedback can occur through shared documents and team meetings. The goal is to provide a structure that encourages everyone to share their ideas. Writing-specific considerations are important to ensure clear understanding and interpretation of the text.

When you ask these questions, you're not only learning how they get to the answer, but you're also learning the cues that your senior engineers are using. Now we just talked about these two strategies. They work in many different settings, but particularly well when we have one-on-one collaboration.

But obviously, engineering collaboration can also happen in groups. So let's talk about some group-specific strategies. I have two of them for you. The first one is called SAIL, the SAIL framework, which stands for Share, Ask, Ideas, and Learn. And this is how it works. It starts off with the presenter sharing their plan. Then the group can ask questions about the plan. Then the group offers ideas on how to improve. And finally, the presenter will conclude what they've learned and what they might do moving forward.

Now let's look at an example. Say you have a team, an engineer is in charge of a POC. They did the work, and they wanted to share with the team and get some discussions going. The leader will share their findings in a Google Doc, and the team can ask questions about the doc. They might leave some of those questions in the comments, and some discussions can start there. Then the team finds the time to get together and talk about the plan, talk about ideas to improve. And finally, the leader will conclude the meeting with some of the things that they might do moving forward. Now depending on the responses as well as the complexity of your project, this process might have to happen multiple times. You might have to repeat some of the steps, and that is okay. The goal is to make sure that there's some sort of a structure that allows everybody to share their ideas.

When we're implementing the SAIL framework, the first step in the framework is very important. That is because it introduces everyone to the topic so that they can participate in the remaining steps. And most of the time, a plan will be shared in writing. So let's talk about some writing-specific considerations that will set you and everyone on your team for success. When we communicate through writing, we are relying on the reader's reading comprehension ability to interpret our text. Their interpretation of the text comes from making connection between the text and their prior knowledge on the topic. And since everyone's prior knowledge on the topic can differ, their interpretation can also differ. So if we want to make sure that people interpret the text exactly the way we want, we need to think about these three things.

4. Audience and Leaderless Discussions

Short description:

Knowing your audience and their background knowledge is crucial. Define key concepts and include goal and non-goal of the document. The SAIL framework aids collaboration with a leader. Leaderless discussions rely on team members' questions. Consider time limits and prior knowledge for effective engagement.

First of all, who's the audience? Knowing who your audience is will help you to decide what words to use. Also, we need to know what topics do you expect the readers to know already before reading your content? And if your document will be read by people from different backgrounds, say in different departments, you might want to include some definitions of key concepts or keywords to make sure that everybody has the same background knowledge and understanding.

Finally, what is the goal and non-goal of the document? The reason why this is important is because readers make connections between the text and what they know on the topic, and their exposure to the topic could come from a variety of experience. When you share with them what your goal and non-goal is, it helps them to set some boundaries around what type of prior knowledge should they be making a connection with the text that you wrote, which will help them to come up with a more accurate understanding of the text.

By sharing the plan in a well-written document in step one, it sets a good foundation for everyone in the group, and this will enable every member to share and engage in the discussions. This framework is useful whenever you have a leader in a group. Discussing POCs is one of them. If you have project management groups, cross-functional collaboration, those are all scenarios where you can use this framework. Sometimes, when we have discussions, we have a leader, but other times we might have discussions where there is no leader. It's kind of like this, where everybody just goes in the same direction, but no leader. How can we make sure that even when we have such a loose process, we can still make everybody's thinking visible?

Introducing the fourth strategy, the leaderless discussion. In a leaderless discussion, we use the team members' questions to guide the discussion. We start off with the team agreeing on a topic, then everyone brings one or two questions into the discussion, and then the team will just go through each of the questions. Sounds very simple. But there are some things to consider. First of all, we want to make sure that everybody gets their chance to ask the question. If you have a big group, you might want to set a time limit on each person's question so that everybody has their chance. Or, if you meet online, some people can post their questions in the chats and have those answered there, so that everyone will still have the opportunity to ask the questions. The second thing to consider is that the kinds of questions you can ask are largely dependent on what is your prior knowledge on the topic.

5. Engaging Discussions and Giving Feedback

Short description:

When facilitating discussions, ensure everyone can engage by pre-submitting questions. Use the leaderless discussion strategy for brainstorming and collaboration. The ladder of feedback is a five-step process to provide constructive feedback without making the receiver feel attacked.

So, if you're a junior engineer, you might be asking more factual questions because you don't know much about the topic, whereas if you're a senior engineer, you might be asking something about the pros and cons of two solutions. If we want to make sure that everyone can engage in the deeper discussions, consider these modifications. First of all, have everybody pre-submit their questions to the document. Then at the start of the meeting, go through all the questions together and identify the ones that provide background information and get those answered first. When we do that, it helps to get everybody on the same page on the topic, and then when we get to the deeper discussions, it encourages everybody in the group to participate.

The steps in the leaderless discussion gives us some guidelines to follow so that even if you don't have a leader leading the process, everybody still has their opportunity to share. Obviously, we can use it in brainstorming, or even if you're working on, say, open source projects or hackathon where everybody just bands together and works on something, you can try this strategy as well.

Now, I have one more strategy to share with you. That has to do with giving and receiving feedback. This can be a little bit sensitive, especially if the person receiving the feedback feels attacked. So how can we make sure that the feedback receiver does not feel that way and can truly benefit from what you're sharing with them? Introducing the ladder of feedback. The ladder of feedback is a five-step process developed by the researchers at Harvard Graduate School of Education, and this is how it works. We start with step one, clarify. You make an effort to understand the work and ask clarifying questions if needed. Step two, value. You acknowledge the good things you see in their work, and you call them out. Step three, questions and concerns. You raise questions and concerns you have about their work. Step four, suggest. This is the last step for the feedback provider. You give suggestion to the feedback partner to let them know how they can improve. And finally, step five, think. As the feedback receiver, you showed gratitude to the feedback provider and share what you have learned. Let's look at an example. Let's say an engineer comes to you and wants you to review their PR. You may want to ask them for clarification on something they did. You can say something like I see that you're using a regic string to validate the input. What made you choose this option? You may notice that I used two strategies at this clarify part. Include what you see and know. That's the first part.

6. Facilitative Questions and Making Thinking Visible

Short description:

When giving feedback, use the ladder of feedback to provide value, raise concerns, and give suggestions. Making thinking visible in engineering collaboration leads to greater understanding, more collaboration, and growth for the team. Connect with the speaker on LinkedIn for further engagement.

And a facilitative question is the second part. Then once you get the clarification you need, you can offer them, you can complete the remaining steps, value, questions, concerns, and suggest. It may sound like this. I tested your solution and it works. That's a value. We might need to reuse this regic somewhere else. That's a concern. Can you move the regics to a shared file? That's a suggestion. Then the feedback receiver will acknowledge your feedback and thank you. They might say something like thanks for the feedback, that's a good callout. I'll fix that right away. Then they fix it, you can give them approval, and we can all move on. The ladder of feedback is useful whenever you need to give feedback to people. PR comments is one of them. But also it's performance review season for a lot of us. So that's also a time that we can leverage this strategy. Or even when you're just giving feedback to others on their day-to-day work. You can use this strategy so that they do not feel attacked and they can truly benefit from what you have to say.

Now, we just went over five strategies on how to make our thinking visible in engineering collaboration. These strategies can work in many different situations, such as one-on-one or group settings. When you can make your thinking visible, others can follow your thought process better, which can lead to greater understanding. And this facilitates more collaboration. And in addition, the more we can make our thinking visible, the easier it will be for others, especially junior members, to learn from each other. And this will help everyone on the team to grow. So I hope you and your team will get to try out some of these strategies soon.

And this brings us to the end of my presentation for today. This is my first time speaking at a tech conference and I'm very excited. I'm also nervous, but I'm so happy that I got to share this with all of you. If you would like to connect with me, you can find me on LinkedIn. My profile name is Karen Lee.

QnA

Discussions in Online and In-Person Settings

Short description:

How to have discussions in online and in-person settings? Strategies can be implemented regardless of the mode of collaboration. Encouraging participation and uplifting quieter voices in collaborative settings.

Thank you so much for joining me today at JS Nation. I do have a bunch of questions I'm going to start with. And I'm just trying to figure out which one I should address. Should I go with the sort of like lightning rod question first? Maybe I will. So I do love the idea of having these sort of discussions to make sure everything is clear and whatnot. How would you go about having these kind of discussions in a current climate right now where there's a lot of it done online, so in a Zoom call, and versus an in-room, in-person, sort of like collaborative kind of discussion? Because I do, you know, I've had both and I remember the last time we did it, I'm like, man, I'm so glad we're all together in this room with this whiteboard kind of kicking it. So how do you feel about that?

That is a great question. And I actually think those strategies work regardless of if it is in person or if it is remote. I have been an engineer for four and a half years. My entire engineering career has been remote. And so I had the experience of implementing some of these strategies in the classroom in person with students, but actually implementing most of them online when I'm interacting with my teammates on Slack and even in Zoom. And what I've noticed is that even though I introduced these strategies very much from an educational perspective, I noticed some of my colleagues who had no background in teaching actually use them when they were communicating with me. And the way I would see it is that their PR comments, for example, would be very clear. They will tell me, oh, I see that you're doing this here. I think maybe you should try this instead. So maybe they're not as structured as the way I listed out just now, but I see the same idea being implemented. And so in that case, I think these strategies can be implemented in all settings. The idea is regardless of which mode of collaboration you're using, ultimately, we all want to make our thinking visible to others so that we can all collaborate better. Okay, thank you.

Here's a question I like. I like them all, by the way. Do you have any advice for encouraging everyone's participation in collaborative settings, especially, specifically for uplifting quieter voices? So someone who's shy or whatnot.

Documenting Thoughts and Encouraging Participation

Short description:

Tips for organizing thoughts when documenting and encouraging participation in collaborative settings. Acknowledge every person in the meeting and call out relevant experiences to foster collaboration. Look for value in individuals even if they have areas for improvement.

So I think off the top of my head right now, I don't have a very good suggestion other than document, document, document. But I think what I found to make documents helpful is that instead of structuring your documents in like long paragraphs, sometimes it is helpful to structure your documents by questions. So just think about if somebody were to go back to this topic a year later, what do they want to know? What are the five questions that they want to know? And can your document answer those five questions? You could just list those five questions from the get go and organize your thought that way. Or if you don't, you can just make sure that whatever you put in your document includes that information. And I think that would be one of my suggestions if we want to organize our thoughts so that we look back to it and we're not like, oh, what did I do here? Thank you.

So when we have a situation like this, I think this reminds me a very classic teacher move, which is you call on some people. The problem with doing that in a workplace is sometimes people feel like they are singled out. So I think this doesn't mean that you shouldn't do it. But the way to do it instead is to frame it in a way to make sure that everybody like if you notice multiple people on your team didn't say something, as a leader, you might want to just acknowledge every single person in the room or in the call and make sure that they had the chance to speak. So that's one way. The other thing that I would consider is if you are the person leading the meeting or if you know that your colleague is working on something not too long ago that is related to the topic that you're discussing and you want to get them to collaborate more, call that out. Because from my experience, I would consider still a junior engineer, junior mid-engineer, sometimes what I notice is that the things that I was thinking about is actually what seniors are thinking about. But I was too scared to talk about it because I thought, oh, maybe like everybody would know this already. And if I share it, it's not contributing. But it turns out it actually is relevant. And I think if somebody else who has worked with me would have maybe called it out, I would feel a lot more comfortable sharing it. And I think that can also help encourage some of the quieter folks in the team to speak up. And just kind of following up on something you just said, I would imagine as well sort of, you know, being a bit more involved might also indicate maybe to some seniors or intermediates in a room that you're, you know, hey, you're constantly thinking, like, you know, kind of thinking out loud and sharing ideas. I would imagine that's positive as well. Yeah. Modeling is a big part of it as well.

Oh, that's a good question. So my first question is going to be, is there anything that person does that you think they should keep doing? Because even if you have nothing good about what they do, let's say, like, they have a lot of mistakes in their changes, they don't document, they don't communicate well, is there anything that they do that you think brings value to the team? Because sometimes some of those values might be a little more, I want to say subtle, but it's just not obvious. Perhaps they are a unique thinker. The way they think, the way they approach a problem or they just, they do things very quickly because they have a set of commands that they are used to using and it's just in their toolbox, they use it so much that they use it without thinking.

Giving Feedback and Document Reviews

Short description:

Giving feedback, acknowledging value even in areas for improvement. Education background and its relation to software development. Encouraging document reviews through reminders and multiple links.

Another question here that's been getting a lot of love. How do you give feedback if you feel you only have bad things to say? Oh, that's a good question. So my first question is going to be, is there anything that person does that you think they should keep doing? Because even if you have nothing good about what they do, let's say, like, they have a lot of mistakes in their changes, they don't document, they don't communicate well, is there anything that they do that you think brings value to the team? Because sometimes some of those values might be a little more, I want to say subtle, but it's just not obvious. Perhaps they are a unique thinker. The way they think, the way they approach a problem or they just, they do things very quickly because they have a set of commands that they are used to using and it's just in their toolbox, they use it so much that they use it without thinking. And that's a good thing. It's just not good because it's almost like they did everything in this black box and nobody knows what happened. And so when we can acknowledge some of those things that it is good in a sense, but it could be better if it is, say, shared with other people or explained a little more, then I think there is at least some room for us to figure out what we can learn, what we can acknowledge or give positive feedback. Because I think ultimately, no matter which team you're working on, there's always something that we can learn from people, even though it's not the obvious, oh, this person codes very fast, or this person comes up with very good quality code, whatever it is, there are things that we can learn and I think it will take a little bit of time to notice those things.

So I have a personal question here I want to ask before I get to the next one. How do you feel your education background brought sort of like, you know, some skills to this position and specifically this talk that you have? That's a very broad question that I feel like I can talk about it for hours. But I think the number one thing I learned from education and how I think it translates to my work today is that when I was an educator, I care a lot about really fulfilling everybody's potential, helping every single student to fulfill their potential. And I think because I had no coding experience when I was teaching, software development felt like just a black box. I was thinking how, how do I do this? I studied piano performance in college. Like my last math class was in high school. How could I even do this? But then as I continued on my journey in software development, I've noticed that software is this tool that allows people to create things and to fulfill their potential just in a different way. Instead of just learning things, you're building things. And so I think that is very similar and it motivates me.

Now this will be the last question. And it's the following, when using the sales strategy, what things should we consider to make sure everyone reviews the document? So depending on your team, if you are on Slack, linking it in Slack, I think when I think about my team as an example, if I want to make sure somebody will read my document, I will actually DM them and I will remind them to leave comments. I understand the challenge because it can be and we have so many of them. So depending on how your team organizes your documents as well, I would encourage people to include the link of the document in multiple places. Because one of the experiences I had before is I wrote a document about an issue. I thought everybody read it, but they didn't. It was in the issue and somebody went into the meeting asking questions that you're just like, yeah, you did not read it at all. And so when that happens, it frustrates me a little, but I also think that maybe sometimes, especially if you work with people who are outside of your team, if you have cross collaboration, it might help to just tell them exactly where the link is because they might not be used to where things are. So overall, maybe a little bit more reminders would be my suggestion. Awesome. Thank you very much for your time. There were a lot of questions, so I would suggest that I'm assuming because you shared your information, if you do want to ask some additional questions to Karen, I guess hit you on LinkedIn. Is that correct? Yes. And that being said, once again, I do want to thank you for your time. Congratulations on your first talk. Did she do well or what?

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Impact: Growing as an Engineer
React Summit 2022React Summit 2022
26 min
Impact: Growing as an Engineer
Top ContentPremium
This Talk explores the concepts of impact and growth in software engineering. It emphasizes the importance of finding ways to make the impossible possible and the role of mastery in expanding one's sphere of impact. The Talk also highlights the significance of understanding business problems and fostering a culture of collaboration and innovation. Effective communication, accountability, and decision-making are essential skills for engineers, and setting goals and finding sponsors can help drive career growth. Feedback, goal setting, and stepping outside of comfort zones are crucial for personal development and growth. Taking responsibility for one's own growth and finding opportunities for impact are key themes discussed in the Talk.
On Becoming a Tech Lead
TechLead Conference 2023TechLead Conference 2023
24 min
On Becoming a Tech Lead
Top ContentPremium
The role of a Tech Lead involves shaping the roadmap, helping the team be more effective, and working on important projects. Lessons learned include encouraging idea sharing, avoiding taking on all the work, and focusing on delegation. Tech Leads focus on the outcome, involve the team in decision-making, and make plans based on how different pieces will interact. The role of a Tech Lead is to focus on engineering and guide the team in figuring out how the whole system should fit together. Architecting can become problematic when it loses touch with the coding part, resulting in implementation issues.
Effective Communication for Engineers
TechLead Conference 2023TechLead Conference 2023
36 min
Effective Communication for Engineers
Top ContentPremium
Today's Talk covers the four building blocks of communication: people, message, context, and effective listening. It emphasizes the importance of considering the perspective of others and tailoring messages to the recipient. The Talk discusses different types and channels of communication, and the need to align them with the intended message. It also highlights the significance of soft skills in communication and provides techniques for effective communication and assessing soft skills in tech interviews. Cross-cultural communication and the impact of bluntness are explored as well.
Imposter Syndrome-Driven Development
TechLead Conference 2023TechLead Conference 2023
31 min
Imposter Syndrome-Driven Development
Imposter syndrome is a common experience that can lead to self-doubt and feeling like a fraud. The speaker shares their personal journey with imposter syndrome in school and throughout their career in software development. They discuss the challenges and doubts they faced, as well as the strategies they used to overcome imposter syndrome. The importance of support from managers, celebrating achievements, and sharing experiences to help others are highlighted. The talk emphasizes the need to embrace imposter syndrome and use it as a motivator for personal growth.
Adapting to the Future of Work in Tech
C3 Dev Festival 2024C3 Dev Festival 2024
28 min
Adapting to the Future of Work in Tech
The Talk explores the AI-assisted programming paradigm shift and the evolution of software engineering. It discusses the limitations of large language models (LLMs) and highlights the importance of balancing forces in software engineering. The future of programming is seen as models solving problems based on datasets. The Talk emphasizes the responsibility of creating a better future and the need to strike a balance between utilizing tools and building problem-solving skills. It also touches on the human dependence on AI and recommends resources for further learning.
You Do Have Time to Build it Twice
React Summit 2022React Summit 2022
21 min
You Do Have Time to Build it Twice
Top Content
Today's Talk focuses on software rewrites, specifically the transition from jQuery to React. The speaker shares their experience of rewriting a jQuery app to React, highlighting the benefits of the rewrite in terms of improved user experience and increased conversions. Approaches to software rewrites are discussed, including the page-by-page approach which allows for product innovation. The speaker emphasizes the importance of prioritizing rewrites or refactors for startups. The Talk concludes with insights on testing, server-side functionality, and the overall value of the rewrite.

Workshops on related topic

How To Design A Sustainable Freelance/Contracting Career
Node Congress 2022Node Congress 2022
39 min
How To Design A Sustainable Freelance/Contracting Career
Workshop
Shane Ketterman
Alexander Weekes
2 authors
Ready to kickstart your freelance career or just getting started on your freelance journey? You’re in the right spot. Learn the tricks of the trade from the industry’s most experienced freelancers.
The independent talent movement is the future of work. If you’re considering leaving full-time employment for a career as a freelancer, now is the time to find your successful space in the independent talent workforce. More people are working freelance today than ever before, with the freelance marketplace now contributing $1.2 trillion to the US economy. Some of the most in-demand roles for freelancers right now are senior developers with professional experience in React, Python, Blockchain, QA, and Node.js.
This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing/contracting career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Designing A Sustainable Freelance Career
React Advanced 2021React Advanced 2021
145 min
Designing A Sustainable Freelance Career
Workshop
Alexander Weekes
Rodrigo Donini
2 authors
Would you like to pursue your passions and have more control over your career? Would you like schedule and location flexibility and project variety? Would you like the stability of working full-time and getting paid consistently? Thousands of companies have embraced remote work and realize that they have access to a global talent pool. This is advantageous for anyone who has considered or is currently considering freelance work.>> Submit your interest on becoming a freelance engineer with Toptal and get a call with Talent Acquisition specialist <<

Freelancing is no longer an unstable career choice.

This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Table of contents

Module 1: Dispelling common myths about freelancing
Module 2: What does freelancing look like in 2021 and beyond
Module 3: Freelancing choices and what to look for (and what to avoid)
Module 4: Benefits of freelancing from a freelancer + case study
BREAK
Module 6: How to get started freelancing (experience, resume, preparation)
Module 7: Common paths to full-time freelancing
Module 8: Essentials: setting your rate and getting work
Module 9: Next steps: networking with peers, upskilling, changing the world
Module 10: Freelancer AMA