Sema software neon logo
Sema software neon logo
Blog
Interviews
 • 
April 20, 2022

Learning in Public for Career Advancement

In this episode of the Open Source Cafe, Matt Van Itallie from Sema shares some of his insights about getting hired, communication best practices and how you can utilise learning in public for career advancement.

 min read

Blog
Interviews
 • 
April 20, 2022

Learning in Public for Career Advancement

In this episode of the Open Source Cafe, Matt Van Itallie from Sema shares some of his insights about getting hired, communication best practices and how you can utilise learning in public for career advancement.

 min read

Video

Community Classroom believes that every student, irrespective of their college or branch, can make it big. Community Classroom is an initiative built on this thought. The organization, founded by Kunal Kushwaha, provides free hands-on training and mentorship in an inclusive community.

Topics covered:

  • Learning in Public
  • Coordinating a global team – and the power of Psychological Safety
  • Giving and Receiving Feedback
  • Getting Started with Learning in Public – Writing and Social Media
  • Getting Started with Learning in Public – Joining the right Community
  • Learning in Public and Career Advancement – in particular through Open Source
  • What Hiring Managers Look For

This conversation has been edited for clarity, context, and annotations.

Introduction

Kunal: Welcome back to another episode of the Open Source Cafe.This is an ongoing series that we have started focused on career development.

Today you can learn about all the amazing years of experiences of Matt Van Itallie of Sema. Today we’re going to ask questions on topics requested by many members of the Community Classroom community, in particular learning in public. 

Before we get started, would you like to tell our viewers a little bit more about yourself?

Matt: Absolutely. Thanks again, Kunal, I had such a pleasure on the Discord chat, I know how much fun this is going to be. 

So I'm Matt Van Itallie. I grew up in a town of about 40,000 people in New York State, a few hours from New York City. I now live in Baltimore, Maryland, which is near Washington, DC. I learned to code when I was five. My parents are coders– my mom was one of the first coders at IBM and then became a math teacher. So we've always had a lot of technology in my family. 

My professional career was spent mostly on the business and the organizational side of code. I put in technology systems at software companies and technology organizations, even working with school districts to use software to help improve teaching and learning. 

After working for many years in and around tech, I really fell in love with and became obsessed with code quality and technical debt. And with helping coders learn more, grow more, and advance their careers. 

One of the things I observed was, so many organizations were trying to treat coders like, let's say, sales people, or people who work on an assembly line. Code is really different. It's a craft, not a competition. 

And so I founded Sema, to work on improving code quality and the craft of coding.

Improving code quality is better for users. And it’s better for coders– because better code is easier to use. And also, better code quality is just the right thing to do. We have an obligation in the coding community, to give back to the code because it's done so much for us. In other words code quality matters for its own sake. 

We’re also helping developers learn more to advance their careers. And hopefully soon enough, we’ll be able to make the interviewing process a little bit better, because we all know it could be a lot better than it is.

Kunal: Yeah, I couldn't agree more. 

About the Sema product

Kunal: Can you tell us a little bit more about the product itself before we move on with the agenda today? 

Matt: Sure. The Sema product is a code review and developer portfolio tool. Right now, it's only available for GitHub, we're going to go to other version control systems soon. 

What it does is make code reviews themselves a little bit more structured, so that they're clear to the audience, to the code author. 

It also creates a dashboard. If you think about all the code reviews you've done, you've probably never looked at those results again– because the data is unstructured. We've built a way by structuring code review data to also create dashboards across all PRs and repositories that are analyzable and explorable. 

Another feature is the ability to take best practices, whether they're from your organization, or whether they're from the community, and insert them into code reviews. We have 20,000 best practices that can be inserted, or you can reuse the comments you would use every day, so you're not reinventing the wheel and retyping the same comment every time. 

And then finally, through these dashboards, you can easily create Developer Portfolios

These Portfolios can be about your own accomplishments – to support a resume, for example. Another use case is to keep track of what you've been working on; some people call that an accomplishment journal, or a brag book. 

But also, you can also create a Portfolio about the code. One of the really cool uses comes from @eddiejaoude of EddieHub, the inclusive Open Source community. Big shout out to him for inventing this use. A Portfolio can serve as a readme file for new engineers to a project. This way it’s not just documentation, and it’s not just “read the code and tell us what you think.” Instead, it’s “Here are engineers whose reviews you should read,” and then you can click through into the code and see great examples or less great examples. So it's a way to ramp up on a new application or project more quickly. 

To get started with it: it’s a free tool. The only requirement is that you use GitHub. Go to Sema’s website and click join the waitlist. We’re using a waitlist because we're letting folks in deliberately: we really want to make sure the product is fully polished before we move to general release. But anyone listening to this, who's a friend or follower of Kunal, you care enough about code quality that we will be glad to let you in.

Learning in Public

Kunal: Amazing. And now let’s come back to the discussion of learning in public, for folks who may be new. Shout out to @eddiejaoude for sharing a lot of great resources. Can you share a little bit more for someone who may be new about learning in public?

Matt: I love talking about learning in public, in part because I had to learn how to do it and my instincts were incorrect. And those of you who love learning – probably everyone on this call – you know that being able to talk about something you did wrong is so satisfying, because it means you're learning something new. 

The idea of learning in public is to share a question as broadly as possible, rather than sharing it privately. 

That’s true in Open Source projects and communities, and it’s true in private companies or organizations. At Sema, we have 45 amazing folks in 25 different countries. It is almost always the right answer to ask your question in a public channel– we use Slack – rather than a private one. 

So the risk of us doing this in public is that you might be asking a “dumb question.”  I'm using air quotes here: 999 times out of 1000, if you have a question, you should put it in a public Slack or Discord channel and open it up to the community for anyone to answer, not just an individual.

If you're asking it, it's almost certain that somebody else is already thinking it too. Nothing is as clear as creators think it is. I know, I know it's true for me, I write things and think it's clear, but they're never clear enough. So by you asking in public, you're doing a service to others who have that question too.

Equally important, and maybe more important, you're doing an incredible favor to the question answerer. 

When you send a message to an individual person, the only person who can answer that is that person, because nobody else knows. If you’re in an Open Source project, it’s likely you’re sending a private message to a Maintainer, they are the leaders of the project. They organize the project, answer questions, and welcome others. They are so busy. 

And so when you ask a question privately, it's on them to answer it. Instead if you ask it in a public channel, someone else can answer. 

I'm a member of a few communities where not only should you put the message in a public channel, but you also shouldn’t tag a Maintainer. 

Kunal: Asking in a public channel is also going to help you because if you ask in public, then more folks are going to see your question and get answered very fast as compared to if you just DM folks.

Coordinating a global team – and the power of Psychological Safety

Kunal: I love the fact you mentioned your team works across 25 countries. How does the communication happen? How do you make sure that you're not getting blocked because of the major time zone differences? So you have such tremendous experience in working remotely? How does that happen?

Matt: We're not perfect, by any means. We definitely have blockers. For any engineering process or really any process, there's always going to be blockers. And so in the spirit of continuous improvement, finding the blockers and being honest about them, is a huge part of fixing them. 

A quick aside: some of you may know the concept of psychological safety. Let me spend a minute or two on this because I think it helps answer how to make global teams work.

Psychological safety, in summary, is about whether you and your colleagues feel safe at work. Safety when you are asking questions, especially when you are asking hard questions, or uncomfortable questions. And safety also relates to making suggestions or criticisms. 

But to boil it down, if an organization has psychological safety, you can feel safe about saying something about something that's not good, something that's wrong, and still be okay: not be criticized, not be attacked, not be fired, or other negative consequences.

There's been a ton of research on the power of psychological safety. Shout out to Tom and Amy, global experts on this. A major study at Google a few years ago found that psychological safety is one of the most important drivers of an organization's success. 

Why does psychological safety matter so much?  If you don't feel safe, for whatever set of reasons, you're not going to be honest, you're not going to give your best. You're worried about what could happen to you, and you're spending so much emotional and intellectual energy worrying. Feeling worried takes away from taking risks and putting yourself out there. 

Now, back to blockers. Like I said, absolutely have blockers on a regular basis, and as we fix old ones, new blockers emerge.

Psychological safety is one of the most important elements of an effective global organization to help you unblock blockers… along with many other benefits.

What does Sema do to get psychological safety right? A lot of it comes from role modeling. Senior leaders have to show that they're really open to suggestions, feedback, and criticism, from all sources. One part of our onboarding at Sema is to reach new colleagues that in their first two weeks at Sema, they should tell me, the CEO, that I'm incorrect. If you can tell the CEO is incorrect, you really feel safe, right? 

Jokes to and about the CEO are a part of psychological safety for us. Let me give you a recent example. We're implementing LaunchDarkly, for feature flags to turn certain features on or off. This week the Engineering team put in a flag for bugs that would only show up on the CEO’s account, my account. I'm so proud of them for that joke. And so I actually measure how much people are teasing me as a good indicator of how safe the organization is. 

Let me come back to Open Source for a moment, and tie it back to Psychological Safety. Another really good reason to share things in public channels in Open Source Repositories is if you say something “stupid” and someone treats you badly or is disrespectful, if the project does not practice Psychological Safety, you should quit and find a new project.  There are so many Open Source projects full of really wonderful people who want your help. 

Let’s talk about other things Sema does to help make a global team work. It's all led by our amazing Culture Committee: an international team from all parts of the organization. 

  • They make sure onboarding is really, really good. 
  • We are really anal about coordinating timezones for meetings, trying to find meeting times that work for everyone or almost everyone. 
  • And we put a lot of what we do in writing. Reading written documents is easier when folks are working in their non-native language. And, written documents that are as detailed as possible prevent blockers, so you can read it, rather than having to have a live conversation.

Giving and Receiving Feedback

Kunal: Amazing, thanks for sharing.

You talked about communication and feedback. What are some of your best practices when it comes to giving and receiving feedback, and constructively criticizing someone? 

Oftentimes, when it comes to sharing your opinions on social media, it may come off as not apt, and not as it was intended. So how do you make sure that when you're giving someone criticism, they take it in a positive way?

Matt: Sure. I'm going to answer this in two parts.  One part is from the perspective of junior members of a team, who are new to a team or not managers. So I want to answer it from that perspective. And the second part is, I’ll talk about it for folks who are managers or leaders of an organization. 

[Editor’s note: I did not, in fact, answer the second part. Insert embarrassed emoji here ;0. We’ll cover what managers should know about setting up systems of feedback another time.]

First, from the perspective of a junior member of a team.

This may be unfortunate but we’ve got to be real: many organizations do not follow best practices on giving and receiving feedback. And so what you need to do is adapt your approach to, to the methods of your manager and of your team. 

I wish it wasn't this way, I wish that people could show up and say, “Hey, I have a suggestion, let us follow best practices for giving and receiving feedback. Let's do it this way.” That almost never works, I would really never recommend it. Because most organizations aren't that open to that kind of “meta feedback,” feedback about giving feedback. 

And so for juniors, the most important thing, the most important thing to do first is to watch before you give feedback of any kind. I would spend at least a week or two observing how other people do it. And especially watch how people give feedback to those people with power. Don’t model yourself on the person with power, model yourself on the person who is giving feedback to that person. Do they tease that person? Do they say “you're wrong”? Do they say “I might do it differently”?  

Watch how people communicate with that powerful person, and mimic that. Mimicking may seem artificial– but I think in a craft or a skill, the first thing you should do is watch and learn from others. 

Second, frequently when people say feedback, they mean criticism, or things to do differently.It’s a universal experience. If I said, “Kunal, I'd like to give you some feedback,” Almost always that means negative things are about to come. That’s a total shame: by definition. feedback includes both positive and negative items. The second piece of advice about feedback is to frequently give positive, specific examples. 

Positive feedback must be specific, and obviously must be real and authentic. Inauthentic positive feedback is much worse than no feedback at all.

The problem with generic positive feedback is that it is hard to believe it– because we use it so often, because it’s easy to say. By contrast, specific positive feedback means the speaker was listening. 

Let me give you examples of general and specific positive feedback, Kunal. Both are real.

General feedback first: “Kunal, you’re an Incredible dude. You have built this amazing community. It's incredible. And I am so impressed.”

This feedback is true, I actually believe those words from my heart. 

But Kunal, you may or may not believe it, because it's pretty broad, right? 

Now let me give you specific positive feedback.

“Kunal, you seem to be working all the time. Early morning, night. As far as I can tell, you are the only person managing the Community Classroom Discord channel. You are writing individual responses to hundreds or thousands of people. I have no idea how you manage that time and how many people you're able to keep track of those conversations.”

“And, I have never seen you lose your temper or express frustration. I personally have seen many comments on Discord where someone should have looked it the question instead of asking it to you, or when a person should have been appreciative rather than saying ‘When's the next video coming out?’ 

“Your equipoise, your ability to stay calm when people are, I'd say a little bit disrespectful, is extremely impressive. And it's a role model for everyone else in the community.”

So like the first piece of feedback I gave, I believe this too. But it's so much more specific, that it’s more likely for you to believe it Kunal– hopefully you do, i see you nodding, that’s a good sign.

For negative feedback, most of us have learned not to give general negative feedback. You don't give say, “Kunal, I hate how you write.” You would say “Oh, you made there's a semicolon missing here, please fix it.” That is specific negative feedback.

What I'm encouraging everyone to do is to make your positive feedback, as specific as that negative feedback, at exactly that same level of detail. 

Kunal: Having some action items with negative feedback is extremely important. Because otherwise the recipient will ask themselves, “Okay, I get it. What do you want me to do about it?” And I appreciate you giving the shout out. It really means a lot.

Getting Started with Learning in Public – Writing and Social Media

Kunal: What are some of the other ways folks can get started with learning in public, in particular Twitter, LinkedIn, and other forms of content creation like blogging. How should one get started?

Matt: The mental model for learning in public is, you're not going to be very good at it to start. So whether it’s writing in public or coding in public, you're just going to get you're just going to get better over time while you do it.

So first off, just be okay with that- start creating and start showing people your mistakes. Reason number one, you're going to learn faster by making more mistakes and having people see them – by doing you are learning more than by not doing. rather than not acting. And reason number two, it is more impressive to an audience to see that you've gotten better over time, than to just be great from the beginning. 

As an example, let’s talk about grade point average. School grades are a really good example. 8.0 is a good grade point average in Indian universities, right? What's perfect?

Kunal: 10.0.

Matt: Okay, so let's say, in your first four semesters at school, you had a 10.0 average. That is actually less impressive than having a 4.0, then 6.0, then 8.0 then a 9.0 in the four semesters. Now how your grades are perceived does also depend on the school and the major. 

But what the second story tells is, you got better, you figured out how to learn, and became much better. There's a trajectory evident in the data. If you got 10.0s all the way through, maybe you weren't being challenged. And that kind of trajectory is really important to employers, because it shows that this person can learn and this person knows how to work harder and get better and better at what they do

This same principle of showing a trajectory of improvement is true for content creation and for coding. 

Another principle of getting better at writing and social media is finding a community of folks who are going to help. Find a group of people who are also writing with social media, either join a community or create one. You want the feedback, you want people giving you authentic feedback on how you're doing – in a way that’s in keeping with psychological safety of course. 

Getting Started with Learning in Public – Joining the right Community

Kunal: Thanks for shedding light on that. You mentioned finding communities: how does one do that? Because the question I have gotten the most is, how do you find the right community? If it's too big, then you may have some difficulty getting involved. And if it is too small, then you may not get much traction. So what are your views on that?

Matt: Completely agree.You've heard me mention the Goldilocks story: pick a community that’s the right size to get started. If a community is too big, you could get lost. Or maybe your skills aren't good enough yet to contribute to a really big Open Source project like a framework that Facebook is building. Early in your career, it's really not worth it for you to try to help there. Because you really want to be helpful. 

And then if a community is too small, there may not be enough work going on. 

Also you want to join a community that is extremely welcoming to newcomers. Investigate that project and see what the feedback looks like. Are there open pull requests? Are they getting approved? Is there feedback on through code reviews coming in? Follow this for a while. That'll give you a sense of how much feedback is happening. For one or two weeks, I would follow two or three projects and just watch, to help pick the right one. 

And then I would pick only one of those repositories to really help rather than trying to help two or three. It's really important to do a small number of things really well, rather than a large number of things done lightly. That's better for your learning. And that’s better for demonstrating commitment to others. 

My last piece of advice is to pick an Open Source project to start that matches your existing skills and knowledge. Some people appropriately work in Open Source as a way to learn new languages, new frameworks, and so on. That's perfectly fine, but I would not do that for your first project. I would be as helpful as you possibly can. For your first project, you’re mainly practicing being a good Open Source Contributor. And the more content knowledge you already have, the more you can just focus on learning the norms, how to communicate, and how to be a good Contributor– and then perhaps become a Maintainer. 

Then, once you know how to be a good Contributor, then you are ready to use your contributions to Open Source repository to learn a new language.

Kunal: I love that point about using Open Source to learn new things. If you look at a project and  you want to contribute to it but you don't know a particular tech stack– that's a silver lining. Now you get to learn something new. 

You know about impostor syndrome. I don’t think students should worry about impostor syndrome– people expect students not to know stuff. They're starting out. So students who do feel this, well, impostor syndrome is an opportunity. There's no shame in not being skilled in a particular technology or whatever that you want to do. But there is shame in staying that way. 

So it’s okay if you want to contribute to a project, or you just got into a new internship and you don't know much about it. Communicate, learn by doing, and ask questions. Just make some progress, just get started with it. You can use Open Source to learn and contribute. I did that, starting in my freshman year, I always learned by doing in Open Source. And I think that has worked out pretty well for me.

Matt: Well, awesome. And remember, if you're joining an Open Source project, and you are feeling impostor syndrome, and the community is making you feel bad or feel shame… you know what I'm gonna say. Walk away, go to another project. Because there are plenty of communities that understand that students are there to learn. 

Exactly as Kunal said– if you feel impostor syndrome, that's fine. We all have those feelings. But if someone else makes you feel it, go somewhere else.

Kunal: Yeah. In internships,one of the ways to highlight recognize great internships is they will ask you how can we help you and your career. They don't expect interns to be production level seniors. Internships are learning experiences. And if a company does not know that, then, you know, nothing is wrong with you. There's something wrong with the company. 

[Editor’s note: EddieHub Maintainers put together seven tips on how to be a great Contributor– you can read them here.]

Learning in Public and Career Advancement – in particular through Open Source

Kunal: Speaking of hiring people– and Matt, you have quite a lot of experience with that– let’s tie that into the discussion about learning in public. How does learning public help in getting a job or an internship? 

Matt: Any kind of learning can help advance your career, but learning in public means that not only are you developing skills and knowledge, but other benefits can come too. 

For one, learning in public can lead to getting to know people, whether it's writing that's public, or whether it's contributing to an Open Source project.

Second, in many situations, the learning that you are doing in public is effectively very similar to the work that you would be doing in a job. And for engineers contributing to Open Source projects, in many cases, working on Open Source projects is a lot closer to what you’d be doing on the job than in a classroom. There’s nothing wrong with a lecture about the theory of coding or some theoretical approach. Not there's that anything wrong with that – it's a huge and incredibly useful underpinning. But coding on an Open Source project is applied. 

You also get code reviews in Open Source projects. Sema has spent a lot of time on code reviews, they are a fundamental part of almost every coding organization. Maybe you’ll be receiving or creating code reviews in your university classes. But you absolutely could and should be going to Open Source projects, and becoming a good Contributor, and if you do that you’ll have received 10, 50, 100, pull requests code reviews over the course of six months.

The last benefit of Open Source is that it’s an advantageous process relative to applying for a formal interview. It’s easier to get into and easier than to get out of a formal internship where you go through a process, once you start it, and then you have to finish that internship.

Whereas if you work in Open Source, you can spend a week or two watching, you can then make one pull request and see what happens and see if they treat you with respect or not. So it there is a much more informal process to start, which I think is a huge advantage. 

And if you make a good contribution, it is possible to transition from that into an organization's career pipeline. Definitely do not start by trying to contribute to Facebook's Open Source because you want a job at Facebook, that is an extremely low likelihood approach. Pick a correctly sized and supported project, be a great Contributor, maybe become a great Maintainer, then you can actually look for Open Source projects that are sponsored by somewhere you'd like to hire, or at least related to that place. 

Kunal: Amazing. That's very practical advice. And not just the company's projects, but the other Open Source projects that the company may be using contributing to that as well. 

What Hiring Managers Look For

Kunal: One more question. You’ve done a lot of hiring. What has your experience been like when you are hiring people? 

Matt: doing a tiny number of things extremely well is the most important thing. 

Taking on projects, or adding “things to your plate,” only when you can do them well, is a really good sign to employers because it shows that you are competent, in the sense of if you're going to do something, you're going to do it well. The opposite of competent is flaky or indecisive.

So picking a small number of activities such as Open Source projects – and only do one really well before you take on a second! – and really being maximally helpful, is hugely helpful.. 

Good organizations ask experiential interview questions, meaning questions about your previous experience. If I were interviewing you at Sema, I will always ask, tell me about something hard you have done. What made it hard? What did you do? And what happened? 

And a good interviewer will be looking for just how difficult was it? What was the degree of difficulty?  “Oh a, a really hard thing I had to do was clean up all of the dishes in my apartment, because it was messy.” That's not that hard. You want to talk about something you did that was difficult. Depending on the organization, how much success you've had may or may not be as important as how hard you worked. 

Signing yourself up for hard things, and doing the best job you can, and putting a lot of energy into them not only gives you experiences that translate into skill and knowledge, but also is a way to be successful in interviews. 

Kunal: absolutely amazing. Thanks a lot for sharing Matt. And we'll be doing more and more such sessions about career advancement. 

Matt: I really enjoyed it. Have a great day and thanks again, everybody.

Video

Community Classroom believes that every student, irrespective of their college or branch, can make it big. Community Classroom is an initiative built on this thought. The organization, founded by Kunal Kushwaha, provides free hands-on training and mentorship in an inclusive community.

Topics covered:

  • Learning in Public
  • Coordinating a global team – and the power of Psychological Safety
  • Giving and Receiving Feedback
  • Getting Started with Learning in Public – Writing and Social Media
  • Getting Started with Learning in Public – Joining the right Community
  • Learning in Public and Career Advancement – in particular through Open Source
  • What Hiring Managers Look For

This conversation has been edited for clarity, context, and annotations.

Introduction

Kunal: Welcome back to another episode of the Open Source Cafe.This is an ongoing series that we have started focused on career development.

Today you can learn about all the amazing years of experiences of Matt Van Itallie of Sema. Today we’re going to ask questions on topics requested by many members of the Community Classroom community, in particular learning in public. 

Before we get started, would you like to tell our viewers a little bit more about yourself?

Matt: Absolutely. Thanks again, Kunal, I had such a pleasure on the Discord chat, I know how much fun this is going to be. 

So I'm Matt Van Itallie. I grew up in a town of about 40,000 people in New York State, a few hours from New York City. I now live in Baltimore, Maryland, which is near Washington, DC. I learned to code when I was five. My parents are coders– my mom was one of the first coders at IBM and then became a math teacher. So we've always had a lot of technology in my family. 

My professional career was spent mostly on the business and the organizational side of code. I put in technology systems at software companies and technology organizations, even working with school districts to use software to help improve teaching and learning. 

After working for many years in and around tech, I really fell in love with and became obsessed with code quality and technical debt. And with helping coders learn more, grow more, and advance their careers. 

One of the things I observed was, so many organizations were trying to treat coders like, let's say, sales people, or people who work on an assembly line. Code is really different. It's a craft, not a competition. 

And so I founded Sema, to work on improving code quality and the craft of coding.

Improving code quality is better for users. And it’s better for coders– because better code is easier to use. And also, better code quality is just the right thing to do. We have an obligation in the coding community, to give back to the code because it's done so much for us. In other words code quality matters for its own sake. 

We’re also helping developers learn more to advance their careers. And hopefully soon enough, we’ll be able to make the interviewing process a little bit better, because we all know it could be a lot better than it is.

Kunal: Yeah, I couldn't agree more. 

About the Sema product

Kunal: Can you tell us a little bit more about the product itself before we move on with the agenda today? 

Matt: Sure. The Sema product is a code review and developer portfolio tool. Right now, it's only available for GitHub, we're going to go to other version control systems soon. 

What it does is make code reviews themselves a little bit more structured, so that they're clear to the audience, to the code author. 

It also creates a dashboard. If you think about all the code reviews you've done, you've probably never looked at those results again– because the data is unstructured. We've built a way by structuring code review data to also create dashboards across all PRs and repositories that are analyzable and explorable. 

Another feature is the ability to take best practices, whether they're from your organization, or whether they're from the community, and insert them into code reviews. We have 20,000 best practices that can be inserted, or you can reuse the comments you would use every day, so you're not reinventing the wheel and retyping the same comment every time. 

And then finally, through these dashboards, you can easily create Developer Portfolios

These Portfolios can be about your own accomplishments – to support a resume, for example. Another use case is to keep track of what you've been working on; some people call that an accomplishment journal, or a brag book. 

But also, you can also create a Portfolio about the code. One of the really cool uses comes from @eddiejaoude of EddieHub, the inclusive Open Source community. Big shout out to him for inventing this use. A Portfolio can serve as a readme file for new engineers to a project. This way it’s not just documentation, and it’s not just “read the code and tell us what you think.” Instead, it’s “Here are engineers whose reviews you should read,” and then you can click through into the code and see great examples or less great examples. So it's a way to ramp up on a new application or project more quickly. 

To get started with it: it’s a free tool. The only requirement is that you use GitHub. Go to Sema’s website and click join the waitlist. We’re using a waitlist because we're letting folks in deliberately: we really want to make sure the product is fully polished before we move to general release. But anyone listening to this, who's a friend or follower of Kunal, you care enough about code quality that we will be glad to let you in.

Learning in Public

Kunal: Amazing. And now let’s come back to the discussion of learning in public, for folks who may be new. Shout out to @eddiejaoude for sharing a lot of great resources. Can you share a little bit more for someone who may be new about learning in public?

Matt: I love talking about learning in public, in part because I had to learn how to do it and my instincts were incorrect. And those of you who love learning – probably everyone on this call – you know that being able to talk about something you did wrong is so satisfying, because it means you're learning something new. 

The idea of learning in public is to share a question as broadly as possible, rather than sharing it privately. 

That’s true in Open Source projects and communities, and it’s true in private companies or organizations. At Sema, we have 45 amazing folks in 25 different countries. It is almost always the right answer to ask your question in a public channel– we use Slack – rather than a private one. 

So the risk of us doing this in public is that you might be asking a “dumb question.”  I'm using air quotes here: 999 times out of 1000, if you have a question, you should put it in a public Slack or Discord channel and open it up to the community for anyone to answer, not just an individual.

If you're asking it, it's almost certain that somebody else is already thinking it too. Nothing is as clear as creators think it is. I know, I know it's true for me, I write things and think it's clear, but they're never clear enough. So by you asking in public, you're doing a service to others who have that question too.

Equally important, and maybe more important, you're doing an incredible favor to the question answerer. 

When you send a message to an individual person, the only person who can answer that is that person, because nobody else knows. If you’re in an Open Source project, it’s likely you’re sending a private message to a Maintainer, they are the leaders of the project. They organize the project, answer questions, and welcome others. They are so busy. 

And so when you ask a question privately, it's on them to answer it. Instead if you ask it in a public channel, someone else can answer. 

I'm a member of a few communities where not only should you put the message in a public channel, but you also shouldn’t tag a Maintainer. 

Kunal: Asking in a public channel is also going to help you because if you ask in public, then more folks are going to see your question and get answered very fast as compared to if you just DM folks.

Coordinating a global team – and the power of Psychological Safety

Kunal: I love the fact you mentioned your team works across 25 countries. How does the communication happen? How do you make sure that you're not getting blocked because of the major time zone differences? So you have such tremendous experience in working remotely? How does that happen?

Matt: We're not perfect, by any means. We definitely have blockers. For any engineering process or really any process, there's always going to be blockers. And so in the spirit of continuous improvement, finding the blockers and being honest about them, is a huge part of fixing them. 

A quick aside: some of you may know the concept of psychological safety. Let me spend a minute or two on this because I think it helps answer how to make global teams work.

Psychological safety, in summary, is about whether you and your colleagues feel safe at work. Safety when you are asking questions, especially when you are asking hard questions, or uncomfortable questions. And safety also relates to making suggestions or criticisms. 

But to boil it down, if an organization has psychological safety, you can feel safe about saying something about something that's not good, something that's wrong, and still be okay: not be criticized, not be attacked, not be fired, or other negative consequences.

There's been a ton of research on the power of psychological safety. Shout out to Tom and Amy, global experts on this. A major study at Google a few years ago found that psychological safety is one of the most important drivers of an organization's success. 

Why does psychological safety matter so much?  If you don't feel safe, for whatever set of reasons, you're not going to be honest, you're not going to give your best. You're worried about what could happen to you, and you're spending so much emotional and intellectual energy worrying. Feeling worried takes away from taking risks and putting yourself out there. 

Now, back to blockers. Like I said, absolutely have blockers on a regular basis, and as we fix old ones, new blockers emerge.

Psychological safety is one of the most important elements of an effective global organization to help you unblock blockers… along with many other benefits.

What does Sema do to get psychological safety right? A lot of it comes from role modeling. Senior leaders have to show that they're really open to suggestions, feedback, and criticism, from all sources. One part of our onboarding at Sema is to reach new colleagues that in their first two weeks at Sema, they should tell me, the CEO, that I'm incorrect. If you can tell the CEO is incorrect, you really feel safe, right? 

Jokes to and about the CEO are a part of psychological safety for us. Let me give you a recent example. We're implementing LaunchDarkly, for feature flags to turn certain features on or off. This week the Engineering team put in a flag for bugs that would only show up on the CEO’s account, my account. I'm so proud of them for that joke. And so I actually measure how much people are teasing me as a good indicator of how safe the organization is. 

Let me come back to Open Source for a moment, and tie it back to Psychological Safety. Another really good reason to share things in public channels in Open Source Repositories is if you say something “stupid” and someone treats you badly or is disrespectful, if the project does not practice Psychological Safety, you should quit and find a new project.  There are so many Open Source projects full of really wonderful people who want your help. 

Let’s talk about other things Sema does to help make a global team work. It's all led by our amazing Culture Committee: an international team from all parts of the organization. 

  • They make sure onboarding is really, really good. 
  • We are really anal about coordinating timezones for meetings, trying to find meeting times that work for everyone or almost everyone. 
  • And we put a lot of what we do in writing. Reading written documents is easier when folks are working in their non-native language. And, written documents that are as detailed as possible prevent blockers, so you can read it, rather than having to have a live conversation.

Giving and Receiving Feedback

Kunal: Amazing, thanks for sharing.

You talked about communication and feedback. What are some of your best practices when it comes to giving and receiving feedback, and constructively criticizing someone? 

Oftentimes, when it comes to sharing your opinions on social media, it may come off as not apt, and not as it was intended. So how do you make sure that when you're giving someone criticism, they take it in a positive way?

Matt: Sure. I'm going to answer this in two parts.  One part is from the perspective of junior members of a team, who are new to a team or not managers. So I want to answer it from that perspective. And the second part is, I’ll talk about it for folks who are managers or leaders of an organization. 

[Editor’s note: I did not, in fact, answer the second part. Insert embarrassed emoji here ;0. We’ll cover what managers should know about setting up systems of feedback another time.]

First, from the perspective of a junior member of a team.

This may be unfortunate but we’ve got to be real: many organizations do not follow best practices on giving and receiving feedback. And so what you need to do is adapt your approach to, to the methods of your manager and of your team. 

I wish it wasn't this way, I wish that people could show up and say, “Hey, I have a suggestion, let us follow best practices for giving and receiving feedback. Let's do it this way.” That almost never works, I would really never recommend it. Because most organizations aren't that open to that kind of “meta feedback,” feedback about giving feedback. 

And so for juniors, the most important thing, the most important thing to do first is to watch before you give feedback of any kind. I would spend at least a week or two observing how other people do it. And especially watch how people give feedback to those people with power. Don’t model yourself on the person with power, model yourself on the person who is giving feedback to that person. Do they tease that person? Do they say “you're wrong”? Do they say “I might do it differently”?  

Watch how people communicate with that powerful person, and mimic that. Mimicking may seem artificial– but I think in a craft or a skill, the first thing you should do is watch and learn from others. 

Second, frequently when people say feedback, they mean criticism, or things to do differently.It’s a universal experience. If I said, “Kunal, I'd like to give you some feedback,” Almost always that means negative things are about to come. That’s a total shame: by definition. feedback includes both positive and negative items. The second piece of advice about feedback is to frequently give positive, specific examples. 

Positive feedback must be specific, and obviously must be real and authentic. Inauthentic positive feedback is much worse than no feedback at all.

The problem with generic positive feedback is that it is hard to believe it– because we use it so often, because it’s easy to say. By contrast, specific positive feedback means the speaker was listening. 

Let me give you examples of general and specific positive feedback, Kunal. Both are real.

General feedback first: “Kunal, you’re an Incredible dude. You have built this amazing community. It's incredible. And I am so impressed.”

This feedback is true, I actually believe those words from my heart. 

But Kunal, you may or may not believe it, because it's pretty broad, right? 

Now let me give you specific positive feedback.

“Kunal, you seem to be working all the time. Early morning, night. As far as I can tell, you are the only person managing the Community Classroom Discord channel. You are writing individual responses to hundreds or thousands of people. I have no idea how you manage that time and how many people you're able to keep track of those conversations.”

“And, I have never seen you lose your temper or express frustration. I personally have seen many comments on Discord where someone should have looked it the question instead of asking it to you, or when a person should have been appreciative rather than saying ‘When's the next video coming out?’ 

“Your equipoise, your ability to stay calm when people are, I'd say a little bit disrespectful, is extremely impressive. And it's a role model for everyone else in the community.”

So like the first piece of feedback I gave, I believe this too. But it's so much more specific, that it’s more likely for you to believe it Kunal– hopefully you do, i see you nodding, that’s a good sign.

For negative feedback, most of us have learned not to give general negative feedback. You don't give say, “Kunal, I hate how you write.” You would say “Oh, you made there's a semicolon missing here, please fix it.” That is specific negative feedback.

What I'm encouraging everyone to do is to make your positive feedback, as specific as that negative feedback, at exactly that same level of detail. 

Kunal: Having some action items with negative feedback is extremely important. Because otherwise the recipient will ask themselves, “Okay, I get it. What do you want me to do about it?” And I appreciate you giving the shout out. It really means a lot.

Getting Started with Learning in Public – Writing and Social Media

Kunal: What are some of the other ways folks can get started with learning in public, in particular Twitter, LinkedIn, and other forms of content creation like blogging. How should one get started?

Matt: The mental model for learning in public is, you're not going to be very good at it to start. So whether it’s writing in public or coding in public, you're just going to get you're just going to get better over time while you do it.

So first off, just be okay with that- start creating and start showing people your mistakes. Reason number one, you're going to learn faster by making more mistakes and having people see them – by doing you are learning more than by not doing. rather than not acting. And reason number two, it is more impressive to an audience to see that you've gotten better over time, than to just be great from the beginning. 

As an example, let’s talk about grade point average. School grades are a really good example. 8.0 is a good grade point average in Indian universities, right? What's perfect?

Kunal: 10.0.

Matt: Okay, so let's say, in your first four semesters at school, you had a 10.0 average. That is actually less impressive than having a 4.0, then 6.0, then 8.0 then a 9.0 in the four semesters. Now how your grades are perceived does also depend on the school and the major. 

But what the second story tells is, you got better, you figured out how to learn, and became much better. There's a trajectory evident in the data. If you got 10.0s all the way through, maybe you weren't being challenged. And that kind of trajectory is really important to employers, because it shows that this person can learn and this person knows how to work harder and get better and better at what they do

This same principle of showing a trajectory of improvement is true for content creation and for coding. 

Another principle of getting better at writing and social media is finding a community of folks who are going to help. Find a group of people who are also writing with social media, either join a community or create one. You want the feedback, you want people giving you authentic feedback on how you're doing – in a way that’s in keeping with psychological safety of course. 

Getting Started with Learning in Public – Joining the right Community

Kunal: Thanks for shedding light on that. You mentioned finding communities: how does one do that? Because the question I have gotten the most is, how do you find the right community? If it's too big, then you may have some difficulty getting involved. And if it is too small, then you may not get much traction. So what are your views on that?

Matt: Completely agree.You've heard me mention the Goldilocks story: pick a community that’s the right size to get started. If a community is too big, you could get lost. Or maybe your skills aren't good enough yet to contribute to a really big Open Source project like a framework that Facebook is building. Early in your career, it's really not worth it for you to try to help there. Because you really want to be helpful. 

And then if a community is too small, there may not be enough work going on. 

Also you want to join a community that is extremely welcoming to newcomers. Investigate that project and see what the feedback looks like. Are there open pull requests? Are they getting approved? Is there feedback on through code reviews coming in? Follow this for a while. That'll give you a sense of how much feedback is happening. For one or two weeks, I would follow two or three projects and just watch, to help pick the right one. 

And then I would pick only one of those repositories to really help rather than trying to help two or three. It's really important to do a small number of things really well, rather than a large number of things done lightly. That's better for your learning. And that’s better for demonstrating commitment to others. 

My last piece of advice is to pick an Open Source project to start that matches your existing skills and knowledge. Some people appropriately work in Open Source as a way to learn new languages, new frameworks, and so on. That's perfectly fine, but I would not do that for your first project. I would be as helpful as you possibly can. For your first project, you’re mainly practicing being a good Open Source Contributor. And the more content knowledge you already have, the more you can just focus on learning the norms, how to communicate, and how to be a good Contributor– and then perhaps become a Maintainer. 

Then, once you know how to be a good Contributor, then you are ready to use your contributions to Open Source repository to learn a new language.

Kunal: I love that point about using Open Source to learn new things. If you look at a project and  you want to contribute to it but you don't know a particular tech stack– that's a silver lining. Now you get to learn something new. 

You know about impostor syndrome. I don’t think students should worry about impostor syndrome– people expect students not to know stuff. They're starting out. So students who do feel this, well, impostor syndrome is an opportunity. There's no shame in not being skilled in a particular technology or whatever that you want to do. But there is shame in staying that way. 

So it’s okay if you want to contribute to a project, or you just got into a new internship and you don't know much about it. Communicate, learn by doing, and ask questions. Just make some progress, just get started with it. You can use Open Source to learn and contribute. I did that, starting in my freshman year, I always learned by doing in Open Source. And I think that has worked out pretty well for me.

Matt: Well, awesome. And remember, if you're joining an Open Source project, and you are feeling impostor syndrome, and the community is making you feel bad or feel shame… you know what I'm gonna say. Walk away, go to another project. Because there are plenty of communities that understand that students are there to learn. 

Exactly as Kunal said– if you feel impostor syndrome, that's fine. We all have those feelings. But if someone else makes you feel it, go somewhere else.

Kunal: Yeah. In internships,one of the ways to highlight recognize great internships is they will ask you how can we help you and your career. They don't expect interns to be production level seniors. Internships are learning experiences. And if a company does not know that, then, you know, nothing is wrong with you. There's something wrong with the company. 

[Editor’s note: EddieHub Maintainers put together seven tips on how to be a great Contributor– you can read them here.]

Learning in Public and Career Advancement – in particular through Open Source

Kunal: Speaking of hiring people– and Matt, you have quite a lot of experience with that– let’s tie that into the discussion about learning in public. How does learning public help in getting a job or an internship? 

Matt: Any kind of learning can help advance your career, but learning in public means that not only are you developing skills and knowledge, but other benefits can come too. 

For one, learning in public can lead to getting to know people, whether it's writing that's public, or whether it's contributing to an Open Source project.

Second, in many situations, the learning that you are doing in public is effectively very similar to the work that you would be doing in a job. And for engineers contributing to Open Source projects, in many cases, working on Open Source projects is a lot closer to what you’d be doing on the job than in a classroom. There’s nothing wrong with a lecture about the theory of coding or some theoretical approach. Not there's that anything wrong with that – it's a huge and incredibly useful underpinning. But coding on an Open Source project is applied. 

You also get code reviews in Open Source projects. Sema has spent a lot of time on code reviews, they are a fundamental part of almost every coding organization. Maybe you’ll be receiving or creating code reviews in your university classes. But you absolutely could and should be going to Open Source projects, and becoming a good Contributor, and if you do that you’ll have received 10, 50, 100, pull requests code reviews over the course of six months.

The last benefit of Open Source is that it’s an advantageous process relative to applying for a formal interview. It’s easier to get into and easier than to get out of a formal internship where you go through a process, once you start it, and then you have to finish that internship.

Whereas if you work in Open Source, you can spend a week or two watching, you can then make one pull request and see what happens and see if they treat you with respect or not. So it there is a much more informal process to start, which I think is a huge advantage. 

And if you make a good contribution, it is possible to transition from that into an organization's career pipeline. Definitely do not start by trying to contribute to Facebook's Open Source because you want a job at Facebook, that is an extremely low likelihood approach. Pick a correctly sized and supported project, be a great Contributor, maybe become a great Maintainer, then you can actually look for Open Source projects that are sponsored by somewhere you'd like to hire, or at least related to that place. 

Kunal: Amazing. That's very practical advice. And not just the company's projects, but the other Open Source projects that the company may be using contributing to that as well. 

What Hiring Managers Look For

Kunal: One more question. You’ve done a lot of hiring. What has your experience been like when you are hiring people? 

Matt: doing a tiny number of things extremely well is the most important thing. 

Taking on projects, or adding “things to your plate,” only when you can do them well, is a really good sign to employers because it shows that you are competent, in the sense of if you're going to do something, you're going to do it well. The opposite of competent is flaky or indecisive.

So picking a small number of activities such as Open Source projects – and only do one really well before you take on a second! – and really being maximally helpful, is hugely helpful.. 

Good organizations ask experiential interview questions, meaning questions about your previous experience. If I were interviewing you at Sema, I will always ask, tell me about something hard you have done. What made it hard? What did you do? And what happened? 

And a good interviewer will be looking for just how difficult was it? What was the degree of difficulty?  “Oh a, a really hard thing I had to do was clean up all of the dishes in my apartment, because it was messy.” That's not that hard. You want to talk about something you did that was difficult. Depending on the organization, how much success you've had may or may not be as important as how hard you worked. 

Signing yourself up for hard things, and doing the best job you can, and putting a lot of energy into them not only gives you experiences that translate into skill and knowledge, but also is a way to be successful in interviews. 

Kunal: absolutely amazing. Thanks a lot for sharing Matt. And we'll be doing more and more such sessions about career advancement. 

Matt: I really enjoyed it. Have a great day and thanks again, everybody.