Reactiflux - Q&A transcripts · Reactiflux

Jenny Truong

Reactiflux — Mon, 05 Jun 2023 16:00:00 GMT

[00:00] Carl Vitullo: Hello folks. Thank you for joining us for another Reactiflux Office Hours. I'm Carl Vitullo, the sort of community manager for Reactiflux, uh, here today with Jenny Truong talking about states of burnout. Uh, I met her at React Miami, she gave a talk called States of Burnout, and I just thought it was a really great subject to talk about. So, yeah, Jenny, really excited to have you on to talk a little more in depth.

[00:25] So you are head of operations and developer relations at Stately. What is the head of operations and how does that have, what does that have to do with developer relations?

[00:33] Jenny Truong: Yeah, so thanks for having me. Operations is basically the, they call me the glue behind the company because I basically do all the paperwork and all the HR related tasks and organization behind the startup. So our team right now at Stately is nine people, and most of them are engineers, but I do the payroll and the administrative and the financial, like all that stuff that like how a business runs, I do. And that's why I put it all under operations.

[01:05] Carl Vitullo: Sure. Operate the company can make sure it keeps going.

[01:07] Jenny Truong: Yeah essentially, yeah.

[01:10] Why do you care about burnout?

[01:10] Carl Vitullo: Sure. Very cool. Where does your passion for talking about burnout come from? Your talk was so well researched and so I know it had, it had so many great concepts to talk about. You were clearly so passionate about it.

[01:22] Jenny Truong: I really want to normalize the way we think about mental health and how like, We also approach it. I, I want to help people understand that like, we're all human. We all experience like this mental load of like, you know, the things that we keep in our head and how we don't express them is very unhealthy.

[01:41] So mental health is something huge that I, I am like trying to spread, if that makes sense. So just, just the idea of like expressing it and, and like having people talk about feelings instead of. Just saying, "hi, how are you" to like, every person we meet, we can either answer the question honestly or just approach the person where it's like, "hi," like take a moment to be like, I've never met you before, or, I've seen you before. I've never had the opportunity to chat. So like, you know, really just have meaningful conversations instead of an empty, Hey, how's it going? Great, how are you? You know?

[02:17] Carl Vitullo: Yeah, deep conversation instead of shallow platitudes.

[02:21] Jenny Truong: Exactly.

[02:23] Carl Vitullo: Okay. Very cool. Yeah, I love the, the backdrop of mental health and, and burnout. Those are definitely very closely related topics. Mental health's very close to me as well, I have some various diagnoses. I definitely have had a very personal relationship with burnout in my career too, so, yeah. Excited to get into it with you.

[02:42] Jenny Truong: Yeah. And then with burnout, people have this. Idea that if you work at a startup, you're always gonna be burnt out because they're gonna push you to your limits. But my personal experience with working at a startup that's only two years old, it's like you can define the workload that you're putting on yourself and your coworkers.

[03:02] So like, if you can create this movement of like everyone only working as much as they can and understanding your own, like, productivity capacity, or your limitations to how productive you are when you are productive, if you can express that onto your team and that can help them understand like where they are.

[03:20] Carl Vitullo: Yeah, definitely. That's reminding me, a couple years ago I wrote a blog post about… I can't remember if it was about burnout, or like, work stress, but one of the things that I researched, I pulled out some government PDFs that were talking about the relationship between productivity and hours worked, and I just, I remember the chart showed that like, okay, yes, at like 30 to 40 to 50 hours, there was a positive correlation between output and time put in.

[03:49] But after like two or three weeks of 50 hours a week, it started to fall off pretty sharply. So even, you know, 10 extra hours a week may not sound like totally burning the midnight oil to, to people. But yeah, like data shows, there's data showing that it doesn't help to burn yourself out.

[04:08] Jenny Truong: Yeah, and like it's, it's great that you mentioned that because it reminds me of like, in my research leading up to that presentation in Miami, I found out about how as humans we experience different types of rest deficits. And so like, that's something that we're gonna talk about later, but like we, we experienced seven different types of rest deficits that we could explore.

[04:33] And that like opened a whole new world on like how we can just be more creative and like have the intention to do something for us. Like do something, whether it's fun, or like new, or uncomfortable. Like, except it's the fact that you're exploring these different areas so then your brain can like just rest for a little bit.

[04:53] Carl Vitullo: Yeah. Yeah. I, we, we can get deeper into it later, but I think even just the, that sentence "seven different types of rest," to me that's very evocative of like, oh yeah, you know, like there are different ways you can become exhausted. You know, I think many people will intuitively understand like, okay, you can be socially drained or you can be, you've worked for 10 hours on a code project and get tapped out on that knowledge work.

[05:16] Stress vs burnout

[05:16] Carl Vitullo: So let's, let's start a little bit like, burnout versus stress. Like how, how would you distinguish between those.

[05:22] Jenny Truong: So I see stress as a positive thing actually, and hopefully I can influence people to see that stress is actually necessary for humans. Cause in our brains, when we experience stress, it's like cortisol and adrenaline to enhance like our current senses, right? Like whether you're hearing or seeing or feeling things more intensely in the moment.

[05:47] And so stress to me is like, okay, it's a natural human experience and occurrence in the brain. If we stress for a long period of time, it's going to overwhelm us and like, not deteriorate us, but more of like, it's just gonna bring us down and, and cause a physical, emotional toll on our brains and our body.

[06:07] How I see like what stress versus burnout is, is burnout is mostly work related. And what I mean by that is the prolonged experience of stress without an idea of where you want to be. Like, you know, there's a finish line, you don't know how to get there. So burnout, you can think of the things that you are sacrificing.

[06:30] Basically you stress to the point where you start giving up these things in life that seem normal, like eating lunch, taking a shower, answering a phone call, and like getting up away and distracting yourself from work. Like those things that you feel guilty about. That's where burnout comes in and differentiates like between what stress is.

[06:51] So stress is like, it's temporary. And if that temporary becomes like, Hours long of like constant stress and you start like not being able to see how to get to your end goal. It becomes burnout. Because burnout is like you're sacrificing all that time and all that energy and you're putting it into like all these work related tasks that, or you know, like it needs to be completed with a deadline, but you don't know how to get there.

[07:18] Carl Vitullo: Yeah. And so earlier you, you mentioned stress as, sort of like, heightened senses, the cortisol, the physiological reaction. So, so maybe to contrast, stress with burnout is like acute versus chronic. Like stress is the moment where your body says, "Ooh, I need a little extra oomph to get through this." and burnout is the accumulation of, you know, the damage of being on alert for an extended period of time? Does that sound right?

[07:44] Jenny Truong: Yeah, that sounds great. That's pretty much what it is, but burnout is what you're giving up as well. Like it's what you're trading that all the things that you're trading out to focus on the work that you're doing.

[07:58] Burnout vs depression

[07:58] Carl Vitullo: What you were saying about sort of burnout and the feeling guilt about getting up to do non-work things. To me that, that just hits this note that makes me think about, like, some symptoms of depression, like, you know, the anhedonia and loss of things that bring you joy. So what do you think about sort of the, the overlap and where they're different between burnout and depression?

[08:21] Jenny Truong: So with my personal experience with depression is that depression's kind of addicting, right? Like what I mean by that is you get comfortable with the idea of like feeling unhappy. So with depression it's like — none of these are choices, by the way. But at the same time with depression, like you are so comfortable with this feeling of like, lack of joy, you're comfortable in this state of like, being unproductive and lazy. I mean, this is just my personal experience, and I hope I don't offend anyone with saying this, but the key difference is that burnout is less of like, you find comfort in, in like the burnout state.

[09:07] And you're just pushing through and forcing yourself to like, okay, "I just need to do this, I need to finish this by this deadline." And then it never gets done and you're always unsatisfied. Versus the depression of just like, "Ugh, I don't wanna do anything today." You intentionally want to just distance yourself from the world.

[09:27] Carl Vitullo: Yeah. I think maybe another way of saying, "you become comfortable," is like sort of like that sort of stuck in a rut. So if you, you become comfortable with sort of the positive framing of it, of you form these new rhythms in your life around, in some ways it's like, mental health day, you take a day off, you take a day to just breathe, but then you take a second mental health day, and then you take a third.

[09:51] Then so that sort of, "treat yourself," like do your, do yourself and your body well, kind of becomes a rut that it becomes difficult to break out of. So do you think it would be fair to say like, burnout can lead to depression?

[10:05] Jenny Truong: Oh, absolutely. And same thing with stress. Stress can lead you to depression as well. It's just, so I want to preface this with, I'm not a medical doctor of any sorts. And I can't diagnose you, but there's a lot of research out there defining the difference between depression and burnout. And what we wanna focus on is, is like with burnout, it's, yes, it's what you're giving up and what you're feeling guilty for, but it's the fear as well.

[10:34] So it's your intention about trying to, to, let's say, finish up a task. Right? But it's the fear of like, okay, "what if I don't finish this? Everyone at work is gonna think low of me." You know, you're basically, it's hard to explain, but.

[10:50] Carl Vitullo: Sort of like an avoidant behavior, like the, you anticipate some harm to your, your, your psyche, your reputation, and so you become avoidant of it?

[10:59] Jenny Truong: I think so essentially, but I mean, we all experience this differently. We all experience like different stages of depression and different stages of burnout, and depending on where we are and like how self-aware we are, that's where we can start making a difference. It's not as easy as like, "oh, I noticed I'm depressed, I'm gonna like get out of it." No, it's like the self-awareness really helps guide you on like what your next intention is going to be.

[11:25] Mindfulness and self awareness

[11:25] Carl Vitullo: Yeah, let's dive into that a little more. So self-awareness, mindfulness, I've heard it called the somatic experience. Just sort of being in tune with what your body is telling you and understanding those messages.

[11:37] What are some things people can do, or what are some things you've done, I guess, to be more in tune with your body and pay attention to early warning indicators for burnout?

[11:46] Jenny Truong: So I went through therapy and that's how I started learning these exercises. But how I've overcome situations where I feel overwhelmed and even notice if I'm in a burnout state is, you sit in that current emotion, or that current like situation, and you ask yourself, "is this something that I should be upset about?" and then you ask yourself, "what kind of feelings am I feeling or emotions that I'm aware of?" And then you ask yourself like, "is this true?"

[12:17] These are really silly questions that I, when I first started asking myself, I thought I was really ridiculous, but once you start honestly answering them, you start realizing like, okay, it is true. Like I'm really angry right now because at myself, because I can't solve these issues and that's probably why it's taken me half the week to just do something as easy as writing a blog post. Right. But with sitting in that current state of mind and, and with working at Stately, I think of everything in, in different states.

[12:48] When you sit in that state and you ask yourself like, "is this true? Is this what I want to feel?" And how do I get out of this stuck feeling or this state that I'm experiencing, whether it's angry or like frustrated or you know, sad. You start getting to know what your limitations are and what your preferences are.

[13:07] Carl Vitullo: Yeah, for sure.

[13:09] Jenny Truong: You can even, what I've done is like write down like maybe I don't feel like visiting it right now, cuz it's a, it's like a big mental toll to like currently sit in that and like be intentional and be curious. What I sometimes do is I just write down a statement in my notebook or like a something nearby, like a sticky note, and I put it somewhere where I know I'm going to revisit like the fridge or the bathroom mirror.

[13:31] I just, I put it there and then I revisit it later, like, "oh, at 2:15 PM today, I was feeling really frustrated and disappointed in myself. What was I doing at that moment in time and like, is this something I want to visit right now?" You know?

[13:44] Carl Vitullo: Yeah, yeah, for sure. Yeah. I see someone in chat saying, using a notebook to externalize their thoughts. I, I think journaling as a window into yourself, your, your sense of self, what your body is doing, what your mind is doing. Yeah. That can be super powerful. I also have done some therapy in my life and that that was a big tool that I feel like I got out of that.

[14:08] You know, I think just being, (frustrated thoughtful exhale) making deliberate effort to be in touch with yourself, I think is, it's not easy and it is challenging, but it is, yeah, it, it is super rewarding too.

[14:21] Jenny Truong: It is, and it's really difficult to be curious, because we're like, we've grown in this society where everyone has to have their own opinions and judgment. So when you, you start visiting your thoughts and like different parts of your body, like, "okay, right now I. I feel like my shoulders are really stiff."

[14:38] Let me like, make a difference and like lose them and then make the intention to like, "okay, I wanna focus my, my energy here on my shoulders and move them." And then be more curious as to like, why are my shoulders stiff? You know, it's, it's the little things that can make a big difference long term. It's just practicing those little things first.

[15:00] Carl Vitullo: Right. Right. And it is, it's, it's all part of a feedback loop. You know, it's all part of your body and your mind. Yeah. I, I think like what you said, just sort of paying attention to, oh, my shoulders are tense right now. Like, that can be, I, that's something I do all the time, is like, oh, I'm clenching my jaw. Oh, I'm tense right now. Let me just relax and then, So like, you know, observe your physical response, adjust that physical response, consciously adjust it, and then you know that, that kind of disrupts that feedback loop a little bit I think.

[15:30] Jenny Truong: Yeah.

[15:31] States of burnout

[15:31] Carl Vitullo: So you, you mentioned thinking in states, so what are, what are, what are the states of burnout?

[15:37] Jenny Truong: Okay, so Dr. Herbert Friedenberg discovered that there are 12 states of burnout. Twelve is like an overwhelming number. When I first discovered that, I was like, oh my gosh. There's actually five really common states that you can group them together in, and it all starts in this honeymoon phase.

[15:55] You'll start getting burnt out, technically, when you become way overly excited and passionate about... whether it's a topic, or your job, or the specific types of tasks that you're doing at a company, and so we call this the honeymoon phase. Within the honeymoon phase it's just you being way too optimistic and saying yes to all the different things that you can do, but are not necessarily responsible for.

[16:23] And it starts there as simple as that. And most people don't consider this a burnout state, but if you really think about it, you are taking on more than you should. You're taking on all these responsibilities just because you're passionate, excited, and you're like, I can absolutely stay up till midnight writing all these different articles and blogs to like output, and you can't.

[16:49] Keep that momentum up for like ever, if that makes sense. You can only do it temporarily, and that's because your mind is like so shocked that this is something that you're finally able to do. You're content doing it, and that excitement is what leads you to the next state of burnout, which is this onset of stress that is like, "okay, I took on all these things. I'm totally capable, but why is it taking me longer to do?"

[17:16] And then you start realizing like, okay, am I actually capable? Because like I used to be able to write two blog posts a week, and now I can barely get one done.

[17:26] So with this onset of stress, you start doubting yourself and you start thinking like, "okay, I should extend my work hours. I should stay up until past 5:00 PM and sacrifice dinner and, and do all these different things to complete all the tasks in the backlog that I should have done last week," and so on.

[17:48] So you start making excuses on,, okay. Work is more important than going to my friend's birthday dinner or work is more important than taking a shower right now and eating dinner and so on. You know, those excuses build up. And then you reach the third state of burnout. These are the most five common states, by the way, so I'm only going up till five.

[18:08] But this third state of burnout is like this huge onset of stress where there's an end goal that you have, like this deadline you have, but you have no idea how to get there. The self-doubt gets stronger. You become cynical towards people. You start thinking, man, my coworkers are like so much better than me because they're able to make these PRs multiple times a day or even a week, and I haven't even submit one yet.

[18:34] Like you start getting jealous, negative views towards not just your coworkers, but people around you, whether it's family or friends. And then if you keep that up, then you'll reach this initial state of burnout.

[18:48] You might not be doing a physical workout, but you wake up like stiff and sore, and realizing, okay I don't wanna work right now and every day feels like a Monday. And you just wake up thinking, "Ugh, not another day. Like, where did my week go?"

[19:03] Carl Vitullo: Yeah, and I, I just wanna connect back, "waking up feeling like you've done a workout," back to what you said earlier about the physiological response to stress. It, it's not a muscle exhaustion.

[19:13] It's not, you know, you worked your muscles and did all that, but it is, you know, your, your body floods with cortisol and adrenaline and all of those chemicals, and it it, it heightens everything in your body. Everything in your body is ready to go. So it's does, it does physically drain you being in that heightened state of stress for, for too long.

[19:32] Jenny Truong: It does. And same thing with like how I just mentioned earlier, oh, my shoulders are stiff because I'm a little anxious or nervous. It's the little things that if you don't recognize, later tonight or tomorrow, I'm gonna figure out like, oh man, I felt like I just lifted a whole sofa, because my shoulders are like constantly up towards my ears. Yeah.

[19:51] Carl Vitullo: Right.

[19:52] Maybe you didn't lift, you know, 50 pounds, but like, what is lifting? It's in terms of duration of a workout, it's a couple of minutes. Whereas if you're, if you're stressed and your muscles are clenched for eight hours. Yeah, I you know, it's, it's a lower expenditure of effort, but it's over a much longer period of time.

[20:09] Jenny Truong: Yes. And so that's, that's why our bodies feel that tension, it's like that tension that's held there for like a long period of time, that's why you're sore the next day. And, and, and it's like, it could be natural. It could be like, okay, I'm used to slouching or I'm used to keeping my shoulders like up towards my ears.

[20:27] And, and your body's basically telling you the next day, "Hey, you've done this for too long, can you stop?"

[20:34] Carl Vitullo: Right. Yeah, definitely.

[20:36] Jenny Truong: One more. So we reached the last state of the most five common states of burnout that people experience. And that last, that last state is like very bad. So it's technically called habitual burnout, but. It's all burnout in a sense. Like no matter which state that you're in, it's very detrimental to your mental health and physical.

[20:57] And so that last state is where it's too late to turn back essentially. And you can't really mentally get out of it yourself. It's very highly recommended that you seek medical or external expertise because at that point, like your mind isn't going to be intentional anymore. It's just like, It's really hard to describe, but in my eyes it's, it's the point where you just become unmotivated to even get outta bed.

[21:26] Carl Vitullo: Sure. Okay. Yeah I think habitual burnout, unmotivated to get out of bed, that's where it does start sounding like it has a lot of symptoms in common with depression.

[21:37] Jenny Truong: Mm-hmm.

[21:38] Carl Vitullo: Yeah, for sure.

[21:40] Jenny Truong: And that's where that type of burnout can lead to depression. And there's a lot of similarities between the two, and I highly recommend that you research the difference if it really, if it, if you think it's something that affects you. But if you're intentional, if you can try to be, if intentional with the things that your mind and your body are experiencing, that will help so much in recognizing like, okay. Where am I in this state of, whether it's burnout or in your mind, and how do I get somewhere where I want to be?

[22:12] Carl Vitullo: Yeah, so you mentioned these are five stages of burnout that you pulled from what you can, can you say the name of the researcher again?

[22:22] Jenny Truong: Dr. Herbert Freudenberger? So he's a German-American psychiatrist that researched, you know, all these different types of burnout. One of the reasons why he researched it is because he feels like helping professions suffer more than most other professions. And what I mean by helping professions is like, People in like sales where they're constantly putting out effort to help people outside of just themselves and people in the medical industry.

[22:50] And he also mentions like people in the tech community very briefly, but to me, like I think the tech community and developers we're all in this helping profession because we're building tools that affect people more than just us.

[23:04] Carl Vitullo: Sure. Yeah, that makes sense. You're, you're concerned for others' needs maybe in a very abstract and technical way, but Sure. Yeah. So just to, to restate the, those five stages of burnout. So there's the honeymoon period, the onset of stress, chronic stress. Then like initial burnout and chronic burnout.

[23:24] Jenny Truong: Mhm, yeah, those are the most common if you were to categorize all 12.

[23:28] When to seek help

[23:28] Carl Vitullo: Sure. Okay. You know, this is gonna vary a lot, person by person and situation by situation, but, there are tools you can use to sort of manage your own stress and your own levels of burnout. Do you think somewhere along those stages you cross the threshold where it's now the stress has become so chronic, the burnout has become so deep that it's now clear, more clear that external help is, will be needed to get yourself out of that state?

[23:57] Jenny Truong: Personally, I like after researching all of this, I think once you reach any state of those five, you should seek help. Because like let's say you're in the first state and you're like saying yes to everything, because yes, you're capable, but you don't have enough time. And I say that because you only ha you should only work 40 hours a week.

[24:16] If not less. And so like when you're in that state and you start realizing like, oh no, I don't wanna get burned out. You can, you gotta put up your boundaries, your work boundaries, and you gotta put up, like, you gotta realize, okay, I myself am a priority and if I can't prioritize myself that I won't be performing at my best.

[24:36] You know, like any state of burnout that you might think you are in, that's where you should seek some type of help. And it does. Some people don't have resources to therapy, right? So you could reach out to even friends and family that you trust enough to listen and, and that you look up to, to seek advice from it.

[24:57] It can just be a relative or a best friend or someone in your life that you highly look up to, and I'm sure they're gonna be concerned for your health as well.

[25:07] Carl Vitullo: Yeah, for sure. Yeah. Maybe even a Discord community.

[25:10] Jenny Truong: Absolutely, and I will say I personally find comfort in talking to a stranger, which is why I talk to a therapist rather than my family, because they're less judgmental.

[25:21] Carl Vitullo: Right. Yeah. That is something that I've thought about a lot in my life is there is something a little freeing in talking to someone who, you know, you won't have an ongoing interaction with, an ongoing relationship with it. You can just kind of, you overlap for what, however long you do, and then you each go your separate ways.

[25:41] Whereas if you're talking to family, if you're talking to someone who knows you deeply, maybe there's so much context there and so much future that it, it can be hard to get into those harder subjects.

[25:51] Jenny Truong: And there's also judgment. We're raised in a society where we have to have all these judgments, and yes, we are allowed to have feelings and preferences, and yes, it is true, but we don't have to push that on people.

[26:05] Carl Vitullo: Judgment, I think is I, so something that I think many of my friends would, uh, I, I think I make a point of talking about sort of the contrast between judgment and curiosity, like, uh, So many. I, I think it is so much more. I think it's very freeing in your life to be conscious of, am I assigning a judgment to this?

[26:26] And then consciously derailing that and saying, no, like, how can I be curious about this? What about instead of looking to dismiss or assign some kind of value or lack of value to, how can I be curious about this?

[26:41] Using curiosity instead of judgement

[26:41] Jenny Truong: In therapy, that's where I learned to ask the question, is this true? If it's true, is it an opinion or an emotion or a fact? Like what I mean by is it true? Is is this a fact? And if it's not a fact, then ask yourself why. And it doesn't have to be blaming like, oh, because I, this is what I was raised to think.

[27:00] It could just be. Like a curious why, like why do I feel this strongly about this topic or this statement or this emotion, right? And so with understanding, okay, this is not a fact, so it's not true. And digging deeper into that, like that's where the, you can help yourself become more aware and you also become kind kinder to yourself in a way.

[27:20] Cuz then you realize, okay, I am being judgmental. Whether or not I have reasons to be judgmental and where they stem from doesn't matter. It's the fact that I just noticed this is not a fact.

[27:31] Carl Vitullo: Sure. Yeah. Right. I think that, I think that is really powerful. It, it, it, it feels almost trite and too small to be as. Powerful as it is, but it is, I think if, you know, it's, if, if you can bring that energy of sort of interrogating your own thoughts a little bit just now and again, you know, o okay, there's, there's also unhealthy rumination, like you can do it too much, but interrogating it a little bit and just trying to better understand your deeper assumptions that you bring to the world.

[28:02] Yeah. I think that that can be really powerful to inform what am I judgmental against? Should I be, are there good things in there too?

[28:09] Jenny Truong: It definitely encourages you to, one, be more self-aware, but two, just be more open-minded.

[28:16] Carl Vitullo: Open-minded. Yeah, definitely. There was a, a, a comment in, in the chat that I, I think would be good to talk about.

[28:23] What about the junior devs?

[28:23] Carl Vitullo: What about the juniors who are trying to get a job? There's no way to work 40 hours and still. Get a place. I think that that's something that I've been aware of in my, my thinking about sort of mental health and where I'm at in my life is I'm 10 years into my career, like I am established, you know, I can go to a conference and network with people and like I'm, I, I have arrived in a se in a way that people who are earlier in their career haven't, and yeah.

[28:49] So I guess like thinking about stress and burnout and managing all of that. Do, do you have any, yeah. What, what do you think about, thinking about stress and burnout early in your career when there is so much external pressure to overwork?

[29:04] Jenny Truong: I find this as an opportunity to redefine the different rates of productivity for everyone on your team. Right? And I know it's like, it's like a dangerous topic to approach because you're like, well, I wanna overwork because I need to show my worth. And then that's where I move up on the ladder or stay at a company, cuz if not like they'll hire someone else.

[29:24] That's the fear. That is all fear that society puts on you and it's all false because, In the end, if you can, like, this is my own personal belief and from my own personal experience, but if you can redefine what your work boundaries are, the people in like, and if they're decent people, they will respect that and say like, okay, this person strictly shuts off and doesn't check their emails after 5:00 PM.

[29:50] You know, it's like the little boundaries that you can place to make people respect you more and. I'm going to have a lot of people disagree with me on this, but. It's what I firmly believe and what I have done at, even at this startup, at state leader ai, like that's what I tell people. And then, you know what?

[30:08] All my coworkers started doing the same thing after 5:00 PM We don't check Discord, we don't check our emails unless it's an emergency. Then my boss will reach me on my cell phone and tell me like, Hey, we really need this fixed now. Like it's a major bug. And, and that's when I know like, okay, I'll sacrifice this amount of time to fix it, but then the next day, I will remind my coworkers I took three hours, so I'm gonna take like a two and a half hour lunch, for example.

[30:35] That's my advice to you, to be that person, to start that movement essentially, and normalize the way we should respect each other in the workplace.

[30:44] Contrasting burnout in tech vs other expert fields

[30:44] Carl Vitullo: Yeah, for sure I can. Yeah, I can definitely empathize with that. I think it's, cuz it is a, it's a cultural thing on a team. It's a matter of, having healthy boundaries within work is definitely super important. I've thought a little bit about sort of like other career paths. Like, you know, people talk about doctors and burnout and lawyers and burnout.

[31:05] You know, those are two industries that in a lot of ways have rigidly codified around, burning out new entrants into the, into the field. And I think tech is not quite so rigidly, you know, in that, you know, there's not like the, you know, you, you graduate medical school and you get your first, your internship and your residency.

[31:28] And like I hear, I've talked with friends who've done that path and it's like, " You do what? You worked for, how long straight, and you were responsible for people's health and lives?" So yeah, I think tech does have more of an opportunity than some fields to set those boundaries. But at, you know, on the flip side, when you're scrambling for any opportunity, I guess it can be really hard to come into it with your own, it, it can be hard to set boundaries.

[31:56] Jenny Truong: It is hard, but that's where like, that's where you have to ask yourself, like, is this gonna be worth it for me to risk, let's say the next six months on being a pushover and being like, and I'm sorry if I said pushover as a strong word, but I consider myself a pushover when I start saying yes to people, to helping them.

[32:16] And so I, I'm basically reflecting on myself. You have to ask yourself like, is this gonna be worth it for six months? Because if it's not worth it and then you find out that you've been putting all this hard work in and your employer is, is just not going to promote you or not even going to recognize your work and then claim that work for their own, that's when you need to get out of that workplace and find better opportunities.

[32:39] Cuz there are people out there, there are decent people out there, but there's also a lot of non decent people out there.

[32:44] Carl Vitullo: Yeah, a lot of people who will happily exploit you for whatever energy you're willing to

[32:49] Jenny Truong: Yes, and that is where you need to understand. This place is not for you if they're going to exploit you for that.

[32:56] Carl Vitullo: Yeah. Yeah. And maybe, maybe another way of thinking about it is, so talking about like the honeymoon period and going, yeah, I can do everything. I can take on everything. And then the, into the onset of stress, maybe a, a similar but distinct way to think about a situation like that if, you, you know, I'm trying to put myself in the shoes of someone early career who wants to get ahead, wants to give it their all.

[33:21] Maybe a way of thinking about it is of going into it sort of with your eyes open, aware of burnout and stress as a serious risk, like it is genuinely a risk. It's not something that you can just gloss over and say like, no, it'll be fine. But that, like you were saying about, you know, thinking about it like six months.

[33:41] So like if, if, when you take something on, considering how long you are willing to over commit yourself and how much, you know, how long you can go at a, at above your capacity.

[33:52] Jenny Truong: This also reminds me of like a practice that I started doing. Uh, so I've only a little bit of background on me. I've only been in tech for three and a half, if not four years, including an internship fresh out of a university. And what I started doing after I found out I was completely burned out the first two years of working in tech was that I don't voice.

[34:14] What my limitations are and what my boundaries are. So when you, let's say you're in the honeymoon phase and you're so excited. You just got your first job and this is the first company that is willing to, you know, invest in you.

[34:25] What you can practice is, is when people ask you to do these favors or these tasks that 4:59 PM is, you can tell them, " I will do this task even though it's not technically part of my responsibilities. I'm happy to take it on and help you achieve it, but I'm not going to work on this until the following workday." Or you can say, I will work on this, but I hope that my lunch will be extended the following, workday and so on. So like, it's kind of like a trade off you.

[34:56] You have them recognize that you're sacrificing something to help them out. And then in trade, like you trade for either more time to do things for yourself or eat lunch, or you just, you gotta put that boundary out there in the beginning so then they can also recognize, oh, you're right. Like I shouldn't be asking someone to do a task at 4:59 PM.

[35:20] Carl Vitullo: Right. And so maybe that, that makes me think of boundaries as less like hard lines in the sand. Like, oh, I'm not gonna do anything after 5:00 PM on a Friday. But maybe more like, okay, that's a good boundary. I don't want to say not to do that, but thinking of boundaries as your available capacity, maybe.

[35:40] Mental inventories

[35:40] Carl Vitullo: Maybe this is a good segue into, uh, as we were preparing to get on this call, you brought up the, the idea of like a mental inventory. And so I'm thinking of sort of like, maybe part of setting boundaries is sort of that, being aware of how much you can work, how much of yourself you can give, and then, you know, the follow up the upkeep work is that mental inventory of saying, what am I doing? How much of my capacity am I using? Could you talk a little bit about that idea of a mental inventory? Um,

[36:11] Jenny Truong: Yeah, so part of that mental inventory is, is knowing what your priorities are. So if you prioritize yourself, then you can put that respect and reserve for yourself, so you respect yourself enough to let others know. You can contact me after 5:00 PM. I may or may not respond, but like, just the fact that you can put it out there so people understand, you know, you're not going to be working those prolonged hours just to, just to sacrifice, you know, life.

[36:41] And so part of that mental inventory is, is self-awareness and recognizing, but also putting those boundaries out there. So then, you know, Not to burn yourself out. And I know these are like practices that you'll achieve later when you're early on into the burnout stages, you're not gonna know where to start, how to get there.

[36:59] It's gonna get overwhelming, but you just start small with either writing those sticky notes and putting them around the house where you constantly visit and then yeah, and then accepting like, okay, you're right. I told my coworkers and my boss, I wouldn't be working past 5:00 PM so I'm going to actually take action on this.

[37:17] And then you be responsible for yourself.

[37:19] Carl Vitullo: Right. Ultimately, we are all responsible for ourselves. No one else will look out for us.

[37:25] Jenny Truong: Yes.

[37:25] Personal boundaries and 7 types of rest

[37:25] Carl Vitullo: ( nervous laughter) Yeah. I, and I guess I also wanna contrast, we've talked a little bit about, you know, sort of like time cutoffs and keeping like, working hours. I have always been a very erratic person, you know, like ADHD and whatever are among my diagnoses.

[37:42] So the idea of like getting up at nine in the morning and like working until five with like lunch break has always been very, I don't know, it's grated against me a little bit. So I, I personally have found it very helpful to say, "I will commit this time, this energy that I have to this project, to this company. But like, don't tell me when to do it." I kind of chased my inspiration personally, just for myself, over working 10, 15 years now. I have learned ways to sort of lean into those quirks of how my brain operates. Like, okay, I'm adhd. I struggle to. Do small rote things, but when I, when I get inspired, it's just best to lean into it.

[38:25] And if I get inspired at 11:00 PM on a Tuesday, maybe I'll work until two in the morning because that's how my brain works. Then I'm in it. And if I'm not in it right now, then it's, I'm not gonna do as if I try to come back to it later, I won't get the same out output. Yeah. But like still coming at it with that sense of managing your boundaries, managing your capacity, and being in tune with your, with what your body's telling you. I guess.

[38:51] Jenny Truong: I want to start by saying that you're in a very fortunate place where you can work remotely and schedule your own work hours.

[39:00] Carl Vitullo: a hundred percent.

[39:01] Jenny Truong: And not all of us are able to schedule our own hours or even work remotely. So this is where the seven types of rests come in, that I absolutely encourage people to explore the seven types of rests, whether it's in a book or a podcast that you come across.

[39:19] Look up the Dr. Sandra Dalton Smith. Take a look at her TED Talks. Take a look at like different articles that, um, she's put out there and all the research that she's done, and find one of these practices to do for 15 to 30 minutes a day in between the different tasks that you're completing. Because when you are constantly using your brain to solve critical problems, you are becoming deficit in other areas, like in that mental area, but also different areas like haven't been touched yet in your brain.

[39:51] And so what she, what I mean by the seven types of rest is that as humans, like we experience so many different things, thanks to the different lobes of our brain being active, you know,

[40:02] Carl Vitullo: Sure. Oh yeah, that's actually, I like that framing of it. Sort of thinking of the different areas of rest as different parts of your brain being in use and letting some of them rest and some of them, you know, like, like give an analogy of a workout. You know, you have arm day and you've got leg day.

[40:18] Jenny Truong: Yeah. Different parts of your muscles that you are putting attention towards, right? So with your brain and, and discovering like what types of rest deficit you might be in, you can just be like, okay, well you know what? I don't want to like, think critically. Anymore and I need to just take a nap and that's like a physical rest.

[40:36] And we can go into the different seven types of rest if you want or if not, I highly encourage, I want to look her up. Seven types of rest by Sandra Dalton Smith.

[40:45] Carl Vitullo: Yeah, I, let's get into the seven types of rest.

[40:47] Jenny Truong: Okay. Yeah, so within physical, which is the first type, you have passive and active, and so you can look into passive as sleeping. Putting your body and your mind into a state where like it's just temporarily idle and on hold and not like exerting physical activities. And then you have the active rest, which is stretching or massages or doing some type of, just the fact that you can just push your shoulders down when they're like raised up really high because you're stressed.

[41:16] Just the fact that you doing that is letting your body physically rest. Then we have mental rest, which is the critical thinking and solving problems in order to rest mentally. You can go shop for groceries and find items in the grocery store or check out your to-do list and start crossing things off that you've already completed or even cooking if, if you're able to cook and follow like a recipe that doesn't require too much thinking and cut vegetables or meat, that activity gives your brain a chance to mentally rest.

[41:48] Then we have social rest, which is where you spend too much time and energy trying to have a conversation, like, I'm gonna be socially drained after this. So one of the things I'm gonna do after our chat is to just sit alone and put my phone on silent and not answer any phone calls for 15 to 30 minutes.

[42:06] That's how much I've realized that I needed in order to socially rest and distance myself, and then be able to have another conversation again and not feel overwhelmed. Some people it could take five minutes. Some people don't even need that type of social rest.

[42:21] Carl Vitullo: Sure.

[42:22] Jenny Truong: Yeah. Then we have spiritual rest, which is, think of it as like helping people outside of what can benefit you.

[42:30] So you could volunteer, you can do activities that are faith-based, like praying it. It's the fact that you're, the actions that you're doing are not going to just benefit you. That's the type of spiritual rest that you can explore. Then we have sensory rest. So with working in tech and always being on the computer and on my phone, there's always emails and pings that I get from discord of, of people needing me for whatever it is they need me for (laughs).

[42:58] Carl Vitullo: Right.

[42:58] Jenny Truong: Yeah. That sensory rest could be as simple as like, okay, shutting off your phone, or if you can't do that, put yourself in a dark room and just have your eyes dilate and like, get used to a different type of environment, so then you're not constantly having like sunlight or the light in your room, like glared into your eyes or the screen of your computer, like constantly putting your eyes to work.

[43:23] Sensory rest could be as simple as like, what I do is I take a bath once a week and I light candles, and the smell is like a sensory rest. To me because I don't usually smell candles all the time. And same thing with like submerging myself in water, like my body's in a different state where like I could be floating or like it's getting warmed up by the heat of the water and so on.

[43:46] You know, that's a sensory rest, which also leads me to creative rest. Creative rest is where you explore different things that are. Not in your comfort zone. So like for example, you might be used to being in your house nine to five, and a creative rest could be just taking a walk. Or what I do is walk my dog.

[44:07] Some people don't have pets, so it could be as simple as just sitting outside and like staring at nature and look at the ducks, fly by or like, you know, waddle by or even if it's like, if you're in a cold place, it's probably not snowing anywhere where you all are right now. But if it is like, it's just as easy as watching the droplets fall from the sky and, and that itself is a creative rest or working at a cafe.

[44:34] If you work from home and you have the flexibility, put yourself in an environment that you're not commonly like placed in and that you're kind of uncomfortable with. And that's where I don't want people to like force themselves to be uncomfortable, but the fact that you can like place yourself in an area where you're not normally in that itself is a creative rest.

[44:54] And then lastly, we have emotional rest, which is where you're intentionally trying to be there in a conversation and, and like uplift the other person. My experience with emotional arrest is that before tech, I was in the beauty industry, the cosmetology industry, and I constantly had to tell people like, yeah, like your hair, your skin, your nails look great, and like, I'm gonna do the best job that I can for you.

[45:21] But that gets straining if you're working 10 hour days at a salon, which is what I used to do. And then after a couple days, if not a week, I start getting. Emotionally drained where I can't really fake the, Hey, how are you? Like, I'm so excited to see you anymore, and that's where I need that emotional break.

[45:41] And just to be honest with the client and say, listen, I can't do these services for you. It's such a high demand that you're asking from me. So I can either have another esthetician help you or I can refer you to a different salon. Like it's the fact that you're being honest. And you're not forcing yourself to smile and, and put services on the other people where you're not having the most effort put in, if that makes sense.

[46:08] Carl Vitullo: Yeah. Right, right. As you were saying that, I was just thinking, yeah, that is emotional work that is being responsible for others' emotions is work. Taking a break from that is definitely important.

[46:19] Body and mind influencing each other

[46:19] Carl Vitullo: I also wanted to go back to what you were saying about like taking a rest, taking a bath with a candle and whatever that was, you know, close to 10 years ago now, I was working with a therapist for the first time, like seriously in my adult life.

[46:33] And that was something that they explicitly told me as like one form of treatment that was useful for me. So, you know, like your mileage may vary, but the justification being like, Tying it back to, you know, mu mu musculature and all sorts of those things like when you're immersed in hot water, your muscles relax, the warmth and the, you know, the pressure is a physi, it will physiologically trigger your muscles to relax.

[47:00] And so, you know, for me, at that time in my life, I was very stressed. I was very strained. And this therapist I was working with advised me to take a bath, come up with a little mantra that you repeat to yourself and then when you're feeling extremely stressed, when you're in this, you know, in that most acute point of stress, now you have a touch point.

[47:21] Use that mantra to summon the feeling in that moment and just to take the edge off of that stress a little bit, and that really stuck with me as such a, it's such an easy and powerful thing to do.

[47:32] Jenny Truong: But it's hard to also mentally like pause on what you're working on and like be able to relax and do that. Before I took baths. I would like not be okay. Like when I first started taking baths, it was really hard to like not think about all the different things in the backlog that I was supposed to complete, you know, so, It's practice.

[47:52] You just gotta try it gradually. And here's another thing, you can do the opposite of a warm bath and do an ice bath. That actually really helped me snap out of whatever current thing I'm thinking about and like be immersed in fear that this is gonna hurt. And then like, it's like a quick 32nd dip and then like get out and then you feel so refreshed.

[48:14] And if you can't, like let's say you don't have a bathtub and you can't like, Take an ice bath. It could be as simple as getting a big bowl that is as big as your face and dipping your face in like a bowl of ice for 10 seconds, for a full minute, if that. So it would be like six times, 10 seconds, ten second rests, or it's not six times.

[48:34] It's like three times I think. I can't count. But you know, just the fact that like you can do that to your brain and your body. It could be like a mental pause on like what exactly is stressing you out and then really help you understand like, okay, you're shocking your mind and your body to where it can pause on exactly what is currently freaking you out in the moment, and then putting you in a different state of mind of whether it's fear or relaxation or, you know, that ice bath would make me fearful until I did it, and then I felt so refreshed afterwards.

[49:08] Carl Vitullo: Yeah. Yeah. I, I love that it is like a, Sort of a hacking your body to influence your mind.

[49:15] Jenny Truong: Yeah, that's one way to put it.

[49:17] Carl Vitullo: Yeah. Yeah. I, you know what, like, it's all connected. You influence one thing and it'll affect the other. Well, we're coming up on an hour here. I did want to, so I, I had looked up Dr. Sandra Dalton Smith and found she has a book called Sacred Rest.

[49:32] Are you familiar with that?

[49:34] Jenny Truong: I am, I actually haven't read the full book yet, but it goes into so many details on like what your human, human body is capable of, and the mind. So if you have the time, let's. Listen to the podcast or read it. There's also plenty of articles that she's written as well.

[49:51] Carl Vitullo: Yeah. Okay. Yeah, I came prepared with a link to that, so yeah, definitely, like if you're feeling stressed, if you're feeling burned out, maybe that's a good resource to, uh, learn some tools to rest. Just good for everyone. Everyone gets stressed. Everyone needs rest. All right, Jenny, thank you so much for coming out.

[50:07] Before we close, anything else you, uh, you wanna close on?

[50:10] Remember you're human

[50:10] Jenny Truong: Yeah, so just a reminder that you are human, okay? You can only do so much. But if you push yourself too much, please try to recognize it and realize you're, you're just human. Do as much as you can for other people. You'll get to a limit where you can't anymore. And then you're gonna think like all these negative things about yourself.

[50:30] Don't do that. Try to be intent, intentional in experiencing life as a human.

[50:35] Carl Vitullo: Yep. We are all human. Be intentional about experiencing life. Great. Great place to close. Awesome. Thanks so much, Jenny.

[50:42] Jenny Truong: Thanks for having me.

Communication with Elizabeth Woolf

Reactiflux — Wed, 17 May 2023 16:00:00 GMT

Elizabeth Woolf

Carl Vitullo: Thank you everyone for joining us for another Office Hours. I am Carl Vitullo, community manager of Reactiflux, here talking today with Elizabeth Woolf, who has recently started a new business doing communication coaching for engineers. Yeah. Elizabeth, can you introduce yourself a little bit? [00:16]

Elizabeth Woolf: Yeah. Hi everyone. It's awesome to see you, even if you're just bubbles. I will say I am just absolutely stoked to be here. I respect the hell out of engineers and I wouldn't be here unless I did. My day job is I work in product management, and then my company that I decided to start because I saw just a huge gap, is coaching engineers and not in the cheesy sense of like, let's help you get to your dreams and like sail above the clouds.[00:45]

"Soft skills"

Elizabeth Woolf: It's, I want to give people the skills to be damn good communicators because that helps accelerate a career and it's a skill. That's not talked about and it can be taught, it's tangible. So that's kind of why I decided to start this in January, and I hope you all learn like one or two things today. If 10, that's even better. [01:05]

Carl Vitullo: I think a lot of people talk about soft skills, but I, I think a lot of the time the conversation kind of stays right around that level of specificity. Yeah. And like it's not very specific, like when people talk soft skills in interviews, (laughter) I think a lot of it is left sort of unsaid as like cultural assumptions. [01:22]

Elizabeth Woolf: Yeah, right. Definitely. It's also like cultural and it assumed to be, like, almost emotional. So having this degree of, like, an EQ or being able to be soft and empathetic, but I think there's a lot of it on just the business side that makes you have a really kick ass team if you guys communicate well. [01:42]

And, yeah, the empathy part might be a part of it, but it's also so many other skill sets that come in it. [01:47]

Carl Vitullo: Yeah, for sure. So like emotional side of things, sure, like empathizing, being able to read, read a room, read other individuals on the team. What, what are, what's some other skills that you think are important to develop around there? [01:59]

Elizabeth Woolf: So let's, we'll call it the pinnacle of like all things and it's also the scariest of all things. I think it's feedback. [02:06]

And there's two sides to it. There's like, you are giving the feedback and there's also you are receiving the feedback. And the people who are really good at this, and I've seen them in my career, they climb whatever ropes you want to assign to whatever role the fastest. [02:20]

And when I started my career, I knew nothing about it. I avoided it like the plague. It made me feel uncomfortable and scared. It was a fear of mine. And some days it still is, but I think because there's ways of actively practicing it, it becomes a lot easier. [02:35]

There's a site I used to, not used to, I still follow. It's called Lead Dev, if anyone's ever tried it. And there's a woman who spoke and she said, "fears are our best clues as to how we can be amazing." I was like, holy cow. And so it's just, fears aren't who we are. Feedback is scary and it's not something that's irrevocable. So it can be taught. [02:54]

And if you name 'em that, that was a big thing for me. Like name what your fears are. If they live in your head, they kind of explode and fester. But if you can write 'em down, make them conscious, make them real, you now have more power. [03:07]

So I think that would be a first step, is you name what your fears are with any, any type of talking that you're doing, cuz there's ways you can address them. You gotta know what they are first. [03:16]

Carl Vitullo: Right. Yeah. I think that that, that makes a lot of sense and is also super hard. I think. [03:20]

Elizabeth Woolf: Oh, yeah. [03:20]

Carl Vitullo: I think maybe another way of framing this is what you're afraid of is things that you're uncomfortable with. It's, you know, when people talk about getting out of your comfort zone, that means selecting to be uncomfortable. [03:32]

Yeah. So like what you said, you know, if you can, name your fear, take it from something subconscious, you, your, your mind is just sort of pushing you away from it, helping you to avoid because it's uncomfortable. [03:44]

Elizabeth Woolf: Yeah. [03:44]

Carl Vitullo: By naming it, you can begin to understand it, and as you understand it, you can figure out how to adapt to it or, or to use it, you know, use it to your favor. [03:53]

Elizabeth Woolf: Definitely. It's all like you, you now have ownership over it. It doesn't control you. You control it, which is the best point to get to, and I'm not gonna sit here and tell you it's like sunshine and rainbows. It's not, it's a lot of growth, but it's, God, is it worth it? It's so worth it. [04:08]

Fear of feedback

Carl Vitullo: Yeah. So you mentioned fear of feedback. Fear around feedback is something that you've had to overcome. So like if you, if you don't mind, like, well, how did that sort of manifest? [04:18]

Elizabeth Woolf: And I hope all of you here with us can also think through how your fear of, fear of feedback manifests. That way you can hopefully go on the journey with us of conquering it. [04:29]

My fear of feedback started when I probably was, like consciously started, when I started my career. I started as a people pleaser where if someone said a task, it was now mine, regardless of time, energy, anything. And before you know it, you are burnt to a crisp. [04:46]

And so I got feedback of, "you take too much on." And then it grew to, because I had so much, "your self-confidence is shot. Like you, you don't have any anymore." And that lit a fire in my head. I'd never have someone told me that to my face. It also was delivered pretty poorly. And that's another part we can talk about. [05:06]

Carl Vitullo: Okay. So in this case you, you've received feedback that received, you had taken on too much. Yeah. Okay. [05:11]

Elizabeth Woolf: Which I think a lot of us start our careers that way. You start being like, experience is great. I'm gonna take it all on (laughter). Sure. Then it's like, "oh God, what have I done?" [05:21]

Carl Vitullo: Sure. You take too much on, you get a, you get your first dose of, oh God, I can't do all of this. [05:26]

Elizabeth Woolf: Yeah. I also know I have colleagues who they can be afraid of their own selves. So in the beginning of their career, it can be you're afraid to take on anything. You don't trust your gut, you don't trust that growth, or the opportunity is scary. And because of this, people can notice. [05:40]

Carl Vitullo: Yeah. I've definitely felt that in my own career. I think, yeah. I, something I've really had to fight to overcome is sort of feeling like, "oh, I don't know how to do this, so I can't." (laughter). [05:51]

Elizabeth Woolf: Yeah. [05:53]

Carl Vitullo: And just, and like recognizing that and realizing like, oh no, I'm just scared to do this because learning something new and trying something hard is just an intimidating prospect and pushing through that fear. Yeah. [06:03]

Elizabeth Woolf: Yeah. And think of, you can also insert that fear with, and I'm gonna use the word again, feedback. For anyone on this call who is in an engineering role, and you want to continue to excel at that role. I will stress that this skill is gonna be a powerhouse for you. And the earlier you learn it, the earlier you get comfortable with it, the more you can grow through it. [06:24]

And so if earlier in your career you find yourself stepping back from different projects, it's, it's that similar feeling. But um, as we talked about fears, name 'em, and then find someone to help you step into them. And I promise you those people, that the ones that speak are the ones who like, grow through their career [06:42]

Carl Vitullo: Speak as in, provides that feedback? [06:45]

Elizabeth Woolf: Mm-hmm. [06:46]

Carl Vitullo: Yeah. For sure. [06:47]

Deciding whether to give feedback

Carl Vitullo: Yeah, so how would you, how do you go about deciding whether something is worth giving feedback about? You know, say you have maybe a fraught situation on a team, like you think somebody overstepped their bounds. Like what, do you have any sort of tools for evaluating that? [07:02]

Elizabeth Woolf: Yeah. Something that, it's gonna sound probably funnier than it should, but like your gut is gonna punch you (laughs), you're gonna see it. Our observational skills are impeccable. Like we really do have really good observational skills. [07:14]

It's just that voice of fear is gonna help shut it down, and also try and keep you safe. If you don't say anything, it's so much more comfortable that way. And I've been there many times. [07:24]

The thing is though, once you hear that voice, it's like… it's retraining yourself. It's almost like driving on the opposite side of the road. Like, wait, I need, and I now need to be on the opposite side. It's a conscious response. [07:35]

Carl Vitullo: Okay, sure. Where the, the comfortable side is, the people pleaser, you, you just wanna make everyone happy and smile and you just, buckle down and like, okay, I can ignore this. This is fine. [07:45]

Elizabeth Woolf: Which is actually a form, and it's just, this is also ironic, like that's a, you just chose feedback, you chose inaction, you chose silence. [07:52]

And I would encourage you in those moments to think about, if I said something and it landed well, cause I knew how to say it, like, what would happen. I just know a lot of, I've worked with engineering teams where they chose that silence, and I've also worked with engineers who are so good at giving feedback, and I just, the ones that were the teams, their output was just bananas. [08:12]

Like, (laughs) you just, you move faster and you move differently, and hiccups aren't the same. So yeah. That's why I, I love it like a celebrity. [08:21]

Trusting your gut

Carl Vitullo: Yeah, haha. Yeah. Okay. So trusting your gut feeling. [08:25]

Elizabeth Woolf: Mm-hmm. You'll, you'll observe it, you'll know it. [08:27]

Carl Vitullo: Yeah. I, I, I can definitely think of a couple times where I had a genuine physical gut feeling in my career when I, one of the, one of them, one of the ones that stands out most strongly in my mind, I woke up one morning with this pit of dread in my chest before going to work, it, it had been a, a, a rough couple of weeks at work, and it, the trajectory didn't look good. And I remember I said to my, uh, my partner at the time, I said, I think I have to quit. And so I, I drafted and printed out a letter of resignation, like on my way to work, and I quit that day. [09:01]

Elizabeth Woolf: Holy cow. [09:01]

Carl Vitullo: So, yeah, that was, that was a pretty, that was a notable gut feeling. [09:05]

Elizabeth Woolf: Was the pit growing? Did the pit grow or was it like you [09:08]

Carl Vitullo: Yeah, and it was some, this was some, this was like a couple of weeks of like, giving feedback. You know, I would go on one-on-one walks with my manager and I would try to talk through this issue and just like kept hitting these walls where it's like, okay, my feedback is being rejected. [09:21]

I'm, I'm trying to be very like, diplomatic and like navigate tough waters because it is hard to give feedback. [09:28]

Elizabeth Woolf: A million percent. [09:29]

Building feedback into team culture

Elizabeth Woolf: Yeah. I, I will say too, um, it's also gonna be really hard if you're in a culture that's like super positive feedback focused or if you're in a culture who just doesn't say anything. [09:39]

Like those are definitely barriers. If you're an a leader, an engineering leader, like I cannot encourage you more. You have a great, now, platform to do this, cuz the people who, people will follow you. So if you decide that you want this as part of your culture, it's gonna happen by osmosis. You just lead by example. [09:57]

But it's really hard, especially if it doesn't start from the culture from day one, which is not normal. [10:03]

Carl Vitullo: Right. Building a culture is hard, changing a culture is harder. [10:07]

Elizabeth Woolf: Oh yeah. Yeah. And there's like, very few greats, that have been built on feedback. Like I know Google is especially good at it. I've talked to people who, they get like a 360 experience. [10:19]

And then also your managers, your coach, I've watched before. And then I know Netflix, one of their values is around feedback. So I mean, they've done some good, they grew pretty fast. So it's not completely painful, it's just you gotta get used to it. Like learning a new language, which is kind of how I like to equate it to. [10:38]

Carl Vitullo: Sure. It's, it is, it is a new form of communicating. Yeah. Yeah, definitely. [10:43]

Giving upward feedback

Carl Vitullo: Question in the chat about the context for feedback. Yeah. Feedback to managers, colleagues. I think that's, I think that's a really important distinction. Let's, let's narrow down to giving upward feedback. Let's say you're talking to your manager or to, to your skip level boss. [10:58]

Yeah. How would you think about whether to give feedback, and some specific ways to structure that? [11:05]

Elizabeth Woolf: A hundred percent. The first thing is do not in any way, shape, or form, I would never recommend like just come out of the blue and spurt it. And also don't do it in a public setting. Like I would keep feedback, always keep it private. [11:16]

Something that helps a lot for human beings is if you quote-unquote, "set the stage," so if they know it's coming, you can have their emotions get heightened, and then release. Because there's something beautiful about humans is our emotions. They feel intensely, but 12 to 24 hours later, they're not the same as they once were. [11:34]

So if you can tell someone the feedback's coming, it just helps a lot for their brains to be in the right place. And then when it comes to delivering it, I want, this is the stuff I'd probably want you to write down is like, You gotta make it specific and tangible, and you can't call out the human person, you gotta call out the behavior. [11:52]

And the way I want you to structure it that has worked really well for me, and again, I've done this to people who are CFOs, so it worked really well, and they are people who are very methodical. All the numbers need to add up. [12:02]

So the first step, start with the behavior. What specifically did they do? One sentence. And then you gotta tell them the outcome cuz something happened because of it. So what outcome did that specific behavior cause? And then the most important thing is, ask for their perspective. [12:21]

There's a whole book about this too. Like if you had this kind of conversation, you never ask for their perspective, the number one thing people wish that had happened was they just asked like, "what was my perspective? How did I perceive it?" So now we're at three, we're at behavior, outcome, perspective. And the last one that you get to do together and it's, think of it as like a Q&A. It's like what are the positive results you wanna see later? How can you make that happen. [12:45]

And when you manage up, they're a good manager, you just looked incredible. I'm not kidding. Like it, yeah, it's so like, I feel like as human beings, we wanna grow, we wanna learn, that that's pretty normal. You wanna do good work, you wanna have meaningful work, and this is a big part of it. [13:03]

So I hope those steps help. I have other ones too, if that didn't help at all. But [13:09]

Carl Vitullo: Yeah, no, I think that, I think that those are really good points. You know, I've read a couple of books on communication as you know, community manager type, that's definitely a, a large part of my role. Those reverse people books.[13:20]

Communication as personal improvement

Carl Vitullo: Yes. Yeah. That, that, that book you just held up, Difficult Conversations. It's, it's on our, you know, recommended reading list on the website and I recommend it to everyone, not just professionally, cuz it, I think it made a huge difference in my personal life too, just cuz feedback is universal. [13:36]

Elizabeth Woolf: Oh yeah. It's to your mom, it's to a grieving friend. It's in a relationship that's gone sour. Like, that's why— I'm gonna tell you a secret. It's why I fricking love this stuff. Ha ha. Because yeah, I might help someone be a better teammate, and that's wonderful, don't get me wrong. But then they get to turn around and have an incredible relationship with their kid, just cuz they learned this one thing. [13:56]

It's just, sure. It's, it's powerful and it's not just in one area. [14:00]

Carl Vitullo: Yeah, definitely cuz, right. I mean, soft skills, communication. Yeah. That's, you know, that's a, that's a dimension of professional life, but it's also just, you know, we live in, we exist in a social context. We are always in contact with other people. [14:14]

Elizabeth Woolf: I will say when I started this journey, there was a podcast I found called Soft Skills Engineering. And if anyone's ever listened to that, if you like to laugh and you like to hear just real things, Jameson and Dave are the host and they are hilarious. And they just talk, people submit questions and they're just engineers at every level. [14:33]

So I would definitely recommend it. And they're 30 minutes, so it's a little blip and you feel very smart. [14:38]

Carl Vitullo: Nice. Yeah. I, I really liked how you framed giving feedback around the behavior and the outcome. I think you, I think what you said about their perspectives, actively soliciting them to provide their perspective on it. [14:52]

Yeah. [14:53]

Importance of listening

Carl Vitullo: I think, and I, I think something else I wanna emphasize is it's not, it's not enough to just, you know, like paint by numbers through these conversations. Like, these are the ingredients. Like if you ask for their perspective and don't authentically listen to them and have it inform your own perspective, then it doesn't actually, it does, you know, that doesn't actually do anything, right? [15:12]

Elizabeth Woolf: Beautifully said. So, in college, I helped professors and students give presentations. We were a public speaking lab, and the first thing we were taught on day one is, how you listen is gonna be far more important than anything you ever say. [15:26]

And I can't tell you how many conversations I've been in where the person's talking and you're like, "okay, okay, okay, okay, okay. I got this. I know what I'm gonna say. Here it comes. Here it comes, here it comes." And then you, you, you're off the mark. You didn't actually hear what they said. [15:39]

Carl Vitullo: Right? Right. Oh man, there's a quote from a movie or a show that I'm, I, I wish I could remember where it was from or exactly what the quote is, but it's, "so many people, they don't listen, they just wait for their turn to talk." [15:52]

Carl (editing): The quote is from Fight Club and actually it's a little bit darker than I remembered. [15:57]

Movie quote: When people think you're dying, man, they really, really listen to you instead of just," "instead of just waiting for their turn to speak." [16:04]

Elizabeth Woolf: yeah. That's exactly it. [16:06]

Carl Vitullo: Right? Yeah. And authentically listening to someone, I think is all, you know, that's also a skill that's also not easy. Yeah. Something else I wanted to, you know, that I have in my notes that I wanted to emphasize is avoiding the appearance of passing judgment. [16:18]

I think that so much of like social interaction is a lot, you know, nobody likes to feel judged. It doesn't feel nice to No have it feel like somebody else is saying "you are a bad person." And I, I think what you said about focusing on behavior is, it's a, it's a pretty subtle adjustment from talking about "the person" to "the behavior." Yeah. But it, it helps avoid it being, it's a powerful adjustment to frame it around something that can be changed rather than something that feels like immutable. [16:48]

Elizabeth Woolf: It's part of you, it's like intrinsicly part of you. Yeah. [16:51]

Carl Vitullo: Right. It's external. [16:51]

It's not, yeah. It's not hard to change something that you do, but it is psychologically, you know, almost insurmountable to change a part of your, who you are. [17:00]

Elizabeth Woolf: Definitely. Yeah. And powerful for your brain to think, like, let's say you're about to get feedback, which also is hard, but totally learnable and like, you wanna assume that the person who's giving you the feedback, they're coming from a place of, I wanna help this person grow. [17:14]

I want them, I wanna help them be badass at their job. Oh, I'm gonna tell you this cause I'm invested in you. And then if you're giving it like, you have to assume like the actions that someone took, they had best intent. It's just you're now here to help them because if they're coming, it's coming from that point of malice or like anger again, emotions when they're heightened. [17:32]

Right. It's just not gonna be constructive. You're gonna just swirl and yeah, you'll turn into like melted ice cream at that point, but just su assume positive intent helps a lot too. Right, [17:43]

Separating tone and content

Carl Vitullo: right. Yeah. So is, can you think of an example quickly just off the top of your head of like, two comments, one about a person and one about a behavior? Like, you know, what, given one situation, how could that be described in each? [17:56]

Elizabeth Woolf: Yeah, I had one that I can actually break down for you that I, okay. For one of my clients, they, they received this as feedback and I'm gonna tell you now, they're also a toxic teammate, but they still got this feedback. [18:07]

Ah, it's, "your code reviews are terrible. You're a broken link on the team." And, oof. Getting that is just a, I'm not it, it's a smack in the face. Like I'm not, I'm not gonna sugarcoat that. [18:19]

Carl Vitullo: Yeah. [18:19]

Elizabeth Woolf: So when they receive this feedback, something that I wanted to walk them through is, you are, one, you're not the feedback, you are not. The feedback is supposed to be there for a purpose, to help you grow. [18:29]

The second thing is that's a tone thing and a content thing. And I'm gonna explain that so that you guys, whenever you get hard feedback, just listen to this. You wanna separate tone from content. So the tone of this, it's negative and it is rude. The content is the code reviews. So take the code reviews out and then turn that in on yourself and say like, how are my code reviews? [18:51]

And normally there's merit in that part, but the rest of it was just hard to receive. And yeah, so one of those things is you have to separate the two and also realize that a lot of people aren't trained on the skill. And that's an example of someone just not trained at all on the skill and then receiving it. [19:07]

Yeah. [19:08]

Carl Vitullo: Yeah. You are a broken link on the team is even if it's, [19:11]

Elizabeth Woolf: and it was sent over Slack. Yeah. So like, and that's the other thing is like you, if you send it virtually, it's like, oh, I'm not there. I'm not the person saying it. It's now through someone, it's new, through another medium, but it's all the same, holds the same weight. [19:23]

It's still a perspective. So yeah, I just would encourage people, cuz you're gonna come across harder individuals in your life who've never been trained on it. So just separate the tone from the content. What is the content? Pull it out. Tone, throw it away. [19:36]

Carl Vitullo: Sure. Right. Okay. So "you're a broken link on the team, your code reviews are terrible." [19:43]

What would be, what do you think would be a more effective way to deliver that feedback? So, okay, receiving the feedback, you ignore the name calling. Just block that out if you want to have a constructive conversation. "Oh, I'm sorry. What about my code reviews are terrible." Yeah, but, but let's, let's flip that and if you're the person giving that feedback, how could it have been done more constructively? [20:05]

Elizabeth Woolf: Yeah. So if you're the person giving the feedback, I think to help everyone practice the skill and we can go through the behavior outcome, those two parts. So sure. The behavior is, "what specifically did you want the employee to do?" You wanted them to conduct a much better code review, period. But I wouldn't say it that way. [20:23]

I would want you to be specific. So can you point to a part in the code? Like can you point to a time, can you point to an instance? So that's the behavior, make it specific. And the outcome. "Wait, so you did this thing, but what happened because of that?" There has to be, it's almost like a snowball effect because you did this, this has now happened. [20:43]

Again, both are external to the person, I did not talk about anything that had to do with who they are as a human being. But I talked about the behavior. So what outcome did a bad code review cause? Did you break production? I've seen it happen. [20:57]

Carl Vitullo: Yeah. Right. I can, I can think of a couple categories of bad code reviews, you know, so like, let's say this person is delivering 50 code style nit comments, but then misses, you know, the, the obvious huge bug in the logic. [21:10]

Elizabeth Woolf: Fired. Oh, gone. [21:12]

Carl Vitullo: Sure. Or, you know, or, or you know, the opposite. They just "looks good to me" on everything without thinking about it. Yeah. So, you know, like those could be like, both of those could be, could constitute terrible code reviews. Yeah. But you know, it's, that's not actionable feedback. It, it requires making that secondary connection to this is terrible. [21:30]

I know the specific behaviors I've been doing are X, Y, Z, so. [21:33]

Elizabeth Woolf: Mm-hmm. [21:34]

Carl Vitullo: Sure. So yeah, that's the content of feedback. [21:38]

Elizabeth Woolf: Yeah. And something that helps. Hopefully help all of you is, since all this stuff can sometimes be brand new, it was brand new to me in my career. If you start early with your manager, with a mentor, with anyone really, and you just create a place that's, I call it like permission for discussion. [21:56]

So if you created as part of your norms, you created a place where it can exist and it's not uncomfortable, then it's just a place that it can actually, it's a safe space. We're gonna call it that. It's a safe space. So I just encourage all of you create permission for discussion. Ask people how do you like to receive feedback. [22:13]

Yeah, some people want an email 72 hours in advance if it's gonna be a hard one. So they can process it and then you can meet about it. Some people want it the same day, they want to get it done and they wanna go think about it and everyone's gonna be different. So you gotta respect that. And you also have to know what it is if this is a relationship that you want to both give and receive feedback from. [22:32]

So that helps a lot for just, again, priming our emotions, cuz they're real and they're just normal. [22:37]

Carl Vitullo: Yeah. Priming emotions. I think that's a, that's a good way to say it. Yeah. [22:41]

Elizabeth Woolf: Yeah. I will say like, I feel like my mom is like a wise owl, and she has just, I feel like you could tell her anything and she could be totally realistic about her emotions, but I, on the other hand, like I've gotten news at work and like I just take a step. [22:54]

I have to take a step back just because it's been like I've been turned down for a promotion before that, I just was like, so, I mean, I'm not gonna lie, I worked my ass off for it and I had all the little cards lined up and it didn't happen and my emotions got in the way of my work. So just learning how to take a step back I think helps a lot. [23:11]

Especially when you feel like it's an attack on you. [23:13]

Carl Vitullo: Yeah, definitely. Work can be so personal because you put so much time and energy. [23:19]

Yeah. [23:19]

You know, energy in the form of actually doing the work, but also I think emotional energy of getting yourself hyped up for it and connecting it to something that is meaningful for you. Yeah. Being aware of your emotional experience, I think, yeah. That's really important. [23:35]

Elizabeth Woolf: Yeah. And you want, it's only human. You want your work to have meaning. Like you wanna wake up and know that if you're working those eight hours, like you did something, you created change. And that's perfectly allowed. And so feeling things at work also so perfectly allowed. [23:48]

And if people don't give you that space, that's a red flag. Yeah, definitely. [23:51]

Negotiations

Carl Vitullo: We also wanted to touch a little bit on negotiation. Do you have any tips [23:55]

for… [23:56]

Elizabeth Woolf: The fun one! I can tell you what not to do. [23:58]

Carl Vitullo: Okay. Okay. So I am, I, you know, say I have two years of experience as an engineer. Yeah. And I am switching jobs, and I get asked, what, what, "what's my expected salary?" [24:11]

Elizabeth Woolf: Nice. Uh, don't answer. [24:13]

Carl Vitullo: Don't answer. [24:14]

Elizabeth Woolf: Not kidding. [24:15]

Carl Vitullo: Why not? [24:16]

Elizabeth Woolf: So when you, and again, these are, these are gonna be my tips. I've seen them work. And again, you might be given other tips that work, but these are the ones that I've seen work. And also I'm gonna, I can send you guys an article that was actually posted in this channel and it's transformed how I think about negotiations. [24:33]

So you are, you have two job offers and, okay. They've now asked you for, are we at the offer stage or are we at the, uh, interviewing stage? [24:42]

Carl Vitullo: Let's start all the way back at interviewing. Yeah. Let's you know, let's start from that first contact of, "what do you expect?" [24:48]

Elizabeth Woolf: Okay. So in the very beginning, and they ask you for the range, you gotta turn it back on them. [24:54]

And I know that sounds weird and funky and odd, but the moment that you give a number, you've either completely limited yourself or you've exceeded where they're willing to go. They need to tell you the range. And for anyone who is any company that's not comfortable telling me the range, I am not comfortable continuing to interview because it's my time and my effort and. [25:17]

I just think that salaries need to be talked about more transparently. Like in Washington now, it's a pay transparency law. Like you can't even post a job unless there's transparency around it. So like we're moving towards that. But if they don't give you a range red flag, and again, don't give them a number. Okay, I want you to read this article, I'm gonna send you guys cuz that's like the number one thing they stress. [25:36]

And then the other thing that I had to learn, so I got my first job if I'm hot outta college, you're 21 years old, you think you're the, you know, the coolest thing to walk the earth. And they paid me less than an administrative assistant in the state of Washington, and I thought if I negotiated, I would lose the job. That's wrong. Like that is actually when you have your most power is once they offer you the job. [25:57]

We're taught, there's a stigma in America that if you negotiate, it's like this view of negotiation as you are now intrinsically poor. Like you're not grateful for what you have. I also had that like, beaten into all me and my friends because our parents were like, "no, you take that and you be grateful. It's a growing and learning experience." No. [26:15]

There's something that I learned in that article, a hundred percent of your gross profit is now subject to that negotiation. So if you go through all those interviews and you're offered the job, take the negotiation seriously and make sure you negotiate. [26:28]

So when you're sitting in that seat, something I would recommend if you're at the last interview and they've offered you the job, say you look forward to seeing the formal offer via email, because I cannot encourage enough doing the negotiation over email. It gives you time to mock up your words, make them look the way you want them to. Again, it gives you more power to not just be like talking off the cuff, which can be really hard. Negotiation is really hard. [26:53]

Hopefully while you're going through this, you've done a lot of research, and I'm not talking about Glassdoor (laughs), like get your booty on LinkedIn and talk to people who have worked there, which I have found so helpful. Who have worked there and have chosen to leave. Why'd they leave? What were they paid? What was the culture like that made them want to go? Like what, what were those motivators? [27:16]

And then I would also talk to someone who works there, who doesn't work on the team, who works with the team, cuz they'll probably be a lot more transparent about the team dynamics. And they also just have a different perspective. And once you have your range, I always encourage people just to go higher than you feel comfortable. [27:37]

Because the worst that happens is you land around, you land among the stars. I have a friend who negotiated going into the same job that I have, and he makes 40,000 more dollars than me. That's just the way it goes. So negotiate, negotiate, negotiate. [27:49]

Carl Vitullo: Right. And is that, so you, you've referenced an article a couple times. [27:54]

Yeah. Is that the Patrick Mackenzie, salary negotiations? [27:57]

Elizabeth Woolf: Yeah, salary negotiation. Make more money, be more Valued. [28:00]

Carl Vitullo: I thought it might be that one. Yeah. That is such a classic. [28:04]

Elizabeth Woolf: It's such a classic. And he has like a greatest hits part of his website and like, this article alone is responsible for 9 million dollars. Like that's amazing. Yeah. That's amazing. [28:14]

Carl Vitullo: Yeah, definitely. Okay, so more information is valuable going into a negotiation. Yeah. [28:22]

Elizabeth Woolf: Something that you could do is, so let's say you have all that information, you've researched the company, you know the job description really well. Now that you know those two things, especially the job description, I would like, I would use their words in everything you talk about. [28:36]

People love to hear what their voice has said. It's a large part of validation. It's just a large part of, "oh, they get it. They get this role. They'd be great in this role." Like take your language and make it theirs. Gotcha. Strong point for leverage. [28:50]

Carl Vitullo: Interesting. So this information gathering you've talked about. [28:53]

Elizabeth Woolf: Yeah. [28:54]

Carl Vitullo: That's a lot of cold contact on LinkedIn. [28:56]

Elizabeth Woolf: Yeah. [28:56]

Carl Vitullo: Especially on like a smaller, like I, most of the companies I've worked for are fewer than 50 people, teams I'm joining are like, less than five. [29:03]

Elizabeth Woolf: Yeah. [29:03]

What if you can't connect with anyone at the company?

Carl Vitullo: So like let's say I'm not able to make any contact. I give my shot, I don't get anything else. I still have to respond to this email. What then? [29:11]

Elizabeth Woolf: What then is, you are now gonna turn it back around onto your life. So know what, what do you need in the next 10 to 15 years? Because this negotiation is going to help that. Again, we're talking about your literal gross profit you're gonna bring into your own life. If you need to buy a home, if you are supporting a family, if you wanna get that dog. [29:31]

If you just wanna have really cool tech equipment or if you wanna be able to travel, like do the math on what you can do to live comfortably and do not be willing to give that up. I think for our, my first two jobs, I gave it up and I regret it. I settled and I just, I don't encourage that for people once you know your value. [29:51]

Carl Vitullo: Yeah, for sure. [29:52]

Yeah. I think that's, I think that recommending that people do the information gathering in their own lives. Yeah. Take stock of what's valuable to them. What do they, you know, what would they use that money for? Yeah. And how much would be better? Yeah. [30:06]

Elizabeth Woolf: Some people— [30:07]

Carl Vitullo: I think that also— [30:07]

Elizabeth Woolf: make boatloads, but don't use the boatloads. [30:09]

Like some people make boatloads and are so unhappy and some people don't make boatloads and they are. Some of the happiest people I've ever met because they find value and merit in their work and they're also work on a team that really respects them. There's so much value in that too. [30:25]

Different dimensions of value to negotiate

Carl Vitullo: Yeah. What are some different dimensions of value that you could negotiate on in a, in this situation? [30:32]

Elizabeth Woolf: Great question. So my best friend did not get exactly what she wanted in terms of pay. So she negotiated stock options and more PTO. I know of some people who have families have negotiated different types of benefits just for themselves in terms of coverage, life insurance. Mm-hmm. So I think those are the two. [30:51]

Like, so if it's not gonna be the dollar amount, what is the next best thing? Especially if you, you're like, "oh my God, I love the company." Like "this is the role I need, this is the kind of growth I wanna have in my arsenal of experience." Then it's what else is gonna be valuable for you? Because your counterparty, whoever that is, whatever company, they just don't share that same model of negotiation. [31:11]

Like 10,000 more dollars normally is a drop in the water. So that's why I encourage people to negotiate and I encourage you to know like, what do you need in those 10 to 15 more years? What do you need right now to be super happy? It's always gonna change, don't get me wrong, but like once you're in the company, making those like hoops and jumps of getting more pay is gonna be much harder. [31:32]

Carl Vitullo: Definitely. Yeah. And even if you change companies, it's rare to take a pay cut. Companies, once you have a salary, that tends to be the floor. Yeah. For any similar role going forward. So it, it really, yeah. I think thinking of it over 10 or 15 years is absolutely correct, even if you don't plan on staying with that company for 10 years. [31:52]

Yeah. Because, the next job will index off of your current salary. Exactly. Whether you, or even if you don't share that number, they'll base it off similar roles. So, you know, you can at least be a data point for higher compensation in there. [32:05]

Elizabeth Woolf: Yeah, I, and I would read the article cuz he gives you so many different scenarios of where they're gonna ask you what your previous pay was and he gives you the literal words to say, to be like, no, I wa I wanna know the range. [32:20]

Because if the range isn't where you need to be, then that's not fair to your time. It's not fair to theirs either. So you can call it a wash. Also a great learning experience. Cause now you just know, [32:29]

Carl Vitullo: right, yeah, I think that's, I think that's very true. It's, I feel like it's one of those, you know, maybe going back to the, existing in a social environment, a social context, like being unwilling to share that information, I think goes, it speaks to a level of guardedness and, and maybe even, you know, it's… [32:48]

The most likely motivators I can think for not, for being aggressive about protecting the salary range for a job, you know, not sharing it, and, secondarily, aggressively pursuing the candidate sharing their range first. Like the only interest I can really think of for both of the, for pursuing both of those lines of action is trying to get the candidate to undersell themselves. [33:11]

It's saying, we know the range is up here, if we do these things, we think we can get at the very bottom of that. [33:17]

Elizabeth Woolf: Yeah. And I've talked to leaders who, like, people have given their number that they want and it's significantly lower than the range, and they take them on because they just, they're happy. They made who's happy, they made a great business deal. [33:31]

They just got a wonderful employee who didn't know what the range was, said, what they're worth and like, that's my just greatest fear is I wouldn't want that for someone. And so that's why hold that so close to your chest until you have like a pretty good understanding of what might the range be. Yeah, definitely. [33:47]

And you don't owe it to them. There's no (laughs), like, there's no script in the world where like you, and if there is, that's shady. I'm gonna say that right now. But you just, you don't owe that to them. That can also be your private information. [34:02]

Information asymmetry in negotiating

Carl Vitullo: Yeah, most definitely. Yeah. I, I think that goes back to something that I have heard it spoken about in salary negotiations. [34:09]

There is so much information asymmetry. I actually, yeah, no, that's something that Patrick McKenzie talks about in his, in his salary negotiation blog post, is you are negotiating with someone who is probably gonna negoti, [34:23]

you know, let's say you're, you're, you're being recruited by a reasonably large company, 500 people. They have a professional recruiter staff. Like they're going to, they are probably going to negotiate offers several times a week. Yeah. [34:38]

Elizabeth Woolf: Oh, they're good at it too. Whereas, yeah, [34:39]

Carl Vitullo: they're good at it. Right? They're practiced at it. Yeah. Whereas [34:42]

Elizabeth Woolf: we do it like once every three to four years maybe. [34:45]

Carl Vitullo: Right. I have done it. [34:47]

I have had more opportunities than most to do it because I've job hopped a lot. I've had probably 10 jobs in my 10 years as an engineer, and that's still, you know, that's only 10. These distinct instances. That's like two months as a recruiter over 10 years as an engineer. Yeah. Yeah. Absolutely. [35:02]

And I'll say, I'm a terrible negotiator! I have learned this over many years in many opportunities. I do not take the opportunities presented to me. [35:09]

Elizabeth Woolf: We're born terrible negotiators. We're not. Yeah. You don't go to elementary school and you're like, "all right, kids, sit down. We're gonna learn some" — "to drive a hard bargain." Yeah. We're gonna learn some good stuff today. [35:19]

It's not normal, but like again, I'm gonna stress this till the cows come home. Like it's learned and you can learn it and you can be good at it. I would, um, So my brother, he sat down with an engineering manager or an engineering leader cuz he was going for engineering jobs and he negotiated with them fake setting. [35:38]

Again, nothing was really on the line, but the manager who's the one normally offering the job has all the context of all the jobs they've offered so they can easily like snap back or throw you off your rails and like you can practice those different situations of how to negotiate what you're worth. [35:54]

So I would encourage find someone in your life you could practice that with. And even if it's like a friend, give 'em a script like, get yourself comfortable. And again, that's why I say if you can get it to email, you can get all the feedback in the world you want on it. Cuz now it's written word. [36:08]

Carl Vitullo: Right? Right. Being able to take an hour to solicit feedback from a couple of people. Yeah. Total game changer. [36:15]

Elizabeth Woolf: It is. (whispers) I love feedback. [36:17]

Finding and knowing your worth

Carl Vitullo: I guess, so you touched on a little bit, knowing your range, knowing your worth. That is so hard to do early in your career. How, how would, what advice would you give to people who are at that stage where they, you know, maybe have some idea, they've read things online, they have an idea of salary range for engineers, but how do they determine where they are on that scale? [36:41]

Elizabeth Woolf: I'd say it's a lot of knowing. Okay. You can think of it this way. What do people come to you for questions about? Hmm. All the time. That means that is worth that you hold that others don't. So that's a really great thing. Sure. I'd also say people who are passionate about something, you can pay someone a gajillion dollars, but they don't have the passion for it. [37:03]

You, it's just falling flat on their face. So what, like what do you Google search for? What do you, what books are you reading? Like what is something that you are just so like hungry for? Because that, you'll learn if there's hurdles, you'll learn them. And so those are just two big things of like, what do people naturally come to you, come to you for that's validating that you're good at it. [37:24]

It's an external validation. Then what are something that you are just like completely insatiable for? And those two things are huge value adds for who you are. [37:34]

Carl Vitullo: Yeah. Yeah. I think that's, I think that's a really good point is seeking some kind of relatively objective sort of feedback on what are your skills? [37:46]

Elizabeth Woolf: Oh yeah. [37:46]

Carl Vitullo: What you, what are, what are you good at? And. How good are you at it compared to your peers? [37:52]

Value of a genuine mentor figure

Elizabeth Woolf: I had a fantastic mentor, her name was Janice, and she was working at my previous company with me and she gave me just an entire, it was like a four page note sheet about like what I'm good at, what roles I could look at. [38:05]

Wow. And it just comes to my mind every time. And she like even linked, hyperlinked me to like 25 different jobs that I could apply to right now based on my skills. Like fine mentors like this. Cause they're, [38:17]

Carl Vitullo: That is so validating. [38:18]

Elizabeth Woolf: They're game changers. I know. But it was like, she also told me like, what do I need to work on? And then like also, what are you really good at right now that you could do? And I love that. Cause I was going for, I was two years into my life, or two years into my career, excuse me, not a two year old. And I'm going for like, I think I could be a director. And she's just like (laughs), " no, but here's what you're good at and here's where you could be." [38:43]

So, yeah, finding those people, they're gems. Don't lose them. I still talk to her. The people who give it to you straight, they're fantastic. [38:51]

Finding a mentor

Carl Vitullo: Yeah. Yeah. That's, you know, I, let's chase that thought down. Yeah. So finding, finding a mentor. Oh, I think we get that. We get questions around that in the community pretty frequently. [39:02]

Mm-hmm. And I'll, I'll give my, so I have a bookmarked tweet from like eight years ago (laughter) where, cause somebody just said it so concisely, it said like, how to find a mentor. Point one, don't ask them to be a mentor. [39:16]

Elizabeth Woolf: (laughs) So true. [39:17]

Carl Vitullo: Point two, ask them specific questions. Mm-hmm. And then follow up with the results. [39:22]

So just like, and that has been such, it's such my experience. Like I've never participated in a formal mentorship program. Like I have never been a mentor, a. Or a mentee through one of those things. But I have found people in my career where it's like, " I'm trying to do this thing. I think you have already done this in a way that I would like to learn from." Yeah. And then, and I, I guess just continuing to chase it down a little bit, like the specific questions, I think is such a challenging thing for a lot of people. [39:53]

Like it's not enough to say like, "Hey, I'm trying to start my career. How can, how can I get my first job?" Yeah. Like, that is so broad. Like that take, that would take like an hour long monologue, what we're doing here. [40:03]

Asking good questions to a mentor

Elizabeth Woolf: Again, like we can go back to those skills we talked about for feedback. Like, so the questions, yeah. If you make them specific, and this one's gonna sound ironic, make them selfish. So they were in your shoes once, they most likely navigated these same waters and were applying for jobs, were getting rejected, felt lost, felt no purpose. So ask them specifically, like, what did you do in this situation? [40:27]

And type out your experience that you're feeling right now, and then if they can respond to it and give you advice to that, they're a mentor. And mentors don't have, like, they, it's not like you're swapping titles. Like mentors can come in anything. Like I have people I admire, I have people who will never know that they're my mentor just cuz I've studied their careers. [40:46]

So it can be, it doesn't have to be someone you physically talk to, to, although that tremendously helps. And so I'd make the questions just super specific and like selfishly about what you're going through and then you get guidance immediately just cuz it's now it's your own experience versus like, how would you do a job hunt? [41:05]

Carl Vitullo: Yeah. Right. Because like, "how would you do a job hunt?" That's a very broad open-ended question. [41:10]

Elizabeth Woolf: Mm-hmm. [41:10]

Carl Vitullo: That even if they gave, you know, let's say they spent an hour writing an answer to it. It may not apply to your situation. [41:16]

Elizabeth Woolf: No. Yeah. [41:18]

Carl Vitullo: Uh, whereas anchoring it around your personal experience more could be like, "Hey, I've applied to 40 jobs and I haven't gotten any responses." [41:27]

Elizabeth Woolf: Yeah. [41:28]

Carl Vitullo: "What problem am I, am I, am I having, how do I get past this?" Yeah. Like, th that is, yeah. Those are two entirely different questions. [41:34]

Elizabeth Woolf: Definitely. And they can be more specific in their answer too. So you're getting the result that you need. And I'm, it's just the, it's the truth of human beings. Like, if you get them in a good place, like they're gonna love talking about themselves. [41:47]

Like it's some, it's, sometimes it's the easiest thing you can talk about is your own experience. Right. So I found more, I've never been turned down for an informational interview. Yes, they might have gotten pushed out, but not in my career. And I will say, these are people I have known or interacted with that makes it easier. [42:05]

The cold ask is always hard. Yeah. So, They're people that are around you that you admire, but I've never been turned down for it. I've also not, never learned something. So that even made any English sense. Yeah. I've always left with like one tiny nugget. You don't believe it at all, but it's just a compilation of nuggets. [42:22]

Carl Vitullo: Yeah. Right. Life is just incremental improvement. Every 3% makes a difference. [42:27]

Elizabeth Woolf: It does! Do the math on that. [42:29]

Mentors and genuine networking

Carl Vitullo: Yeah. Right. Yeah. I like your point about, I feel like it went very sort of incidentally, but your point about informational interviews from people you've interacted with and know in real life. [42:40]

Yeah. Or in, maybe not in real life, but know and have interacted with in a meaningful way. Yeah. I think that's, I think that's so important because like that's real networking, you know? Reaching out to a stranger and saying, "hello, I would like to learn from you. Please give me your knowledge." [42:54]

Elizabeth Woolf: Like there's no, I, I think there's no tie. There's like, there's that chasm, like you're just like, why? [43:00]

Carl Vitullo: Why? Right. And I think this is a point that I've made before on, on another event, but I think that for a lot of experienced people, like their knowledge is in demand. Like there are totally many people who would love to know what they know. [43:12]

Yeah. And I think in those situations there's a, you know, maybe even a, a subconscious measure of, is this person worth the effort of me going, providing the answer they want. [43:25]

Elizabeth Woolf: A hundred percent. Time is, time is the only thing you cannot get back. Like that is the one resource you cannot get back. It's more fragile than money ever will be. [43:33]

So some people take that very seriously and sometimes it sucks to be on the other side of that. That's why having that tie or like I would say, so if you meet someone and they said something really cool or they've lived an experience that you just want to know about, ask in that moment because yeah, the connection was just made. [43:51]

And like, so ask as soon as you feel it. And if they say no, it's normally for a reason of like, busy, don't have time, or just like they're not doing that at the moment. And then, you know, but I find just monopolizing on that moment is so helpful for getting the information that you think is gonna help yourself. [44:08]

Yeah. [44:08]

Carl Vitullo: Yeah. I think that's absolutely correct. You gotta, you have to, oh, this feels like a, um, a bit of a catchphrase I've had of, it's a way of cultivating serendipity. Like, you know, it is, it is just sort of a magic moment that you couldn't have planned for, but by approaching a, a situation, by putting yourself in an environment where it's more likely that events like that will happen. Yeah, you can, you can take advantage of it. You can cultivate it. [44:36]

Elizabeth Woolf: Definitely. Definitely. And again, putting the power back in your own shoes, right? Yeah, [44:42]

Carl Vitullo: Definitely. Yeah. I, I, I want, I want to connect it to another, another. Thought in my head a little bit, how much of networking, how much of connecting with people is really just showing up. [44:51]

Like the, the people who are met with the most skepticism when they make an ask, [44:56]

Elizabeth Woolf: Yeah. [44:57]

Carl Vitullo: Are like the cold contacts. If you've never met or heard of someone and they show up out of the gate asking for something. Yeah. Like the default response is like defensiveness and just, and suspicion. Just like, who are you? [45:10]

Let me like, are you, yeah. Why are you asking for this? What, what's your motivation? Whereas if you can come at it from a warm, you've already met them, you've already spent time, they know you a little bit. They know your background and your motivation, then yeah. You can get a lot, you can get a warmer reception. [45:25]

Elizabeth Woolf: Mm-hmm. Most times, always. Yeah. [45:27]

Networking effectively

Carl Vitullo: Yeah. You know, we, we hadn't, I, we hadn't like discussed this in advance, but I think networking is a, another big part of communication. Yeah. So it's, it's maybe a, before you start your first job as you're just trying to figure out how to get that first role, connecting with people in the field and yeah, understanding it. [45:44]

Elizabeth Woolf: I'm not gonna lie, when I started my career networking, I mean sometimes I feel it now it feels gross. Like, it's like, why do I have to go out there and talk about myself to other people who are just talking about themselves? It sometimes it feels just like a very shallow pool. [45:58]

But the ways I was able to change that is, I found events that, first and foremost, that benefited me. And something that really helps is if you go to like speaking events, cuz then you're not just talking about your lives, now you're talking about someone who went up there and talked about something cool, and then now it's basically free game to anyone. Cause now you all have that event in common. [46:22]

So I would highly recommend base it around an event where you get to go learn something and then make connections from there. I've also been a bit of a freak for this, but anytime I've gone to those events, mosey your way up to the front and just say hi to the speaker and tell them one thing you learned. [46:39]

Rarely as speakers do we get that opportunity to just hear what you learned. And that's also a really good connection point. They're on the stage for a reason. So that's something I would say try. It might take a few sessions. That's okay. Yeah. But transformational. [46:54]

Carl Vitullo: Talk about scary situations. [46:56]

Elizabeth Woolf: Yeah. Yeah (laughs) [46:57]

The power of showing up consistently

Carl Vitullo: Yeah, I like that a lot. I think, yeah, just going, showing up to something that is of interest to you. I, I, I think I, this is something I've tried to, you know, put to words a couple times and never really succeeded very well at, but there's so much underrated power in just showing up consistently. [47:15]

Like, as you know, for networking for, for developing these kind of skills Yeah. That we're talking about communication skills, just showing up and being in the same space, forming community with a group of people around a shared interest. Yeah. Is so un it, it sounds so like trite and obvious and I don't know, I, I think it gets taken for granted that like, the hardest part of it doing anything is just showing up for consistently. And when you do that, yeah. It's just, it's so powerful. [47:45]

Elizabeth Woolf: That's why I would throw anyone who's struggling with it, I would just, I wouldn't even say anything. I would just throw the book Atomic Habits at their face. [47:51]

Just make it part of your identity. Make it part of how you wanna show up in the world. Don't make it a goal. Don't make it a New Year's resolution. Make it part of who you are and it makes it so much easier. Then it's like, "I, I can't, I can't skip. It's part of how, who Elizabeth is, she's gotta go. I'm sorry." [48:09]

Carl Vitullo: Right, right. I think something else that I have learned over my years of becoming an older human is, I think I had gotten that part of it, like, you know, make it part of your identity, and I think something that was hard for me was cutting out parts of my identity that were no longer serving me. [48:26]

Elizabeth Woolf: Yeah. How'd you figure those out? [48:28]

Carl Vitullo: I think it, it goes back a little bit to what you said about like, the gut feeling. Yeah. Like, just occasionally taking an inventory of your life, like what's in your life and why is it there? You know, may maybe a Marie Kondo kind of vibe. Ah, but like, you know, okay. [48:43]

If part of your identity is, "I am someone who goes to JavaScript meetups in my community," that was something that I kind of experienced myself. May maybe why I'm bringing it up as an, as an example. I went to meetups, I went to conferences, pretty consistently for three or four years and at some point at a conference, I had the, I had this moment of like, "oh, like I've seen this talk before." [49:05]

Like, "oh, I, I know how to use the, all of these technologies that are being talked about." I don't know if I need to keep coming to these. Yeah. And yeah, so just sort of that sort of introspection and self-awareness of what am I showing up to and what am I getting out of it? [49:21]

Elizabeth Woolf: Mm-hmm. And what do you want out of it? [49:23]

Yeah. Like before you choose anything, what do you want out of it? I've been doing this thing lately, I feel like. So the world is starting to open up again. There's so many new events and a lot of 'em are starting to be in person. And when someone asks me about an event, and maybe you guys can try this too, and this protects you if your head does not go, "hell yes," it's a no. [49:44]

And then I'm gonna tell you, lean towards that feedback loop. And figure out ways of removing yourself from the things that just are not making you feel like "hell yes," this is what I want to be at. I mean, not to be morbid, but life so short. Yeah. Choose the hell yeses I God, you'll smile so much more (laughs). [50:02]

Learning to trust your gut

Carl Vitullo: Yeah. Well that's, tying it back to something you said earlier that, you know, balancing that "go with the hell Yes" and following your gut. [50:11]

Elizabeth Woolf: Mm-hmm. [50:12]

Carl Vitullo: That's where I think the hard part of it comes in, because like so many times you're like, hell yes, this is awesome. Let's get, let's go for it. Yeah. And then as it gets closer and it gets real, there's that moment of anxiety of like, oh God is this, is this, it is. [50:25]

Right. Yeah. Is this for me? So yeah. I, I I think that's, that's where, that's where it's so hard. You have to actually, that's where I think that like taking mental inventory and self-awareness of figuring out is this, is this a hell yes that I'm anxious about or is this not a hell yes. [50:41]

Elizabeth Woolf: Yeah. " Is this not hell yes." (laughs) I'm glad that none of that was like, bleeped just been bleep. Yes, bleep yes (laughs). [50:51]

Carl Vitullo: No, this is, uh, this is an adult's only podcast. We can swear here. Love it. [50:56]

Yeah. In chat, "find a goal and enjoy the process." I think that, I think that's right. [51:02]

Looking backwards to find what gives you joy

Elizabeth Woolf: Yeah. And you'll, you know what feels like I had this talk with my brother, like, it's wild how even some of the things you were curious about as a kid, like they will, they will come and they'll pop their heads, like they'll come back into your life in your twenties and your thirties and your forties. [51:17]

Like, they're not something that just leaves you, it's part of, it's just how you're wired and don't fight it. Like you're really gonna have things that just light you on fire. And I, I would encourage anyone to like, choose those. It's, I mean, it's not gonna be like sunshine and rainbows because you choose the things that motivate you. [51:34]

You have to give up to get what you want. But I'm always gonna lean towards. Choose the hell yeses, cuz, I don't know, it's easier to sleep at night (laughs). [51:43]

Carl Vitullo: Yeah, for sure. Or drain. Yeah. I love, I love what you just said about like looking at what excited you as a kid. Mm-hmm. Or as you were growing up because I think there is something so true to that. [51:54]

Yeah. You know, given as you're just learning what the world is, what excites you, I think it never really stops exciting you like, you know, maybe other things take priority but looking backwards to see trends. Yeah. It's so I think that is so powerful for orienting what you want your life to be based around. [52:13]

Elizabeth Woolf: Yeah. When I was 16 I was obsessed with communication and like, I'm 27 now and it's just grown exponentially and if I look back to who I was at 12 and 11, there were like peeps of it and it, I just look at the trends. You've made decisions in your life for a reason. I did this thing where I wrote out, you can call me insane, and I will probably accept that I wrote out all my decisions I've made since I was like five. [52:38]

And that taught me so much. Huh? About how I make decisions in my life and how they've changed. So it's the decision you made and why and Okay. It was like I had, I had to call my mom and be like, is this this? Is this normal? Am I okay? She's like, yeah, but it's wild to see how your decision making changes, but your reasoning stays pretty grounded. [53:00]

Mm-hmm. Yeah. Reflection's huge. It's a good, it's a very good trait to have. [53:05]

Carl Vitullo: Yeah. And that, you know, that reminds me of something I did relatively recently. So over the last year and a half I've been focusing more on community and really, really kind of making a career shift from software engineer into developer community human. [53:19]

And one of the, one of the reasons… maybe sort of a post-facto explanation, not, I'm not sure how much decision making, how much this went in as an input to the decision making. [53:28]

Elizabeth Woolf: Mm-hmm. [53:28]

Carl Vitullo: But as I've reflected on it, after having made the decision to go harder into community work, I realized, like I've been, I've had a natural inclination to do that my whole life. [53:39]

Like high school teams, I set up forums when I was an incoming freshman, I set up an IRC chat for incoming freshmen. So like, I think there is something so powerful about that. Like looking at what has consistently attracted your attention and, and energy through your whole life. [53:54]

Elizabeth Woolf: Mm-hmm. [53:54]

Yeah. I'd say also to like, yeah, I'm gonna say the term, to also trim the fat. Like if you're not sure if it's a hell yes or not, that's okay. But if you go to the event and you leave and you're drained or you go to that anything X, Y, Z, whatever's on your calendar and you're, you don't leave with a part of you rejuvenated. Yeah. [54:13]

Now, you know, and at the beginning of like my twenties, I did not know what anything was that fueled me. Like I just, I had a smorgasboard of things. I thought it was on behalf of other people, but once I was told that, it was a lot easier to figure out, oh wait, I'm exhausted and I want to sleep for nine years. Maybe this is not what I should ever do again. And it's just easier that way. So you might not know going in. [54:36]

Yeah. You just know later. [54:38]

Carl Vitullo: Yeah. You gotta play around a little bit. Mm-hmm. Play in different parts of the world and see what gives you energy. Yeah. I think that's so right about leaving something, feeling rejuvenated. Like all of the best events I've gone to or something. Or you know, events I've gone to, like celebrations, parties, networking events, one-on-one conversations. [54:57]

The best ones are the ones where I, at the end of it, my brain is whirring with new, new ideas and new thoughts. Yeah. Making new connections. And it's just been like, You know, it almost feel a little manic like, like, "oh man, this is so great. I'm gonna do all this thing." You know? [55:13]

Elizabeth Woolf: When when you leave and you have a to-do list like this, it's a great day. [55:16]

Like, yeah, right. And tomorrow I'm gonna cure cancer. And then the day after that, I'm gonna solve world hunger. It's gonna be a great week. [55:22]

Carl Vitullo: Right? Day two is for editing. You know, it's then you, then you pare it back into accomplishable things. But yeah. [55:29]

Elizabeth Woolf: Yeah, I can completely relate. Damn is it a beautiful feeling. [55:32]

That's why I encourage you to figure it out early rather than later. I know people who were in their fifties and they didn't figure out what really fires them up until they were like 57. Hmm. And they blinked and they're 57. And then figuring out then what it is, and I'm gonna be really honest here and say like, the reason I am so absolutely. [55:53]

Just like this is the only place I would wanna work is with engineers, is because they're the people who are literally building the future. Look around, like it just speaks for itself. Right. And that's why like giving anyone those skills of like knowing what to like, say, do move forward with how to choose things in your life. [56:11]

So important to do now you're just gonna be that much better. 5, 10, 15 years, it compounds quickly. [56:17]

Carl Vitullo: Yeah. Yeah. [56:19]

What if your no could have taught you more than yes?

Carl Vitullo: Before we go too far, I see questioning from the chat. Yeah. What if your "No" could have taught you more than your "hell Yes." Cuz you could find so much, so many interesting things at a hell no event. [56:28]

Yeah. What do you, what do you think about that? I, I have some thoughts. [56:33]

Elizabeth Woolf: That's a really good one. Um, that makes you think of when you're managing, like when you have a bunch of things to do and you put the hardest things at the bottom. [56:40]

Carl Vitullo: Mmm [56:41]

Elizabeth Woolf: and you're just avoiding them, um, yeah. Be really clear, so if it's an event that you're just not sure about or you dunno what the output's gonna be, go into it knowing what you want to get out of it. [56:52]

Like for me, I'm lucky at the stage in my life where I don't have kids or a marriage I need to build or an entire family of little peoples that I'm responsible for. So if you wanna experiment with those events that you think might be a hell no, do it, cuz you'll have the time to rejuvenate yourself. As long as those other priorities that you have in your life, you're not completely just shutting down, but also keep track of if you did get drained. [57:18]

Me personally, yeah, the filter has gotten better as I practiced it more so that's why I can sit here and say like, here's the advice. But definitely I would say try it out and if those "no"s start to come up, listen to them. [57:30]

Carl Vitullo: Yeah, I like that because I think there can be several different types of hell no. [57:34]

Like is it (laughter), I think the wrong hell no is something based out of fear. [57:40]

Elizabeth Woolf: Mm-hmm. [57:40]

Carl Vitullo: You know, like if it's a hell no. Like I, I'm, I would, would not be comfortable doing that. Then that's something that you should maybe think twice about avoiding, like maybe that's just an avoidant behavior. Yeah. If it, if it's hell no, like that's not worth my time. [57:55]

I, you know, may maybe do some double checks to make sure that you have a, an accurate gauge of your read on something that you might do. Mm-hmm. But yeah, it's like you, like you were saying, as you develop your gut feel mm-hmm. I think you can trust in your "hell no"s a little more. But I think, especially early when you're evaluating things, considering what, what about it is a hell no. [58:17]

Elizabeth Woolf: Yeah. I completely agree. Because I have some nights where it's just like, " I'm pooped and I can't bring any kind of Elizabeth that I want to this event," whatever it may be. Yeah. That's allowed, like it actually is, and it took me a long time to learn that. That you don't have to exhaust yourself just to like get to some point. You just, you don't. [58:39]

Carl Vitullo: Yeah. Yeah. Not everything has to be an exhausting journey. [58:42]

Elizabeth Woolf: No. Cuz there will be the exhausting journeys. Like that's part of, that's just part of waking up, breathing, sleeping, eating. That's just, there's gonna be exhausting journeys in this thing we call life, but filter. Filter as much as you can. [58:55]

Carl Vitullo: Sure. Yeah. Make sure you're selecting the best exhausting opportunities. [58:59]

Elizabeth Woolf: Yeah (laughs). [59:02]

Yeah. And if it's one, if it's an event that you're afraid of, a hell no that you're afraid of, I'd lean back to, it's that fears are your best clues into how you can be amazing. So if you're afraid of it, try it. Not even kidding. Try it. You will shock yourself every time. And if you're still there and you feel uncomfortable, you tried it. You are incredible for trying it. [59:23]

Carl Vitullo: Now, you know, to try something else. Yeah. Well, I I love that. I think that's really great. [59:27]

I see we have, we've gotten another question out outta the chat that I think is worth bringing up. [59:31]

Elizabeth Woolf: Love it. [59:32]

Handling being underleveled when hired

Carl Vitullo: Uh, "how do you handle being placed in a position that you feel is below what you're capable of? [59:37]

Elizabeth Woolf: That's a phenomenal question. Doesn't get asked enough. [59:39]

Carl Vitullo: Yeah. That's a really hard situation to communicate in. I think there's, when you think that you are, you've been indexed too low versus your actual skills, there's a lot of Yeah. A lot of fine communication work. [59:53]

Elizabeth Woolf: Yeah. You are now giving difficult feedback, period. [59:56]

Carl Vitullo: Yes. [59:56]

Elizabeth Woolf: So like, let's say you are, you're two positions below, below where you should be. Your counterparts are doing more of the work that you know you can do. [01:00:05]

If you are in an environment where you are allowed, where your voice has weight and God do I hope it does. Those people that are doing that work, I would figure out ways of either sitting in on or being able to watch or even be a part of those projects they're responsible for. Cuz there's gotta be a light role that you can play. So that's just one part of it. [01:00:25]

Figure out what responsibilities you can take on next to those people who are holding those roles, because now you're with them by association. Those are some of the largest growth moments I've had in my career, is when I ask someone a question, they brought me in and then all of a sudden I'm the one managing the work like six months later. [01:00:40]

So that's like best case, worst case is a team is continually saying no and like they're protective of their work. They're protective of their growth cuz there are people who are like that. And, that's a sad environment to be in, but it's also a real one. This is when I would lean on your manager, and I know some people don't advocate for that, but I just, that's why I believe managers are there. That's why we have them. [01:01:04]

And telling them your skills where they're aligned and asking them the why and then having them also advocate for you. Their voice might hold more weight. It might look different in this different setting. I hate political powers cuz they're stupid. Right. But like it's real. Having their voice speak on your behalf can also hold a lot of weight and give them the words you want them to use. [01:01:26]

Not even kidding. Write it in an email. Say like, I can do this, this and this. Here's me doing that. I'd love the opportunity to try it and I'm sorry that's happening. Yeah, that's really hard. I've been there too. [01:01:37]

Carl Vitullo: I, I, I, I a hundred percent endorse everything you've just said. I think leaning on your manager, trying to get in a position where you are peers with other people at the level you believe yourself to be. [01:01:49]

What if your manager under-leveled you?

Carl Vitullo: What about the case where your manager is the one who under leveled you? [01:01:53]

Elizabeth Woolf: So good and, oh yeah. [01:01:56]

Carl Vitullo: That's hard. That's, my, my first thought is start looking for a new job. [01:02:01]

Elizabeth Woolf: Yeah. And I laugh cuz the podcast I listen to, they like try and avoid saying that because they're, they're both like, and new job and, but No, no, no, no. [01:02:08]

Right. So if it's your manager, ugh, okay. I'll be so blunt. I've had that in my career. I love them now because they're not my manager, but they were, and I felt small. What I chose to do, which I would never endorse, is I always chose silence. Because it was comfortable because I was early career and I thought I would receive punishment for it. [01:02:30]

Now that I am where I am and I think a voice is so powerful, I would use it to your advantage. The first thing I would do is probably like write out your logic if you have it documented. Oh my God, that's even better. Like either if it's been things that are said that are keeping you small, if it's decisions they've made that are keeping you small, but you know you're capable. [01:02:50]

And then a few different routes are your skip level, so who manages them. And also if it's a whole level of managers, it's someone near them. And I wouldn't go at those conversations being like, "I was undermined." [01:03:05]

"This is why," I would say, "this is how I want to grow. How can I get there?" If they outline the steps, say "These are my barriers." And if the one of the barriers is what your manager is doing, it's come up naturally now and then you can address it. But I'd never just walk into a conversation as the blame game. I would have it come up organically, explain your why, and then they can help navigate that with you. Not just you telling it, cuz it's just the tone is so different. [01:03:33]

Carl Vitullo: Yeah. I think, what that's making me think of is, I think in situations like that, if you know you're, you're, let's say you're talking to your manager, you're talking to your skip level, you're talking to your peers. Yeah. The default assumption I think in most cases is going to be that, that the manager is correct. There's a lot of people who have an inaccurate judge of their own skills and, [01:03:53]

Elizabeth Woolf: too often too. [01:03:54]

Carl Vitullo: Right. So, you know, e- even not assuming that to be the situation here, I think that the perception of most situations where someone is claiming to be under leveled is, "well prove it." And, actually, I think one of the ways you can prove that is through navigating that situation effectively. [01:04:10]

Elizabeth Woolf: Yeah. [01:04:11]

Carl Vitullo: Like what we're talking about now. [01:04:12]

Elizabeth Woolf: Mm-hmm. [01:04:12]

Carl Vitullo: Because soft skills are one measure of seniority. [01:04:15]

Elizabeth Woolf: Oh my God. Yeah. [01:04:16]

Carl Vitullo: Navigating a difficult conversation like "I've been under leveled," that takes a lot of soft skills. Yeah. [01:04:21]

Elizabeth Woolf: I interviewed a CTO and he's like, "if you can't communicate, you can't get promoted." [01:04:24]

it's terrifying. But it can, it's, it's learned. Yeah. It's the same way you learned React, and I, I know it might sound different and look different, but it's, it's gonna take the same level of learning and practicing. It's not innate, you weren't born knowing how to do this, you know. [01:04:41]

Carl Vitullo: Yeah. And I think one of the other constraints around trying to become properly leveled is going to be whatever performance cycle you're a part of now. [01:04:52]

Elizabeth Woolf: Yeah. [01:04:53]

Carl Vitullo: Like I think that there's, I think there's a lot of, there's so many ways to, to fail that set of interactions. There's only really one way to succeed. Ultimately you're asking for a promotion. [01:05:03]

Elizabeth Woolf: Mm-hmm. But you should ask for it a year before you want it. [01:05:05]

Carl Vitullo: Right. Which I, I think that's another way of saying, it will take a year to get what you want. [01:05:10]

Elizabeth Woolf: It will, you're never gonna be promoted unless you're doing the work. It's just, that's the way it works. They have to trust you so much in that role. And I get it, cause it's a business decision. It's hard emotionally though. So I have always advocated for people if, like, if you, if this is the year you wanna get promoted, say it. [01:05:26]

And then you have a manager who has that authority to get you there because now they know if you're telling them a month before the promotion cycle, I'm so sorry, Sweet P, but like that's gonna be real hard. [01:05:38]

And you know, like if you tell 'em a year beforehand, now you have the benchmarks you gotta hit. Now you can, now you know, like, where do I need to be? What do I have to do? Which makes it so much easier on both sides, especially when they have to go tell your case. [01:05:49]

Carl Vitullo: Yeah, definitely. All right, Elizabeth, thank you so much for coming out. [01:05:53]

Elizabeth Woolf: Oh my God. Are you kidding? This was great. [01:05:55]

Carl Vitullo: Yeah, it was very fun talking communication and soft skills. Anything you'd like to plug? Any, any worry we can find you on socials or anything you want to wanna share with us? [01:06:05]

Elizabeth Woolf: Yeah. Um, if anyone, so we talked lightly today about feedback, different ways of doing it. I'm doing a webinar next week if you just wanna learn more. And the reason I'm doing it is so you can enter the webinar, and then after it you can leave and literally go to your next meeting and know how to do it. I am not one to do fluff. If you just wanna learn it, get out and start practicing your skill. I'm here for you on that. [01:06:27]

And then I'm also doing, so let's be honest, communication is hard and it hurts sometimes, so I'm doing just live sessions. So Q&A sessions, you just take a time, you book it and we can practice it. It is free. It is just you and me or other people, and we can just practice or talk about things you're facing. So the threshold for entry is really small, but making sure that you get what you want to just be a badass engineer, which is the goal. [01:06:54]

Carl Vitullo: Heck yeah. All right. Well thank you so much for coming out. This was an absolute blast. [01:06:59]

See ya. [01:07:00]

Elizabeth Woolf: Bye all.

React Miami with Michelle Bakels

Reactiflux — Fri, 28 Apr 2023 16:00:00 GMT

Listen or subscribe

Carl Vitullo: I'm here today speaking with Michelle Bakels, who is working with G2i as director of developer Health and organizer of the React Miami Conference, which is coming up in a couple of weeks on April 20th. [00:13]

Yeah, Michelle, thanks so much for joining us. [00:15]

Michelle Bakels: Yeah, so thanks so much. I am organizing the React Miami Conference. We have a partnership between G2i, which is the company that one of your moderators Gabe Greenberg, is the founder of, and JS World Conferences, which is a huge conference organizing body that's based out of the Netherlands. [00:33]

They do JS world conferences. They do Vue Conf, React Conf over there. And so, um, yeah, So I co co-organized that with them, and I am the director of developer health at G2i as well, so I, outside of the conference I work on initiatives to support the mental and physical health of software developers. I've also been really active in the South Florida tech community for a really long time, so I am on the board of organization called South Florida Tech Hub Foundation, which is a nonprofit that helps provide like, tech Pathways in South Florida. [01:10]

And then also I'm on the board of 1909, which is also a non-profit, that's a community of creators, entrepreneurs, founders, small business owners in Palm Beach County. Just help them thrive. [01:23]

Carl Vitullo: That's awesome. Wow. So you're, involved with so many different community based organizations, that's really great. [01:29]

Michelle Bakels: Yeah, I'm like a community addict (laughter). I like, can't get enough. [01:33]

Developer health, and planning a conference

Carl Vitullo: Oh, that's incredible. Very nice. Could you talk a little bit about developer health, and how that has influenced how you think about the conference? [01:41]

Michelle Bakels: Yeah, um, that's such a good question, because obviously because like this is such a, a core piece of G2i is to, to focus on developer health. We brought it into the conference as well. The conference is on Miami Beach. So for one, it is absolutely beautiful place to be, to relax, to get some sun, enjoy some life. [02:03]

So like, sometimes conferences can be like really hectic for attendees, but even though we have a lot going on in our conference, we do encourage people to really, like, kinda take a step back and enjoy what's around. I've been to a lot of conferences where you kind of like, fly into the city, you go to the conference location, you grind all day at the conference, and then you fly out right away. [02:25]

We really try and like, integrate our conference into the Miami Tech scene and into just like, basically Miami culture as a whole so that it can be like a little bit more relaxing. Like you kind of leave, like you learned a lot of stuff, but you also leave like, a little bit happier, more relaxed, not really stressed out. [02:42]

And then furthermore, we have a couple of talks this year that are specifically designed around giving developers advice and support on you know, how to maintain mental health and physical health. [02:55]

Carl Vitullo: Oh, that's great. [02:56]

Michelle Bakels: Yeah, we have like three talks that are like, really specifically developer health focused. [03:01]

Tejas Kumar, React as a developer health tool

Michelle Bakels: One of them is Tejas Kumar, who is really well known conference speaker. If you don't follow Tejas, he has you know, like a long history of health related issues stemming from a sun allergy. He's gone through a lot ,and so he's gonna talk about how, you know, coding and specifically React, kind of like helped him through a lot of this. So it's called "React as a developer health tool." So that's really cool. [03:26]

Jenny Truong, unexpected states of burnout

Michelle Bakels: Then we have Jenny Truong of Stately. She's going to be talking about the unexpected states of burnout, she actually, like, if you're familiar with Stately and how it, it basically is like state machines and like diagrams and stuff. She's actually gonna kind of take that visual and that concept and map out, diagram out, burnout like how we experience it in the terms of like state. So that's yeah, it's super interesting. Like, I was like, this is so clever. [03:55]

Andrew Shew, mental tooling from professional baseball

Michelle Bakels: And then there's also Andrew Shew of Vercel. He's a content engineer, but he was a pro baseball player for six years before he went be a full Slack developer for Vercel. So he's gonna talk about all of the mental tooling that professional baseball players use to perform their best. And how you can literally take like the tools of professional athletes and apply them to your work so that you can. [04:21]

Athletes, the longevity of their career is so important. So if they themselves too hard, like they have to find that barrier between like giving their best performance but not putting themselves out for a season. And that's where like engineers kind of break that. Like we constantly burn out, so we go into that injury area so often. [04:41]

So he's gonna share like the tools of like, okay, how do you pace yourself so that you're performing as best as you can over a long period of time. So that one's gonna be really interesting too. [04:52]

Carl Vitullo: Yeah, I'm really interested to hear a professional athlete talk about that aspect of health and really thinking about. Thinking about the long term, like yeah, this is, this is not a sprint, this is a livelihood. This is something you will likely do for your life. So, yeah. Oh, that's so interesting. [05:09]

Early bird outdoor activities

Michelle Bakels: it's super interesting. And we, and then we also have like the second morning, so it's a two day conference. So the second morning we have our, basically our developer health, like choose your own adventure. Basically if you're an early bird you can wake up and do yoga on the beach, which we had last year but we have a couple more options this year. [05:27]

Um, One of our speakers, Henri Helvetica, He's going to be leading like a 30 minute run in the morning. So you can choose that or the Sunrise Yoga or another one of our speakers, will Johnson, is going to be leading basically beach volleyball. So you can kind of like choose which one you wanna do, if you wanna wake up early and get active. [05:46]

Carl Vitullo: Okay. That's pretty fun. I'm in a beach volleyball league in New York, so I'll have to, I'll have to try and check that out. [05:53]

Michelle Bakels: Yes absolutely. [05:54]

Who is the target audience for React Miami?

Carl Vitullo: I, I see a question in the chat here. Who's the target audience of this conference? Is that mostly gonna be aimed at people who are already working with React professionally? [06:03]

Michelle Bakels: Um, Yeah, so we have I would say React developer or JavaScript developer, and it can be from beginner to experienced. We try to have a range of topics that can kind of like speak to both ends of a career. [06:18]

Carl Vitullo: That makes sense. Yeah. I feel like every conference is gonna have some talks that are very educational for anyone who is just trying to learn. But then a lot of the developer health kind of talks, that sounds a little bit more professionally oriented. [06:31]

Michelle Bakels: Yeah, it's a good one too for beginners though, because I mean, to be able to get ahead of those burnout experiences early in your career and like develop those good habits early is. Really like beneficial. But yeah, there's like some that are gonna be, I imagine a bit advanced, for example, Sunil Pai, who's like just prolific in, in web development… [06:54]

Carl Vitullo: We just had him on. [06:55]

Michelle Bakels: Yeah. Like, yes, exactly. He's so amazing. He's gonna be talking about this you know, collaborative app that he's working on, realtime collaborative app. And I imagine that the technical content of that talk is going to maybe go over a few people's heads, probably even go over my head. [07:14]

He also has this like super interactive moment built into his talk that, you know, anybody can have fun. Like, you know, maybe you're catching like 10 or 20% of what he's saying, but it'll still be really fun cuz he has this like really fun activity planned for everyone. [07:30]

Carl Vitullo: Yeah. And we do have a discount code to give away. If you're thinking about a conference I think this one sounds like a pretty great one to go to. [07:38]

Carl Vitullo (editing): If you do grab one, at reactmiami.com, make sure you use our discount code, REACTIFLUX10 [07:44]

Speakers Michelle is excited for

Carl Vitullo: You've mentioned some of the speakers, especially the ones talking around developer health and burnout. Who are some of the speakers you're really interested in hearing from? [07:52]

Michelle Bakels: It's really hard for me to say because all of them, I do do most of the selection for the speaker lineup. Not a hundred percent, but very close to. I think obviously the developer health talks are gonna be super interesting. [08:06]

Christopher Chedeau, who's like one of the React pioneers of like, the GOATs of React, he's gonna be speaking and he's gonna be talking about. I don't know if, if you guys follow him, then you'll have seen these like tweets of him kind of like learning in public, building in public, this in browser video editor. [08:28]

I don't know that he's spoken about this at any other conferences yet, and it's very much something that he's like actively building, and he's going to be talking about that, which I'm really excited about. So his talk is one that I'm super looking forward to. [08:44]

Julian Benegas of Basement Studio. So I don't know if you guys are familiar with Basement Studio. They're like based in Argentina. They're a design and dev shop in Argentina, and they are so high quality, like, they're the minds behind, like the Next.JS rebrand. They just did Mr. Beast's new website, which is like an award-winning website. [09:07]

They actually do a lot of the work behind, like the Vercel website, like what you see on Vercel's site. They work really closely with the Vercel design team. And they have like a upcoming project with Solana and like a really cool like metaverse fashion show project too. So their head of development is gonna be giving a talk about Scrolly Telling. [09:28]

Basically like captivating your audience, like on your landing page by like on scroll animations and like telling a story, like as you know, a user goes through your website, and I don't know if you guys saw uh, Next.JS conf like. Uh, Guillermo RA's keynote, the basement studio team built out that whole keynote. So, I can only imagine what their talk is gonna look like. So that's another one that's gonna be amazing. [09:54]

Carl Vitullo: Yeah. That's pretty incredible. The Next website… It felt like it's on the cutting edge of web design, leading the charge on that. So that's, that's pretty cool. I I, I didn't realize that that team that had built, that was based in Argentina. I've definitely heard a lot about Argentina based development companies. It sounds like there's a, a lot of really cool stuff happening in Argentina. [10:14]

Michelle Bakels: Argentina has such strong talent. It's like blows my mind how underrated it is. It's like phenomenal. Like the people that you see working from Argentina, like they're just, they have such great talent. [10:27]

Carl Vitullo: Yeah, and Christopher Chedeau, I'm always interested to hear him talk. He's such a, intelligent and giving person. We, we actually had him on a couple weeks ago to talk about the React documentary uh, which he helped organize and we ended up getting deep into the history of Reactiflux because turned out he helped organize Reactiflux too, he was one of the behind the scenes guys, [10:48]

Michelle Bakels: I was listening in on that one. That one was super interesting. Yeah [10:52]

Carl Vitullo: So that's some of the speakers you're excited about. [10:55]

Michelle's philosophy for organizing a conference

Carl Vitullo: Could you talk a little, a little bit about the, I guess, the philosophy that you've approached organizing a conference from, like, how have you thought about creating space and programming to help developers with their careers? [11:09]

Michelle Bakels: That's such a good question. It's like this question like between that question and like how do you choose speakers, I always feel like that Always Sunny in Philadelphia meme of like that crazy map with like the red string. I'm like, so this is how it works. This. [11:23]

Carl Vitullo: You go insane for a couple days. [11:26]

Michelle Bakels: Yeah. But, but yeah, like hopefully I can like come up with like a comprehensive answer to this, [11:34]

So, how do I think about creating a conference to help devs with their careers? So, so first of all, like born and raised South Floridian. So the conference is on my home turf, I'm like very well connected with the community and with the environment that we're working in. So, again, like I really try and bring the city into our conference and vice versa, so that people are really, oh, what's up South Floridian. Okay. So like, I'm like looking at the chat too. [12:03]

So try and like, bring it all together to really feel like community, because I think part of what makes a conference the most successful it can be for attendees is to facilitate networking as much as possible. [12:17]

The talks are all obviously like the key learning moments, on the books. But it's like being able to talk to the speakers, network with the speakers, and network with the other people there and create, like all of these relationships is so important. [12:32]

We definitely wanna make it like a fun environment where you wanna stay and you wanna hang out and that you can relax and you don't feel stressed. So like you're really there as your best self, and like an energetic person. So there's definitely that aspect to it. I think also like a huge part of our philosophy is diversity of our speaker lineup and diversity of our attendees. If you don't know, like Miami is an incredibly diverse city. [13:00]

We want to be true to that in our conference as well. We really try to, first and foremost, I, I have the personal belief that your speaker lineup is gonna be a reflection of the people who are going to come to the conference. [13:15]

So if you have like, all of these big names, everybody's like super senior, they've been in the game for like two decades. Like it's gonna probably feel a little bit intimidating and it's might not feel like the most welcoming place for everyone. I definitely want. People to be able to like look at the speaker lineup and be like, oh, there's first time speakers, there's a lot of women, there's experts. [13:39]

So like, there's just this range of attendees that can come and see themselves being comfortable in this environment. So I think diversity is like huge for us. And then of course, like the community aspect and then of, for just logistics, we co-organized this with JS World Conference, who's like, a pro at putting together conferences. [14:00]

And so logistically they are just like on top of every single aspect of like operations. So that's the main, the main kind of like concept behind the conference. [14:12]

Carl Vitullo: Sure. Yeah. Very nice. Yeah. I love what you said about the speaker lineup driving who feels comfortable showing up. I think that's so true and that's such a… nobody will ever will ever tell you why they didn't show up. Like you never get to talk with the people who don't come to a conference. [14:29]

I think keeping that in mind and designing a speaker layout so that people looking at what's gonna be happening will feel comfortable, will feel like, yes, these are my people, I can show up and be a part of this. I, I, I love that. That's such a great way to think about it. [14:43]

Michelle Bakels: Thank you. Yeah, we try and do a lot of scholarships too. So our scholarship closed like last week, I think, but you know, we have 500 attendees max for our conference, and last year I, we were able to give away 60 scholarship tickets to help with diversity inclusion. And this year is a little bit of a different year for conferences, but I think we've done, I think we've been able to do 40 tickets so far. 30 or 40 scholarship tickets so far. [15:13]

We actually have a sponsorship package where we, you know, if companies come to us and they're like, oh, I wanna be a bronze sponsor, which is like $5,000 level. We also have what's, basically we called it DE&I sponsorship as well. So instead of saying like, I want my $5,000 to go to the conference, it's almost like dedicated funds for, the way that you would do dedicated funds to a nonprofit and you're like, I want my $5,000 specifically to go towards funding tickets from your diversity inclusion applicants. [15:43]

Carl Vitullo: Right. Very nice. Okay. So they can pay to help support the logistics and operations of the conference, or they can give money directly to paying for tickets for attendees who otherwise might not be able to make it. That seems like a great way to structure sponsorship. [15:56]

Putting on a conference in 2023

Carl Vitullo: While you were just saying that, about it being, you know, a different time for conferences, we're in 2023, it's starting to feel like the pandemic is over. How is designing a large event that people are gonna be traveling to attend to, how is, how has that been? [16:11]

Michelle Bakels: I mean, we did our conference last year. So yeah, it was like last year was I think the first. It was like last April, I would say that was like the first time that a lot of people started really, I think traveling. So now we have had like a full calendar year of people traveling and going to all kinds of different events. [16:32]

And so, the people that are comfortable with traveling and attending conferences, I think people are like getting to be a little bit more comfortable with that. I don't even think that the issues this year are necessarily with that so much as the economy of the tech industry right now is it, it's in a really tough place. Like one, one of the toughest spots that it's been in a really long time. So, or maybe ever. [16:57]

So yeah, we're just very cognizant of, you know, we depend a lot on sponsorships, obviously, to be able to meet our attendees expectations. And so many companies just have their marketing budgets frozen until q3 and it usually takes about three months to like work with a company on a sponsorship. [17:14]

So I think, let's say this kind of like hard economic hardship flushes itself out on time with what's projected? I think it'll be in, you know, Q4 when conferences start actually kind, kinda like seeing the typical sponsorships and numbers that they used to. [17:32]

Carl Vitullo: So you, you are a native South Floridian. Could you talk a little bit about the Miami tech scene and how that's evolved in the time you've been working as a professional? [17:41]

Michelle Bakels: Yeah, so, so basically I've been a software developer for like the last seven years, maybe eight now. So basically when I started learning how to code and I, I learned like I got a computer science degree, but I took my classes all like remotely from Florida State University. I've always just been in South Florida since I started coding. [18:03]

And when I started coding, it was so hard to find a community especially because I'm like really in Palm Beach County. But it was so hard to find a community where I could like connect with other developers and I could learn from them, or I could find like a mentor. [18:18]

Right around the same time that I was looking for a community, there was one getting started called Palm Beach Tech. So I really just threw myself into that community and, and tried to pull together pieces around that of technical people in, in South Florida. And Palm Beach Tech grew to expand to the region, which is now called South Florida Tech Hub and as I mentioned earlier in the interview, like I'm now the chair of the foundation for South Florida Tech Hub. [18:48]

So that's one of those things that's like really evolved over time, of starting as a few like disparate meetups coming together as a proper nonprofit organization that has like big tech companies to like Office Depot and also NextEra Energy, which if you're familiar with it, is the world's leading producer of renewable energy, but like having companies like that involved in the organization. [19:11]

So that's kind of like the north region perspective, and then in the south region closer to Miami, you had also like a lot of people, 10, 15 years ago that were. Pulling together, you know, pieces to build a tech community. [19:27]

So React Miami is kind of like a conference within a conference. We have a partnership with a general tech conference called eMerge Americas. And one of the reasons why I really love working with them is because, a) all of our attendees get free tickets to eMerge America so they can like, enjoy this conference that's like, 40 times bigger than ours, at the enjoying React Miami, but also the founders of eMerge Americas are like, tried and true, like Miamians and like Miami Tech Builders. [19:55]

So the founder of eMerge, his name is Manny Medina, he moved to Miami from Cuba and he had a telecom company and he wanted to sell it and, you know, stay in Miami and everybody was like, no, you have to move to San Francisco or New York to sell a company. [20:11]

And he was like, absolutely not, I'm staying in Miami. And this was, I think, a little over 10 years ago, maybe 12 years ago. He is like, "absolutely not, I'm staying in Miami and I'm gonna sell my company from Miami Beach." And so he did just that. And he sold his company to Verizon for I think like $1.2 billion. [20:33]

Carl Vitullo: Wow. [20:34]

Michelle Bakels: Yeah, like something really high. Like really crazy like that. And he's basically taken that money, created eMerge Americas with his daughter Melissa, who's now the president of, of eMerge. And they are, for the last decade, been putting on eMerge America's conference every single community event that pops up, like they'll sponsor it, they'll support it. [20:58]

When they heard about React Miami, they were like, how can we get involved? Like how can we help you? Which is like, I think a hallmark of South Florida tech community in Miami tech community is this phrase, how can I help? [21:10]

Which has become almost a cliche because of like the tweet from Mayor Suarez. But it is really something that we say all the time, like very collaborative. So, you know, over the years it's been very like grassroots, building up the tech community, bringing in resources, making connections. [21:25]

And then of course, over 2020 we had people from San Francisco, you know, investors from San Francisco, VCs from San Francisco come in and recognize what's happening in our region. And then they kind of like made it Twitter famous, I guess. So it was growing at a great rate already in building up. And then we kind of just had this like, kind of like boom over the last couple years. [21:53]

Carl Vitullo: Nice. Oh, very great. Yeah. What a, what a great story of somebody building something on their own. Staying authentic to their roots, you know, giving back where the city they came from and the city that helped them build their business. That's, that's so great. And now to have it be this huge network of different conferences, that's a really incredible like origin story. [22:14]

Michelle Bakels: Yeah, they are amazing. I definitely admire Melissa Medina is like, it's so funny cuz she's the organizer and president of eMerge, but at the same time she's absolutely like a role model of mine. I definitely look up to her. [22:27]

Choosing topics for the conference

Carl Vitullo: We had some good questions show up in the chat. When you're scheduling the speakers, how do the topics get chosen? Do you have an idea in mind of what topics you'd like to have on stage and then you find people who could talk about them? Or do you do outreach specifically to speakers? Is it inbound? [22:42]

Michelle Bakels: It's both. So usually we have to, in order to stimulate sales of tickets, we have to have some speakers announced. So we usually do a preliminary outreach to a couple people that we feel would be a good representation of our conference and what we're looking for. So it'll be a mix of some first time speakers. To very experienced speakers and like experts in the field. [23:09]

And then among those people that we reach out to, we try and also have racial and gender diversity represented as well. So that is what we call the speaker preview. And that's direct outreach. And that's like the down low, like, "Hey, don't say anything. We're gonna do a big announcement" kind of thing. [23:26]

And then throughout this whole time we have our call for papers open as well. I would say that as far, if — this is like my Always Sunny in Philadelphia moment again — but like I would say that like as far as picking topics and speakers from the CFPs, I really don't think that I have with certainty, some kind of knowledge ahead of time of exactly what the speaker lineup will end up looking like, because there are so many people that apply for the CFP that I'm like, "how did you even find this? Like you're not on Twitter, you're not on Instagram. Like, how did you even hear about us?" And they're like, and, and they're just the most incredible people. [24:06]

And they, maybe they've never even spoken at a conference, but you read the other things that they've done and you're like, "oh my God, I have to have you here." And so, I would say that there's definitely a mix of just trying to find like a huge range of diversity among the speakers. Which makes it just so interesting. [24:23]

And then as far as topics go definitely wanna try and hit what's trending. Obviously things that are really important to people, but I also try and avoid things that are trendy, if that makes sense. There was some like, Twitter explosion around like suspense, for example, last year. And React 18 actually came out like two months after our CFP actually closed. [24:51]

And so people were like, why isn't there a talk on this? And I'm like, well, we chose our whole lineup before this even came out. And aside from that, you can see how like the discussion around suspense like really quieted down. So it's like, you know, for the people that are coming, a lot of times they're sent by their companies and a lot of times they're like, maybe not even on Twitter or part of these conversations. [25:14]

And so you wanna try and find the things that appeal to enterprise and corporate developers as well. People who can't change their tech stack decisions or their design decisions based on like, what's happening on Twitter, right? So you also wanna try and keep like the tried and true talk. [25:30]

So I try and always have, straight React talk, talks that involve machine learning, talks that involve type safety, you know, a little bit of backend, and infrastructure. So it's like, yes, it's front end, but I think that the days of like just somebody being solely a front end developer is kind of fading away. [25:52]

So it's like I kind of try and feel out like a lineup of topics that speaks more to the full stack developer that does React as the front end. [26:02]

Carl Vitullo: Yeah, that definitely makes sense. That's a trend that I've noticed as well. And I guess that the React core team has sort of been pushing as well a lot more emphasis on crossing the client server boundary. That makes sense. Yeah. What you said about tr picking things that are trending but not trendy, that sounds like a tough balance to reach. [26:21]

Michelle Bakels: (laughter) It is, and sometimes get called out. [26:25]

Carl Vitullo: Sure. Right. Yeah. It's picking something that people are excited about, but that has staying power survive the life cycle of organizing a conference. Yeah. That sounds like a, a tricky balance. [26:36]

Michelle Bakels: Yes. Yeah, you, because the videos last forever and you obviously, you wanna have something beneficial to people in the moment, but you also wanna have something that people can watch again in two years, and it's still informative. [26:48]

Carl Vitullo: Right. Somewhat timeless at least. [26:51]

Reaching out to first-time speakers

Carl Vitullo: Did I hear you say that you do some outreach early in the conference to first time speakers? [26:56]

Michelle Bakels: Yes. [26:57]

Carl Vitullo: How do you do that? How do you discover people, first time speakers to reach out to at that phase? [27:02]

Michelle Bakels: It's actually one of the very small benefits of being chronically online. So I spend a lot of time on Twitter and you connect with all kinds of people. You start to like be able to see who these like rising star developers are. [27:17]

We usually try and have like a good handful of first time speakers, but one of our first time speakers was Will Johnson of Auth0 and Okta. And I think you can see like how much he's blown up over the last year with his content and, and the material that he creates. [27:34]

And then another one is Camie Ramos who was a first time speaker and React Miami was her first conference. I remember one night at the speaker hotel like, Brandon Bayer, Tejas Kumar, Kent Dodds, Facundo Giuliani, like all of them on the back patio of the speaker hotel, giving her feedback on like her practicing her talk. And now she's probably given like 20 conference talks. Like she's in such high demand now and traveling all over the world since then. [28:01]

So I think like part of it is just being online and like seeing, okay, who's building, who's creating, who has like, who's kind of walking into a topic or a niche and is gonna probably have a lot to say about it. [28:15]

So that's how you, how I kind of find the first time speakers. [28:19]

Carl Vitullo: Yeah, I like that, that's a really good answer. [28:21]

You had said earlier that one of your, one of the driving motivations behind the conference is… networking is such an important aspect. So hearing a story of a first time speaker being given an opportunity to be in network with these very experienced speakers, and that being a, a spring pad for her, at least for her speaking career. [28:42]

You know, who what that, how that reflects back on the actual career, but, oh, that's so great. That's, that's such a good example of a, a success. [28:50]

Michelle Bakels: Yeah, it's something that's really awesome. And I think also I have this, I don't wanna like curse, but like, basically like no a-hole policy. So it's like, even if you're like the biggest superstar in the world, but you're like constantly picking fights on Twitter, I probably am not gonna like, Ask you to be a part of like our super lineup because I love those moments. [29:13]

Like the people that are, like the veterans that do come, they're so generous with their knowledge and their time, and I think that's so important. And so I think it's also like finding the right personalities that make everyone feel comfortable when they're there. And, you know, Tejas Kumar, I think is like an exemplary speaker here because, he's even offered this year to do one-on-one coaching and feedback the whole time leading up to the conference. So speakers can reach out to him and like get feedback from him. And he obviously spoken at like a hundred conferences and is a pro. [29:45]

Carl Vitullo: I had an opportunity to speak with him, really for the first time. I, you know, I had met him at conferences, but we had him on to talk about his new business and going independent a couple of weeks ago. Yeah, I really, he's just so generous, so generous and so enthusiastic. [30:00]

Michelle Bakels: Mm-hmm. [30:01]

Carl Vitullo: Like you said about getting the right personalities to have the event feel good. Someone who knows a lot and who gets joy from bringing other people up to their level. I think that's, such a good energy to, to bring. [30:13]

Michelle Bakels: Yeah, definitely. I think all of those guys, Facundo, Kent Dodds, Brandon Bayer, they all have that energy and there's like, I love that. I love seeing them spend time with the speakers ahead of time and give feedback. It's like warms your heart. [30:27]

Carl Vitullo: Yeah. Sort of, I guess a follow up to the question I asked about reaching out to first time speakers. [30:32]

Tips for wanna-be speakers?

Carl Vitullo: Any tips for people who have never spoken, getting their first speaking opportunity? [30:37]

Michelle Bakels: I'll preface this by saying that the things that would stand out to me are not true for all conferences. All of the things that I described on like how I do a speaker lineup, that is not true for everyone. All conferences kind of have their own criteria of who they choose. [30:52]

So with that said, I would say, there are some conferences that just are not interested in first time speakers. If you apply to one of those conferences, unfortunately, like it's so hard to like, we try and like kind of lay out the criteria in our CFP, but not every conference does that. [31:09]

You could very well accidentally apply to one of these conferences that are like, "we only want celebrities" and you know, I would say biggest thing is just not to take it personally. Like if you get rejected, it pretty much happens to everyone and it will happen to even the experts, like even the veterans get rejected still to this day. [31:27]

So with that said, I would say, if you don't have any conference experience, it's really important to convey to the organizer what kind of energy you're gonna bring to the stage, how you are as a speaker. We want people who are on stage who are going to like, engage the audience. You know, seem really energetic. That carries over to the recordings and stuff that go up on YouTube afterwards. [31:51]

So we want people who are also really good at explaining their ideas. So if there is an opportunity, even if it's optional, always try and submit a video or something of you talking about your topic, you know, what your ideas are or how you're gonna be as a speaker because there's just no premise for it that anybody can reference. And I think that's like the biggest thing is for people to get an idea of who you are. Cause culture is huge at conferences. So I would say that is a video is really helpful. [32:21]

If you don't do a video, don't skimp out on, you know, describing what your talk is about. Don't skimp out on your bio. You know, you'll see like somebody like Ken Wheeler today, his bio is, "an award-winning, critically acclaimed music producer that's just doing computer stuff for the money." [32:40]

A first time speaker can't submit that as a bio. Ken Wheeler can submit that. Cause everybody knows Ken Wheeler now. [32:47]

Carl Vitullo: Ken Wheeler has a brand. [32:49]

Michelle Bakels: Yeah, exactly. So it's like, at least three to five sentences, like explain, you know, the most impressive things about you. And yeah, I think somebody said context is key. How does it relate to this conference? You're basically like trying to get hired, right? So like, why should we pick you? [33:05]

And then your topic idea, just make it really clear and make it really well understood, like why you're the expert to talk about. Thing, like if there's, you know, 10 people who submitted talks on accessibility, why should they choose yours? What are you gonna bring in your talk that's gonna be really important and beneficial to the audience? [33:24]

So those are definitely a couple of my biggest tips. [33:27]

Carl Vitullo: Yeah, that makes sense. I know that a lot of the time, many speakers at conferences are either professional developer relations, you know, they're working for a company specifically to go to conferences and speak about the product. Consultants or people like that will do it for a branding opportunity. [33:44]

There's a lot of competition and, and like you said about some conferences really focusing in on the celebrity speakers. I imagine that those conferences are not going to tell you that's what they're doing. [33:54]

Michelle Bakels: No, no, like just on the D-L, like between all 50 of us and whoever listens to the recording, like I know for a fact that there are conferences that rank really highly, like the number of Twitter followers that you have. They're never gonna put that on their website, but it is what it is. [34:12]

Carl Vitullo: Right. Yeah, that makes sense. I like how you describe it as, you are trying to be hired, basically, you know, it's, it's lower stakes because it's one event, not an ongoing, compensation structure. But yeah, you are selling yourself in a very similar way to a job interview. [34:26]

One piece of advice I've heard given before that I'd love to hear your take on, is to speak at meetups because it's a smaller scale, lower stakes environment to get a speaking experience. [34:36]

Michelle Bakels: Yeah. Yeah, I definitely think it's definitely good advice if you're able to do that, to try and find a virtual meetup. Or a one in your community, or you can just organize one yourself. I think that's a really great way to get speaking experience and I think it's a really great way to get your ideas across. [34:53]

We don't limit the number of proposals somebody can like send us, so there are definitely a few people that submit tons of talks that, sometimes it feels like, well, are you. You know, is this for a line item on your LinkedIn, or do you really care about talking about this thing? And so sometimes I can really tell that people care about that thing that they wanna talk about, but it, you know, we have a single track conference and at some point we have to cut off who we accept. [35:21]

And I would say also, just like if your talk doesn't get accepted, even if you make your own video at home, just talking about this thing the next time you go to apply for a conference, now you have a video of you talking about this thing. And you know, like you have people who are like interested in you talking about it. [35:40]

Like you kind of have an audience which makes you more compelling, you know, for the next time around. [35:46]

Carl Vitullo: Right. Yeah, that makes sense. Yeah. So I guess maybe one point of feedback that could be valuable for someone trying to get the first time speaking experience is just start speaking, find any opportunity you can to get a platform of, to talk on whether it's Meetup in person or virtually. [36:03]

I know, you know, like we've had a number of people reach out to reactiflux to me to say, Hey, I'd love to come on and do an office hours event. [36:10]

Carl Vitullo (editing): Hint, hint! We accept inbound requests to speak at events like this, you can DM me, vcarl, or email hello@reactiflux.com. [36:18]

Carl Vitullo: So yeah, I think we are one stage event where people , could come up and talk. I've heard of like virtual coffee podcasts, things like that. There's, I think there are a lot of speaking opportunities that are maybe lower stakes, a lower barrier to entry than you know, in-person live on stage at a conference. [36:35]

Michelle Bakels: Absolutely for sure. [36:37]

Will talks be recorded? (yes)

Carl Vitullo: One question about the conference, for people who attend virtually, will the presentations be recorded? [36:42]

Michelle Bakels: Yeah, so we'll have, as we get closer to the conference, I mean, we're two weeks away, so I guess it should be in a couple of days, hopefully. We're going to have a link up to register for the live stream, which is going to be free. So we're gonna have a live stream of the conference and then, I would say about, it takes two weeks of post-production work to get the talks all ready to go. [37:04]

So I think at probably at least two weeks after the conference, then the recordings will be up. For anybody who wants to watch. [37:12]

Documentary screening, afterparty, beautiful venue

Carl Vitullo: Sure. Yeah, that's a lot of video content. Anything about the conference you feel like should be highlighted? [37:17]

Michelle Bakels: We gotta talk about so many fun things about the conference. I think again, I mean, I think we have like an amazing speaker lineup that's super interesting. Two days in Miami Beach, like , cannot beat that, in my opinion. I think one thing that we didn't talk about yet is the opening party. [37:35]

The conference starts on a Thursday morning, so the night before on Wednesday, we're gonna have a React documentary screening. There's a rooftop cinema club on Miami Beach, which is obviously a rooftop cinema, which is very cool. And it's very fun, they have like, almost feels like carnival concessions, and then like these comfy Adirondack chairs in a, in front of a big screen. [37:57]

We're gonna have some networking. We're gonna screen the React documentary, and then afterwards we're going to have Ida Bechtle, who was on the Reactiflux. For the documentary, Ida and Christopher Trudeau are both going to do a live short Q&A with Sunil Pai. [38:13]

So they're gonna kind of have like a Q&A conversation for about 15 minutes after the documentary, and then you'll be able to network with them after the documentary screening as well. And it's just such a fun environment. [38:25]

And we're also gonna have like a, a DJ who's a really cool DJ because they're actually like, South Florida, founder, entrepreneur, community builder person. And then they like have like the DJ thing too going. So it's like a really cool person to meet. And also do a great job DJing. So she's gonna DJ for the opening party and she's gonna DJ for the after party, which is at the backyard, at Marsai hotel, which is just this gorgeous hotel on the beach. [38:53]

if you ever see any pictures of React Miami or the videos of React Miami with this kind of like outdoor boardwalk kind of thing with like a shallow pool and like these lily pad platforms, that's the Marsai Hotel. We did our opening brunch there last year and now we're doing our after party again. [39:11]

DJ Lovely uh, is gonna be DJing that as well. It's just this really cool backyard chill area and the beach is like right on the other side of the gate and it's just like, so cool. So those are kind of the extra little gems. [39:25]

Carl Vitullo: Yeah, that sounds pretty awesome. The opening and closing party especially, that sounds like something not to miss. [39:32]

Michelle Bakels: Yes. [39:33]

Carl Vitullo: Cool. Well, we're coming up on an hour here. Yeah, Michelle, thank you so much for coming out. This has been a really great talking to you about React Miami and conferences in general. [39:40]

Michelle Bakels: Thank you. Yeah, it was like definitely fun to have this conversation and like I said, an hour ago or so, I could talk about React Miami forever, so I enjoyed it. [39:52]

Where can people learn more?

Carl Vitullo: For sure. Yeah. Well, where can people find more information about either what you're doing or the conference itself? [39:58]

Michelle Bakels: you have some good, perfect links here in the chat. So reactmiami.com is our website. ReactMiamiConf is our Twitter, where we post everything first. We're also on Instagram at React Miami Conf. And then for me on Twitter at Michelle Bakels. So you got the best links already up [40:18]

Carl Vitullo: Perfect. Excellent. Yeah. Thanks so much for coming out. It's been really great talking to you. [40:21]

Michelle Bakels: Of course. Thank you. [40:23]

Carl Vitullo (editing): All right. Thanks for listening! If this has piqued your interest, it is not too late to get a ticket, though I'm not so sure about flights and hotels. If you do grab one, at reactmiami.com, make sure you use our discount code, REACTIFLUX10. Thanks so much for listening!

Sunil Pai and Mark Erikson

Reactiflux — Wed, 15 Mar 2023 16:00:00 GMT

Introductions

Carl Vitullo: Thanks so much for joining us for another Office Hours in Reactiflux. I'm here today with Mark Erickson, acemarke, and Sunil Pai, threepointone. Mark. I'm sure you all know Mark. He's been here for years! [00:10]

Many of you may know Sunil Pai. He's been on the React Core team. He worked at Facebook, he worked at CloudFlare , he has worked at a bunch of places and given a bunch of conference talks and is currently doing his own startup party kit for interactive multi-player experiences. Sunil, you want to introduce yourself a little bit. [00:28]

Sunil Pai: But you did such a good job! [00:29]

Hey. Hi. Yeah, my name's Sunil. I did all those things. I'm super excited to be talking about rewrites because, mostly, we don't even talk about product engineering and social media anyway. A lot of the attention goes to libraries and design patterns and well, a bunch of hyped up stuff. [00:45]

But product engineering is what drives the world and rewrites are such an important part of it, and I wanted to share some of my experiences. Also, I get to hang with my buddy Mark. Hi Mark. [00:56]

Mark Erikson: Yo! [00:57]

Carl Vitullo: Yeah, definitely agree. Rewrites are just a very real part of managing tech debt over a product that's going to be used and maintained over a period of years. So I think they approach inevitability as a product continues to be maintained. [01:11]

First rewrite

Carl Vitullo: Sunil, so what was the first rewrite project that crossed your path in your career? [01:16]

Sunil Pai: The first big one was when I joined Yahoo in late 2010, early 2011. Yahoo at the time was going through a not so great period, that they'd just gotten a new CEO and everyone was happy with him because he used to be the ex-CTO of PayPal. [01:33]

But then one day in the news, I think some. Investor was trying to take over the board or something, discovered that he had faked his computer engineering degree, so he got fired for it. It was hilarious, it was so dramatic. But then my favorite CEO of all time took over Yahoo, Marisa Meyers, she's so cool. [01:51]

In the middle of that, we were rewriting Yahoo Maps to move away from being a fully Yahoo product to using the tiles from Nokia as a provider and. That was a fun project. [02:02]

It was also an interesting time for the company. Fun fact, if I'm right, Yahoo Maps and Google Maps actually launched within 24 hours of each other. Some, some point during the two thousands, but Google just, yeah, but Google just killed it. They did such a great job. Anyway but this was my first job doing a rewrite, and I was worried, but I learned a bunch of things right then how to do it without collapsing and failing. [02:25]

But that's, that's the first one that I did. That's, that's my first one. [02:28]

Carl Vitullo: And how long had you been working as a professional developer at that point? [02:31]

Sunil Pai: I had been a professional software engineer for about seven years by then. [02:36]

Carl Vitullo: Oh wow. Okay. So pretty established. [02:39]

Mark Erikson: You actually got to do new stuff for a while. [02:41]

Sunil Pai: I did get to do new stuff, of course. When I started off as a JavaScript engineer, it wasn't even considered real engineering. It was widgets, and we were the worst paid in the office for a while. [02:52]

Some web dev history

Sunil Pai: And honestly, that was great because people just left you alone and you could learn. I remember when Firebug 0.1 was launched, it was incredible, like just such a great day. For the younger folks in the audience, before you had your fancy dev tools, you had to use window.alert() to actually debug your code and see what the values were, sometimes there were bugs that didn't show up when you used alerts. So it was a lot of trial and error to build these applications. [03:16]

I don't think that was the concept of a rewrite at the time. I think it was always burn everything down and let's just do a new thing. So the, it wasn't really a rewrite. People just used to build stuff and then build it again. Yahoo had a way more serious way of approaching front end programming. They had their own module system, bundlers, delivery and insight. [03:37]

And that was one of the reasons a rewrite could make sense because we could actually say, Hey, let's work on these modules first. Hey, let's make an architecture diagram where these things point to these things. And thankfully I could write JavaScript professionally by that time, so it wasn't too hard. I think it was good. [03:54]

Mark's refactor experience

Carl Vitullo: For sure. Yeah. Mark, let me throw it over to you . So you've mentioned doing a lot of refactors and like major maintenance work in your career. Could you just talk about that sort of at a high level for a minute? [04:05]

Mark Erikson: Yeah, so right before we started, I was actually jotting down a list and trying to trace what time have I actually spent doing rewrites. I think basically I've spent about half my career at least doing rewrites or migrations or another [04:19]

2011 and 2012, I built a brand new app using GWT, Google Web Toolkit, which was a Java to JavaScript compiler. 2016, I went back and I replaced the GWT client entirely with React and Redux. 2017, the Backbone app that I was working on needed some new features, but I got frustrated with Backbone and figured out how to put React and Redux in the middle of all the Backbone. [04:46]

2019 we got permission to finish migrating our Backbone app to React and Redux, and there was another team's GWT app that we were going to completely replace the client with React and Redux. We spent a year prototyping that, had some good progress, then those projects got canceled entirely. [05:04]

I got switched over to be the team lead for an existing internal tool that was built with the classical MEAN stack, so Angular one on the client side and Express on the backend. And we spent the next two years migrating the client side to be to use the Next framework with React, Redux and TypeScript on the front end and converting the backend Express app to be TypeScript. [05:30]

And then in 2022, I joined Replay, and the Replay code base started as a copy paste of the Firefox dev tools. It used React and Redux, but it was very old school React and Redux from like 2015. And so we spent the next nine months modernizing that, deleting a lot of code, converting the entire code base TypeScript modernizing the Redux and bringing in really, really fancy stuff like alpha level React suspense things. [05:59]

So yeah, I've, I've spent at least as much time doing a rewrite or a migration of some kind as I have spent actually getting to build anything new in shiny. [06:08]

Carl Vitullo: Yeah. Wow. That's a lot of rewrites and major refactor projects through your career. [06:13]

Rewrites are definitely very fraught. I don't think I've ever been on a project that was branded as a major rewrite that was successful. I did work one place that transitioned from Backbone to React, but that was a gradual transition, not a rewrite. [06:28]

Sunil, I really liked the points you raised about like product engineering and the reality of rewrites as a necessary part of engineering. [06:36]

Zero cost feedback loops

Sunil Pai: I've been thinking about this ever since we started talking about it on Twitter. I think my one line banger for this is, rewrites are possible if you have a zero cost feedback loop. And what I mean by that is, at any point of time, you should be able to demonstrate what the status of the existing project is, but also the work in progress is. [06:56]

So you'd be like, Hey, I'm, I'm trying out something new. Have a look at it. Can you share it very simply with a link to something. Are you able to get feedback on something before it's deployed? Are you able to deploy everything immediately to a smaller audience? And is it easy to revert a change? [07:13]

So this is what I call zero cost feedback. So if you can do this, that means that you can do course corrections, not just every sprint, and not just every day. Like you can do course corrections every hour if you want to. [07:26]

Sunil's two largest rewrites

Sunil Pai: So the two projects that I think about for this are the two biggest rewrites that I've done, so one is we rewrote an e-commerce website, myntra.com, which is a very big apparel, clothing site in India. It got acquired by Flip Card simply because we scaled. Those were great days, and that was at the point of time when every PHP site was being rewritten with Node just so that it could scale. And we had to do that without shutting down the site. Like you, you can't say, Hey, come back in six months. You still need to have sales. [07:53]

The second one was Wrangler, which is the CLI for CloudFlare workers. That's another situation where we are like, shit. The existing cli, it wasn't particularly bad, but it was incredibly hard to iterate on. [08:06]

Like it was built with Rust and it was fast-ish, but it didn't really matter because it was mostly IO bound, and the one part of the thing that should have been in Rust was the bundler, but they used webpack instead, which is actually much slower. So we flipped it and we redid the entire CLI with TypeScript and used ESBuild as the bundler instead. So it made everything faster. [08:26]

But I remember the way we did both these projects, which is from day one, we started doing demos and, Hey, do you wanna see a cool trick? Imagine if you could use Wrangler without a configuration file, and we just infer everything. [08:38]

So you start off with the, "wow, look at how great the experience could be," and then start filling in those features. And on the e-commerce side of thing, it was a, "Hey, how quickly can we put up a much quicker shop?" Every E-commerce site has like five pages. It has a homepage, it has a search page, it has a details page, it has a cart and a checkout, roughly speaking. [08:56]

So we started off with a search page because that's where most of the SEO juice would land. So we figured, if we could fix that, then we could work on the other parts really quickly. Being able to make a setup where we are like, "Hey, for every PR we can make a deploy preview that you can check if you want to and give feedback on." [09:13]

Vercel has now actually formalized this by not only having preview URLs, but also having comments on previews. I don't know if you've seen this. It's such a great feature, by the way. Phenomenal stuff. I think that's why they did it. [09:24]

With the Wrangler cli, we used to publish every commit to a beta tag. We'd go into the community Discord and tell a bunch of people, "Hey, like, you wanna try something new? Just do npx wrangler@beta this thing." [09:34]

if you are doing sprints, that would mean in a year you got about 26 chances for reviews and course correction. But if you do every commit, that means you have about a thousand chances at course correction. So that's a 20, 40 x in increase in opportunities to fix the thing. [09:51]

And I think that's the thing I wanted to talk about today, which is that's how you do rewrites. You don't do rewrites by saying, Hey, we are disappearing for six months, and we'll come up with something that looks exactly the same, but better for some reason. The trick is to just iterate like mad. What do you think? [10:06]

Carl Vitullo: Yeah, I really like that framing. I hadn't really considered about sprints versus commits and opportunities for review, but I think that's a really good way to think about it. It's so many more opportunities to get feedback. And what you also said about where those successful rewrites in your career came from, it sounds like they all started from a real point of friction for users. [10:27]

There was some technical reason why the current solution was not working as well as it could have for users and by making small demos of what improvements could look like and then working to get those into a suitable replacement. That does seem like a, a much more successful way to approach a rewrite than saying, "ah, this is old! We need something new!" And vanishing for six months, like you said. [10:51]

Mark's experience, government project timelines

Mark Erikson: Funny, I'm definitely not gonna disagree, but it is kind of funny that my own career has had a somewhat different arc and experience in those terms. And a lot of it's because I spent the majority of my career working at a large government contractor where we would typically do development cycles that were six to eight months, maybe even like a year long. [11:12]

And even after that, there would be several more months of testing cycles and whatnot before the software finally got deployed. And on top of that, we were generally building internal tools, so we didn't have chances to show things off to customers and whatnot. [11:27]

So a couple of the, a couple of the things that I worked on like the rewrite that I did in 2016 I was actually able to basically disappear for like six to eight months and work on that stuff. Or the project we're working on in 2019 was going to be a ground up rewrite of the two different clients ,and we had all of 2019 to do prototyping and proof of concepting, which started to look an awful lot like real development, but can't do that cuz contract says we're not allowed to do development. [11:55]

And we were going to spend all of 2020 officially executing on that development. So very different environment from what you were describing but to kind of go along and, and support the point that you were making, the internal tool that I worked on in 20 and 21 was a live app. It was still an internal tool with a relatively limited user base, but we had actual people using it and as we were trained to do that, angular to next migration. [12:24]

We had to do it in a way that the site never went down and that we didn't, you know, go off and disappear for six months and be utterly unresponsive to user feedback. So we had to do it in a very iterative kind of way where every time we did a release, we were making an improvement and, being able to respond to, you know, bug fixes and that kind of thing. [12:45]

And then the same thing with Replay, where we completely gutted and rebuilt the client side bit by bit over the course of last year. And it was always functional, but it was always getting better as we went. [12:59]

Replay, Mark's current work

Sunil Pai: Actually, I'd love to hear more about your experiences in Replay, by the way. It's just such a fascinating product. Company and all my favorite people are inside it, so I tell, tell us more. I want, I wanna hear more. [13:11]

Mark Erikson: Okay, fine! twisted my arm, okay! [13:15]

All All right, so quick sales pitch. I currently work for Replay, which is a time traveling debugger for JavaScript applications. And the basic sales pitch is that you download our special forks of either Firefox currently or Chrome coming shortly. You open up your website, you press the record button, use your program for a couple minutes, like, you know, press the button that accidentally makes everything crash, and hit save, and it uploads the recording to the cloud. [13:44]

You go to our website and log in, open up the recording, and now you see what appears to be the Firefox dev tools as an app in the browser because it basically did start as the Firefox dev tools as an app in the browser. [13:58]

But instead of debugging and like only being able to, you know, step forward, step forward, step forward — oops, I went too far. You now have the ability to jump to any point in time in the recording, and you can add print statements, which are kind of like console logs, but with superpowers. So if I put a print statement on a line that got run 10 times, I will now see 10 different messages from that line over in the console area because it's evaluating that at every time the line of code ran. [14:35]

And then you can jump to any one of those points. You can hover over the variables and see what their values were at that point in time. You can do the usual browser or the debugger, step in, step out, step over. And it's. It is amazing. I love using it as a programmer because it is possible to debug things that would've just been completely unsolvable otherwise. [14:59]

And I'm having a ton of fun building features for this. I've gotten to build some really cool things, like just within the last couple weeks I built a new experimental feature that checks to see if you're debugging an app that uses React. And if you are it reverse engineers every time you called Reacts set state function and shows that as a list over in the sidebar. [15:24]

And it also works the same way if you did a Redux dispatch too, because it turns out that every React render funnels through the same function. And so I look at the internals of React and sort of backtrack that and figure out what part of your code triggered the update. [15:38]

Sunil Pai: So tell us about the rewrite. If I understand right, the rewrite was for perf reasons, right? It was starting to get a little unusable. [15:46]

Mark Erikson: It was about maintainability. [15:47]

So Replay's client started as a literal copy paste of the source code for the entire Firefox browser dev tools as it existed about three years ago. And that code was React and Redux, but it was primarily written around 2015, 2016. So very early in Redux's life cycle and just when React was starting to get popular. And there were a lot of problems with this. One is that the code itself was extremely verbose. [16:17]

Think about all the old school Redux you've seen that has, you know, switch case statements everywhere and, you know, lots of verbose action creators and spread operators and all that sort of thing. It was using the old school React Connect api. It was using class components, and in fact the Firefox dev tools had some unique build constraints. Like for the longest time they could not use Babel to to compile JSX. And so there were some very old components that were still using this really, really ancient thing called React dom factories, where you called functions named div and span and li, instead of having the JSX angle bracket tags, [16:59]

The Firefox dev tools code, once upon a time, was written using the Flow type checking syntax. They had actually stripped all the Flow types out sometime before we uh, Replay started. So the code was all plain JavaScript. It was about 150,000 lines of code, and it was using a bunch of weird patterns that were also specific to the Firefox dev tools, where there were these mutable class instances that were wrappers around fetching data from the backend protocol that did the analysis of like, here's the contents of an object. [17:34]

So when I joined the code base was open source and you could even go back and look at how it looked, you know, a year ago. I knew it was React and Redux. I could look at it and say, okay, here's all the ways that Modern Redux Code can, you know, make this easier to work with. And so I started doing some of that work shortly after I joined. [17:52]

There was about 20% of the code base that had been written in the previous couple years specific to Replay that was relatively modern. It was TypeScript, mostly used function components and some React Redux hooks. But it was more specific to the new Replay features that had been built. So like all, all the existing debugger functionality basically was still the old school code. [18:15]

So I began trying to modernize the Redex code. I began trying to migrate large chunks of the codebase to TypeScript piece by piece. And later on in the year, Brian Vaughn, who used to be on the React team, joined and he started rewriting things like the the print statement and breakpoint functionality. [18:35]

And he began to introduce new patterns like React suspense for data fetching. Late in like, kinda like around August, September I went in and spent a couple months trying to eradicate that mutable class data wrapper instance pattern. For a while I didn't think I was gonna be able to do it. And then by chipping away at it piece by piece, I finally isolated the last parts down and was able to rip them out in one giant swoop. [19:02]

It was a nine month effort, but by the time we were done, the code base was down to about 90,000 lines, including a lot of the new functionality we'd rewritten after deleting like 40,000 lines of code that was entirely dead. [19:15]

All but a couple thousand lines of the code base are now TypeScript. It's better organized. It's much more readable, and we now actually have a good foundation and we've been able to spend the last couple months moving forward and building shiny new features on top of that. [19:29]

Rewrites on small teams

Carl Vitullo: Nice. Heck yeah. And so you mentioned yourself and Brian Vaughn. How many other engineers were working on the code base while this rewrite was underway? [19:38]

Mark Erikson: Really just me and Brian. There we have, we have another teammate Holger who kind of splits his time between the front end and the back end. But for the most part, it's the two of us. [19:48]

Carl Vitullo: I've always thought having a smaller team makes things like rewrites so much easier. One of the major struggles, anytime I've tried to make a major code change that approaches a rewrite, separate from all of the technical challenges of actually changing the code. If you have other teammates who are still used to the, the old patterns, used to the old ways of doing things, then you have a social problem there as well. That just adds on the challenge. [20:11]

Suspense rewrite at Facebook

Carl Vitullo: Yeah. Sunil, I wanna toss up your way cuz we, your experience sounds like it's, has included some larger teams doing big rewrites. You mentioned in the prep, the suspense rewrite at Facebook. Can you talk about that a little bit? [20:23]

Sunil Pai: Oh, that was that was a) fascinating, b) it was also one of the secret things nobody wanted to do, so what happened is, and at some point somebody's going to correct me about these details. But this is how I remember it. React had finished the fiber rewrite, and that underway working on the suspense. [20:39]

Hooks were already out there, and in fact, they were already being used inside Facebook for all their other projects. But suspense it turned out, required a bit of a rewrite from scratch. They'd tried a bunch to introduce it to existing code, and it worked well for some parts. [20:57]

But they realized… so the reason that time slicing, suspense, et cetera, was built into React. The Facebook use case that drove it is that on facebook.com, especially on the main feed, you have code from a number of teams on the same page. Specifically because there are different kinds of cards and panels. [21:15]

There'll be one, which is a… man, I don't even use Facebook that much, but you know what I mean, like every card is slightly different. And they're usually built by like different teams. These are teams spread across the world, and there are thousands of engineers. So you can end up in a position where, for example, one, not badly coded, but let's say a CPU intense card, can make every other card suffer and it's hard to coordinate. [21:37]

So there's a good computer science concept to solve this of cooperative multitasking, where you try to adjust CPU across different concerns based on priorities and whatnot. So one thing can't just take over completely. [21:51]

A big offshoot of this was the Scheduler project, which was supposed to become a web standard, and the team still talks to the Chrome team, I think, well, I don't know. It's been a couple of years, so I don't know if they're still doing that. But at some point it'll become a first class API that the browser provides you. [22:06]

But that was effectively invented inside React. I think Andrew did a lot of that work, as did Sebastian, but Andrew did a lot of it, from what I remember, And anyway, so, but for that to work, as you can imagine, the entire page has to be written with using the new React and components that take advantage of it with suspense and deferred transitions and what have you. [22:30]

So the whole team just started building that out. It was kind of fun because they also took the opportunity to change the whole design up. If you remember, it used to be the whole blues and grays before it became this bright white, well, they have a dark mode as well. So that was a project that I kind of got to see from the outside, but I didn't really write any of the code myself. [22:47]

I did some research for them on images and stuff, but it was fascinating to see probably one of the world's biggest websites/homepages being rewritten from scratch. And the way they did that is, because they have the world's best analytics, metrics, and dev tooling available, they have the best feature flagging system so they can push out, everybody merges to main. [23:11]

There's no branch-based developer workflow inside Facebook, but they do it with feature flags on and they turn on the feature flags for a small group of people and do measurements and see if it worked fine, and if it did, they turn it on for a larger group of people, et cetera. [23:24]

If there are errors on the page, they have some mad science which is able to target which diff/PR actually caused it, and potentially automatically back it out. And just a lot of feedback because everything was in the same repo. It's the, their big giant mono repo thing with 200,000 components. [23:42]

All these sound like ridiculous numbers to me, by the way. [23:44]

But because it was that way, it meant that anybody could be like, Hey, I think I can make this a little better. I see, I see a common problem. And and that's kind of the nature of how. Facebook's code base also grows, like even though everybody has ownership, you can actually just send a PR that makes something better. [23:59]

One of my favorite things in the two and a half years that I spent there was seeing Sophie Albert's touches everywhere. Like if you just do a blame on any arbitrary piece of code, you'll probably see Sophie somewhere there, just like, "Hey, I made this better and fixed performance by 60% or fixed this bug." it was incredible to see. [24:17]

But the point I'm making is if you want to undertake a rewrite of facebook.com, it's not enough to say, "Hey, we have the will." You also need the tooling and all these guardrails around you so that you can do it right, that you can iterate so quickly. They would've been up the river. [24:34]

Is that the phrase? I don't know what the phrase is. [24:35]

Carl Vitullo (editing): There's two sayings he might be thinking of here. There's "up the river," a saying that originates from Sing-Sing Prison, which was "up the river" from New York City. But he might also be thinking of "up shit creek without a paddle" which is probably the one I'd go with. [24:47]

Sunil Pai: They would've been a shit show if they didn't have tooling like that. That's. [24:51]

Tooling support to make rewrites work

Carl Vitullo: The feature flagging definitely sounds like a prerequisite for any kind of major re-architecture for an app like Facebook that needs to keep working for everyone at all times. The tooling you mentioned of being able to assign a new error back to a specific change, that sounds pretty incredible and it definitely sounds like a huge enabling factor for a team, or, for an organization as large as Facebook with so many engineers all touching the same code that definitely seems like a massive win for iteration speed. If you can safely push changes and know that, if the change doesn't work, it will be caught and repaired quickly. [25:29]

Sunil Pai: At the very least, even if it's not repaired, even if it isolates it down to, let's say, five PRs instead of say, the one, right? Every Facebook employee has one of the work phones or whatever, I think it was called Banana phone, I forget what it called, it's the version of PagerDuty or something. Like you'll get screamed at by your phone where you're like, oh shit, something's going wrong, so you can like hop on and fix it immediately. Instead of waiting for a whole day where you are losing revenue and you, and it's affecting only some group of people somewhere in the world because you didn't do your LTR CSS right, or some shit like that. [26:04]

Carl Vitullo (editing): Quick note: LTR that he's referencing here is left to right, as contrasted with RTL or right to left, which is a text rendering, which is used in some languages like Arabic, Hebrew, Uighur, or a bunch of other languages. RTL rendering is notorious for causing subtle bugs because of deeply embedded assumptions developers have about layout direction. So for instance flexbox layout needs to be reversed in RTL rendering. [26:29]

Sunil Pai: The only way you can do this is with automated like analytics and mon monitoring. It's impossible to do it without that. It was during that, in a couple of other projects that I really understood the value of building that. [26:39]

So, for example, even React, right? Like React does a public release like, twice a year max, right? But internally in Facebook, they. Actually, when I joined, they used to do it roughly once a week, but then they fixed… I think Brian actually made the builds a lot faster. I don't remember who did it. But they got it so that they could push it pretty much every day. And sometimes we'd do it two or three times a day, that you'd push it out to facebook.com. And the way to do that is to say, "Hey, we're pushing it out. But we are enabling it literally only for the six people on the React team so that we get to see it, nobody else would see it." [27:11]

And then we'd be like, okay, fine. I'm gonna push it out to some other people. During a meeting with review, we'd be like, "Hey, which feature flags have we forgotten to turn off," or what have you. Which is why every time a React release comes out more often than less, most questions are answered Yes. [27:25]

With the reason that the hooks are not called use mount, use unmount is because we tried it and it didn't work. That's why we went to the model that they have right now, et cetera. So, yeah, you need, you need some kind of feedback loop. [27:36]

If you're a smaller team, and if your users are developers, the good thing about it is they'll just abuse you on Twitter. Like that's a good signal as well. So, that's, that, that's an option as well. As long as you have some kind of feedback loop, you are, you're just gold. You, you can move fairly quickly. [27:51]

Carl Vitullo: A feedback loop that includes the end users of what you're changing? [27:55]

Sunil Pai: Exactly, yes. [27:56]

Carl Vitullo: That definitely seems essential. I guess fundamentally the point of a rewrite is to improve things without degrading the experience for anyone. So definitely can see why tight feedback loops would be super important there. [28:08]

Mark Erikson: Yeah, on a, on a much, much smaller scale than that the. The Angular app that I was working on in, in 20 and 21 I ended up building the world's tiniest feature flag system. It was one file with a single JavaScript object that mapped flag names to booleans. It was all built in at compiled time and, you know, there was no way to like, you know, dynamically change it or roll it out to different subsets of users. [28:34]

But even just having that one little file and the, you know, is flag enabled function made it possible for us to build certain things and, and iterate on those over time. [28:44]

Carl Vitullo: I think feature flagging is one of those very essential responsibilities within a code base that once you grow beyond a certain number of users and a certain number of engineers, it just becomes a hard requirement. [28:56]

Zero cost feedback loops, revisited

Carl Vitullo: Yeah. Sunil, I wanted to go back to what you said about the zero cost. Was it zero cost rewrites? [29:03]

Sunil Pai: Zero cost feedback loops… or some shit. I I made a phrase that sounded very smart. We'll have to check the tape later. [29:09]

Carl Vitullo (editing): I checked the tape and it is in fact, zero cost feedback loops! [29:13]

Carl Vitullo: Could you talk a little bit more about how you go about designing zero cost feedback loops and how to get them set up and working effectively? [29:20]

Sunil Pai: There are like two classes of tools. The let me tell you about the one that I did it from scratch for. So this was when we were building the CLI for CloudFlare workers called Wrangler. I spun up the Rust code base and the first time I did a build, I think it took something like 12 minutes. [29:34]

And I was like, this is insane. I think they had a dev mode or something, but I was too stupid to know how to write and uh, I used Rust anyway. And this is for me, where, I come from a world where not only can I press F5 or Command R and refresh my browser and immediately see changes, in fact, now our build systems actually push changes with hot reload and stuff and React actually made that so cool, right? That for me is how I would like to program. I would like to type some code and immediately see what the change is. [30:01]

So the first form of feedback loop you want to do is local. Like how fast can you write code and see the changes yourself and choosing tools that have a compile cycle are not compatible with this. This was also why I was so happy when I discovered React Native and realized I wouldn't have to write Objective C or Java for any part of my life. [30:21]

The first time I demoed hot reloading in a mobile app to other people inside Myntra, they thought I was cheating. Like they thought I was a liar. It was an incredible feeling. So choosing JavaScript actually like makes that so simple. And not only did I use choose JavaScript, I also decided to go full in on ES build at the time. [30:39]

So ES build is the fastest bundler out there right now, the trade-offs are that you can't do some things with it, right? Like you can't do some fancy code level transforms and extraction. [30:51]

It turns out it didn't matter in this case. Oh, it also doesn't support CSS module bundle splitting or some, something like that. It didn't matter for the CLI. [30:58]

But what it did mean is I could set up a thing where I could write some code and immediately run the CLI again. Like I could have a command that just ran on every change and it was instantaneous. The same kind of experience that I have when I developed front end applications. I got that when I was building a CLI as well. [31:17]

That meant that my local feedback loop was, "Okay, is this working? Is this not working? Does this look good? Does this not look good?" It was instantaneous. That's one thing. The second thing I did is I set it up so that every commit to the repository got published to NPM with a beta tag. [31:34]

This was awesome because… I'm also a big fan of the NPX command, I don't know how many people here know this, but you don't really need to npm install a utility to start using it in your terminal. You can literally say, NPX, say Wrangler, and it'll automatically install it for you. But what that meant is I could Make a PR, land it and on the team chat, I'd be like, "Hey, run this command in your terminal and tell me what you think." [32:00]

npx wrangler@beta-dev some-file-or-the-other. So be being able to share that with people became a zero cost thing without having to do a full npm release and change logs and all that, no. We just immediately just started shipping everything that got committed. That's the second thing. [32:15]

In fact, we actually got this brilliant dude on the team named Greg Bribe. You might see him on Twitter, et cetera. He set it up so that it published to a private reg a, when I say private registry, just just a CloudFlare worker, in fact. It published GitHub artifacts to that so that you could use Wrangler before it was even committed to the main repository, it would do a publish for a PR. [32:37]

So you could try a PR before it even got committed, which was also great for feedback because, well, obviously, right, like even for people who are trying to contribute and stuff, they'd be like, "Hey, you can try out this command to try out this change that I've built out for you." So that feedback loop got better. [32:52]

One of the lessons I learned from not doing so well when I was in Facebook was that I need to communicate more. So I've become an over communicative asshole. Like if you look at me the wrong way, I'll show you a demo of what I'm working on right now. [33:04]

Like, Hey, hey, can, hey, can you, quickly jump on the call right now? Here's a link. Just come on, just come on for like 30 seconds. I wanna show you something. And I did this with my CTO, I did this with my SVP, I did this with the PMs, I did this with the team, just nonstop. You could wake me up and I'd do a demo for you, like, in, in the middle of my sleep or whatever. [33:20]

But what this meant, especially because we were doing this in 2021, 2022, when we are still working from home, is we had this absurd level of transparency into the Wrangler project from anyone in the team. I would keep demoing it everywhere. Everybody knew what was going on. There was no, oh shit, they're spending six months to rewrite wrangle. [33:38]

They're like, no, it's been three days and Sunil hasn't shown us a demo yet. He's either ill or he is dead. Uh, So by making sure we had all of these things going, and that's just it. Anytime we did a release, I made it a point to drop a thing in the main chat channel saying, "Hey, the Wrangler 0.41 is out, and here are the new things in it, and here's a GIF for it." [33:58]

There's a level of presentation that you want to do to get people interested in it as well, so, even before we did a full launch, a lot of people were already using it because we did a beta launch six months into the thing which that was the public beta launch and people just started using it right then. [34:13]

But by the time we did a full launch, it was just so solid. Like it worked super well. So that's what I mean, like you, you have to look at every single interaction of your workflow for building and sharing it with the world and say, "Hey, how do we make this dirt simple," like anybody should be able to use it. So that's what I did. [34:30]

That's, and you can do this even with frontend apps, it's actually easier with frontend application. Like there's a reason why Vercel and Netlify have like preview URLs in your PR, because it's so powerful to say, Hey, we can have a look and decide what to do with this. Even if you're not in the same room or whatever. [34:46]

I would be surprised if every person here couldn't go back to whatever they were working on and say, "Hey, I think I can make this faster, this easier, this, can we just rethink this so that the feedback loop gets shorter?" That, I think, is, is key. That's what I think. [35:01]

Carl Vitullo: Yeah, definitely. You know, you mentioned hot reloading and PR previews, both of those really became much more prevalent through my career. Like, I think I had three or four years of experience when Hot Reloading came out. You know, it became mainstream through React. I think Netlify did a lot of work for growing the mindshare of people realizing you can preview PRs. And both of those were seismic shifts for how productive I could be as an individual developer. [35:27]

Automation as a way to enable communication

Carl Vitullo: And I think what you're saying about all the communication you do in process of doing these rewrites and getting user feedback, it strikes me that by automating all of the deployment and building work and getting those as tight and fast as possible, it really frees you, you up, you as a human to do the more human side of that launch that you know, it lets you do that required communication because like you said, you need feedback and if you're spending, you know, 80% of your time writing the code, you only really have enough bandwidth to do one other thing. [36:04]

So, if that one other thing is building and shipping the code, then I think your stores of energy are gonna be so much lower for the incredibly important communication side of things. [36:13]

Sunil Pai: Mm-hmm. Yeah. And you like, I don't know if it's apparent enough, but I have a massive ego. Like, I like it when like people look at my shit and whether it's good or not. Like I need the external validation. It's not a very healthy way to be, but it makes for good software. [36:28]

Carl Vitullo: Well, you do keep making good shit. So, I think that ego's pretty well deserved. [36:32]

How to evaluate a possible rewrite

Carl Vitullo: I wanna bring this back a little bit to, as an individual developer, if I am on a team and I think that there is opportunity to rewrite something, you know, I, I see some user pain, I see some maintenance burden that I think is substantially slowing down development progress. [36:47]

What do you think would be your first step to initiate a rewrite project? How would you think about framing that problem to others, to convince them that it's something that needs to happen? Or even identifying to yourself like, yes, this problem is important enough to undertake a large rewrite project. [37:05]

Sunil Pai: I think not only are you supposed to identify the problem and that's a big part of it anyway, it's like, "Hey, we have a problem." But you have to give people a glimpse of what's possible. Like you have to be, either you have to do it via prototype or you can even say, Hey, some other people are doing it this way, or what, what? [37:24]

Whatever, because. One of the big things about a rewrite is getting buy-in in the beginning, and that is so hard to do for rewrites right now, and understandably so because 9 out of 10 rewrites don't come from the right place I think. And I'm glad that I've had accountability checks in my life because I've proposed many rewrites that shouldn't have happened and gladly didn't happen as well. [37:44]

Actively looking for buy-in also keeps you honest to yourself where you're like, "Okay, fine. I'm going to go up to the most serious person in my orbit of influence and see if I can convince them whether a rewrite is a good thing." In my situation, it was trying to convince Kenton Varda, the principal engineer of CloudFlare workers, and he thought it was a very bad idea. [38:05]

So I was like, okay, fine. Let me demo an alternate Wrangler experience where we fix some of the other issues and then he was like, okay, fine. You know what, just try it for a while and let's see how it goes. So that for me counts as buy-in where I'm like, okay, fine. He didn't say no, it wasn't a clear yes, but he didn't say no. [38:21]

And then I eventually convinced him like it worked. It was right, and he agreed as well. But getting buy-in does two things, right? One is it of course, it gives you the space to to execute, but also it gives you It means the people who gave you buy-in also are encouraging of you and willing to excuse some mistakes. [38:40]

Because if you go in instead saying, I'm gonna do this rewrite. I don't give a shit what any of you all are saying, I think it's the right thing to do. That means they're waiting for the first moment that you slip up. The moment you slip, make even the single mistake — and you will — they'll be like, well, you tried, sorry. We are done. We are shutting down this project. [38:55]

So I think, I think there's a very human side of this that needs to be like, worked out before you start writing the code. [39:02]

Mark Erikson: Absolutely, yeah. And they're like, there's. There's a lot of considerations that have to go in, you know, like, why are you wanting to do the rewrite in the first place? I think certainly the JavaScript ecosystem has a sort of well-deserved and not good reputation for, there's a new framework coming out every five minutes, and everyone's busy rewriting things all the time. [39:22]

It's true that new tools, new frameworks can offer advantages over the existing ones. But it's also true that just because a new tool exists doesn't mean you should automatically go throw away everything you've built and start chasing towards the new shiny. So you need to spend some time and consider like, what actual problems are we seeing in the code base? [39:43]

Is it, the builds are too slow? Is it that the tool that we're using is end of life and will not be receiving any more updates? Is there a user facing problem that can only be addressed by a major re architecture and, you know, really consider the justifications for why you're wanting to do this, and then use that as part of that ammunition for convincing the rest of the team and management that it's worth doing. [40:09]

Smell tests for justifications

Carl Vitullo: Mark, are there any examples of justifications for rewrites that now don't pass your smell test? Say, a more junior engineer comes to you and says, I think we need to rewrite this because X. What are some examples of X that would give you pause, would make you ask them to think harder about it? [40:25]

Mark Erikson: The biggest one I think I would have concerns with is, changing to a different tool or framework because it's being recommended by, I don't know, influencers on Twitter, YouTube, or like a hacker news post or something. Like, that's, that's what I was pointing to a second ago. [40:43]

There are new tools coming out all the time and just because a new tool exists does not mean you should automatically shift over to it. Something we did a few times when I was at my previous company, was a trade study. So it was a, you know, lightly formalized process where you say like, we're considering like a range of possible tools that we might switch to, or even comparing like our current tool versus a set of different tools. [41:09]

And you actually take the time to lay out a list of criteria that you're interested in, assign weights and scores to each of the different criteria. Try to do a non-biased evaluation of each of the different tools in the different categories, and then actually add up the scores and see like, which of these tools seems to be the best based on the criteria that we care about. [41:31]

And the criteria could be anything from, how well does this tool seem to be supported versus like, how good is the documentation? How many other examples are there out there? You know, like actually taking the time to do your homework and make an informed decision rather than jumping on something just because you saw a demo somewhere. [41:51]

Carl Vitullo: Hey, I saw Mark Erickson and Sunil Pai recommended this tool. I think we should jump on it. [41:55]

Sunil Pai: Yeah, don't listen to my recommendations on anything at this point. I, I, I feel so overwhelmed. Yeah. No. [42:02]

Carl Vitullo: for sure. Well, yeah. Sunil, I'd love to hear your response to that same question. What are some reasons to do a rewrite that you don't really buy anymore? [42:11]

Sunil Pai: The one that I always get suspicious of is, it is faster and better in every way. And this is just actually, it's one derived away from influencer told me so, because what the influencer usually says, "Hey, it's faster and better in every way." And fundamentally speaking, this is not possible unless you change the laws of physics, right? [42:30]

Like, why, what if you're telling me framework B is better and faster than framework A? Why does framework A not do it? What is the reason? If it's legacy, it's legacy if is this? But I need to understand at a very deep level why it doesn't do this. And can we retrofit that functionality onto framework A? Can we buy five years with it? [42:47]

Because if you're saying that, then that means in five years A is doing that. And usually the answer is — and I hate using this phrasing, but it's true — it's because it hasn't been exposed to enough edge cases yet, to enough situations. It's actually not as broadly applicable simply because it hasn't been tried in as many separate scenarios yet the idea of being battle tested. [43:07]

And it's because the moment you start doing that, you end up having… either you make a trade off in the system or you decide to not go towards that use case. Those are the two choices that you have, and that is what makes framework B more like framework A, the more time that passes. [43:21]

This is only slightly related. This is why I'm excited about Astro as a framework, because Astro very clearly has said, "Here are the four cases we are good for marketing, blogs, portfolios, e-commerce. Don't use this to build your fancy next interactive app." And that is a, such a brave decision. But oh, it is such a good decision because it means they can now focus that, and that they're telling you the trade-offs right there. [43:45]

A framework that is honest about their use cases is telling you that trade-offs right there. And I, I trust tools that do that more than we're like, well, this is a new version of React called "Ne-act". Sure. Ne-act and it is better than React in every way. And you're like, really? Have you, are you sure? Are you sure? You're telling me you, you're smarter than Andrew? No, I'm not. I'm not so sure of that. Let's see. We'll, I'll keep an eye on you, but let's revisit this in six months. But yeah, people saying that solution B is better and faster in every way without anything novel changing for what caused the situation to happen. [44:19]

That's always nah, no. Nice. [44:22]

Mark Erikson: That's also the hazard with those proof of concept demos to show that a rewrite is feasible because proof of concept demo only has a fraction of the features and the use cases that the old code covered and of course it's gonna be faster, simpler, easier to look at cuz you aren't dealing with all the complexity that the existing system does. [44:44]

Carl Vitullo: Right. [44:45]

Joel's Spolksy's cultural impact on rewrites

Mark Erikson: There's a classic article from a guy named Joel Spolsky who used to write a, a software blog that was very well known in influential like 15, 20 years ago. And he wrote an article way back in the day where he talked about the net, the Netscape folks rewriting Netscape source code. [45:05]

It was either Netscape or Firefox, one of the two early on and basically saying like, look, you stopped the world for a couple years, and in the process you've thrown away all the knowledge of the world that was embedded in your source code. And you've lost all that information. Like, yeah, that function was ugly, but that's because it solved like six different user facing bugs and now that's all gone. [45:28]

Carl Vitullo: Right. [45:28]

Mark Erikson: like you, you have to be very careful about both throwing away knowledge that was hard earned over time by the evolution of the system as well as the, you know, the lu of the new shiny and, oh look, this demo is fast and simple. And as Sunil said, well, yeah, it's because you haven't dealt with most of the complexity yet. [45:48]

Sunil Pai: So that's Spolsky post itself, by the way, my bone to pick with that post is that people use that to dismiss all rewrites. And because the lesson from the post also is, oh shit, Netscape shouldn't have done a full rewrite, they should have done an incremental thing because that's just it; at the point, the browser wasn't even, particularly, they were not solving a real user problem, I think, with that rewrite. And of course it was the late nineties, people were on acid the whole time. I don't know. Right. [46:14]

Carl Vitullo: Right, leading into the dot-com crash. [46:16]

Sunil had to hop off the call at this point because we hit the hour and he had another meeting, but mark and I kept chatting for another few minutes. [46:23]

Readability as a justification for rewriting

Carl Vitullo: I have one other thought I wanna say, I think for me, the top unjustified rewrite, you know, among my top worst reasons to do a rewrite is it's not readable. I think so many times, especially on smaller teams, and especially from I think less experienced developers, you join a new code base, you start trying to work on it and it's, it just feels hard. [46:47]

And I think that that is often seen as a justification for a rewrite. And this is something that I feel like I have had to overcome in my career. Just like I've worked at a bunch of different companies and I al so frequently, I've come in thought, "oh, this is garbage, we gotta start over!" Now, at this point in my career, I just feel like that is wrong 100% of the time. [47:05]

Give it 18 months to settle down before you decide that the code is the problem. Develop your experience with working with it and feel out the pain points a little bit more. [47:16]

Mark Erikson: Yep. So a, a couple different waves of thought. With rewrites in general. And, and this goes back to the point I was making a minute ago about, you know, having all this existing knowledge of the system encoded in the existing code base. When you start a rewrite or a migration, it is very, very important to actually capture the intent and the purpose of the system. [47:42]

Whether it's like some combination of documentation and automated tests. So, for example, if you're, if you're doing a rewrite and you're looking at an existing feature There's probably a lot of code that is sitting around and some of it might not be necessary anymore. Maybe the systems requirements have changed over time and there's some code that is there handling the use case that isn't actually relevant. [48:09]

And in the rewrite we can safely drop that. But you have to know what requirements you're trying to match with the new system in order to know that it's safe to drop that old code. Or the flip side is you have to know here are the requirements we need to match and we need to make sure that we build equivalent functionality all the way through. [48:29]

So being able to document the existing system and the current needs and requirements so that you can cross compare versus the old code and see what needs to be persisted is, is very, very critical. And then just, just as a general thing, I feel like as an industry, we really don't spend much time teaching people how to maintain code, how to deal with legacy systems, , how to do things that aren't just sitting down and building a new project from scratch. [48:55]

Like it's, it's great that tools will let you get up and started running and have something productive in five minutes with a single command, and that's good. But most of us are gonna spend our, the majority of our time working on systems that have been around for years. Tens of thousands of lines of code that were written by other people over time, two-thirds of those people aren't even at the company anymore, and learning how to work within existing systems is a critical skill and I, I really don't feel like we teach anything about that either in formal, you know, college, you know, CS degrees or even informally. [49:33]

Carl Vitullo: Yeah, that's, that's a really good point. Working with Legacy Code, you know, legacy Code is a bit of a, a [49:39]

Mark Erikson: L Legacy Code is anything that I wrote more than five minutes ago. [49:44]

Carl Vitullo: Right. Right. Yeah. [49:46]

And that's, that is an essential skill. Reading other people's code, figuring out what their intentions were as they were writing it. Yeah. That is a, an incredibly important skill. [49:55]

What you just said about how we emphasize new projects so much. Maybe that does incentivize people not to think about it, it, it biases them in favor of rewrites because we have so much of our brain, so much of the marketing materials, so much of the new launches are targeting that use case of do something new. Yeah. [50:15]

Software lifespan

Mark Erikson: There's also, you know, there's other factors as well. I mean, software does have a limited lifespan. Requirements change, teams change, bits expire. But also that like, a lot of people might only be on a team for a couple years, which means that A), there's loss of a lot of institutional knowledge, but also people don't generally have time to see the effects of the decisions they made. [50:36]

I was lucky enough to spend, either seven or nine years, depending on how you slice it, on one project. And so I, I saw the initial decisions. I was there as we did the initial design work. I saw how some of those decisions panned out well, and others not so much. I made some of the decisions about the evolution of the code base, and they were the right decisions early on. And five years later, things had changed and we had to revisit those. [51:03]

Being able to see the impacts of those decisions and how they either cause problems or worked out well has, has been a really useful experience for me. [51:12]

Carl Vitullo: Absolutely. Well, I think that's an awesome note to end it on. Yeah, Mark, thanks so much for coming out. Sunil's gone already, but it was really great to talk with both of you. [51:21]

Mark Erikson: Yep. Good discussion. And really glad Sunil could pop in and give us a whole bunch of insight. [51:25]

Carl Vitullo: Yeah, definitely. All right. Thanks so much everyone for staying with us and learning about rewrites.

Ankita Kulkarni

Reactiflux — Wed, 08 Mar 2023 16:00:00 GMT

Carl Vitullo: I'm Carl Vitullo, I am here with Ankita Kulkarni she is a engineering manager, senior developer content creator and educator currently developing a course for people who are interested in the management track, and how to decide whether being a manager is something that they want. [00:17]

Being laid off as a bittersweet opportunity

Carl Vitullo: Ankita. How are you? [00:19]

Ankita Kulkarni: I'm great. I guess a bit about me I've been working in the industry, tech industry for more than 10 years now, it feels like a very long time. I initially started as a developer, transitioned into leadership and I'm at the intersection of both where I would love, I call myself a leader at times, I called myself a developer at times and things like that. Last year, an opportunity came up because of the, the layoffs. [00:48]

It was a bittersweet situation where I'm like, I really wanted to, I love teaching. I already have a course, I'm enjoying this. I love teaching people and helping them level up in their engineering careers. So I was like, this is something I'm really excited and passionate for. So I decided to go full-time being an educator. [01:04]

So that is really exciting. And yeah, like you mentioned, working on a program just to help developers to transition into leadership. And help ease that transition a little bit. [01:17]

Carl Vitullo: Yeah. I, I did a similar transition. I, I spent about a year and a half as an engineering manager, and yeah, when we spoke in prep, you mentioned having to hit the ground running. I think it's really great for you to give back what you learned and really try and spread that knowledge. [01:32]

Building databases at IBM and doing freelance web dev on the side

Carl Vitullo: If you could talk a bit about your background, how did you get your first job? [01:36]

Ankita Kulkarni: I decided to go get my internship done as part of graduating from school. It was just a co-op program and I interned at IBM for 16 months. It was kind of cool actually. I learned a lot about you know, just like the release cycles of databases. [01:54]

That's where I started. And then I worked on Java XML, but for IBM, which was kind of cool. So like, contributed a lot to the core java stuff, which is really awesome, and like how the parsers work and things like that. [02:09]

I quickly learned that I wanna be a web developer because I love seeing things and, just designing and developing websites in general. As I decided to run my own company and help local businesses build apps and I was like, I love my job, you know, after my day job. [02:26]

Carl Vitullo: Yeah, that's fun. So while you were working at IBM on databases, which is, wow, what a first job experience. I feel like that's thrown pretty deep in the, in the trenches. [02:37]

Ankita Kulkarni: I would say like I was interested in web development since pretty much high school. I really, and that's why I decided to take computer science and go learn at a school and things like that. But I would say, during my day job, I would do databases and then I wanted to still like learn web development and apply things professionally and like learn and build on really cool apps and, and actually do some good as well. [03:00]

So I started doing contracts on the side, which kind of was a really happy side effect was I paid off my tuition before graduating, which was kind of cool. Yeah. But was also a lot of really long hours after work and things like that. So [03:13]

Carl Vitullo: Yeah. Wow. I've thought about doing some freelance on the side before, while I had a full-time job, but man, even just the context switching involved with keeping multiple code bases in your head at once. I, I, anytime I've started trying to do that, I found it just prohibitively difficult. So, major kudos for making that work. [03:31]

New appreciation for coworkers after freelancing

Ankita Kulkarni: For sure. Yeah. I think the, the number one thing I learned from that experience was that empathy for all the different roles and all the different hats that you have to kind of wear being a freelancer, right? But also managing two different jobs and multitasking is not that great. It'll burn you out. So kinda, I feel like at the time I was like, I'm so excited. I'm passionate about web development. I have to do this. [03:57]

So it was more fun for me and it did not feel like work at all. It was definitely something that I built, which was like empathy. Like empathy for all the roles and different hats and things like that. Cuz when I went full-time with IBM, Suddenly there were so many roles that, and I was like, whoa, I appreciate you so much. [04:15]

You have no idea of being a freelancer cuz you are doing so many things that I did not realize as a developer. And I guess that help build that mindset too, right? Like how is a system built? And how things work end to end. Because I had to do the, a lot of that as a freelancer. [04:31]

Carl Vitullo: For sure, so you mean talking about having the support of other developers taking different chunks of work away from your responsibility? [04:40]

Ankita Kulkarni: Yeah, that, and also like the fact that you had as a freelancer, you also had to do marketing and copywriting and like, supporting and promoting work and things like that too. Project management and all those things. And when you take up a job full-time, there are already pros. People are already working there, so it's like, "oh, I don't have to do all these things." [05:03]

As a developer, my job would be to maintain the systems, write code, collaborate with other developers, and I can always ask other people what to do about project management and things like that, which is kind of cool. [05:16]

Carl Vitullo: Okay, so we've been talking about your first job. Your you said 16 month internship at IBM [05:21]

Ankita Kulkarni: Yep [05:22]

Carl Vitullo: working on databases. Definitely a very different environment from web development. [05:26]

Ankita Kulkarni: Yep. A hundred percent. Yeah. But then that's when you know what you're more passionate about. When you work on things that you, it's really great for as a first job, right? You learn so much about how software works and how at that scale, how, what are the consequences of your changes and like how do you collaborate and like really write good documentation because there was support and things like that. [05:51]

So just like you learn so much there, but also you learn this was great for 16 months, but I would love to get into web development as I graduate or on the side. [06:03]

Carl Vitullo: Absolutely. Yeah, I think database development is such a very distinct niche from anywhere else in software. What you said about, you know, the impact of your changes. If I, as a web developer ship a change that breaks something like, oh no, I have to fix it, run it through CI, three minutes later it's shipped, it's done. But if a database ships a bug, like the release cycle on that is just so long that it's an entirely different world of development. [06:29]

Ankita Kulkarni: A hundred percent. And I think that's when you really have to take a step back and you really learn how to really review your changes and make sure everything is good. You learn the importance of testing and like writing test cases too. And no code will get deployed until everything has been tested like 10 different times by different people as having a separate testing QA team and things like that too. [06:54]

Carl Vitullo: Yeah, for sure. [06:56]

Getting her first management opportunity

Carl Vitullo: When you were a senior engineer getting your first management opportunity what were you doing there and how did the conversation start of, "do you wanna be a manager?" [07:06]

Ankita Kulkarni: Mm-hmm. . Yeah, for sure. So I was a solution architect working at a consulting firm here in Toronto. So I was pretty much leading a lot of different projects and like architecting them and things like that because the position just sort of like opened up when their, the company wasn't doing so well at the time, so there was like, there were layoffs and like people were leaving and things like that. [07:30]

So there was some, there's someone that needed to step in to help developers grow. And I sort of like started taking that position. So it wasn't like the idea, here you are promoted, congratulations, and now you can start doing the, doing a job, right? It was more so like, okay, like I need to really step up and really understand management and leadership and things like that and how. [07:54]

That would work and how that's different from developers. So for that, like I really, you know, hired a coach and I found mentors and really, I really did not take it lightly because I know that it's really important to grow developers and just like maintaining the technical excellence of things too, which really helped. [08:15]

Leadership vs management

Carl Vitullo: Yeah. You mentioning leadership and management, I've heard from a couple of people about sort of the distinction there. Like being a good leader is an entirely different set of skills from being a good manager in many cases. So what sort, what size company was this that you were working at when you first started managing? [08:32]

Ankita Kulkarni: They were about close to 300 people, so not that big, but the projects were really for big clients, so the impact was huge. Right? So, not having a leader is really, I, you know, was really necessary there. [08:46]

But I would say like one thing you touched upon, which was like management and leadership, right? And I think something I wanted to add there was and this is something I'm really passionate about, so you're gonna hear me hear from me a little [08:59]

Carl Vitullo: Pop off, please! [09:00]

Ankita Kulkarni: Yeah. So I really believe in like, oh, you need to stop being a boss, you should start being a leader, right? And I think the word "boss" kind of comes from there, I think a boss like really commands you to do things right? [09:10]

But a leader is honestly like there to help guide that change, help you navigate the change. Instead of telling you what to do, they are asking you questions and coaching you and things like that, which is like really significant and important, right? So, I think that's the distinguish, I would say like the huge distinction between like management and leadership is that as a leader you wanna drive that change so that even if you're gone, that change is still getting applied and being worked on. Whereas if you're just doing management, then you can just, you know, have a project and assign people to it and like they become resources and not like actual people working on it. So there's a lot involved there essentially. [09:51]

Carl Vitullo: Yeah, I think that's a good framing of the difference. I'm trying to think about a good metaphor for this. I'm imagining like, medieval times, like a battlefield, leader versus a manager. Somebody leading the charge from the front of the lines versus somebody like sitting away in the back and like, shouting over a megaphone, " go, go." [10:08]

Ankita Kulkarni: I never thought about it like that, but yes, exactly. And there's also this image too, where just like a leader is just gonna create more leaders, right? Because they're enabling that change versus a boss is always going to have dependencies on them. And you all know how dependencies work, in software. It also applies here. [10:28]

Carl Vitullo: I think that's actually a really apt metaphor. Managing dependencies as a developer is such a huge part of our job and such a struggle. It's hard, and it doesn't get any easier when the dependencies are people. [10:38]

Ankita Kulkarni: Yeah. Yeah, exactly. It's just like, I think software is still easy, right? Like you have to handle dependencies, you can review the code changes and figure out if there are some issues over there , right? [10:50]

But like, for management of people, it's like completely different. People are complex. We are complex human beings. So it's not easy for you to just manage anyone, right? I think you need to really drive that change and they need to really be motivated to do it, to enable that. Yeah. [11:07]

Carl Vitullo: Yeah. I think motivated is a good word to use there. A lot of management wants to treat people as fungible, as interchangeable. They're different cogs in a machine and if one cog wears out, you just replace it with another one. But I think people's expertise and motivation is really different and really something really challenging to manage. [11:28]

Intrinsic motivation and finding a team that supports your goals

Ankita Kulkarni: Yeah, for sure. I guess like if you assess like what their goals are, what they wanna work on, and then figure out what the goals of the org, right? And again, it's like a venn diagram. It has to be, because if those are not, then they're just two circles working on their own. But like, you need to figure out what people are motivated by, what are they interested in, how they want to grow. [11:47]

Because as developers we love trying new things. We love, you know, playing with new technology and things like that. So that opportunity should always be there for us to grow our brand and grow our skills. And that is something that we need to enable, right? [12:01]

That's not something I can tell anyone, hey, you need to be motivated about this thing. Intrinsic motivation is what I was talking about. [12:08]

Carl Vitullo: Intrinsic motivation is one of my favorite phrases. It's so important. [12:12]

Ankita Kulkarni: Yeah, exactly. If I tell you what to do, you're not gonna do it. If I ask you questions and make you think for how you should be doing those things to help you progress in your career and how that benefits to the wider org, right? And our vision for the company, then you're going to position things differently and you're gonna think about it a little bit more. [12:31]

And we can work out like what that, what that Venn diagram is. (Laughter) [12:36]

Carl Vitullo: Yeah. And like you said about Venn diagram, if they don't overlap, if the orgs goals and your personal goals don't overlap, then maybe that's not a good job for you. Maybe that's not the right role. [12:46]

Ankita Kulkarni: Yeah, exactly. And I, and maybe, and yeah, that's a really good point too, I have been in positions, plus also I've seen other developers being in that position too. Like if that doesn't overlap, then I think you should probably find a team, or ask your manager to help you find a team, to figure out where it overlaps, right? Because otherwise it's just gonna you are never gonna find that intrinsic motivation that we just talked about. [13:09]

You are just gonna treat a job as a job, which is totally cool too, right? Like if that's what you want to do and that's what your priorities are. But like, I think in order for you to grow in your career, I think it will be important for you to be passionate about it as well. [13:22]

Carl Vitullo: Yeah, I definitely agree. It's very hard to keep your energy level high if you aren't genuinely interested in the work you're doing. And if your energy isn't high, like you said, absolutely nothing wrong with just treating it like a job. You go in, you know, you go to the code mines, you put some text in a file and you go home and you don't think about it past that. [13:41]

Nothing wrong with that, but I think that for, for those who are very motivated to improve and better themselves and do meaningful work, I think keeping the energy high and keeping something that you are genuinely intrinsically motivated about is really crucial. [13:57]

Ankita Kulkarni: Mm-hmm. A hundred percent. Yeah, I think it's really important to figure that out. [14:01]

Carl Vitullo: Yeah, for sure. [14:03]

Developer to Leader program

Carl Vitullo: So you've been working on courses. Can you talk about your current course and what you've done in the past? [14:11]

Ankita Kulkarni: Yeah, for sure. My current, I would say, like, program, cuz it's like more than a course at this point, but like the current program is called Developer to Leader. And the idea is that doesn't matter where you are in terms of your journey as a leader, if you have no experience or you do have experience. [14:28]

Right. And I think my, my course will help you give you that transformation that you need to become a leader. So I have like different sort of modules planned out to help you build a solid foundation. And again, we talked about like difference between a leader and a boss, but also staying true to engineering and figuring out, okay, what does technical excellence for your team look like, and things like that too. [14:51]

And I would say this program will really help you with that. And it's more than that too. It also helps with giving you that additional accountability. So I really wanted to design a community that really helps you become better as a leader, as a person in general. [15:05]

So in the community I have like lots of different fun activities such as lightweight cohorts , and hotseats, which are like recorded one-on-one conversations to help you become better as a leader. Cuz I genuinely believe, whenever anyone tries to do things on their own… being a developer or leader doesn't matter. As a person, I think it becomes very hard… you are still gonna struggle, right? So why not talk to other people who are on the same path as you, and really help with that. [15:30]

I've been working on that and the wait list is open right now. But I'm just like really asking for feedback from my newsletter and, sharing updates and all the cool things I'm working on. [15:41]

So if you're interested, yeah. [15:44]

Carl Vitullo: Yeah, I put a link in the chat, and there will be a link in the description for the, when we publish this as well. [15:50]

How do you recognize a good leader?

Carl Vitullo: I see a question in the chat that I think is good to get to. How do you recognize a good leader? [15:54]

Do you any intuitions there, anything you think is helpful for people? [15:59]

Ankita Kulkarni: Yeah, for sure. I think early on, and this is a pattern that I've noticed, a lot of developers that want to lead more, they are really passionate about mentoring and helping others grow, right? So I would say if you really want that leadership experience, start looking for opportunities to help others grow. [16:16]

If you have experience, which you could probably do at wherever you are at, try to figure out who else needs your help and try to help mentor them. But in terms of figuring out if they are a good leader or not. I think it just takes time and hard work and consistency and a lot of experience too, wherein you have to like learn from the mistakes you made, instead of asking people to do things, just like ask them questions, get curious about where they're at in their career and really like, drive change for them is what I would say is probably like the gist of it too. [16:50]

I'm gonna use an analogy: like a duck. Like you can see like everything is smooth and nothing is going on, but then underneath the water it's just like, they're swimming, right? Similar thing with leader too, you are going to see that the team members are really happier. They know what they're looking for, they have proper goals set up. So a good leader would naturally have a lot of these things set up already. Good systems in place. Even if a leader is gone, there's not a lot of dependencies. [17:19]

People are also leveling up in their careers and are not stagnant. So they're not at the same level even a year from now or two years from now, depending where you are, which company you are at, right? [17:30]

All these signs would tell you like, Hey, like is this is this someone good leader or not? Because people should be genuinely happy and excited for the work that they're doing as well. [17:42]

Teams as a group of individuals

Carl Vitullo: That reminds me of something that I have always believed pretty strongly about management and software teams, I guess really teams in general. They're all made up of individuals. Any team is a group of people figuring out how to most effectively work together. [17:59]

The same way that you can't build an Olympic team by just picking the best individual players. The most important factor is not individual skill. It's so important that the members trust each other and understand what each other are good at, and I think that that's, I think this is restating something that you've just said. [18:21]

I think good leaders, good managers are able to identify those things. They have that radar to say, " ah, I see you and this person , maybe you'll have friction with each other because of your communication styles." And identify those issues and help build a system where that team is able to collaborate effectively. [18:40]

Ankita Kulkarni: A hundred percent. You need to keep a pulse on things as a leader, right? Trusting your gut and intuition is very important as well. So for example, like you just said, if two people are not getting along and you can see some signs, don't hesitate to approach them and just ask them, right? [18:58]

Like, "Hey, I noticed something there. Is there something you wanna talk about or is there something I can help?" I would also say that's a good leader too, you're not just assuming and changing things around based on projects because you saw something. Getting curious and really understanding. [19:12]

And like you said too, like figuring out who works well together, what projects and goals they have, and like how you can maybe even shuffle things around a little bit. But all this adds up to, which is something I talk about as well a lot, is like, what's a high performing team? [19:29]

Right? Like you said, like high performing team doesn't mean that there are a bunch of high performers in one team, who are crushing tickets and like, they have crazy velocity of like, and the way they're shipping things, right? It's not like that at all. It's kind of like, They work well together. If they fail, they fail together. They figure out how we can iterate now that we have failed. [19:53]

So like, fail fast, iterate quickly, giving feedback to each other, and always making the team better, right? Because as a team, you need to figure out if you're at a, you wanna get to B, if you do go out at it on your own, you're not going together, right? Like, you need to really figure out, let's go together and let's brainstorm. This is not working, let's tweak this, and things like that. So again, like you will also notice that a good leader would help establish those practices, right? [20:23]

Carl Vitullo: Yeah, and what were you saying before about leaders keeping a pulse on things and understanding and reaching out to members to identify problems maybe before they happen, [20:33]

Psychological safety in software teams

Carl Vitullo: are you familiar with the term psychological safety? [20:35]

Ankita Kulkarni: Yep. I've written a blog post on it because I'm so passionate about it. (Laughter) [20:41]

Yeah, I think psychological safety is very important because, as a leader, you set the tone, right, for your team. The way you act in meetings, the way you are, sets the tone for the rest of your team. So it's really important that you walk the walk, right. And talk the talk. [20:58]

Just to make sure that your team knows that it's okay to make mistakes, it's okay to, you know, do certain things and they can always ask you questions, if they need help, if something is going on personally, they can always come to you for help as well. Or they don't have to talk to you about personal stuff, but like, they can give you a heads up and like, if they need time off. All these things add to making a team really psychologically safe and asks the psychological safety of the team because it's important that as a leader, people feel like they can make mistakes. [21:32]

Because think about it, how many bugs we run into, how many unexpected things we run into as a developer. If the manager is not able to understand that, then they're gonna have a hard time in software in general because it's important for us to collaborate together and like, yeah, ship things collaboratively. [21:50]

Carl Vitullo: Yeah, definitely. I think a commonly given piece of advice for managers and leaders is to like, remember the human, and be able to, I don't know, work with people when they are in, maybe in a point of struggle. Maybe somebody's output is dipped. They were a high performer six months ago, and now they've, they're really, they're struggling. [22:10]

They're not getting tickets closed or whatever. And I think a naive management approach might be to come in and say, "Hey, what's going on? What's wrong? Why aren't you doing this? Work faster?" [22:20]

Ankita Kulkarni: Yeah. [22:20]

Carl Vitullo: Maybe what that person needs is not the stick. You know, not getting like a whapped like, "Hey, faster go, go, go." [22:28]

But maybe, you know, their life has changed. Maybe a parent got sick, they need to care for someone. They are going through a relationship struggle. They are, in a position where they don't have as much available brain space. If a third of your spare brain cycles are occupied by some major personal event, then of course you're not as effective at work. [22:51]

And you know, maybe the fix there isn't even anything that a manager has influence over other than just like, "Hey, take a breather, take care of yourself. Come back when you're ready." [23:01]

Having empathy as a leader

Ankita Kulkarni: Exactly. Like I totally resonate with this. Like, I think it's important to be thoughtful in your approach as a manager, right? It happened in the past like many times where people have personal stuff, so I, I did as well. [23:14]

And I think what's important here is… again, like, like you said, "okay, work faster. I don't care what's going on at home. Like this is work. You get paid for this." Like, that attitude is so bad. Like it's toxic, right? We don't want those managers at all, or we don't wanna train people to be those managers at all. Instead, I think you have a project that you wanna deliver, right? So as a manager, you are responsible for it. So if you push that person to work harder, they're going to burn out. They're probably gonna take a few days off and you're not gonna deliver your project. [23:48]

Instead, if you're empathetic and thoughtful and if you're curious about you know, what's going on in their life or things like that, right? I think it's really, you don't, you don't have to get personal, right? But you can just ask them, "Hey, I've noticed that you've been a bit off." Is there something going on or would you like to take some time off? Offer a few solutions too. [24:09]

And this happened like in my past position, like someone was a high performer, was crushing tickets, always had things under control. Suddenly their performance dipped. And I was really curious. I was like, are they okay? Like, is everything okay personally because your personal stuff does impact work because we are humans, right? Like we talked about. And they were like, yes, something is, I don't know how you could tell that something was going on. And I'm like, take the day off. It doesn't matter. We'll keep working on things, what's important is that you take care of yourself and your mental health, right? And next day they took the day off. Next day they came back and they were back to their usual groove. [24:48]

I'm honestly surprised because a day off can be so important, and then you have that support. They told me that after, " thank you for giving me that psychological safety in the team, that I could take the time off because I felt like I couldn't because of the project delivery." [25:04]

We were able to get our project done, and it was okay. Everything was fine toward the end. So it's just like, what's important is to really be mindful and thoughtful in your approach. [25:14]

You're dealing with people, it's not just software, oh, there's a bug, let's fix it. Right? There is a situation here. Let's talk to them, figure out if they're okay. And then based on that, your strategy is always gonna be different. [25:26]

Carl Vitullo: Yeah, definitely. I think what you said about this team member thanking you for giving them the psychological safety to take a day for themselves. I really think that a manager, a leader approaching someone who has had their performance dip or something like that, and just genuinely approaching them curiously about like, Hey, what's going on? How are you doing? [25:48]

Even if they don't wanna talk about it. Like, okay, sure, there are personal and professional boundaries. Like maybe I don't want to talk to my manager about like a sick grandparent or something like that. But just giving space for them to have these personal experiences that are disconnected from work and saying, yes, I acknowledge that this job is not the only thing in your world. [26:09]

I think that can really go a long way to just, you know, okay, maybe one day off is not, doesn't fix all their problems. It doesn't fix their life, but it sends a signal that they are supported, they are, they have a friend and I think sometimes that's all you need. [26:24]

Ankita Kulkarni: Yep. Exactly. And like even if you think about like outside of work, right? If you're going through something personal, you're always gonna talk to a friend or a family member, right? Someone who, you know, would have your back and would support you regardless. And I think that's important here as well, to have your manager's support. [26:41]

And I think in that case, you're always going to grow and you're going to make the team better. And you're probably also maybe going to be more loyal too because you, to the work that you're doing, cuz you are supported, you're happier, right? Because that's what we want sometimes. [26:56]

Carl Vitullo: Right. Yeah. Loyalty is a two-way street. If a company, if a manager demonstrates meaningful commitment to an employee in a time of need, I think the inverse is much more likely to be true. [27:06]

Like if there is an urgent deadline, I think it's much easier for people to say, yes, cool. I understand the situation, I have to put everything else on pause and go, go, go. But if you just expect that, if that's the default assumption that everyone will drop everything at a moment's notice, then that starts feeling not so good. [27:25]

Serving those you lead

Ankita Kulkarni: Exactly. Yeah. And personally for me, because I've had that technical background, right? I don't mind getting my hands dirty anytime in need. And I'm like, how can I help? Do you need me to do anything? Because like at that point, my focus is also probably the project, right? That the team needs more help and asking them that, they're like, yes, can you please help us with this, this, and this? [27:47]

And I'm like, done. That's taken off your plates and I'm gonna take care of that. Right? So again, like that also helps and helps build trust too because they know that Oh yeah. We can always ask her to help us. With, with whatever work we need. Or it doesn't even have to be code. It can be process oriented. It could be code reviews, it could be anything else, or like you're blocked by something small. Anything that you can help again, like how can I help is always like a really good approach in most scenarios. [28:15]

Carl Vitullo: Yeah, definitely. So that's feels like it touches on the idea of like servant leadership, where a leader's role is to serve the people that they are in charge of. [28:25]

Ankita Kulkarni: Yeah, totally. The term servant I think probably has maybe a negative connotation, I don't know. But just like servant leadership in general, like what it talks about that, Hey, I'm here for you. [28:37]

Whatever you need, let me know. I'm going to help you. And again, the attitude is also more so like, let's help each other. Right. Let's collaborate, let's have fun working together. And less about like, when is it gonna be done? Gimme updates, like all the freaking time, right? It's just not, not great. [28:54]

Carl Vitullo: Right. If you're all in this together, you're all trying to ship the same project, which you know you understand is a shared goal because that foundation has been laid over the professional relationship then yeah, absolutely. [29:06]

Spotting burnout as a leader

Carl Vitullo: So as a manager, have there been times where you recognized that someone on your team, somebody in your company, maybe not one of your direct reports, was at risk of burnout? [29:16]

Ankita Kulkarni: Yeah, for sure. Like it happened a few times. It also happened with me personally too, it's good to keep a pulse on things for yourself too, because your mental health is also important and as, as equally as your teams, right? So make sure you do that. [29:29]

I have noticed when someone is considered a high performer and they feel like they need to do everything and they really crush tickets, like they're really working all the time and I think. In that case, I definitely approach it. [29:45]

I know you're passionate about it, but I definitely believe in sustainable pace, so I really don't want them to burn out. But even letting them know that is really important because they think for some reason they have to do this thing, because they're the most senior most member, or they have the most experience in that specific team or whatever might be the reason. [30:06]

But I think like, it's important that just letting them know that they can take time off they can maintain that work-life balance, whatever that is for them. Maintain that sustainable pace. I also don't hesitate to tell people, especially senior members of the team, that their actions also have an impact on more junior folks who are looking up to them as well. [30:27]

Setting the tone on a team

Ankita Kulkarni: Because they're setting the tone too, and that changes the culture significantly. So if they think that the senior most member is working 80 hours a week, then they think in order to get promoted, they also need to work 80 hours a week. [30:40]

That's the job of a manager, to make sure that they know that they're setting the tone for the rest of the team and something that they should not do as much. It's fine. Obviously, we all get our, like, oh my God, I'm so excited for this feature, and things like that. [30:54]

But it's also good to openly talk about it. I know the question was burnout, but I think it's also like important that all this adds up, that they know the expectations are not for them to work 80 hours a week. [31:06]

Carl Vitullo: Yeah, definitely. I think that that is maybe not directly burnout, but I think that, it's a major contributor to it, you know? It, it does set the tone. Like you said, if people see that the influential high-performing people are overworking themselves, then yeah, then that's, that appears to be behavior that's rewarded. [31:24]

That's something that I've definitely tried to be cognizant of in my career. I've been a manager, I've been a tech lead, I've been just like a very senior engineer on a team. And I personally, I have ADHD, I am neuro divergent, whatever I. I enjoy unstructured time. [31:42]

I don't do nine to five very well. I like following whatever thread my brain is on and, you know, do that, chase it down, go somewhere else. And so, especially through the covid time, through its pandemic and work from home, I personally found that it was really beneficial for me to just work a loose schedule. [31:58]

Like if I wanna take three hours and do a home errand in the afternoon, I'll make that up on the back end. I'll work, I'll pick up, work up at six and work until nine or something like that. [32:08]

But the flip side of that is, that works great for me. Nobody on my team, nobody in Slack knows that I took a three hour break in the afternoon. [32:15]

Ankita Kulkarni: Yep. [32:17]

Carl Vitullo: So if I'm pushing commits at 10, 11 at night, that looks like I am, you know, working 80 hours a week when that's not the case. That can be a challenging balance. [32:27]

Proactively setting team norms

Ankita Kulkarni: Hundred percent in, in fact, it did happen a couple times in the past with my teams. And what we did was we created a team norms document. Team norms are kind of like, again, like just something that the team does that we are just documenting it and letting everyone know. And it's like a healthy discussion. [32:44]

So for example, Carl, you know, he loves unstructured time, so expect that just because Carl is working after 11 doesn't mean that Carl is crunching, I don't know, whatever hours, right? It doesn't mean that's how Carl works. And letting people know that certainly gives them context. [33:00]

Right? And I, and team norms, I, there's an exercise for that, which I love to do whenever I join a new team, or more so like when I, when the team is new, cuz I think it really just like triggers so many discussions, right? Like, oh yeah, I'm not like that at all. I love my morning time. Oh I love my evening time. [33:18]

And I'm like, yes, that's totally cool. Like as long as like you are doing it, it's just amazing. Like, doesn't matter when you do it, but again, it depends company to company as well. But so you could totally be in a culture where it's only purely nine to five. And I think you have to kinda assess that too for yourself, right? [33:36]

Like what's the culture like? And like, then accordingly adjust. [33:39]

Carl Vitullo: Yeah, most definitely. Yeah, those sorts of meta conversations, talking about how we work rather than just talking about the work itself, I think those are so crucially important, especially for a leader, to be facilitating. And I think that that's one of the very difficult parts of maintaining a high performance team over a long period of time. [34:03]

You know, cuz like you said, you, you join a new team, you sort of have some of these conversations. They're good icebreakers, they're good, like get to know your questions for people on a team. [34:11]

Ankita Kulkarni: Mm-hmm. [34:12]

Carl Vitullo: But then, you know, six months later, people change, people's preferences, interests, expertise, evolves. And if there isn't an external event, like a new manager, you know, a major team reorganization, then I think it's hard for those conversations to surface naturally. [34:30]

I wanted to give voice to that sort of idea of talking about your own preferences, comparing notes with other people and just sort of getting to know them better and how they think about their work, I think is one of the hallmarks of a high performing team over the long run. [34:49]

Prioritizing your own growth as a leader

Ankita Kulkarni: Hundred percent. And I think that one thing I wanna touch upon that you just mentioned, like as developers, right? We are very good. Like we wanna get good at React. We are going to become the best React developers, and we have this timeframe in our head, or I decided, right? I wanna be, become the best that I can be. [35:06]

As manager, you don't focus on react, you focus on all these things, right? Like, yeah, it's definitely good to play around with all these technologies, right? But like, as a leader, what you should be doing is, for example, if there's a React code base, after six months, we're still gonna work on it, we're still gonna improve it. [35:24]

We're always gonna keep brainstorming different ways via code reviews and all these different things. But as a manager, make sure that you're doing the same, you are investing time in becoming better. Talk to other leaders in the company. How are they doing things? [35:38]

What is something that has worked really well? Book coffee chats. Your learning and growth doesn't stop the minute you become a leader or a manager. It still needs to keep going, it's just that what you do changes, right? So instead of, you know, building React projects, you are basically looking at what processes can I create? What can I automate? How, what are others doing that's working really well? I have this specific challenge, before trying to solve it on my own, figure out who else has done it in that same company more likely, so that you have that context here, right? And I think that also helps a lot because your learning shouldn't stop right then and there. [36:16]

So otherwise things are going to get stale. I've seen that newer leaders can fall into this trap wherein they feel like their growth is dictated by the code they push, and it's the opposite. It's like, it's like, wow, new leaders should look at the code that your team pushes and you build all the systems and the infrastructure for your team to function like a well oiled machine, right? So that's what's important. [36:42]

The value of informal chats

Carl Vitullo: I think you bringing up coffee chats, I think just going for informal, you know, informal… I want to use the term meetings, they are meetings, but they're not, they're like this semi-formal, they're in this liminal space of not-quite-work. [36:58]

I think that that is where some of the most powerful communication happens in a company, is where it's not formally structured. It's not in an office, in a obviously professional capacity, but just like going for a walk around the block with someone, walking to the nearest coffee shop in a, like a very limited, like one-on-one or, a small group setting. [37:19]

I think that's where so much of the most potent like team building and sharing of context and sharing of background and figuring out how to do work well. I think that's where a lot of that happens and I think that that's a under acknowledged dimension of work that especially among the individual contributors. [37:40]

Ankita Kulkarni: Hundred percent. I think that even as an IC, an individual contributor, if you wanna learn something from someone, like figure out how they're doing it, like just pick their brain on things, book a coffee chat with them, ask them, get to know them a little bit. Right? And you are going to learn so much more as an IC because of that, right? [37:59]

And you're going to build better relations and communication is also going to get better because of that too. So, yeah, like, I think it's really underrated, but something that we should all do more of. [38:09]

I feel like even this conversation wouldn't have happened, you know, like I just like, oh, I need to message Carl cuz I really loved previous Office Hour events in the community. And I was like, this is so cool. I'd love to be a part of it. And conversations will flow naturally and you get to know people, which is really cool because what's the point of just working, for me at least, it's like let's make it more fun, right? And I think as you get to know people, you will make it more fun. [38:35]

Carl Vitullo: Definitely. Yeah. And there's, there have been a number of times in my career where, you know, I've spent weeks trying to figure out why this is broken, or why aren't we prioritizing this? I think this part is so obviously bad. Why, how could it have possibly gotten into this state? [38:50]

And then I go for like a 15 minute walk and talk with somebody who's been there six months or a year longer than I have. And just in that space where you can talk maybe a little more honestly because you're in a different, you're in a change of space, you don't have to worry about like, is somebody go gonna overhear or you know, you can just speak very honestly about it. [39:10]

And I think sometimes that that's where you learn context about the work you're doing. Like why is this work happening? Why isn't this other work that I think is important happening? And I think that sort of contextual information, even if you're just an individual contributor, even if you don't have, you know, responsibility over prioritizing or anything, [39:34]

I have always found that that is gaining more understanding there has really helped me, even if I don't agree with the priorities, understanding the logic of why they are that has always been very helpful for me. [39:48]

Soft skills in your career

Ankita Kulkarni: Yeah, a hundred percent. I completely agree with you there, and I feel like. A lot of, like, a lot of us, even like when I did, I did as well, like when I was growing too as a developer, that you think that you are a good developer or you want to be a great developer just by the code you write. [40:05]

In a company's context, it's not just the code you write. It's also like all these other soft skills and like, how you collaborate well together, how do you give feedback, how do you receive feedback? Like all these things. And like even in code reviews, how do you review code and like ask questions and again, like drive that change, right? [40:26]

Versus like, make statements and be rude about it. Like all these things also add up to how great of a developer you are and not just the code you write, because that's just part of it, right? So I think it's really important for a lot of developers to think about that too. That, and something that often doesn't get talked about. That it's not just code, it's also people. So remember that. [40:50]

How to get a taste of the management track

Carl Vitullo: Definitely. Yeah, that feels like a pretty decent segue into… I think we've touched on this a little bit, but I think that could be a good jumping off point into a conversation about how do you decide if you want to move into management. So, you are a senior engineer, you're pretty accomplished in your career, and you're looking at the staff role and the engineering manager role. [41:13]

What do you think are some good questions that a person can ask themselves to help them decide what track they wanna follow? [41:21]

Ankita Kulkarni: Yeah, for sure. I think that very early on, I think you should start mentoring folks, start doing that just to understand like, mentoring should be, should happen regardless as you grow a senior, right? But like, you can assess if you know, do you get more happiness and fulfillment through via the growth of others? Or do you get fulfillment and happiness by just your growth, like directly the code that you write, the work that you do? [41:48]

And that distinction is really important. Cuz if you enjoy building systems and like driving change through others and like seeing other people grow, then I think maybe you should look into stepping into maybe like a leadership, like leading a project. [42:05]

Role or something like that, like a team lead or a tech lead. But not even that, but just like a project lead, right? Like for a short period of time, see how it, how you can do it and like assess if like that's something you like doing. And if you did, then you can figure out, okay, maybe like what about if a bigger project, right? [42:23]

And the more you do that, like slowly and steadily, you're going to understand if leadership is for you or not. And at that point you, you'll decide that, nope, I still love writing code, I still want like 50% of my time spent on code or like 80% of, or 60% of my time, whatever can, it can be different from different companies, but like majority of my time spent on code and an architecture versus people and maybe 20% on code. [42:52]

If you feel like what brings you joy, and if you're not sure, then again try out these positions. But if you are sure, then maybe try out start walking down the leadership path. And if not, then walking down maybe the IC path further and seeing how you can grow there. [43:08]

I would say don't just wait to get to senior or staff or whatever to figure out if you should go to management. Start, you know, getting curious, right? Very early on, like, this is something I wanna do. Maybe I should lead a small thing like project, then I should lead a team. [43:23]

Or if then opportunity comes up, maybe you can shadow your manager for a little bit too, just to figure out if this is something you really wanna do, right? And if not completely okay. In fact, if you go to become a manager and a year later you decide you don't wanna do it completely, okay? There's no shame in that. [43:41]

And I think that's really important to acknowledge that too, because. You know, it's, I feel like maybe you miscode then go back to code, do that for a year. You again, miss people and do wanna do more planning and roadmap and all that fun stuff. Then do leadership again. Like it's totally okay to go back and forth. [43:58]

And the beauty of it is that we can do that right. Versus like, it's not a huge career change. It's definitely a different skill set that you need to develop. [44:09]

Carl Vitullo: Yeah, definitely. I think that makes a lot of sense. In my career, I've found that I've oscillated back and forth between, I feel like I've always been a leader on a team, maybe not a manager. I'm not always setting priorities or have formal authority over decisions or anything like that. But I think what you said about starting from mentorship, And seeing if that sort of people aspect is something you get joy from. I think that's really powerful and accurate. [44:39]

You know, so much of management really comes down to something similar to mentorship. As a manager maybe you won't always be the most technical. If somebody's blocked by a technical bug, maybe they can't always come to you to become unblocked. I think mentorship can be a good way of practicing those soft skills, like you mentioned of understanding someone, where are they coming from, what are their experiences, you know, where do they want to grow, where do they need to grow? [45:05]

Ankita Kulkarni: Mm-hmm. a hundred percent. Yeah. And I guess like take baby steps to figure out if this is what you wanna do, right? Like you said too. And I think it's, it starts with mentoring for sure. Cuz I think you start interacting in, you're not responsible for their progress, but you are invested in it. [45:23]

And that gives you that taste initially of leadership, which is kind of cool. [45:28]

Carl Vitullo: Yeah, definitely. Yeah, you're not responsible, but you're invested. I like that. [45:32]

Ankita Kulkarni: Mm-hmm. ,oh my God, we have so many quotes from this conversation. We should create a Shopify store with different t-shirts. [45:43]

Carl Vitullo: We gotta get the merch going. It's where the real money's at, [45:47]

Ankita Kulkarni: yeah, yeah, for sure. I think this is the educator, entrepreneur, business person, brain in me. [45:53]

Carl Vitullo: Yeah. You got the indie hustler mindset. Always thinking about what's, what's next. [45:57]

Ankita Kulkarni: yeah, yeah. Exactly. [46:00]

Carl Vitullo: We're coming up on an hour here. Yeah. Any, anything you want to close out with? So I know you've run a, a newsletter, you have done a number of courses, you're working on this program. [46:10]

Ankita Kulkarni: Yeah, I would say like the best way, if you have any questions, I'm in the community, but also on Twitter at kulkarniankita9 as well. But I also run a front end and leadership newsletter as well, so if you're interested in leveling up in your career, whether it be engineering, leadership, or software engineering, just like go to my website kulkarniankita.com and sign up for either of those. And yeah, if you have any questions, please never hesitate to reach out. And if you are interested in becoming a leader, then sign up for the wait list. [46:45]

Carl Vitullo: Excellent. Yeah. I'll drop some of these links in the chat here and they'll be in the description when they get this gets published. [46:52]

Ankita Kulkarni: Yeah, for sure. [46:54]

Carl Vitullo: Well, Ankita, thanks so much for coming out. This was, this was really great. [46:57]

Ankita Kulkarni: Yeah, for sure. No, thank you so much for having me. I also gonna add that if you if you want like a mind map, like just like a roadmap to becoming a leader, right? There's a link to that that I've sent you Carl as well. If you can share that too, that would be awesome. [47:09]

Cuz again, like people who understand what are the responsibilities of a leader and looking at that, you'll be like, oh my goodness, this is too much, or yeah, this is kind of cool. This is interesting. Then yeah, check that out too, cuz we have a lot of front end roadmaps and this mind map would be helpful if folks are interested. Yeah. [47:27]

But yeah, thank you so much for having me. This is so much fun. [47:30]

Carl Vitullo: Yeah, it was very fun to talk shop about management, leadership. [47:33]

Thanks so much everyone for sticking with us through this hour and keep an eye on our upcoming events. Next week we're gonna be talking with Sunil Pai about Refactors and the difficulties there. [47:45]

It should be a good conversation. Cool. All right. Thanks so much. Talk to you later. [47:49]

Ankita Kulkarni: Bye!

Behind the React Documentary

Reactiflux — Wed, 15 Feb 2023 16:00:00 GMT

Introductions

Carl Vitullo: I'm here with Ida Bechtle, a documentary filmmaker from the European job board site Honeypot, and vjeux, or Christopher Chedeau, who has deep roots with the React ecosystem and just absolutely incredible contributions to the JavaScript ecosystem at large. [00:18]

We're really excited to have both of them on to talk about the recent React documentary that just launched on February 10th. Yeah, I've been thinking about this as a behind the scenes, DVD commentary type of conversation. But yeah, let's just see where the conversation takes us. [00:33]

So Ida, could you talk a little bit about your role and your responsibilities with producing these documentaries? [00:40]

Ida Bechtle: Yes. First of all, hi to everybody in the audience, I'm Ida. I've been working at Honeypot for the last three years as a filmmaker, so I'm just making these developer portraits and tech documentaries full-time, which is pretty cool. And I've been working on the React documentary for the last year or so. [00:59]

So I'm super excited for it to finally be out. It's been a lot of work, so I'm really happy about the response so far. [01:06]

Ida on being a 1-person production team

Carl Vitullo: You said when we were talking in preparation for this event that you are a one person show. You do all of it, you do the cinematography, the directing, and the editing. Is that right? [01:17]

Ida Bechtle: Yeah, exactly. This is all me from start to finish. Except for the title animation basically. So that's why it was so much work. But it's also cool, you know, to see the result in the end when it came from my hands. [01:30]

Carl Vitullo: Right. It's really very much a product of you. You really own it from start to finish. That's very cool. I feel like that would require a very entrepreneurial mindset , you can't just do one part of this work over and over again. You have to really think about the entire project from ideation to conclusion. I'd love to get into that with you later on. [01:50]

Christopher Chedeau as a driving force

Carl Vitullo: Vjeux, Ida had told me that you were one of the, really the driving force behind getting this event to come together. What was that like to getting corporate comms to approve an event talking about things that happened 10 years ago? [02:03]

Christopher Chedeau: Yeah, of course. So the first thing so, in the React community I've been always trying to build the community. And so I was wondering like, early React, doing like the community roundup and also organize like the first React Conf for. And so if you watch the documentary, you can see like how it happened and how it went. [02:20]

And so, early last year in I think January a lot like Ida reached out to a lot of people from the early days of React saying, Hey, I'm working on this doc. I want to build this documentary. Are you interested in participating? But the issue is like nobody replies. [02:36]

And when she finally was able to reach out to me, I was like, oh my God, this is so amazing. We're going to be having a documentary about it. And so I started basically taking ownership of the project from the React team's perspective. And I started convincing every single person that you can see in the cast, hey, you should be participating, this is going to be good. [02:53]

And as you mentioned, we also needed to convince like Facebook/Meta to participate. And this was like a bit of an awkward dance because this is not coming from like the company. It's coming from Honeypot which is like a European job search company. And so I had to convince people that it was worth like taking the chance on this. Great thing is they've already done a documentary on GraphQL, which is from Meta, and also one on Vue. [03:22]

So what I did was this, some background research, ask Evan You from Vue and ask Daniel Schafer and Byron from like the GraphQL one. And I asked them, Hey, how did the experience go? How did it feel? And I watch the two and. Everybody told me like, yeah, the experience was fantastic. And the end result was like, really positive, uplifting, and really like told the story they wanted to tell. [03:43]

And so based on this, I talked to the head of open source Dave Viner, and that put me in touch with all of the right, people from like Comms and Legal to make sure that hey, we like it makes sense and we can do it. And so it took I think like a month or two to convince people, like, Hey, let's do it. And then it was about like actually doing the recording. And so Ida like, took on this parts. [04:07]

Carl Vitullo: I guess it makes sense that Lee Byron had done one of these before, since there was one on GraphQL, but I hadn't put that together when I was watching. Okay. Very nice. [04:15]

Why Honeypot makes these documentaries

Carl Vitullo: Ida, could you talk about why Honeypot makes these documentaries and why the timing felt right to try and make one about React? [04:24]

Ida Bechtle: Sure. So Honeypot is like just a small company here in Germany and we built a lot of our product on using open source software. We try to be more visible in the community and give back a bit. I think that's why it started. One of our co-founders was also a journalist, so I think she had a different approach to both to marketing, but also to storytelling and connecting the audience what you can say. [04:48]

So I think that's how it started. I think our first documentary was about Elixir and I think it was kind of an experiment really. And we just put it on YouTube four years ago or something, and I think it got like a thousand views or something. The team back then was super excited. [05:03]

And then it just grew from there. Since the early days people have been asking about React. So, if you look at like any other documentary on our channel, you will always find a viewer being like, "ah, let's do, can you do React?" So now was just finally the moment to do it. Also, after Covid, it was a bit tough to produce documentaries then. So after that we were ah let's get one of the big ones out now. So that's how it started on my side. [05:31]

Carl Vitullo: That's really nice. Coming from a job board and remembering that the companies, the projects, the people who you're placing at jobs have these stories that their careers are anchored around, and then really trying to tell those stories. I think that's a really excellent way to give back to the community. I'm really happy that somebody is making these. [05:49]

Getting trapped in a park while filming

Carl Vitullo: Are there any stories about the production of this that you think might be fun to share? Any bloopers? I know there was one scene in the documentary where Andrew Clark gets a little self complimentary. Like, "oh, we really nailed that, didn't we?" Any other bits like that as production happened, that would be fun to share? [06:07]

Ida Bechtle: Most of these shoots, I just go in and out pretty fast, spend a few hours with the people I'm interviewing. I think actually Christopher was one of the ones I like hung out with the most because we were filming in London I think we were basically had three days or something so we could like also get to know each other a bit better. But otherwise it's, sometimes it's a bit like professional almost, you know, I just go in, I set up all the gear and try to get to know the people a bit more in person. [06:34]

Christopher Chedeau: There was one thing that, so we were in London and we wanted to get like a shot at the sunset, and so went into a park, And they actually closed the gates of the park behind us. And so we had to basically walk around or like walk on top of the like fence and everything. And it was super cool, like there was people like drunk, passing by and cheering. Yeah. Go. So yeah, didn't make it into the movie, but this was pretty fun. [07:00]

Ida Bechtle: Yeah, true. I forgot about that part. Getting locked in the park. [07:03]

Carl Vitullo: That's pretty good. [07:04]

Jordan Walke's participation

Carl Vitullo: I noticed that you got so many of the major players in the early days of React involved in this as interview subjects. Obviously a major player who was not represented was Jordan Walke. Could you talk about why he didn't want to be involved in this, or, did he not want to be involved? Could you just not get scheduling right? [07:24]

Christopher Chedeau: Yeah. So in practice Jordan is a very like, private person. And he has always been, and so this is not really the thing, like he enjoys. And so I worked with him super closely and the way he like, works best is in one-on-one with people. And so even internally, at the time, like he's never done like any all hands or any major events. He's always been convincing people like one by one. And you can see in the documentary like how he was able to convince Lee Byron, how he was able to convince me. [07:53]

And so this is like in his personality to like actually be behind the scenes. And the one thing I want to mention is he's been involved like since day one. He was like receptive. Like he was actually like happy that the documentary existed and like he's been watching it with us. Like he was commenting during the live q and a on the comments. So, and this is like something like we have to respect like his wishes. [08:18]

And in the documentary you can also see like his experience, like actually being on stage was not a good one. So I can also understand like that's he's not like particularly looking forward to be like more exposed than he is. [08:32]

Carl Vitullo: Yeah, that makes sense. He's already a private person. He had a pretty bad experience with being in the limelight and just is very happy to help make things happen, but not be the center of attention. That makes sense. [08:44]

About the focus on the early days of React

Carl Vitullo: I noticed that the documentary really focused a lot on the earlier days of the React ecosystem, how it came to be and how it grew. Was that a editorial decision? [08:56]

Ida Bechtle: I think for me, when I first started looking into React, I think that was like the story that really stood out for me and I think especially before the open source release, that part of the story I think has not really been told, about how it was created at Facebook. And I just found I really wanted to credit the team also, like it's such a big technology now. [09:15]

And back then they had this massive backlash. So I think it's cool to just share that story and how they came out victorious. And I think also maybe the storyline is a bit easier from like a maybe a bit more simple storyline or like, The events are pretty clear in what happened where maybe, I don't know, it might be a bit tougher for more recent events, but I don't know, maybe Christopher has a different opinion. [09:41]

Christopher Chedeau: Yeah, and I think the documentary is already an hour and 20 minutes. I'm pretty sure we could do another like full hour or two on the like more recent events. So I don't know if either you have anything planned for the next year, but. [09:53]

Ida Bechtle: Yeah, true. Next one. [09:56]

Carl Vitullo: Yeah, sure. And I guess, it feels like the last maybe two or three years of React has been marked by a lot of really grand plans that have not yet fully shaken out. So, I could also see how, you know, it's still it's maybe less of a documentary for the time since the release of Hooks, as you know, it's still under active exploration, active investigation. So, it's less of a documentary and more of a, I don't know, industry event. [10:24]

Deciding where to focus your attention

Carl Vitullo: So Christopher, you've been involved in so many hugely impactful projects in the JavaScript ecosystem. Can you talk a little bit about how these ideas cross your radar and how you decide which ones you're going to dedicate your attention to? [10:44]

Christopher Chedeau: So, to give some context, so I helped like popularize React and I also co-created with Jordan, Ashwin, and Lynn, React Native. And I also worked like with James Long on Prettier. And so I dunno if you think, like right now I'm working on Excalidraw, and so for me, like the way I think about like this big project is it always starts with like, there's a problem. [11:08]

And so, for example, I can talk about Prettier I've always felt like code reviews were like super annoying. So when I joined Facebook I was like, outta new grad, like super, super excited. Okay, I'm going to do big things. And then uh, my first uh, deep review was like 20 comments around "Hey, you should put a space here, and the parenthesis there, and like, put a new line here." And to me, it felt bad because I felt like it was nitpicky and not as useful. And I was talking to this amazing engineer and she spent our time doing this, just like nit picking on my thing. [11:41]

And then I realized that later, I think a year or two after I was in the reverse position. Where like, oh, there was new people in the team. And I was like, okay, I need to be doing this work. I'm telling them, because otherwise, like the code-based quality is not going to be as good and we won't be able to move as fast. [11:58]

And so, I've been really shaped by go and go fmt. And this was a way to automatically reformat the codebase. and the very interesting thing about this is I saw this could actually solve all of the issues I've had like in the code review process. [12:15]

But now the challenge is, go fmt, like a lot of people were crediting it due to the fact that like they created the language with it. And so it was possible to have adoption with this. And in the JavaScript ecosystem, there's been a lot of attempt at building like an automatic format, but they all failed. So now that I have the problem that I want to solve, that was a solution. And so now my process is around, okay, so if I I need to convince myself that this solution can actually work. And so the first step is to look at all of the existing, if nobody tried it, like, I mean, like it's not a real problem. [12:52]

And so I started contacting all of the people that built JavaScript formatters in the past, and I've asked them, "Hey, why did it fail? Why did you stop working on it and everything?" And they give me a lot of reasons. One of the cool thing is like, the programming scene is actually like, people are interested and excited about talking about this kind of things. [13:10]

So you can actually like private message somebody and they're going to likely answer you if you are excited about the idea. And the thing that I realized is this is a problem where, like, this is not the usual, like 80%/20%. What I mean by this is, most projects, you can have an 80% version working and then this is going to really like work and you can grow from there, and like the last 20% you can spend a lot of time on. Now for pretty printing a language; it needs to actually be rock solid because if you pretty print something and like the code doesn't work or like, has a different meaning at the end, people are just going to stop using it. [13:50]

So the same time of correctness. And then if the code looks bad or looks weird, people are also not going to use it. And so for this it was a project where like, you need to actually get it like 99.9% good before it can actually like, take off and be successful. And so now this is basically like shaped for this one, how I went about it. [14:10]

Going in a submarine and ignoring your manager

Christopher Chedeau: And it was like, I'm going to be in a submarine for like six months and I'm just going to code code, code, code, code, get it like 99.9% correct. And then I'm going to start like, getting the adoption going and everything. And so this was like, okay, me, myself, convincing that I can work and like I have a plan that I feel is going to work. [14:27]

I was working in a team and I basically told my manager, Hey, look, I'm going to do this for the next six months. So it didn't work out super well in the beginning because , I was supposed to do other things, but I went ahead and did it. And then the plan actually worked, okay, it's successful and everything. And later I got credited as part of the work within the company. [14:47]

So there's three steps around, like finding the problem, convincing yourself it'll work, and then actually going and like all in onto this. So this has been my process around getting into this kind of like crazy ambitious projects. [15:01]

Carl Vitullo: That makes a lot of sense. As you were talking about getting something to 99.9%, I immediately jumped to the difficult challenge of trying to make everyone happy enough with what the output looks like. [15:15]

Making Prettier pretty through data

Carl Vitullo: I didn't even think about correctness issues. I, I immediately went to, everyone has their own personal bike shed about whether or not to use semicolons at the end of the line or things like that. And that's something that I've always thought was one of the very subtle brilliances of Prettier, is how it managed to have an extremely minimal configuration that let you know 99% of developers use it and go, "oh yeah, okay. I'm happy with how that looks." [15:45]

I think getting developers to agree that some that code is pretty, is an incredible challenge. It's entirely separate from the technical challenge of actually making that happen. [15:55]

Christopher Chedeau: For this was very data driven. So what I did was, I had access to the Facebook code base. And so what I would do is every time there's needed to like, have a decision on how to print it, what I would do is actually look in the Facebook database and get statistics around like, how many people are using this formatting or this other formatting. [16:14]

And then I would basically pick the one that is most used. And so at the time, at Facebook, there was convention and everything, but this is still an organic system. And so because we had , I don't probably like millions of lines of code, this was big enough to be representative of like, what reasonable code looks like. [16:30]

And so I basically just followed the wisdom of the crowds and ended up being like, good looking or like acceptable by people. [16:41]

Carl Vitullo: Right, right. Yeah, that makes a lot of sense. So you have a lot of data to draw on by virtue of the enormous code bases you work with, and I imagine it wasn't terribly difficult to get other developers to solicit feedback on code. Commenting on code style is a favorite developer pastime. [16:58]

Ida's documentary process

Carl Vitullo: Ida, I'd love to jump back to you. So I mentioned at the start of this that I feel like there is a lot of entrepreneurial spirit involved in your role and really owning these projects from start to finish. How do you think about that? How do you think about bringing a project from idea, to production, to completion? [17:19]

Ida Bechtle: I never really thought about it like that, but I think you're right in that definition. I think that's what I really like about my position here at Honeypot actually, because we do get ownership of these projects from beginning to end, all the way through. And I really like being a part of the whole process. [17:37]

Like, I'm the one reaching out to the people. I do the interviews before we go filming. I shape this storyline and then I meet the people see them live and film with them. And you can already like, Build your interviews off of the relation you had in those earlier calls. And while I'm filming, I'll already be thinking about editing it all together. [17:57]

So I think it's a lot of work, but I think it's really beneficial also because you can really like link every part of the production process to each other in a sense. Yeah, I really like it [18:10]

Carl Vitullo: Yeah, that makes a lot of sense. As you're doing the prep work for the interviews, then actually doing the interviews, then doing the editing. You've now done so many separate passes of thinking through these conversations that you're having, that I imagine that lets you flow from one to the next pretty well, especially now that you've been doing this for a number of years and really have a lot of practice doing it. [18:32]

Ida Bechtle: Yeah, for sure. You definitely learn from each project. I will say this is the biggest one I've done. An hour and 20 minutes. So that was also a cool challenge. [18:42]

Carl Vitullo: Biggest only by length or is it bigger by other metrics as well? Like number of people involved or, [18:48]

Ida Bechtle: yeah, also a number of in interviews. I would say length, amount of hours. I had to edit. I had like 25 hours of just interview footage, so, yeah, that's why it turned a bit long. [19:02]

Carl Vitullo: Yeah that's a lot of footage. And you do all of the cinematography as well, right? [19:07]

Ida Bechtle: Yes. Yeah. So for this one, I brought two cameras. Normally, actually at Honeypot we have a pretty simple setup. We don't have that advanced equipment or anything, but I think we can still looks pretty good even with our simple setup and being one filmmaker [19:21]

Carl Vitullo: Yeah. No. Just from watching the trailer, I assumed that there was a whole team behind making this happen. So when you told me that , nope, it's all you, you do all the prep recording and editing. I was blown away. You do an absolutely phenomenal job. [19:33]

Ida Bechtle: Thanks. [19:34]

Christopher Chedeau: I think Ida you are really underselling yourself, like this movie feels like a real Hollywood movie and yeah, you did an amazing job with this. [19:42]

Ida Bechtle: Thank you. That's nice to hear. [19:45]

Carl Vitullo: Hearing you talk about the independence you have and just owning these projects, that's something I've always aspired to and thought out. Over the last year I've been working independently and really trying to make this community be my job. That's kind of what I'm trying to do with these events. And so just getting a little tiny taste of, like, I've been doing these events, I've been getting interesting guests to come talk about cool things they're doing and then editing it and publishing it all up so it, you know, I have seen how much work that is for me. And so seeing an hour and 20 minute long video documentary done by one person I'm blown away. You do a really great job. [20:22]

Ida Bechtle: Thanks. [20:23]

Christopher Chedeau: One thing that was you told me I was interesting. So all of the cameras and different lightning conditions look different, and so you spend literally hours changing the color grading for every single scene that you have, so that they all look consistent. When you told me this, I was like, "oh my God, this is a lot of work," but you can see it in the result like, yeah, it looks coherent. [20:43]

Ida Bechtle: Yeah, I mean, we both do color balance, but also like the look you have to make it look alike or the same colors getting brought out. There's a lot of little details that people don't really think about for sure. Like also weird sound effects and many layers on everything that it's only visible when you see my whole timeline. [21:01]

I try to put it on our Twitter for people to get like a glimpse of the whole thing, but I don't know if it's easy to tell all the different layers that are actually in it. [21:11]

Carl Vitullo: I've dabbled in film and video stuff through high school videos or whatever, I, I know just enough to appreciate how much detail work went into all of that. [21:20]

Christopher's involvement in the early days of Reactiflux

Carl Vitullo: Christopher I'll throw it back over to you. You mentioned a couple of the major projects you've worked on. And I realized actually while doing some of the prep work for this, that you have the first message in the Reactiflux server. You've done all of these huge, enormously impactful projects, and also you were actively involved in the discussion of where Reactiflux should move after Slack decided that we had too many active members back in 2015. How did Reactiflux cross your radar so long ago? [21:49]

Christopher Chedeau: Yeah. So as I mentioned like early days in React, my biggest contribution was around building the community. And so at that time, we were very big on the IRC channel. And I forgot who, but we decided, hey, we should have a user Slack, because this was the the big thing at the time, and I was like, yep, this is a good idea. Let's have like a channel where people can like geek about React on Slack. And so this is where like, Reactiflux first started. And like, oh, it took off. [22:17]

And at some point it took off so much that we basically got bullied off Slack, and they were like, oh, either you like start paying, or find something else. But Slack was priced on a per user basis and so it would've cost like hundreds of thousands of dollars like a month to like, maintain the community. [22:34]

Because I really cared about having a place for the community to like be chatting and everything. So what I did was to start a process of looking at all of the available options at the time. And one of the thing is, they almost all like, were really bad. [22:49]

And so, Slack was actually like much better than anything else and all of the open source versions were bad. But there was one tool that I was using not for anything open source rated, but for like gaming, which was Discord. Discord was one of the earliest adopters of React. And the mobile apps are fully using React Native on both iOS and Android. And I was like, oh, but this is the perfect thing for Reactiflux, really solid chats and you can have like channels and like good notification system and everything. [23:18]

And this was designed for community. Whereas Slack was designed for work, but the biggest challenge at the time was Discord was fully focused on gaming. I chatted with the CTO that I've been working on with React and React Native and, like, I was convincing him, Hey, please we have been booted off Slack this is the best service and everything and let us use it. And he was like, yep, that, sure, go for it. [23:42]

The one thing that we wanted was to have like, code blocks that was in Slack and not in Discord. And I think it was the next day they implemented it, the velocity of Discord is amazing. And so now we are like, oh, we had everything we need, so we started migrating, and a few years later Discord actually changed their whole strategy to be not only for gaming, but for everything else. [24:04]

And now because of the Reactiflux success, a lot of the other open source projects and everything started using Discord, and it works really well. And so I'm really glad that now, Discord is working well for the open source and it helped. And Reactiflux was the like driver for changing the strategy of like Discord as a whole. So it's been like a pretty good success story. So, [24:26]

Carl Vitullo: Yeah. That's incredible. I didn't realize that you were one of the driving forces behind creating this community as well. [24:32]

Actually that's when I got involved, is I raised my hand to volunteer to help out however I could, right, I think a month before Slack closed signups So, yeah I very intimately remember that whole conversation and discussing like, oh, will matrix chat work? What about Gitter? What about, you know, all of those. That's fascinating. That's awesome. [24:54]

Christopher Chedeau: Yeah, and I don't want to take a lot of the credit, all of you are the ones actually running it day to day. The help I gave here was to actually like, make decisions. And this is one of the things that I found to be the hardest with communities growing, is like nobody feels empowered to make decisions. [25:10]

So one of my strengths is to be able to like, Hey, we are doing this, and let's go. And this is the same thing I've done for the documentary. I was like, yep, we're doing this documentary. And I basically tell everybody we're doing this documentary and like, it happened, but Ida did all of the work of actually making it happen. [25:28]

So yeah, this is my contribution. [25:30]

Ida Bechtle: Very important contribution though [25:33]

Carl Vitullo: Yeah, now that I've been trying to, you know, run this community less as a hobby and more as, with some of the professionalism that I think it deserves, given its place in the React ecosystem I, I'm running into those same kind of problems as, nobody feels comfortable being the one to say, I think we should do this. I think it is important that, we make this decision and being willing to put your hand up and take accountability and take a risk. I think being comfortable taking risks is, it's a real skill and I think the projects you've taken on really show how good you are at identifying good risks and then going all in on them. [26:14]

Christopher Chedeau: I'm trying to. [26:15]

Christopher's largest human-centered accomplishment

Carl Vitullo: Let's back up a little bit on some of your other major projects. So you had major contributions to React Native. I know that you wrote the algorithm that did the flex box layout for React Native, and Docusaurus, Prettier. Any other major omissions there? [26:32]

Christopher Chedeau: I was the one that's made this infamous slide deck around CSS in js. [26:38]

So that's got like a bunch of drama, but also a bunch of exciting projects. So, yeah. [26:44]

Carl Vitullo: What contribution holds the fondest place in your heart? [26:47]

Christopher Chedeau: I think the biggest one for me was React for sure, being able to create this community of incredible people. And like, yeah, we had the documentary and this has been so good to go back to memory lane and like actually reflect on all of the people that really helped make this happen. [27:03]

And this is one of the thing is I found like super good about the documentary. Like it showed that it was not a one person thing. So yes, Jordan, started it and created it. But then you can see in the documentary, like a lot of people actually were energized and were pushing for it and everything. [27:16]

So it was really like a community effort. And I loved how there's been so many tweets written along the documentary and each behind each of those tweets is one person, that spends a lot of time and a lot of effort and building something in the ecosystem. So for me, this is not about me, but about how all of those folks came together and all of you in the audience that are coming together to actually like build something bigger and like move the industry forward. So this is my proudest accomplishment. [27:45]

Carl Vitullo: Yeah. That's both a large accomplishment and just a very, human-centered accomplishment. You got a bunch of people excited about something and then they did so many cool things with it. [27:55]

Ida, now that you've spent a year working on this React documentary, what do you think is next for you? [28:01]

Ida Bechtle: I actually already know my next project. I'm not sure I can say it out loud yet, but I'm gonna go straight to making another, not, probably not as big as React . Maybe no more like our usual time, like 30 minutes or so. I'll try to limit myself a bit more this time. But yeah, so hopefully our next bigger production will be out in the fall, I think is the plan so far. [28:24]

Christopher Chedeau: Nice. [28:25]

Ida Bechtle: Yes. [28:25]

Carl Vitullo: Can you give us any hints as to what it will be about? Is it a, an it's another open source documentary. [28:31]

Ida Bechtle: Yeah, it's another open source. Actually, I don't know, I should probably have cleared this, if I can even tease it now. I'm not sure. [28:38]

Carl Vitullo: Fair enough. Okay. But we'll keep an eye out for something in the fall. [28:40]

Ida Bechtle: And I mean, we are also open to suggestions. Like people can always contact us and we'll see what we can do with all the ideas. They can write us on Twitter, it's @honeypotio. They can contact our hello@honeypot.io email, or even on YouTube like writing comments. A bit like people requested also the React documentary. If we see it enough times we normally try to do it. [29:03]

Carl Vitullo: Christopher, Ida, anything else you'd like to get into? Any other topics you think we haven't covered yet? [29:09]

Christopher Chedeau: We have a lot of people in the audience, if you have any questions please like put them in the chat. One question I'm seeing is Motorhead saying, Hey, how do you feel about VueJS? Are there idea s or inspiration you get from it. [29:19]

So, one of the thing that a lot of people don't realize is that, they feel that the React team is like in competition, like, dear Enemy with the Vue team or like the Angular team and you, and like people are trying to pit us against each other. But actually we are working very closely with all of them. So during the early days of React, we had many meetings at the Google campus between the Angular team and the React team, and for Evan You personally, like I've been playing Hades with him trying to speed around the game. And so we are all working well together. [29:50]

And so for a few, like one of the biggest thing it's did for the React, like on the React team was the quality of the documentation. Vue's documentation is amazing. And so when I was managing the React team I actually pushed to rewrite the documentation and using Vue as basically the guideline. [30:09]

And so it's been one of the thing that like really helped. And right now the other thing coming from the Vue ecosystem is Vite, like the bundler, which is way faster than anything else. And this is something that now a lot of people in the React ecosystem are using. [30:24]

So like two things that have directly influenced, there's a lot of myriad of details have happened. And so I'm really excited that we're like, well, like my goal. and and the React team's goal is not to actually like, make React better, but this is like make the entire ecosystem better. [30:41]

And so we actually want to encourage people to try out Vue and like, oh, if there are something that's better in there, oh, are there any ways we can bring into React or vice versa, so. [30:51]

or. [30:54]

Carl Vitullo: Yeah, definitely. So thinking of it as we're all in the web and JavaScript ecosystem, rather than carving out little fiefdoms of, this is a React ecosystem and this is the Vue ecosystem. Really collaborating to grow the space. I didn't realize that Vue's documentation was an inspiration for the revamped React documentation. [31:13]

I know that the beta docs have been beta for a very long time now and are now being released. Do you have any involvement in that documentation project? [31:22]

Christopher Chedeau: I've been out of the React team for like, more than five years now, so I've been superficially looking at it. And so my involvement for this was again of convincing like Dan Abramov to actually push for it. And so he is always been a really good writer and he wasn't really sure like, "Hey, does it make sense for me as an engineer at the company to work on docs almost full-time?" [31:43]

And I was like, Nope. This is how you have impact. Like your writing is why, what gets you in the company and everything. So this thing you should be really pushing. And so I'm really glad that he was able to like, yep, actually like, work on this. And so it's been in beta for a long time because , One of the thing is at this point, React is not, this small project, it's used by literary the entire industry. [32:03]

And so, one of the thing around this is any smaller decision that's been made in the project is going to have long-lasting consequences. And so one of the thing that the React team has always been really good at is really making sure every single decision is thought out and is going to last for another, like 10, 20 years. [32:21]

And this is really hard to do, but this is how the team is operating. And so this is why it feels like the team is moving slower. You mentioned like, oh, all of the concurrency and everything has not still , yet been fully shipped and the docs are still in beta, but this is how you actually steward such a big and important project. [32:38]

And so I think they're doing the right thing to actually get feedback and iterate and, like convincing themselves that this is the right direction. Because if they are wrong, then this is going to be really bad and incur a lot of costs in the entire community. And so for this, it's all about making sure you, you are right and it's still time to back out. [32:58]

And this is one thing, I feel like a lot of people don't do a lot is, they work on something and they get feedback, it's not going to work out. And then they're basically still pushing because of the sunk cost fallacy, but the React team is like, oh, let's actually convince ourselves, convince the, the rest of the team, the rest of the world that this is working. And then let's do it. [33:16]

Carl Vitullo: Yeah. And I think that. That intentionality that the React team has brought to developing the api, developing the library, that's something that I've always really tremendously respected and thought was really one of the biggest selling points. And I think you're absolutely correct about the level of impact that React has had and how that raises the stakes. [33:36]

Now it's like anything that, any change that React makes is now closer in stature and weightiness to, like, a change to JavaScript. So, approaching it with care is absolutely incredibly appropriate, because yeah, you only get one shot. You can't put something out there and then make a subtle adjustment because, those subtle adjustments will never be fully dispersed out to the community. It just fragments. [34:01]

Christopher Chedeau: Another question in the chat from Tactician. Was there anyone else you wanted to interview for the documentary that you were not able to? [34:08]

So actually, like for me personally, there's Jing Chen, so, she actually did talk to Ida, but she doesn't want to be on camera. But Jing has been absolutely fantastic and so influential to build connection with the customers. And so a lot of the times people are thinking about React as this technical like piece of art and everything. But one of the thing now to be successful is you need to actually work with the customer actually going to use it. And Jing has been the one that build a customer relationship. [34:38]

And it was very hard at in many time, but she was the ball. Like you dropped, like she dropped into this relation and now all of a sudden, like everybody was excited, everybody was productive. So I want to give a huge shoutout to her around this. [34:52]

Carl Vitullo: Yeah, that was mentioned in the documentary, her ability to get people oriented around the topic. Do you have a sense for how she manages to do that? [34:59]

Christopher Chedeau: So I think for this basically always putting the needs of the other first, and really deeply understanding, hey, what is the challenges of, like for example, we're working with Instagram, Hey, what is the needs of Instagram team? What are they thinking through and everything? [35:14]

And then basically telling them like, Hey, we are going to be able to solve your needs. And this is something that a lot of people in engineering and tech are like, oh, I want to build my thing because I think it's going to be better, but not putting themselves into the shoes of the others, and conflict management and conflict resolution kind of things has been her superpower. [35:34]

Carl Vitullo: Do you think it would be accurate to say that she approaches these situations with curiosity rather than a preconceived solution? [35:41]

Christopher Chedeau: Yeah, that makes sense. [35:43]

Carl Vitullo: Ida, if there's anything else you'd like to say about how the documentary came together? [35:48]

Ida Bechtle: I guess not too much to say other than just to add thanks to the cast and to Christopher, so for helping me. I think he did, especially with Meta. I think he did a lot of stuff kind of behind the screen or like that I didn't really realize. He made it super easy for me to be able to film even at Meta and to feature engineers working at Meta now. [36:09]

So yeah, I just wanna shout out the whole cast who were amazing and we've gotten so many compliments also about just how they tell this story. It's super entertaining, what do you say? Like, storytelling throughout. So that's all them. [36:23]

Carl Vitullo: Yeah, you can really tell how much everyone cares about all their coworkers and about the project they're working on. Yeah, Christopher any, anyone you wanna shout out? Anything you wanna plug? [36:31]

Christopher Chedeau: Nothing really, go watch documentary if you haven't yet. And if you have, share it with your friends. One of the things that I found like was really good is that the documentary is done in a way, even if you're not technical, you can understand it. And so my wife, knows nothing about tech, but she was hooked from the beginning to the end. [36:48]

And this is very hard, like she's picky and everything. So, it's a really good testament of Ida's skills and yeah. One thing I really want is, can we get it on Netflix? So I'm trying to convince people to see if we can do it, but we'll see. [37:02]

Carl Vitullo: Sure. Yeah. I mean, they get a big shout out in there. Be a good marketing play for them. Well, if I see the React Documentary on Netflix I'll know who to thank. [37:09]

Yeah. Thanks so much for coming out, Christopher and Ida. [37:13]

Ida Bechtle: Thanks for having us. [37:14]

Christopher Chedeau: Thank you so much, Carl, for hosting. [37:16]

Carl Vitullo: Yeah, very glad you could make it. Yeah. Well, thanks so much for coming everyone in the audience. And make sure to join us next week. We're doing the first episode of This Month in React with Sebastien Lorber, and myself, and Mark Erickson. Really excited to try it out and keep you guys on the top of what's happening in the React ecosystem. [37:33]

Yeah. Thank you so much everyone. This was really fun to do. [37:37]

Christopher Chedeau: Bye.

Josh W Comeau

Reactiflux — Wed, 01 Feb 2023 16:00:00 GMT

Introductions

Carl Vitullo: Welcome, Josh Comeau! Thank you for coming out. Josh Comeau is a indie hacker educator, longtime member of the React community. I found that his explanations of complex subjects have a way of just being very intuitive and interactive, and I'm really excited to have him on and talk about his content creation process, how he's navigated the tech industry, and what he is looking forward to. [00:22]

This is sort of a first trial of a different format of event that I'm thinking of. So far we've done office hours, but I'm thinking of this more as a community spotlight, just putting some attention on people in the ecosystem who are doing really great work. [00:36]

Josh, yeah. Anything you wanna say about yourself? [00:39]

Josh W Comeau: Yeah, I appreciate the invitation. I'm happy to be here. I'm excited to talk about this stuff too. I've been, I think I started using React in 2015. And before that, I mean, I was like a Ruby developer in 2014 tinkering with HTML, CSS, a little bit of PHP, a little bit of WordPress before that. [00:55]

And it's just been a journey ever since. In 2020, I left the job that I had to become an independent content creator, blogging at my blog and creating online courses, and that's what I've been doing ever since. [01:06]

Carl Vitullo: Heck yeah. Coming up on three years independent. [01:10]

Josh W Comeau: Which is wild. It feels like it's been a few months, maybe. I mean, you know, it simultaneously feels really short and like I've been doing it forever, but [01:18]

Carl Vitullo: Yeah. It's nice when things feel that way. It's, you know, it feels like it's got a long road ahead, in a good way. [01:23]

Josh W Comeau: Because it's true, it does feel like I'm just at the beginning, like I'm in the middle of working on my second course. Cuz it takes me like two years to make a course. But there's several more I could imagine myself doing. So it certainly feels like there's a lot more to come.

Early career [01:35]

Carl Vitullo: Heck yeah. So you sounds like had a very broad web experience early in your career. When did you get your first job and what was it? [01:44]

Josh W Comeau: Yeah. It's, you know, it's always hard to count because I started just like tinkering, experimenting with HTML CSS back in 2007. Like, that's when I really, I had Dream Weaver and I did a couple of like freelance projects. It was 2014 when I decided that like, I really wanna start taking this whole thing more seriously. [01:59]

So I went to a bootcamp. I did a, it was a Ruby based bootcamp in Toronto called BitMaker Labs. It has since been acquired by General Assembly. And, you know, it, typical of bootcamp programs, it was two, three months, 10 weeks, something like that. Immediately after graduating, I got a job at a startup. I was myself and one other person were the first two hires for this company that these two guys had this idea. [02:19]

The idea was to create a platform for like, influencers and people who are, you know, have large followings online, to connect with brands to do typical brand deals. Something that actually has gotten a lot bigger since then. And, you know, it's one of those things where I had just graduated from the bootcamp and I was I would say yes to pretty much anything, right? I was looking to get my foot in the door. It was wild because it was me and one other person. Both of us bootcamp graduates, neither of us really know what we were doing, but we figured it out. We did some pretty cool stuff. Like we had a real-time chat room. We had like a two way, two-sided marketplace. [02:48]

They each had their own views. I was only there for about four months- ish. And then I got a job at a services company called Conrad Group. And, you know, we did a couple of projects for different clients. We built a news reader app for CFOs of a prominent Inc. 500 company that I've been told I'm not supposed to reference by name. I got yelled at for putting it on my LinkedIn. [03:06]

Carl Vitullo: Okay, wow. [03:07]

Josh W Comeau: So I did that those two jobs were the first six months of my career and they were really just like, just trying things out. After that I got a job at a company called Breather, and that was my first, like I was there for almost two years. For me two years is considered a long stint, cuz that's the longest I've spent anywhere. [03:21]

I spent two years at Breather, and actually it was a Conrad group, my second job where I got introduced to React because this was early 2015. And they had been primarily using Angular at the time, but React was starting to pick up steam. And so my manager was like, Hey Josh, like we are thinking about this tool. Why don't you spend a couple weeks getting up to speed with it? Build a little like prototype app. And then like, I think it was like a Mad Libs type thing that I built where you put in some words and it scrambles it into a sentence. And it was Flux too. It was React and Flux because that was the do it at the time. [03:48]

Carl Vitullo (editing): React and flux, does that sound familiar? That's where the name Reactiflux comes from originally. Just a fun little side note. [03:55]

Josh W Comeau: And . Yeah. Yeah. Even pre-Redux, like this is really going back. And I figured in a couple weeks that I liked it so much more than I liked Angular, but I had no idea what I was like. It's still just felt so magical, like, okay, I guess, you write this thing that looks like HTML and it works somehow. So it was very cool and I really enjoyed working with it.

Mid-career [04:12]

Josh W Comeau: When I went from there to Breather they were primarily using Backbone at the time and I was the only one that had React experience and I had been trying to convince them that like, Hey, this is, like, it's actually a lot better, like what we're doing right now really feels painful in comparison. But you know, it's a hard sell to, let's redo everything. But they put me in charge of what we called Backstage, which was the internal app. [04:33]

I should back up a little bit. Breather is a company like Airbnb for office spaces, and as you might imagine, there's a lot of logistics with that kind of business where after every reservation, a cleaner has to come and clean the space ahead of any other reservations. And so there was like an administration app that we were building and maintaining that was specifically for both the cleaning the cleaners themselves, the people operating the cleaners, so telling them where to go and the customer support staff who would be booking people through the phone or online. [04:58]

And so we had this little app that was specifically for employees and I was the only one working on it. And so when it came time to add new features, I just started migrating to React. Like there was no one to tell me no cuz I was the only person doing it. And I built this thing, it was like a calendar view, but it was really interactive and dynamic. Like it would show you in real time what was happening in every space and. I think people were impressed with how quickly I was able to get it built. And so pretty quickly after that I started helping them. And I shouldn't, I don't wanna take too much credit cuz there were lots of other people that did a lot of work too. [05:28]

But we started migrating the front end to React as well which was went pretty smoothly. I mean, I left the company before that process was completed, but I would check in with them and hear how it was going. And as far as I know, like the whole thing is react now, so that's always cool. [05:39]

I went from there to a company called Unsplash, which— [05:42]

I realize now I'm talking for quite a bit. Let me know, like if you wanna jump to something else, otherwise I'll just keep going. [05:47]

Carl Vitullo: No, yeah. Happy to let you run. [05:49]

Josh W Comeau: Cool. I went to Unsplash, which is like a photography community thing. The idea is that photographers can share their photos and everything is royalty free. Like Creative Commons Zero, so you can use their photos for whatever you want. I was also it was already using React, but I helped us migrate to Redux because or at least I helped us restructure how we were using Redux. [06:07]

And that was what was cool about that job is that for most of the time that I was there and I wasn't there long, I was only there about six months. The backend was where a bunch of work was needed. Like, we couldn't really do much in the way of new features because the, like, we were having a lot of like scale issues and performance issues on the backend. [06:22]

And so I had the freedom to like, okay, since we're not, we don't have stress in terms of like, you have to be doing all these things. Let's spend time refactoring this application. And so we totally rebuilt it. Which is always very satisfying when you're able to do that. So we did that. I went from there to Khan Academy where I spent a couple years working. [06:38]

Khan Academy also was migrating from Backbone to React. But that started way before I got there. In fact, Khan Academy was one of the first non-Facebook organizations to adopt React like Sophie Albert, who was the manager of the React team for quite a while now she's moved on. She was working at Khan Academy at the time, and this might have even been before React had a public release. [06:55]

Like she knew what they were doing and she thought it was cool. So she experimenting with it at Khan Academy. Yeah, I think it was like 2013, 2012, something like really early. And so by the time I got there, they had already, there were a couple of like old views that still used Backbone because there were just, no one ever got around to prioritizing them. [07:12]

But the entire thing had already been on React for a couple years. Yeah, I think I got there in 2016, so yeah, it was a couple years before that. Or 2017 maybe. But yeah, I spent two years there. I jumped around between a few different teams, like I was briefly on, or actually most of my time there was on the teacher team, so we were building tools to be used in classroom. [07:27]

I spent some time on the independent learner team, which was where we focus on people using the site independently, which is most of them, right? People use Khan Academy, which is an educational platform to like brush up on their math skills after school. And yeah, it was a great job. It was a lot of fun. [07:41]

After a couple years I went from there to Digital Ocean where again, we were migrating from Ember to React, and I came in with relatively a good amount of React experience. There were other people on the team that were familiar as well.

RSI Injury [07:52]

Josh W Comeau: And then finally I wound up at Gatsby Inc. The company behind the Gatsby JS framework. And I was there for about six months. And right around that time, like as I was at Gatsby, I started developing an RSI. So I started having burning, tingling elbows as I was typing. [08:06]

Carl Vitullo: That's a, repetitive strain injury? [08:08]

Josh W Comeau: I never know if the S stands for stress or sprain. But, or strain either way, though, so you're doing too much with your arms. Yeah. It was a whole saga where I spent a few months trying to figure out how to fix it. In the end, it turned out that actually like a lot of RSI can be prolonged for emotional reasons. It was wild to me because it started, I was in physiotherapy for unrelated reasons. [08:30]

I pulled a nerve doing the exercise the physiotherapist gave me, which is very ironic. And everyone I saw kept telling me like, oh yeah, that's the kind of thing that heals in like six to eight weeks at the longest. But it had been bothering me for like months and it started in the other arm, which was wild cause I hadn't pulled anything. [08:45]

And I was sharing the story about this on Twitter and like just seeing if other people had experienced it. And so many people kept telling me to read this book called The Mind Body Prescription, which was about like how you, how a lot of physical injuries can be affected by stress or by emotional, like emotional just anything really. [09:03]

So I gave that a try. I started journaling more, tried to be a little bit more open with myself and with emotions and kind of magically that got better. So I spent I think seven or eight months where I was primarily using a microphone and an eye tracker to code and just to do work in general. [09:20]

Fortunately, now that was a couple years ago and I've been happily using a keyboard ever since. But that whole experience gave me the perspective that. I had been working for all these different companies that I've been talking about for several years, and a lot of that work was really satisfying. Like I, I enjoyed contributing to these organizations. I believed in most of the missions that we were doing, right. Khan Academy is a great mission.

A finite number of keystrokes in us [09:40]

Josh W Comeau: But I really liked the idea of doing my own thing. And it had been an idea I had on my calendar or like in the back of my mind for quite a while. And I had the realization that even though like this this nerve injury that I'm having will likely be temporary, you never know what's around the corner, right? [09:55]

Like, each, every one of us has a finite number of keystrokes in us that we can imagine ourselves, like hopefully decades and decades from now. And if we had the omniscience to know, there would be like a number of floating above our head, which is how many times we've pressed a key on a keyboard, and hopefully that number would begin like the billions or the trillions. [10:12]

But it's a finite number, right? You. And so I started to think of that as like a currency. Like every time I press a button on the keyboard, that number ticks down by one, right? I only have so many of them remaining in my life. And so I should spend that, those keystrokes doing something that I'm really interested in and passionate about. [10:27]

And so it was during this whole fiasco that I left my job at Gatsby and started hacking on my course platform and the first course that became CSS for JavaScript developers. [10:35]

Carl Vitullo: Very cool. Wow. Yeah. That's such a powerful way to approach figuring out what's really important to you and thinking about your career as a finite series of interactions. I can see how that would be a very motivating reason to do what's important to you. [10:52]

Josh W Comeau: It was definitely a perspective shift, before that my thinking had been, I have all the time in the world, right? It's still, you know, if we assume that I got my first job in 2014 I've been in this career for six years. You know, most people spent 30 or 40 years in their career, so there was no shortage in terms of expected time spent coding. And I figure maybe I'll do what I'm doing now for another 20, 30 years, and then I'll move on to something else. [11:13]

But I shouldn't take for granted that's how that will work out, right? I was also very, I should mention, very lucky in that I had probably about a year and a half of savings saved up so that I wasn't, like I had the financial freedom to really say, okay, let me spend my let me give this my full attention and really just see what can happen with it, which I know is not a luxury that most people have. [11:34]

But yeah, that was really I had the realization that like, there's really no reason for me not to do this because if it doesn't work out, I will have burned through most of my savings, which is unfortunate, but I felt pretty confident I'd be able to get another job as I had been doing, just doing, you know, typical IC software development work. [11:49]

And yeah, just when I framed it like that, when I framed it as like, the currency thing about only having so many keystrokes left, it seemed like, just the solution was obvious that it was something I had to do right now. [11:58]

Carl Vitullo: Right. Yeah. Yeah. And maybe reframing it a little bit, it sounds like really reckoning with your own mortality in a way. Maybe the mortality of your career, but really realizing how time is finite. Yeah. [12:13]

Josh W Comeau: I probably should have mentioned that. Yeah. This is a very morbid idea.

An expectation of being able to code [12:16]

Josh W Comeau: And of course, you know, I didn't have any sort of expectation that I wouldn't be able to continue coding. And actually a big part of this whole experience taught me that like no matter what life throws at me, I will find a way, like with how good technology is. Cuz and we were speaking about this before the event started, even with the microphone and the eye tracker being a significantly different way to approach writing code, I was still able to move relatively quickly, like not as fast as I can with the keyboard, but certainly fast enough that it felt viable, right? It seemed like, okay, I'm gonna have to be a little bit more careful with how I prioritize. Like maybe I can't go through and spend as much time polishing things as I would like. Cause maybe I'm moving at half the speed that I normally would, but I can still get a lot done especially if I prioritize a little bit more ruthlessly. [12:59]

Carl Vitullo: Right. Yeah. I see that we've had many people join. Lemme just reintroduce very quickly. Josh Comeau is joining us today. He's an indie hacker educator. He has worked at Gatsby, Digital Ocean, Khan Academy, and many others, and is currently an independent educator. And just recently released his course, the Joy of React. And we're here talking about mortality and the limited time we have on Earth.

Job hopping [13:25]

Carl Vitullo: But I, if I could back up maybe a little bit. So you've mentioned a lot of shorter stints at various jobs in your career. How have you thought about that? How have you approached the question of, should I stay or should I leave? [13:38]

Josh W Comeau: Yeah, so when I was at the bootcamp in 2014 one of the instructors that we had he took like a whiteboard marker and drew a graph and show—granted, this is an audio format, so let me see if I can describe a graph. It shoots up linearly and then slows down, right? Like the, like the first half of a bell curve, right where it goes up and then it starts peaking. [13:58]

Carl Vitullo: Plateauing, sure. [13:58]

Josh W Comeau: And he was saying that you hit this plateau maybe like a year and a half, two years into your career and you wanna leave your job before that point, like leave the job where you're still getting that fast momentum. The thing that was being graphed, I should say, was how much you're learning, how much you're growing just, how healthy it is for you as a developer. [14:14]

Carl Vitullo: Sure. Skill advancement. [14:16]

Josh W Comeau: Yeah. And his point was that unless like, and there are certainly exceptions, right? Like if you work at a company where you're constantly being moved to new projects in new departments, then that kind of works the same way. But if you're spending more than two years hacking, especially I think mostly like early in your career, like certainly there are lots of benefits to maintaining a project long term. [14:33]

But I think his point was that for the first few years you wanna sort of, expose yourself to lots of different code bases and different technologies, right? Like you have to figure out like you get a lot of benefit at first and that benefit slows down. And the more these experiences you have, the more you things you can reference, right? The more you can appreciate, you can bring solutions you learned at one place to another place. It's just like all around good. [14:54]

And I know that there is this debate, like if an employer sees that you have a bunch of these like six month, nine month, a year stints, the fear of course is that are we gonna hire this person, in six months they're gonna leave. I personally haven't had many issues with that, but I'm very careful not to generalize that to anyone else. Like I recognize that there's a lot of privilege that I have as a white guy in tech. I have no idea. You know, like, it, I don't know how much of the lenience I was given in this particular area is because of that, but I would expect quite a lot. So there is definitely, like, I don't wanna generalize this as good career advice for anybody else. [15:25]

I do think there's much more tolerance for it in tech than other sectors. And you know, my third job was breather. I was there for a little under two years. I think it was like a year, 10 months, something like that. And for me that was like a good enough stretch of time. Like I feel pretty confident that if you asked someone at Breather whether it was worth hiring me for that amount of time, they would say yes, right? I got a lot of good things done when I was there. [15:46]

Maybe if it's every six months like that, and if you have five or six of those, like if your resume is two and a half years long and you've worked at six places, maybe that does start to become a problem. But if you spend a couple years somewhere I think that at least in my own experience has been like, it's never come up for me. I've never had an interviewer say that. Granted you never know why you don't get a job, but I've had pretty good luck when it comes to companies that I really wanna work for.

Unconventional job hunting tips [16:09]

Josh W Comeau: You know, I also and this might be worth, it's totally not what we're here to talk about, but I do have a kind of an unconventional tip for job hunting. I worked at a bootcamp, right? [16:18]

For three years I was teaching part-time at a local coding bootcamp called Concordia Bootcamps. I was doing this while I was at Khan Academy, Digital Ocean and Gatsby. I was working 14 hours a week for them. [16:26]

And the advice that most people give in these settings, both at the bootcamp we were at in just generally online, is that it's a numbers game and you want to get out n number of applications a week, right? 15 a day if you can, and grab a templated cover letter and very quickly, like do the find and replace where you put in the company name and the technologies. You know, I am very interested in Acme Inc. Because I am passionate about dynamite or whatever it is. And that I think when you're first starting out, yeah. For your first job, maybe that's good advice. [16:55]

As I got my second and third job, I started being much more strategic and like, okay, who are the companies I really wanna work for? And what can I do to make myself a pretty attractive option? [17:04]

So the one example was, I liked the idea of working at Spotify. So I built an application with Spotify's api. It's called Panther. It's panther.audio. It's still online if anyone wants to go check it out. Essentially it hits the Spotify API, it pulls information about an artist that you search for and three related artists, and it lets you move through this big node graph of like, okay, this artist is connected to these three artists. And then if you click on one of those artists, it pulls that one to the center. Just a way to discover like related artists to one that you like, as an exercise in like, here's an interesting interface for the data that this API provides. And I applied to Spotify. In fact, I think it was even like I posted it online and people at Spotify saw it and put in a word internally for me, like that's always a good thing. [17:46]

It didn't work out because it became apparent pretty quick that they wanted me to move to Sweden. And I had just moved to Montreal to be where my partner lived. So I withdrew from that process. I think I had one interview. So it, like, I, it's impossible to know how that would've gone. But certainly it didn't hurt, right? [18:00]

Like, certainly the fact that I had spent significant time and you don't hear this advice a lot because it's a lot of eggs to put in one basket, right? Like if you spend. 60 hours on a single job application cuz you spent a week and a half building this thing and they're just not hiring junior developers at the time. That's seen as a waste of time, but really, like, it's still a valuable side project. Right. Even it doesn't, I can use that elsewhere and it just it creates it stacks the odds in your favor. Similarly with Khan Academy, right? Khan Academy I forget the numbers, but it was something like, they get several hundred applicants for every open position. [18:32]

Like it's a very competitive place to work because so many people use Khan Academy in high school and college and then they graduate. I was also one of the only people there without a CS degree. Like they, they really, in fact, most people had like advanced degrees that were there. And I think the reason I was able to pull that off was a bunch of stuff.

Personal projects, open source, and networking [18:46]

Josh W Comeau: Like, one of them was that I Khan Academy had an open source project called Aphrodite. I had contributed to that project and spoken to some of the developers on it, and in fact, I think I made a couple of contributions to it. I forget exactly. I also became friends with someone that worked there at a hackathon. [18:58]

And that was, that's hard to engineer or something like that. But I became friends with someone who worked there. And I put like a lot of work into my cover letter. I saw it as a dream job of mine, so I put a lot of work into it, and it worked out. I went through eight interviews, because that was what their process was and it worked out. [19:15]

So I do think like I say, right, for your first job, your second job, maybe it's the shotgun approach of just trying to get as many applications as you can out. Maybe that's not a bad idea. Beyond that, I do think like find two or three companies that you would love to work for and put a lot of work into it, because those things matter. [19:30]

Carl Vitullo: Yeah, I've never quite gone that far into picking a company and deciding that I wanted to work there, but I have followed a similar sort of trajectory as what you just described, where, just by following my own in interests and coming up with a project that I thought sounded like fun. And you know, just like maybe this touches on like build in public and learning public kind of topics as well, but just by working on things and publishing them and making them visible to the world I think that can be a very powerful way to get jobs. [20:02]

And it gives you something to network around. You know, if you go to a conference and you're looking for a job or something, it's much easier to start that conversation and find new friends who may then be able to get you an in at a company if you can talk about some project that you're excited about, you know, look at this cool thing I made. [20:18]

Josh W Comeau: Yeah, totally. And I would also say there's like a spectrum here, right? It's not like you either spend five minutes or 30 hours. When I worked at Unsplash, I was actually put in charge of hiring my own replacement cause I was leaving and we needed to replace me. So I did a lot of interviewing and I was amazed at how little effort most people put in. [20:37]

Carl Vitullo: I know, it's shocking. [20:38]

Josh W Comeau: And so if someone put 10 minutes into the application, right? They wrote a paragraph in the cover letter about why they thought our company in particular was interesting. Like little things like that can really help you stand So I do think like the strategy I suggest is like almost imagine a spectrum where the more you wanna work at a place, the more work you put into it. [20:56]

And you can start by applying to the places you're not super interested in and not put that much energy into them. And maybe that'll give you some practice, right? Like scale the amount of energy into an application based on how much you wanna work. [21:08]

Carl Vitullo: Yeah, I think that's excellent advice. You know, maybe not full templated cover letter or whatever, but you know, if there is a job that you're interested in, that sounds like a really good fit, that sounds like it would be on a team that you could learn from then. Yeah. You know, spending 20 minutes on a more personalized cover letter, I think is absolutely worth the effort. [21:29]

And on your point about the lack of effort, I've interviewed a number of people over my career and unfortunately, a very effective screener project I found for hiring for a React role was, write a button that increments a counter. It was disappointingly effective at people who claimed, moderate to expert level react knowledge. [21:53]

So I, I think a lot of the times the bar is lower than many people expect. [22:01]

Josh W Comeau: Yeah. That's interesting. Like if a job application lists a bunch of requirements, right? It's easy to assume that if you don't match a lot of them, that you're gonna be near the bottom of the people applying. But, I think you probably learned that's not really true. Like you're probably much higher in that stack than you think. [22:17]

Carl Vitullo: Yeah, I definitely agree with that. Yeah. And going back a little further to what you said about job hopping What you said about it not really being a factor that you noticed as a limitation in your career. That's been my experience as well. I had I had a stint where I worked three jobs in a row that I left in under six months. [22:36]

I think the shortest was just over four months. And yeah, like nobody ever brought that up in interviews ever again. I got a couple of questions about why I left, and so I did have to come up with a you know, devise a bit of a story, tell a story about what the situation was. [22:51]

But yeah, my experience mirrors your own, I think where once you get one job where you stay longer than a couple of months, I think that really shows that you can stay places you are willing to stay, places. You're not getting fired because you're bad at things. You're leaving because you're looking for the next thing, which I think is appealing to many interviewers. [23:11]

Josh W Comeau: Yeah. it's funny, that's I had an answer prepared for if someone asks, like, Hey, I've noticed you've worked at a lot of companies in the last couple years. The answer, and it's honestly, it's pretty much true, was, yeah, look, you know, I'm relatively new to the industry. I wanted to try out a few different environments. [23:25]

So I worked at a services company, I worked at a product company. And now with my application now, I've kind of worked out what sorts of environments I like, and I'm trying to find the kind of place that would fit that environment. And I think that might be you, whoever I'm talking to, right. [23:38]

Which kind of positions it as, it's not just that you're addicted to leaving companies after six months. Cause really it's a lot of work to leave a company like, I don't think most people are. But that's, I think, the impression people can get. It's more that like, you know, you're trying to find the right sort of environment for you. [23:51]

Carl Vitullo: Right, careers are a bread first search, and as you narrow down, you look for a better fit [23:56]

Josh W Comeau: Mm-hmm. Yeah. Yeah. I like that [24:00]

Carl Vitullo: You know, so you came up. That's a great story. I think that's, I think that would be a very compelling answer. But you were ever, never asked that question? [24:06]

Josh W Comeau: Yeah, I never had the chance to give it [24:09]

Carl Vitullo: Too bad. (laughter)

Ideation for blog posts [24:12]

Carl Vitullo: Maybe changing topics a little bit. So you've been an educator for a long time. Could you talk a little bit about your creative process? How do you find a topic that you think is in need of explaining and how do you take that topic and come up with a way to make it intuitive to people? [24:27]

Josh W Comeau: There's, I have a Notion document, I have the app on my phone, and if I'm out walking or wherever I'm in my life, ideas just pop into my head. Like, maybe I'll think of here's a little UI detail that I think would make a good blog post. Or like, here's a really good analogy for explaining this random thing. [24:41]

And over time, these bullet points in my notion document, collect notes on them. And it sort of happens pretty organically, where eventually one of these blog post ideas will have like four or five points that sort of form a vague skeleton. And if I think it would be an interesting thing to write about, then I'll spend the time and bring it over from Notion into markdown. [25:02]

I write in MDX which is basically Markdown And often it does start from like a particular visualization or a particular analogy, like, I do wanna have some sort of, hook is not really the right word, but some sort of thing that makes this blog post worthwhile. [25:16]

I should say there's lots of valid ways to do this. [25:17]

Like, there are plenty of people who produce a lot of work that is very valuable, which is tailored around search results, right? Like, just if you get run into an error, then make a blog post about that error. That's not really what I do. Like, I try to have longer, more comprehensive blog posts that dig into a particular idea. [25:32]

I have a bunch of ideas that are, I probably have 150, 200 potential post ideas and most of them are never gonna happen cuz they're not particularly good. Right? It's the brainstorming thing of you just throw any idea that you have. But yeah, eventually these ideas, they kind of coalesce into something that I think would be compelling. [25:48]

I've noticed there's this fun thing that happens where when I started blogging, I had a pretty small audience, which meant that the only people that were gonna read my blog were people that were in my personal network, roughly at the same level that I was. I don't remember when I started blogging, but it was a long time ago, And I started on Medium. I wrote a few dozen posts for Medium and then I created the blog that I have now, And when I was first doing this, it didn't make sense for me to write introductory, like intro to CSS Transitions because, you know, most of the people that I was working with already do that. [26:17]

So I would have to find these pretty, Like, niche things. Like, one of my early blog posts was about rehydration and React, which is something that I think a lot of experienced, React developers still struggle with. And like I was getting these weird bugs where like everything looked fine in development, but you deploy it and the wrong elements are in the wrong places. [26:34]

And I mean, that's specific to Gatsby because they don't do server-side rendering and development. Um, But yeah, so I would do these like very specialized niche things because those are the types of things that people in my network would benefit from. But as my blog has grown more popular, it's sort of given me the allowance to do more introductory topics because now when I publish something, it spreads beyond my network. [26:55]

And I think my most popular blog post now is an Interactive Guide to CSS Transitions. And then I have one about Flexbox as well, which it's interesting, right? Like the further you get in your career, or the further you get in terms of building your network the more introductory you can go. Because even if one of these topics has been covered a hundred times already I know that I can put my own spin on it and I can make it interesting and it will reach those people who otherwise I have no way of reaching [27:21]

Carl Vitullo: Yeah, that makes a lot of sense. So you started blogging just for yourself and for the people in your network, and then as you gained an audience, you started writing more for that audience. Does that sound right?

Writing for advanced audiences [27:32]

Josh W Comeau: Yeah, and I think it's like, it's given me the freedom to write about things that may not be directly relevant for the people. At this point I feel like I can write a blog post on anything that interests me or that I think I have an interesting way to present it. [27:45]

I think this is one of the problems, right? If you're trying to reach people who are just starting to code, like they're not working as a developer, maybe they're thinking about enrolling in a bootcamp. Maybe they're in a bootcamp. They're gonna know about FreeCodeCamp. Maybe they know about Wes Bos, like they know about the biggest creators, the search, the first result on Google for a given thing. Um, It's like the people who have been doing this for a while that know about more niche creators like myself, and I'd still put myself in that category to a large degree. [28:11]

I think it's interesting that the further you get into the content creation thing, the more possible it is to reach people that are earlier in their career, at scale, right? Like when I worked at the bootcamp, I actually did know quite a few people that were in that situation. [28:24]

But, um, I would have no way of reaching people outside the people I met in real life or that were in my direct network like that. [28:31]

Carl Vitullo: Right. Yeah. I haven't blogged with any kind of regularity in probably four years now. But my experience as well is that the more introductory topics tend to have a larger natural audience. The first, you know, one to four years of your career, I think are when you tend to learn the most subjects, the most quickly. [28:51]

And so you're very seeking out new things to learn, new places to learn it from, new ways of thinking about it. The numbers here are maybe fuzzy, but after about four years, I think, you start feeling more confident in your knowledge, and I at least began learning things more on a sort of "just-in-time" basis. Like, oh, I need to do this next week. Let me dig into the subject. [29:16]

Trying to write educational content for an intermediate to advanced audience, it's just much harder because there's fewer people actively seeking it out. [29:25]

Josh W Comeau: It is interesting how that tends to work. And actually, I have a blog post called How to Learn Stuff Quickly which touches on this a little bit. Like when you're first starting to learn something, you don't know what you don't know, right? Like you need a really guided introduction to that thing. And the further you get into it, the more able you are to answer your own questions, to fill in your own gaps. [29:44]

And so the learning becomes much more unguided and you can answer more of your own questions cuz you know what you don't know at that point and you can go find those things. Yeah it's funny how that works out. [29:53]

I do think that there is there's still I think a big audience for guided advanced content just for the matter of like, you could figure this thing out. And the example I always think of is like whimsical animations, which is something that I want to create a course on at some point. Because like there are so many things that I just had to figure out the hard way that it took me a lot longer than it would have because there just, like you can certainly Google and find the solution to any discreet problem. [30:18]

But I think what's harder is to move up a ladder, right? And to kind of get a broader overview and to understand how all these small things connect and what the best tool is to solve a given problem, rather than just searching for the code that you need or the strategy to do it at a more granular level. [30:31]

I think what you're saying is totally right, that when you're first starting out, that's why I think a lot of beginner tutorials are so popular because it's really, there's not really any other way to do it other than to have someone kind of walk you through, okay, these are what the tools are, this is how they work. And to give you that, the skeleton that you can then go on top of. [30:46]

Carl Vitullo: Right, right. Yeah, a concept that I try to keep myself too, when I'm doing a new project is have a novelty budget. You know, try and keep keep the reins on how many new things I'm doing at once. And that's just not something do when you're a beginner. When everything is new to you, it's inherently overwhelming. And so a tutorial that gives you a skeleton is a good framework to delegate the setup process so you can focus on what you're trying to learn in the moment.

Other creators and the power of interactive explanation [31:15]

Carl Vitullo: Who are some other educators and content creators who you're keeping an eye on? [31:20]

Josh W Comeau: Yeah. So thing for me you know, my blog uses MDX, which as I mentioned, is Markdown with React components. And the really cool thing about that is that it allows you to like, create bespoke one-off interactions or widgets or code editors or just, you know, things that will help you explain this idea. [31:35]

And so really I'm always delighted when I see people that publish in a similar style. Now, the two people that come to mind are Maxime Heckel. He blogs at maximeheckel.com, and hopefully I pronounce this even partially correctly. Nanda Syahrasyad, he blogs at nan.fyi. And both of them I'm pretty sure they both use mdx. [31:55]

They do the same sort of thing that I do, which is to have blog posts that have unique embedded things right in the blog post that let you poke in prod of the idea, right? Maybe there are sliders, maybe there's interactive code that demonstrate the idea that you're talking about. [32:07]

I think about how people learn and, until we had the internet, it was all like, maybe mostly it's books and then you have videos. Maybe you'd get like a VHS that would have a tutorial for something and those are both good and certainly like there are things where video is the best way to learn something. But for a lot of things, I think if you can interact with it, right, like if you can make it, like bring some of the things that video games have in terms of interaction and exploration, it just makes it so much more effective. [32:33]

And I feel like just as a community, we haven't really taken full advantage of that. Like there's so much we could be doing to make educational content more kind of engaging. I don't know if they're a company or a non-profit, but brilliant.org, it's like an interactive textbook is I think how they describe it, where it's like for math and physics and things. You can play with the ideas as you're learning them and it's so much more effective than reading a textbook or watching a video. [32:55]

So yeah, those are a couple examples of creators that are that are doing this. But I hope other people get involved cuz , first of all, it's just really fun too, to build them, right? You get to use your programming skills and your content creation skills together, which is always fun. There's so much more potential for what you can do with that [33:10]

Carl Vitullo: That really resonates with me because when you're trying to learn something, I think at the core, what you're doing is building a mental model, and it's so much easier to develop that mental model if you can interact and run tiny little experiments like, you know, if you, if you can play with a simulation and think in your head, I think when I change this, this will happen. If you can get that immediate feedback by interacting with the material you're learning from. I can absolutely see how that is very effective for learning. [33:40]

Josh W Comeau: Yeah, and like I mentioned, right, often I'll be walking down the street and I'll think, in fact this happened. I have a blog post on introduction to CSS Transitions. And what I imagined was what if we visualized every frame in the transition? So like if a circle moves from left to right, what if we like have a little shadow, like an outline of where that circle was for every frame? [34:02]

And that allows you to visualize easing curves. Like if something moves linearly, then all of these circles are equidistant apart. If it has an ease, then it, they bunch up at one end. It allows you to show how frame rate matters, right? Like if you lower the frame rate, you can see that there's less. So like I was, I forget what I was doing, but I wasn't coding. [34:18]

I was doing something in my regular life and I had that idea. And then pretty much immediately I was like, okay, this has to be a blog post. And that was only possible. Uh, I guess I could have made little videos and then included like a gif of it, but it wouldn't have been, it wouldn't have been as effective. [34:30]

And it's so cool when you can literally change the easing curve for yourself and then replay the thing and see what it does differently. It's exciting that we have technology to do this now, right? Like it's it's relatively recent, but MDX and tools like it. I forget what it's called, but there is a Vue alternative to this. So it's it not specific to React. Although given that this is a React community, I don't imagine that'll be a problem. It's amazing that we have the tools that we do, and I hope more people will take advantage. [34:53]

Carl Vitullo: Yeah. and an example from you that really stuck in my head as the power of explaining things with those sort of interactive elements was, I remember seeing, I think it was on pudding.cool. You did an interactive explanation of sin waves, I think it was, or sound waves. [35:08]

Josh W Comeau: Yeah, that was, you know, actually I didn't mention this, but much earlier, in a former life, I went to school for audio engineering, and it was like a six month trade school kind of thing. And I never worked as an audio engineer, but I found it very interesting. And so I had these ideas for how I could visualize that. And it was over like a winter break when I was working at Khan Academy, I had sketches of how this could work, and I decided to see if it could be built, and sure enough it could. Um, And it, yeah, it was a lot of fun. [35:34]

I initially it alone, and then the folks at pudding.cool reached out and offered to buy it from me essentially, like to pay me to have it published through their journal. I don't think I was familiar with them before, but I took a look at their work and it was super cool. [35:46]

It's kind of cool that there are organizations out there that will pay you to do this, which I had no idea. It's another one of those things where it was just an idea that I had. I was honestly kind of waiting for my skills to catch up because I had the idea years before, but I just had no idea how to do it. [35:59]

Like I figured maybe svg, but I didn't have much SVG experience at the time. Actually I wound up building it twice. I built it in in Canvas partially just as like as a learning exercise, but because I wanted to see which one was more, both performant, but also which one just felt better to use. [36:14]

I forget. I think I wound up going with SVG in the end. It was definitely a challenging project, but a really satisfying one.

Going before you think you're ready [36:19]

Carl Vitullo: What you just said about, it sat with you, it sat in your head for a number of years before you were actually able to get it out onto a webpage. It's sort of that, "overnight success takes many years" concept. It takes so long to, for an idea to percolate around before it becomes fully fleshed out. [36:36]

Josh W Comeau: Yeah. And it is, And this is something too, like I probably could have done it earlier. And this is something I've told so many bootcamp students, that like, if you wait until you are a hundred percent ready to do something, you're never gonna do it. Like you have to eventually, whether it's like applying to jobs after, cuz a lot of people, they finish the program and they still feel like they don't have any solid grasp of anything. [36:57]

The urge often is to spend a few months solidifying what you've learned so that you're ready to get your first job. When really I think, you can probably advance much quicker by applying to jobs now and then developing those skills on the job. If you wait until you're ready, you're never gonna be ready because there's always… I don't feel like I've ever hit the point where I am a hundred percent confident in everything that I'm doing, and I feel like I know everything there is to know, like, of course not, right? There's always things that I don't know how to do and that I'll figure that out, like you mentioned, right? You figure it out as you go. [37:30]

I probably should have started that project a year or two earlier, but I'm glad I started it when I did, or I'm glad I didn't start it later. [37:36]

Carl Vitullo: Sure. (laughter) Yeah. Advice that I have heard is that if you're ever at a point where you know everything you need to do your job, you should find a new job because you're not being challenged anymore. And if you're not being challenged, you aren't growing. [37:48]

Josh W Comeau: Yeah. This is actually something I mentioned in my new course because I did, so my new course, the Joy of React has a module on hooks and in that hooks module we talk about use effect. And there's just, there's so much confusion about use effect out there, right? It's a challenging api. And, I was building this course, and I decided I was gonna cover effects before refs because I figured most of the things you do with refs require effects, right? Like the typical example is you wanna focus and input after the component mounts. So you use a ref for that, but then to actually do the focusing, you have to do that in an effect. [38:24]

And so I, we covered effects and I kept finding myself setting up the examples where like, I would have to have these disclaimers, like, this isn't really how you should do this, and later on we'll learn why. And I showed it to some people and the feedback was a lot of like yeah, like this, it's kind of hard to follow. [38:40]

And so I wound up redoing a huge chunk of it. Like I spent probably five or six weeks just redoing and structuring it differently so that refs are covered first and everything does work way better in that. But it really did, like I had a couple days there where I was just like, my goodness, should I even continue with this course? Like it's taken so much longer than I thought it would And it just struck me that like, this is how so many people feel when working with hooks.

Ignoring imposter syndrome [39:01]

Josh W Comeau: So in the redone content, the first video before the effects is like, just an honest conversation about how, like there will be times where you feel like you don't know what you're doing, and should you ever share some code that you've written on Twitter that uses an effect, people will come outta the woodwork and tell you that you're doing it wrong. Like, this shouldn't be like this, you should do this instead. The best practice is this, right? You shouldn't use an effect for this. You should use something. And all of this advice is, not all of it. Most of it is very, very good, like the person sharing it is good intentioned and trying to help, maybe they made the same mistake and they're trying to share it. [39:34]

And the advice is usually helpful. Like your code will be better if you follow that advice. But like the big but at the end of all this, the, this run on sentence, is that it still works. Like most of the code that most of us write is not optimal, but it still works. And you should never feel guilt or shame for writing code that isn't like the top, that isn't the most conventional, the most aligned with best practices. [39:59]

I can tell you, like I worked at Kahn Academy, which as I mentioned was one of the first organizations outside of Facebook to use React. We did so many things that were like objectively wrong. Like, I'll give you an example. We used Redux. We had like five different Redux stores because we had a different Redux store for every concern. And sometimes things overlapped, so we'd have to sync things between different Redux stores. Which if, you know Redux, like that's the big thing that you're not supposed to do. [40:23]

Carl Vitullo: Right, that's sort of a cardinal sin, [40:25]

Josh W Comeau: But I'll tell you what. We never got a support ticket that said, Hey uh, I'm trying to learn physics on your program, and you're, you have too many Redux stores. Right? Like this invisible to the user. It slows you down in your development a little bit, which is it is still a good idea to fix these things. But you can absolutely create brilliant things, while still making pretty foundational mistakes. And that's just the way it goes. [40:47]

And the, the reason I thought of all this was when I look at code, I started this course platform in early 2020. It uses Hooks exclusively, or almost exclusively Hooks came out in 2019. So when I started working on this course, platform Hooks were new and none of us knew like what the best practices were, right? [41:03]

I have a lot of eslint disable next line before my dependency array in the use effect hook, which is what you're not supposed to do. Uh, But the course platform works just fine. And I am, you know, there's like the Boy Scout thing of, like, every time you touch a piece of code to make it a little bit better.

"Best practices" vs "Happy practices" [41:16]

Josh W Comeau: So I am slowly getting rid of those bad practices, but I'm pretty sure that no bugs have been caused by these bad practices. No experiences have been degraded. And the course platform works pretty well. So, uh, you know, I think it's the important thing I realize and that I hope other people realize in this course is that none of this stuff is life or death. [41:35]

Like, You will make mistakes, that's fine. And if you look back at code that you wrote a year or two ago as I've been doing, working on my course platform, and you're embarrassed by the code, that's a good thing because it means that you have grown that much better in the time since. [41:48]

Carl Vitullo: Yeah. And you know, in the community, we get a lot of questions like, what's the best, you know, form library, what's the best component toolkit? What's the best way to fetch data? And [41:59]

Josh W Comeau: Hmm. [42:00]

Carl Vitullo: I thought of this because you mentioned optimal, and "best", or "optimal" is just it's couched in so much context, In order to correctly answer that question, that, there is no best, no optimal. It, It depends on what you're optimizing for. And you know, sometimes you're optimizing for speed of authoring. Maybe you need to ship a feature in two weeks and you know, there's some deadline that's crucial and yeah, you know what the the optimal code for that is something that works. So, yeah, just, uh, optimal or best is so subjective. [42:33]

Josh W Comeau: So my React course still has a couple modules yet to come, and I, I haven't quite figured out the structure for it, but I do think one of the, if not an entire module a chunk of a module is going to be on things that I've learned about using React effectively, like building on everything that we've learned so far, here are some things that I used to do that I've since learned are not as good as they could be, or, and my plan is to call them "happy practices" rather than "best practices." Cuz like, they're not the best, they're, they're just things that make me happy. I think that's ultimately a better way to look at it cuz you're right, there's no such thing as a best practice because it really depends on the circumstances. [43:05]

Carl Vitullo: Yeah, absolutely. Some Bob Ross vibes there. Happy little braces. [43:10]

Josh W Comeau: I mean, it's called the Joy of React. [43:12]

Carl Vitullo: Should bring joy to people. [43:13]

Josh W Comeau: I figure I should lean into that. [43:16]

Carl Vitullo: If there's anything else you wanna talk about on your course, I'd love to hear it. Two years in progress, what are you looking to do next with it? [43:23]

Josh W Comeau: I think I started working on this in early of last year, so it's been about a year. And I did take about a month off, cuz now I have two courses. So there was a month there where I was going back and updating a bunch of stuff in the CSS course.

Taking breaks, not unit testing [43:34]

Josh W Comeau: I say that it takes about two years to make a course. Really it's about a year and a half. And then I take a six month break in between making them both to support the new course and also just recharge a little bit. And so I've been working on it for about a year. [43:45]

The course is about two thirds finished. Like the plan is to have six modules and three projects, and right now there are four modules and two projects. So literally two thirds done. And yeah, so over the next few months, the plan is to finish that course. There have been a lot of questions about like, what is to come in those modules, and I definitely have some ideas. [44:01]

This is another thing that I think catches people off guard. One of the more common requests I've gotten is to cover component testing because my course doesn't touch on it at all, and I don't do any component testing. like in my course platform, the only test that I have are end-to-end tests, and I have maybe like 20 or 30 of them. It's not extensive. [44:19]

It covers the most critical flows, like, signing up and onboarding stuff, right? The things that, I want to know if this thing breaks cuz it, progress tracking is another one. But no, don't really, uh, do any component testing and I, I used to, but it's been four or five years since I did like Enzyme. I don't even know if Enzyme exists anymore. [44:36]

Carl Vitullo: That's been my experience too. I remember early in my career, I wrote so many unit tests . And then at some point I realized like, you know what? These tests are just breaking constantly for no reason. They're not giving me value. [44:48]

I haven't quite gotten all the way out to end-to-end tests, just because I've found them flaky. They're difficult to set up. Mocking is a challenge, yeah. If it doesn't alert you reliably of a critical breakage, then… tests can be more harmful than helpful in a lot of cases. [45:06]

So yeah, I think your experience with testing I think is maybe more broadly applicable than many developers realize. [45:13]

Josh W Comeau: Yeah, I wanna make clear that this is my own subjective personal opinion and not even a, an opinion I feel very confident in, but I think it makes sense for unit tests when you have a library or a component library, anything where it's like other developers are consuming your tool because yeah, you wanna make sure that like your API is rigid, right? [45:30]

If you're not doing a major version bump, then like I feel like that is really good to have. In your own code where you're not versioning it, there's no semantic versioning and it, it's so much work to keep the tests up to date as you make changes. Snapshot tests make that a little bit nicer, but again, I haven't done them in years, so I have no confidence in my ability to explain how to use them well.

How do you work in public? [45:50]

Carl Vitullo: We do, we do have a question in the chat of, how do you actually work in public? Do you have any thoughts you wanna share on that? [45:57]

Josh W Comeau: Yeah, that's a great question. I think for myself personally, it's tricky to say if this is generalizable because, my business right now is creating courses and so it really does help me to, just get people to be aware of the mind you, I guess this is generally applicable cuz you do want people to know about the things that you're doing. You never know how, like a thing that you share will be noticed by someone that works at a company that you wanna work for and appreciated by them. [46:20]

So I and I don't have too rigid of a strategy. Often, And I've been neglecting this recently, but for a long time, whenever I either learned or was reminded of like a cool trick, whether it's like a CSS thing, like I think my most popular tweet is, uh, how the CSS filter drop shadow behaves quite a bit like the CSS property box-shadow, but if you apply it to an image and that image is transparent, so say you have like my little 3D mascot character, it'll apply the shadow to the outline of the image rather than just the box, like the square that the image takes up. Um, and that was like a cool. It is pretty neat. I think I already knew that, but I remembered that this thing existed, so I spent the 10 minutes to like format it nicely into a tweet to show the before and after. That was like a really helpful thing because it, I think it got something like 7,000 likes, like it, it spread pretty far beyond the people that typically follow me. And I do think like there's the audience building aspect, which I do think, like I mentioned, even if you're not trying to sell a course, it's still useful cuz it grows your network and you never know when those connections come in. [47:20]

But, it's also just really good for organizing your own thoughts, the same thing as true of teaching. You realize what you don't understand when you try to explain it. Like you might think you have a pretty solid grasp of something, and then someone asks you a question and you open your mouth and all of a sudden you realize that there's this gaping hole in your knowledge. Like you actually can't explain it as coherently as you thought you would be able to. [47:40]

And learning in public gives you a lot of the same benefit. Like you go to tweet something, and this is something that happens to me too. Like, I'll tweet something that I just discovered that I thought was cool, and people will ask like deep questions that like, I don't know, I just found out this thing existed. But it's a good question! Sometimes I'll just say I don't know, you, if you find out, let me know. But, if it is something I'm interested in, that gives me the impetus to do the digging and to answer it. And that's something that, you know, I wind up benefiting from that because I answer that question. [48:08]

Carl Vitullo: Yeah. Yeah. I can't remember if this is the right term, but, concept of, paradox of expertise, I think is maybe it, where as you become more expert in some domain of knowledge, you become so immersed in the jargon that you lose the ability to communicate that knowledge to others because, you know, your your fundamental building blocks that you have your mental model based on are so specialized that other people can't even follow what you're saying. [48:38]

Like blogging and trying to communicate things; it's a good exercise because communication is such a influential aspect of anyone's career. Even if you're not a professional educator, justifying your ideas and convincing other people that your solution is correct or good in some dimension So, yeah making small efforts to communicate what you know to others, I think is just so beneficial. Even if you're not trying to become an educator or trying to build a personal brand. [49:06]

Josh W Comeau: There's just so many benefits. Trying to explain something changes how you think about it. What you're saying is totally true. It's hard to remember what it was like not to know something. If we imagine like the connections into your brain as like paths through a forest, right? People walk the same path over time and so that gets worn down there, you lose the ability to wander off that path. Like you get stuck in these thought patterns and explaining things, teaching people, sharing things in public is a great way to veer off that path. [49:33]

Carl Vitullo: Get off in the weeds. [49:34]

Josh W Comeau: Yeah, exactly. That's a good way to say it. [49:36]

Carl Vitullo: Yeah, that's a really nice metaphor. I like that a lot. [49:38]

Josh W Comeau: I just came up with it. So that's. Usually I have to prepare these things. [49:41]

Carl Vitullo: Nice. We are just a little bit over time here.

AI's impact on web development [49:45]

Carl Vitullo: Maybe one last quick question from that same post in the chat. Do you have any opinions on AI and whether it's going to destroy our future careers as software developers? Is that something you think about? [49:56]

Josh W Comeau: I have a bunch of thoughts. I do think that it will make redundant some of the things that we do as developers, right? Like, I think that's been true of pretty much every new technology that comes around. I struggle to imagine that we'll ever get to a place where someone will type in, like build me an Airbnb application, but for dog rental and like, it'll spit out a fully functional app that not only will do exactly what you expected in what you intended for it to do, but will be modifiable by you, it just strikes me as like not something that's around the corner. Honestly I think the bigger disruption is things like Squarespace or Webflow. [50:36]

I think that has probably already disrupted many, many of our jobs, right? I imagine it used to be that if you're like a bakery or a dentist and you want a website, you have to like find someone and pay them. Whereas now you go to Webflow and you find the template that you like and you fill in the information. [50:50]

I think that's a wonderful thing because it means that small business owners are no longer required to spend tens of thousands or hundreds of thousands of dollars hiring a team to do this. But it also means that like us developers can work on more interesting, challenging projects like. I imagine I would probably feel bored if I spent a whole career building static landing pages for similarly kinds… it just seems like it's, there's not a lot of variety there, and that it wouldn't challenge me as much as some of the work that can be done now that can't be done in tools like Squarespace or Webflow. I don't think our jobs are going anywhere, anytime soon. I do think that these tools will make some of our jobs easier, and will make some of the work that we do… it'll free us up from the more rote parts of our job and let us spend more time on the challenging problem solving design type stuff. [51:39]

Carl Vitullo: I think that's exactly my take on it as well. It's just another tool. And our jobs didn't go away when Squarespace and Webflow came out. It just changed and evolved. I think I agree with you a hundred percent on AI's influence on our job as well. Yeah. [51:54]

Well Josh, thanks so much for coming out. It's been really great chatting with you. [51:57]

Josh W Comeau: Oh, the pleasure's all mine. This was, this was a lot of fun. I hope it was uh, useful or interesting in some way. [52:02]

Carl Vitullo: Yeah, absolutely. Yeah, we'll sign off here. Josh has more courses coming out, so check it out at joyreact.com. Thanks so much.

Tejas Kumar

Reactiflux — Wed, 25 Jan 2023 16:00:00 GMT

Introduction

Carl Vitullo: Tejas, thanks so much for joining us. Excited to have you. I know you have worked in developer relations for years. You've worked at companies like Vercel, Xata, G2i, Spotify, and you're now working independently as an educator and content creator. [00:13]

Yeah. Anything else? Any major points that I missed? [00:16]

Tejas Kumar: No, you got it man. That's that's a great introduction. I like how short it was. It's it's nice. Now we can get into actually a nice conversation. [00:24]

Carl Vitullo: heck yeah. Yeah. Maybe we can start off with, I know you are currently starting a company and it's a little bit too early to get into the fine details of it, but Yeah. Why are you starting a company.

Why are you starting a company [00:35]

Tejas Kumar: That's an excellent question. And I found, I, I really don't do it lightly because I know that nine out of 10 companies fail and all of this. But I feel like the stars kind of align for one, I've wanted to do this for years. And two, I, I don't know if y'all have had Sunil Pai on this on this like discussion office hours thing. [00:54]

Carl Vitullo: We haven't actually. I'm familiar with him and he's an incredible person. I followed him for years. He's great. [00:59]

Tejas Kumar: Yes. I highly recommend. Let's, we need to make that happen because he's, especially now, he's doing the same thing, right? He's. He started a company called Cool Computer Club. He's building something awesome called Party Kit. And he took me aside in November in a tech conference after I had quit my job at Xata. [01:15]

And he said, listen man you are in a very special point of your life right now because this is one of the rare occasions where you'll have literally no job and all the time to do all the things you've ever dreamed of. Also I've worked for the last 15 years nonstop. I've been an, I've been an employee for the past 15 years without a break. [01:32]

And in those 15 years you come up with dreams and things and you hear, more importantly, you hear about the pain that companies have. And my most recent role in Xata as the director of developer relations, I got to see the pain that a lot of companies have to endure doing developer relations. [01:50]

And then I became an angel investor last year and, got to see like from the cap table perspective how hard DevRel is for companies, firstly to hire great people, and either there's not enough talent or there's not enough talent that the companies are willing to pay for. You do get great talent at a very high price. [02:07]

And so companies will end up like maybe hiring like less than that price. And they might hire inexperienced people and then it's, DevRel is so young that it hasn't really been codified very well. And so what happens is either the person doesn't perform according to the company's expectations and they let them go. Or the company uses the vague role of DevRel to overwork people and overwhelm them, and both ways. One of the sides, if not both, has trouble. So I've seen this pain and the company I'm starting aims to codify and fix what we think of DevRel and really help companies get the most out of DevRel. So I'm really excited about that. [02:46]

Carl Vitullo: Yeah, that makes a lot of sense. I think of DevRel as being, it's one of those things that I think now a lot of teams, especially companies that run like SaaS products or otherwise have developers as one of their target customers think of it as something that, they need to do in order to develop their business. [03:04]

But I think the finer points of "what does it mean to start a developer relations program" are not well understood. So is that sort of the niche you're look, you're looking to explore? [03:14]

Tejas Kumar: Exactly not just looking to explore, but looking to surf. Is this exactly, that is companies one thinking about do you even need DevRel and two if the consensus that you do, which we're seeing by the way, just a massive like hockey stick style growth of dev tools companies these days as well. [03:30]

DevRel and community are immeasurable [03:30]

Tejas Kumar: And chances are most of them need DevRel. But then, how do you go about doing it? A lot of people have no idea how to measure DevRel. In fact, you'll see a lot of conference talks, even some by me, where people, they try to answer the question, how do you measure dev? And the answer they come up with is just don't because they say it's immeasurable. [03:49]

Carl Vitullo: Yeah that's something that I feel, deep in my heart and soul about. How I've thought about community is, there, there are a lot of metrics I could track in running Reactiflux, and I, there are metrics that I do track, like number of active members week to week or whatever, that's information that I use to inform I don't use it as a target. [04:09]

It's not oh no we lost 15 active members. We need to bump those numbers up. And, too often people try to come up with metrics and then those metrics become the only thing that matters. Yeah I definitely I relate to what you said about just don't do it, don't measure. As soon as you start measuring that, those become the target that becomes, reason to do it. And the reason to do it is so much broader than those metrics. [04:34]

Tejas Kumar: Exactly. And it's so interesting you say that because the word relations isn't the name dev relations. Imagine if you took your relationships with your friends or your close, family even and said what are the goals for this relationship? How do we, that's immediately a turnoff in most relationships because it, it ends up like commoditizing the people. [04:56]

And I've, this is one of the mistakes I've seen companies make is they, through whatever wacky DevRel measurement process they'll try to come up with, they turn people into commodities or assets to be exploited. And that deep there's a lot to be said about devaluing people with that, but I think that's a big criti that's a big factor. [05:16]

And I think the solution to it is to recognize, okay, this is something that has a lot to do with people. And in many ways it's, it has parallels. I would even say with politics. Like a politician's approval rating is very similar to a dev tools company's approval rating among developers. And so you have to go at it from that campaigning angle. [05:34]

Like you, you don't see like presidential candidates just outright, saying, Hey, what's the, like what's the goal of campaigning? They'll probably have those conversations behind doors, but they're trying to really connect with people on a very real level. And I think that's where DevRel stands. [05:51]

Extractive relationships in DevRel and community [05:58]

Carl Vitullo: Yeah, that makes a lot of sense. And it, something that I've said and thought about a lot is in, in community, and I think also within developer relations, one of the things you can optimize for is engagement. Who's reacting, who's participating. But as soon as you start trying, as soon as that becomes the goal, it's it incentivizes you to do a lot of things that I think are harmful to the broader picture of it, to what like you said, to forming relationships with these people. [06:21]

Like I think one of the common approaches to build a community when companies try to do it, is just to do things like giveaways or, raffles. and it just sets up this like transactional exploitative nature of this relationship, which is just it just poisons the well, and as soon as you start from that place, it's so hard to claw your way out and get to authentically and deeply connecting with people. [06:47]

Swag and broken trust [06:50]

Tejas Kumar: Yeah, exactly. This is where, so at Xata, I'm really proud of this man at Xata. When, where I was leading DevRel. We had the best reputation on any conference sponsor, booth floor. And that's because we had a lot of swag to give people. And it was also the most inclusive swag. Like we had earrings, we had like t-shirts in both men and women's cuts, for example. [07:10]

And people showed up and it was really interesting. They were like hesitant to take the stuff we just openly wanted to give away. And when we asked them why they said they, they were just surprised that they could take it. They were like they said to us, oh no, these other companies with booths they asked us for contact information in exchange for this water bottle. [07:26]

And they looked at us in disbelief. They're like, wait, so we can just have it really? And they're like, yeah, can I have two? Sure. Because we don't we spend the money. We got these things. We don't really care about, extracting money and contact information from you. We want to genuinely give you this because we want to bless you. [07:41]

And if you either use our thing or you don't, that's secondary. We can talk about that later. So this, what does this do? Already sets the groundwork for a healthy relationship. It's look unconditionally, we're gonna support you. And if you want to, if you don't want to support us, that's fine, but that builds way more trust than something transactional like you were talking about. [08:00]

So thinking through these really high level things and working with companies to train their DevRel people to think at this level is what my new company's about. [08:10]

Carl Vitullo: Very nice. Yeah. Okay. I like that a lot. Yeah. And it's even just hearing you tell that story, like those people, those companies and groups who approach the relationships from that sort of transactional nature, I'll give you this if you give me that. Like it doesn't just poison their own well, it sets a standard that people then come to expect from all companies doing that. So yeah I could see how there's a lot of value in getting people to do it well, like not just for those companies, but for the whole industry. [08:40]

Tejas Kumar: Exactly. And can you imagine an industry where all of the dev tools companies compete with each other on who can best serve their developer communities and who can best bless their developer communities. What's awesome about this? Through that competition, developers win, a lot. And that's what I'm going for is what's best for developers and developer communities at the cost of companies that can afford it. [09:02]

Carl Vitullo: Yeah. Okay. I like that a lot. [09:04]

Transactional relationships [09:07]

Tejas Kumar: With Reactiflux, right? Like the, I'm sure like talking to you about this, you've got the same passion, I would say for developer communities and giveaways and wellbeing. I guess I don't see anything transactional in Reactiflux almost ever and what I do see is a lot of, service to the community. [09:21]

So it sounds like you would have resonating thoughts about that. [09:25]

Carl Vitullo: Yeah. Trying to not be transactional is one of the reasons I try and do events like this nobody, no money is changing hands here. We don't have any sponsorship for these events. We just, I just try to reach out to people who I think will have interesting things to say and who I can have a good conversation with and benefit the members who are interested in tuning in. [09:47]

It's interesting to hear you say that you think of this as a very non-transactional space, because I actually think of it differently. I think that one of the struggles we've had at a, community level is that 95% of the members, the only way they participate is by asking for and providing help, which I think is a very transactional relationship. [10:08]

It's, you have a problem, you hop into, Reactiflux, you ask, and in a couple of hours you've had a conversation. Cool. Thanks. Bye. Trying to break away from that sort of hop in, hop out, transactional help is, has been one of the things that I've been, I don't wanna force a change, but just trying to provide opportunities for deeper relationships to form and doing events like this, I think is one way that we can encourage that, so this is we do some office hours. [10:38]

I'd like to do more office hours where we get community members just talking about their experiences. As well as, I thought I've had recently as refocusing events where we have external guests coming in like you and position those as a "community spotlight." Here is somebody who we, I as a community leader think is doing something really great and deserves a little bit more recognition. [11:03]

Tejas Kumar: Wow. Thanks. It's a nice compliment in there. I appreciate that. [11:08]

Carl Vitullo: Yeah. You said in, as we were preparing that one of the reasons you were think you were interested in doing a company was to not be one of those people who keeps talking about one of these days doing something. [11:21]

Can you talk a little bit about that? [11:23]

Fear about trying something new [11:28]

Tejas Kumar: yeah. I've been a part of this discord for a while though I haven't really asked for help or anything. But I feel like everyone here, the 80 plus people that are here have the ability, through code, to build literally anything we want, any software we want, any app we want, right? [11:39]

I'm sure there's in the room, over a hundred people in the room. There's potential and ideas like, oh, I wanna build this. Oh, I've been dreaming about this one app and this, but we don't do it. And I've fallen afraid of that myself, where I working in DevRel for as long as I have, I've seen so many pain points and so many things that I think could be improved. [11:58]

And I spent the past year 2022 working in this space and kind of just complaining oh, if I had a company, I would do this differently. Oh, I would what was I'd hire all the women and people of color and fix the state of, inequity and all this stuff. And it's, I find it, what I was saying earlier, it's very easy to like shake your fist at the sky and say these things. [12:16]

But when I thought about actually doing it multiple times, I immediately felt fear. And this fear immediately made me back away from it without actually backing away from it. It made me, and this is something I don't know I'd love to hear if you can relate. It made me back away from it. But still at the same time feel like I'm doing something towards it. [12:35]

It's so weird, Carl. What I mean by that is I quit my job, right? And I thought, as I mentioned, Sunil Pai told me, "hey, you're in a great time to do that thing you've been putting off." So I said, great, I'm gonna do it. But then I'd start to feel the fear and then I'd be like, you know what? No, I'm just gonna take a job. [12:51]

I'd call CloudFlare. I'd be like, Hey, I heard you're hiring developer advocates. Can I and that would happen over and over again to the point where I got really frustrated with myself. Why do I keep applying for jobs I have this dream? And ultimately it took some reflection when I realized, listen It's better to try this thing, to build it, maybe fail than to not try at all. [13:14]

And that statement is really what cemented me to start building this thing. And you know what? It probably will fail Carl. Nine out of 10 startups fail. And that's, I don't think that's a bad thing. I feel like it's, it gives you closure. When I was a younger single guy there was this whole thing about oh, let's see if I can talk to this pretty girl at the thing. [13:31]

And a lot of guys were afraid of rejection. But like on the other side of that, Quote, unquote, failure at the time when you're a young man chasing women is oftentimes a feeling of Hey, wait a second. I did that and I tried and now I'm not gonna spend the rest of the day regretting that I chickened out. [13:49]

So that's what's really the driving force here. And I feel like there's people here who are similar, who feel like an inkling of entrepreneurialism, but it's snuffed out by fear and also by people around them telling them, oh, maybe, pay the bills with this or that. [14:03]

And and full disclosure, like it's very risky and I'm watching, my family finances go down day by day every day that my company doesn't make money. But it's part of it. It's part of it because I feel like in tech we have this bubble where like we just take our money and, react front end engineer salaries for granted and everything's. [14:25]

Given, you know what I'm saying? And to be able to be able to feel like human things once in a while. It's very exciting. Anyway, sorry I'm ranting a bit, but hope that answers your question. [14:35]

Carl Vitullo: Yeah. No, I think that was a great answer that I there's so much to respond to there, to in there. I really deeply and viscerally feel what you were saying about the fear of starting a company… actually taking a real shot at it is so hard because, it probably will fail. Most people who try something new do not replicate their software developer salary in the first year or even in the first five years. [14:58]

Tejas Kumar: Yeah. There's the other side to it too. There's the other side where you expect to fall, but then you fall in reverse AKA flying. And this happened to I don't know if y'all have had James Q Quick on the channel. [15:10]

Carl Vitullo: We have not, I'm familiar with his name. [15:12]

Tejas Kumar: He was, he's been a developer advocate for most of his career I'd say. And he was working at Planet Scale, so a direct competitor to Xata at the time. That's how I know him. And he got laid off, dude. And he got laid off and he, again, he was in the same place I was without a job, and he was like, I'm and when he got laid off, I was working at a competitor and I messaged him instantly and I said, oh, you got laid off Mr. Competitor, come work for us. We'll treat you good, right? And he said, yeah, cool, cool. I'll get back to you. But first I've been dreaming of being a YouTuber for such a long time. [15:44]

I wanna just try this YouTube thing. I wanna be a full-time content creator. See how it goes. We'll probably fail, but whatever. Carl, like within the first year being a content creator, he made basically his salary back just doing it. Exactly. And that's, those are the stories we need to hear more of because I think, we hear too much of the negative and it's probably good cuz it protects us, but there's also the other side. [16:06]

Carl Vitullo: Yeah. Yeah. I do. I've been listening to a podcast, People I Mostly Admire, which I would recommend. It's really great. It's from one of the authors of Freakonomics. And one of the points that he hits on in a lot of his interviews is, "talk more about failure." Just because fail, it's so common and there's so much you can learn about things that don't work. [16:29]

Like, why didn't it work? Was this, a, what are the specific details about this attempt that made it not work? And really just normalize that yeah, you know what, you try something new, you try something hard, you try something out of your experience. And yeah, it probably won't go well but you learn something, you get better at it and you can try again later. [16:49]

Tejas Kumar: Exactly man. And that learning it's for one, like from, so I'm currently living that, Carl, I'm in the middle of that, right? And it's exhilarating. It's like learning how to deal with dude. I wrote an SOW myself the other day, like a statement of work. [17:04]

Carl Vitullo: Yeah I'm in the same boat. I'm writing those too. [17:07]

Trying something new; an exercise in empathy [17:13]

Tejas Kumar: Dude, it's nuts. spent three hours writing a 13 page contract thinking, oh my gosh, I better hire someone don't know, it's just exhilarating not knowing where your next paycheck's gonna come and working I'm reminded so I grew up in a Muslim country and I'm reminded of, I, if there's any Muslims in the audience, but I'm reminded of, Ramadan from the Muslim it's this thing where you for an entire And the reason they do it, they They don't eat like from sunrise to sunset, which in some countries closer to the poles where a day is 14, 16 hours, it's pretty wild. And they do this for a month. and I was wondering why when I was younger and they said it's because we want to feel what people who don't have a lot feel, it's literally, it's a month long exercise in empathy. And that I think is pretty cool. [17:50]

And that's exactly where I think we both are because it's not to say we're I've been an employee in a startup. I've been employee number six. I've been an employee at a large company like Spotify. I've been an employee at a mid-size startup like G2i. [18:02]

What I've had in common with all these roles is I've worked with founders, but I've never been a founder and I've never been able to empathize with the things they have to deal with. Then this is what I'm talking about, like an exercise in empathy that way. it's nuts, man. I will probably never speak ill of another founder ever again. [18:19]

Carl's past failed company [18:25]

Carl Vitullo: Yeah it's a hard life. It's, it is just full of so many challenges. I'm in a similar sort of spot. I've been working independently for the past year trying to do community and technical community consulting and yeah, it's, this is not my first company that I founded, but going back to what you said about feeling the fear to get started the last time I started a company was like 2014 or 15, and I was trying to do a subscription box service with my partner at the time. [18:50]

Tejas Kumar: Nice. [18:50]

Carl Vitullo: like we did it for about a year and a half and ended up shutting it down and just I learned so many things through doing it badly. Oops, I didn't file all my taxes right. here's a two grand in IRS… scary letters from the IRS are not fun. But, I, so I did it badly once and then I spent six years working at companies and not trying again. [19:11]

But then that experience of having done it so badly and failed pretty hard just gave me, when I started thinking about it again and okay, I wanna take, I wanna do it seriously this time. What does that mean? It just gave me, it shoved the door open, just that little bit much wider where I understood more about what it takes and how to do it right. [19:30]

Tejas Kumar: you're, you're in a similar place now. I, you may or may not be starting something, but you're, you've been independent Do you feel like you might lean towards putting that, into putting those things you've learned in practice again, [19:42]

Carl Vitullo: Yeah. I am doing that a little bit right now. I, but more in the consulting work than building. I don't know. I think of consulting very differently from building a startup, building a company. Yeah. But another dimension of it that I'm just really enjoying is the freedom to pursue self-directed goals. [20:00]

I think that is just such a great aspect of working independently or trying to start a company is needing to take stock of short-term goals. Okay, where does the next dollar come from? What is work that I can do right now that will get me closer to that next dollar, but also set up something bigger down the line? [20:19]

Tejas Kumar: yeah. So you think short and long term at the same time? [20:22]

Carl Vitullo: Right. It's so challenging though. [20:23]

Tejas Kumar: Yeah. No, I agree. I, what you've done for me, Carl, in this discussion already, which I'm super thankful for, given me confidence that failure isn't that bad. I'm full disclosure, man, I'm terrified, but like talking about how you failed with this tax stuff and you took a job and it was fine, and then you tried again. That's It's a bounce back story. [20:41]

Carl Vitullo: Yeah, And I mean ultimately we work, we all work in tech. We have a lot of skills and I think that is, so freeing in a way that like, yeah, there's always something to fall back to if doing something on your own doesn't work. There's always other jobs. [20:53]

Tejas Kumar: Yeah. And I feel like that's a really good encouragement to the people listening. Is there's always, especially in a community like this, there's a job board here in Reactiflux, you know what Carl, that's where I'm if everything fails and I need a job straight to the job board. [21:06]

Carl Vitullo: Straight to the job board. There we go. I didn't really expect to get so deep into entrepreneurship and whatever on this, but I'm glad we did. [21:12]

Tejas Kumar: Me neither. I do feel like it's, I don't know if it's interesting for the people, I mean with the name like Reactiflux, I expect us to be talking about react and things which not complaining. I could talk about entrepreneurship all day. Especially cuz it's currently my whole personality and adventure. [21:28]

Carl Vitullo: Independent content creator. But yeah. Let's bring it back a little bit more into the technical side of things.

New web technologies you're excited for [21:34]

Carl Vitullo: What are some new technologies that you're excited about in web development? In the web space? [21:40]

Tejas Kumar: Ooooh. [21:40]

Carl Vitullo: Big question. [21:41]

Tejas Kumar: That's an excellent question. That's a great question. So part of my independence from employment is starting a YouTube channel. And this answers that question in a broad context, but I'm not gonna be one oh, just click the link and go to my YouTube type of answers. [21:55]

A lot of people have asked me actually about this YouTube channel, like, why are you starting it bro? Theo and there's Primagen, there's all these YouTubers already. [22:03]

Carl Vitullo: Crowded space. [22:04]

Tejas Kumar: It's a crowded space, but I feel what I'm, what my intention for YouTube is not really to create tutorials. [22:09]

There's plenty of coding tutorials and they're awesome, but my intention is to like, talk about tech that I find in the web and not just talk about like we just did with the entrepreneurial stuff. Like deeply review them and discuss their trade offs, and what's exciting and what's worth it and why it's exciting and so on. [22:26]

Zod and tRPC, type safety on network calls [22:27]

Tejas Kumar: To bring it back to your question, one of the videos I'm currently working on is a video on, Zod, have you heard of and used Zod Carl? [22:34]

Carl Vitullo: Oh, I've heard of it. Is that's the like validation library, sort of like, Yup or Joi [22:39]

Tejas Kumar: It's like that, but more, and that's why I love it so much. It does do validation of types and ske and json. If it's an object, you'll do validation on schema as well. But it also pairs perfectly with TypeScript such that you don't have to write types and TypeScript anymore. [22:54]

You just do type of whatever your Zod thing is and you get a TypeScript type just for free. [22:59]

Carl Vitullo: Wait that's pretty cool. [23:00]

Tejas Kumar: it completely changes way you, it works as a source for your types, which then you take and plug into type native things like tRPC, to generate like APIs and things. [23:10]

And then what you've end up, what you've ended up creating is a completely end-to-end type safe client server relationship, but also at runtime, not just build and compile time because Zod validates on the run time. Your apps are just way more robust with Zod and tRPC. [23:27]

So I think those two are technologies in the front end space that I'm, and in the backend space because they're I'm quite excited about those as full stack holistic TypeScript technologies. [23:36]

Carl Vitullo: Yeah, definitely. Yeah. I think that tRPC was the context in which I had have heard about Zod most. Yeah. And I've been hearing for years about generating types off. API schemas, I think the first person heard talk about that was Jared Palmer back in like 2017. He was, generated a GraphQL schema and then used that to create types for the front end consuming it. [24:01]

And I just remember it was like a light bulb, like mind explosion moment. Like, wait, you can do that. Holy shit. I can, prevent my app from shipping a breaking change. What!? So yeah it's cool to see new approaches to that. [24:14]

Chronological Snobbery and jQuery [24:18]

Tejas Kumar: Yeah. I also the code gen route is actually, gosh, I'm, so there's a term one of my favorite authors CS Lewis uses, he calls it chronological snobbery . That's when we look at the past and go like, oh my gosh, that's so primitive. You know? Some of us would look at jQuery and talk about it like that. [24:32]

Oh my gosh, jQuery. But jQuery still runs most of the web. It runs more of the web than React But what I'm about to say sounds very chronologically snobbish. But, this like Graph QL code gen type stuff is no longer the premier way, no-breaking-change, type-safety, API server and client like it, it just isn't, because… [24:53]

think about it, right? Like you, you have your terminal talk to some server, do an introspection query, and then generate files on your file system. Those files can be out of sync with the server and you have to work on some type of like Chokidar, like watcher magic to make sure that when you save the code is gen. It's clunky because there's so many moving parts. Whereas tRPC, is all of it. tRPC does the schema description exactly like GraphQL and it also exports for you a data fetching library that's type safe using your description and has runtime validation with Zod. It's taken the best of this graph ql code gen stuff, and like evolved it to 2023. [25:35]

It's quite exciting. In fact, again, I have to thank you Carl for this discussion because it's basically writing my next YouTube script for me. [25:42]

Carl Vitullo: Great. Yeah, no I, tRPC is definitely, I haven't I haven't yet had occasion to use it, but it's definitely top of my list of tools to reach for. [25:52]

React as a middle aged man [26:02]

Tejas Kumar: Yeah. tRPC and Zod. About what's exciting also, I think there was an awesome tweet, man. Have y'all had, I'm about to ask you if you've had another person on this Feel free to feel free just to know, but have y'all had, Jani Eväkallio on this, on, on [26:05]

Carl Vitullo: Oh no we haven't. I'm familiar with him though. He worked at Formiddable Labs for a long time and is, I think he's also doing an entrepreneurship thing right now. [26:13]

Tejas Kumar: Yeah. He's got a, AI writing tool, which is phenomenal. I bring him up because he tweeted something today that was hilarious. I thought it was so good that I retweeted it. He said React is in its middle-aged man era. It's at the top of its economic productivity, but culturally completely irrelevant. [26:32]

At the top of its economic productivity, but culturally completely irrelevant. I thought that was hilarious. Because React is exactly that. It's not maybe completely irrelevant, it's just this like mature thing that cool, it exists, but it's not really as sexy as it once was. [26:49]

Carl Vitullo: Right, it's not the, hype generator that it was, five years ago, five, 10 years ago. [26:54]

Tejas Kumar: Yeah, exactly, because like server components is this huge shift and it's a massive one, but people don't seem to care as much as they did about hooks. [27:03]

Carl Vitullo: Yeah. That reminds me of years ago when I was at, working at my first startup, I read, I, I can't remember if it was like a TechCrunch article or just like a blog post, but it used the metaphor of a clock face to talk about startup life cycle. [27:19]

And it really, it put this idea in my head that I've seen apply to all sorts of things, and I think that's a good example of it, where, early in something's life. It is, it's the darling, it's the, everyone loves that. Everyone's so excited for the possibilities. And then over time as those possibilities get explored, and some of them pan out, some of them don't, the energy drops and like skepticism comes in and then like later on as it gets older and starts to fade out of relevance or hype, then people start cheering its downfall. And I don't think react is quite into the cheering its downfall phase of that, but it's certainly into the the phase of its life where it's getting a lot more skepticism than it used to. [27:59]

Tejas Kumar: Yeah, but I think part of that comes from the same reason why there is so much hate on JavaScript. And Ja for example, like I could literally open my console right now and type for you JavaScript type of null. And the type of null is an object, right? And oh my gosh, that's so stupid. [28:15]

React compared with Qwik's design goals [28:27]

How can null be an object? I And JavaScript will still have some hate, but there is no arguing with the fact that it is the best language, the only language of the web so I feel like React is there, React is locked into its own design and unfortunately, It's design is outdated. [28:36]

It's design does not allow for some of the sexy new stuff we're in libraries like Qwik and Solid, because it was not designed for that. And you have things like quick coming in this ridiculous level of code splitting where a pool of workers can in unison, collaboratively hydrate, not even hydrate collaboratively, send different parts of your website to the browser pa in parallel. [29:01]

Carl Vitullo: Oh, interesting. [29:02]

Tejas Kumar: Nuts And yeah, it's absolutely nuts. And react can't even come to this zip code because it was never designed for that level of code splitting and distributed So I think that's losing its sex appeal cuz there's plenty of sex appeal being had in newer things that are able to be designed for modern architectures, [29:19]

Carl Vitullo: yeah. That's interesting. I haven't, I've heard of quick, but I haven't really dug into it before. So that's a new description to me. So it, it uses cloudflare's edge workers, that sort of technology. [29:31]

Tejas Kumar: It can use that. You know react, when you ship, react to a user. What you're shipping is React js, the, that's the browser, like React library. You're shipping React dom, which is massive, which is like 200 kilobytes. And if it's a NextJS site, you're probably also shipping like the NextJS run time. And if you use get static props, you're probably shipping like a huge bunch of json. You're shipping a lot like the JavaScript you'll multiple kilobytes, sometimes hundreds. [29:55]

Qwik is one kilobyte constantly, always on first load, actually less. Because it's so small, they inline all of Qwik directly into the HTML that you serve. And then how it works is when you hover over something interactive, or rather, when you interact with something interactive, let's say for example, you have a button that has an on click callback. At build time quick will wrap that callback with the dynamic import to the file that contains the callback. [30:24]

So you write code that looks just like react, but at build time Qwik will split out closures like from on click handlers into separate modules. It'll replace your on click handler with a dynamic import of getting that on click handler. So then your user, enjoys the one kilobyte first load clicks on a button, which triggers a dynamic import of this other module. And that then pulls that down the wire and then your call back. The page rather the JavaScript bundle slowly grows as people use your thing as opposed to everything upfront. And the benefit is if a user never interacts with something, they never download the code for it. [31:04]

Carl Vitullo: Yeah that's I'm thinking of optimizations I've done to add code splitting on, by a page or by a feature or something like that. That was all a manual work. I had to figure out where the seams were and like, and analyze like what was coming and where to figure out where a good seam to introduce was. [31:20]

Okay, so quick does all of that– [31:22]

Tejas Kumar: Automatically. [31:23]

So when you're talking about finding the seams, right, Carl? I feel a big deterrent to code splitting and React is, closures. In the body of a function component, if you have use state at the top, then In the component's return in the JSX tree you have on click and you have something that uses that state variable from outside the scope of your function. You can't code split that because it's using something outside its closure. So Qwik does that, it does like compiler level magic to put the closure and the outside state together in some file that is lazy loaded And it does all of that for you. And it just like splits literally everything. [32:04]

Carl Vitullo: Okay. That's very cool. Yeah, cuz one of the sort of, I think of it as a failure mode for optimizations I've tried to do with code splitting. It ends up where, okay cool, great. The code for this particular page is loaded asynchronously, but the only code that is only used on that page is like four kilobytes. [32:25]

Okay, great. You're, you've cut four kilobytes off your initial load, but now you've introduced more latency when people try to get to that page. So it's a wash. [32:32]

Tejas Kumar: That's why I'm so excited about Quick also, by the I'm not like here trying to evangelize quick, we kind of just drifted at the topic, but I feel like, builder io, so the people who make quick, this is their like, full-time job to think about all this stuff that we tried to think about and I've pressed them hard. I've spoken to the guy in charge and I was like, okay, dude, but I get that one kilobyte first load and my, my internet connection dies. Then I can't even click on your button cuz it's all dynamic, it's all lazy, loaded. And he looks at me and he's like, no dude. And I said, explain. [33:00]

So when it loads that first kilobyte it also has a manifest of things to prefetch. And as soon as you get pixels on the screen and that first paint, it immediately starts prefetching all of the other modules. Not only does it prefetch all of the code split modules in the background, so not blocking it also prefetch them in an order of likelihood to be interacted with that it calculates. [33:26]

Carl Vitullo: Do you know if that's like part of the runtime, is it will do, like realtime monitoring of what people are interacting with and update that priority list. They do. [33:34]

Tejas Kumar: think, I think it is right now, I think that's why it's beta, because that's pretty hard to get right. I [33:39]

Carl Vitullo: Yeah, that's a hard problem. That's interesting, huh. Okay. That's very cool. [33:43]

Tejas Kumar: Yeah. Exactly. And since everything is code split, I think the really cool thing is you could serve different parts from different workers all at the edge and get these, like of trademark, blazing fast load times. And so when you have all of this innovation in the UI space and you look back at React, it's this tweet from Yani about React being this middle-aged man that's not so relevant, but at the top of its productivity, I think is just on the nose, like on hammer on the nail. [34:12]

Carl Vitullo: Another thing I'd love to talk with you about is, I know you're working on a course platform, is that right? You and Sara Vieira. [34:22]

Tejas Kumar: Sarah and I are building this thing because we want to empower people to make great stuff and profit from it. And also we want to empower the people who download and buy these courses to enrich their careers. I feel like in some way it's a direct competitor to egghead. [34:39]

But one thing about me, Carl, I, I hate competition. I I'm the most anti-competitive person on earth. it's not like I hate the people that compete against me. That's not what I'm saying. I hate the notion of competition. I think it's a scarcity thought. [34:52]

And I'm more instead of saying, we compete, I prefer to say we complete the landscape. And so we do the course platform is basically egghead, but in many ways, less curated. Like If you've tried to teach on egghead, they'll send you like a microphone and they have like guidelines for how you can do a course I feel like they should, because there's so many instructors. We're going about it by being a bit different. Instead of. Opening the net really wide to everybody initially being an instructor and then policing them with, you know, use this microphone and speak this way. [35:27]

We're just gonna be pretty casual about it. Hey, you want to teach? Here you go. You have a basic webcam and mic. Awesome. Good luck. And give them the tools and the training and whatever they need as teachers ourselves. And then say, good luck. Sell your course for whatever you want. Use whatever you want. We'll support you. And also an to try and empower people who aren't well represented in the industry as Like women and people of color, like if they wanna teach giving them the best skills and tools to do that, and creating a platform on which they can sell their courses. [35:58]

I've heard from a lot of women actually who want to do courses that. Like on YouTube, for example, like, oh, I would love to teach on YouTube, but I'm scared of the comments I'll get from people. [36:09]

Carl Vitullo: Oh, yeah. [36:09]

Tejas Kumar: So creating a platform where that's and allows people to feel empowered instead of intimidated is something that's important to us. [36:17]

Carl Vitullo: I've seen a lot of independent educators building their own their own platforms. You I'm thinking of like Matt Pocock and, Josh Comeau, both developing their own educational platform rather than going to somebody like Egghead. So, is is, is that the sort of creator you're thinking of serving more, or is it a little bit more similar to Eggheads [36:39]

Tejas Kumar: No, these people are famous. also Pocock is not doing his own platform. Is teaching. He's partnering with Badass Courses. [36:47]

But yeah, no, Josh Comeau is, in my opinion, Carl, Josh Comeau is like the best educator I know. He's up there with Kent Dodds. I respect Josh immensely because of exactly that. Like, he'll build the platform. He puts so much care into it. Like he makes these like awesome 3D graphics go. It's just beautiful. Like nobody can disagree with the fact that it's just stunning work. [37:11]

Not necessarily Josh as well, because Josh has, the passion, the drive, the skills, the everything [37:18]

Carl Vitullo: He'll build everything he needs. [37:20]

Tejas Kumar: We're after the people who, feel like they could but are maybe not fully confident in themselves. We're after the kind of people who, like if you go to them and say, I believe you can sell a bunch of courses cuz you're very smart. They would look at you and get shy and be like, oh, I don't, I doubt that I'm skeptic. [37:37]

So people who like doubt the people you want to help sell courses. And the cool thing is we're building it using, react NextJS. We're doing it in public over live streams every so often. We had one today, I'm exhausted. It was a like three hour live stream. But yeah, we're doing it in public to show people listen, like it's, we want to, do it in public to, to show people how much we mess up and hate the fact that sometimes doing auth is hard. [38:02]

Carl Vitullo: Right. Yeah. That's funny. I feel like authentication is one of those things, everyone needs it, so it can't be that hard, right? No, no. It, it's hard. [38:10]

Tejas Kumar: Yeah. And oftentimes it's because of the silliest things. It's like, Oh, I forgotten my dot or I put something in my dot N, but I forgot to restart the dev server or something like this. [38:19]

Carl Vitullo: Classic. Okay. Yeah. Very nice. I love the, uh, the build in public ethos. I think that makes a lot of sense for a course platform as well. [38:27]

Tejas Kumar: Yeah, [38:27]

Carl Vitullo: it's kind of dog food to your own process. Show what producing the content looks [38:33]

Tejas Kumar: exactly. And the cool thing is once we're done with that, the platform's just gonna be open If anybody wants to take it and use it for their own, like Matt Pocock TypeScript course, whatever, they can just feel free, like clone the repo, do whatever you want. So the plan is to monetize the actual course content from creators. [38:49]

And of course creators keep 100% of whatever money their course makes. What we're thinking of doing is every creator course creator, like they plug in their like stripe to the platform. And then, it's just a direct line between the person on the other side who clicks buy and the creator. We, we don't do any app store, like 30% nonsense. [39:10]

All of it, just for the sake of education and learning and fun. I'm sure you're, you can relate Carl. It's another way of expressing I am unemployed and I have way too much time, [39:21]

Carl Vitullo: Right. When you have so much time, it becomes a challenge to fill it. Yeah. Well, you've, you've definitely got a lot of things going on. [39:29]

Tejas Kumar: Yeah, I'm really excited about it. it. And then, this chat has so many insights and ideas that I didn't even know I had. that's because of your awesome skills as a host and conversationalist, so I appreciate that. [39:40]

Carl Vitullo: That's the whole point of talking to people is see what you didn't know you knew. [39:44]

Anything else you wanna touch on before we wrap up? I'm curious to hear what your experience with Angel investing has been. If you want to share a little bit about that [39:53]

Tejas Kumar: yeah. As a first time non-employee founder person, I've, I've been diving a lot into finance actually, and investments and taxes and all of this. And, I see more of the value of Angel investing actually now as a founder. it's been good. it's been, It's been interesting. There's criteria to, to be an angel investor, oftentimes you can even circumvent that if you really want to. But these safeguards are put place to protect you because angel investing is like the riskiest type of investing on Earth. And it has to be, it has to be money that you're 100% comfortable losing. [40:27]

It has to be cash that you're willing to set on fire, like the Joker in The Dark Night. [40:31]

Carl Vitullo: Are you referencing like the accredited investor check? [40:34]

Tejas Kumar: yeah. So that check is also very interesting cause it doesn't help those of us who don't live in the usa. So I'm more than capable of, at least when I started, I was more than of angel investing. Because I was talked into it by my friend, Show Depot from Polygon. [40:47]

He is like, dude, write some checks. And I was like, sure man. How? [40:49]

Carl Vitullo: How? Big question. [40:51]

Tejas Kumar: Anyway, long story short. Well it turns out it's not hard. You talk to founders and you say, Hey, I wanna support with an angel check. You them your address and your money and your ID stuff, and they have their lawyers look at it and they send you, a contract saying you'll pay them that much. [41:06]

And most often it depends on the type of company. Some company will straight up give you like ownership contractually in exchange for your angel check, of course proportionate to your angel check and the valuation of the company at the time. Angel checks vary in size, and I've seen the smallest angel checks are like $5,000. The largest angel checks are $800,000. I've seen weird sizes of all shapes. I wanna be the kind of who's comfortable enough to Angel invest $800,000, honestly. [41:38]

But proportionate to your investment, you get, an ownership stake in the company. Some companies do this new thing that Y Combinator invented called A SAFE, which is a sale agreement of future equity. it aims to just simplify it. So you give them money and they give you an agreement to sell you equity in the future, when the valuation is higher. And you usually will have some type of like maximum valuation cap. [42:02]

Carl Vitullo: Right. Okay. Yeah. Right. That's like a convertible debt, I think is a term used to reference that? [42:06]

Tejas Kumar: Yes, it's the, it's like convertible debt version two is the SAFE. And yeah, that's basically it. It's just you sign contracts, you send addresses, you send money. And over time, the hope is that the companies have some type of exit. Either they go public, they sell, or some other very wealthy investors who's up and they're like, oh, what are those shares? Who does that belong to? I'll buy it from them. [42:27]

Carl Vitullo: Ahh, secondary market. [42:28]

Tejas Kumar: Right. And they have to buy it from you at the valuation of the company, which And then you get way wealthier. But and all the angel investing I've done, it's literally money I don't mind this money that I didn't even know I had. [42:41]

Dude, I've been a tech employee for 15 years and over that time I've accumulated scary amounts of money, as I'm sure multiple engineers have. And I didn't know what to do with it. So I decided let's just angel invest and what I've angel invested, I'm okay to lose, but I've strategically angel invested not so much in the companies, but in the founders. [43:02]

In the founders who I'm like, listen, like if their company fails, there's no hope for any of like some of the smartest people in the world, who I'm convinced are able to pivot and save their company in an emergency event. But who I'm also convinced that will not have emergencies cuz they're just absolutely brilliant So for me it's about the people and then whatever company it is, I don't really care. But then, there's also some savings that I was not comfortable betting with angel investing. And I learned about like safer investments like ETFs. There's a whole bunch I could say about all of that. [43:34]

I've, since I've become unemployed and since I've started, I recently invested 60% of all the cash I've ever made my entire life in different places. This happened like three days ago. And dude, like losing quote unquote, losing 60% of everything you've ever worked for, is pretty nuts. [43:51]

And I did it for multiple reasons. One, to beat inflation because at least in Germany, year on year, cash is losing 10% of its value year on year. So I did it to beat inflation, but also I did it to feel the squeeze. I wanna feel like, oh my gosh, we don't have any money. the hope is it would motivate me with this business be successful. [44:11]

Carl Vitullo: Yeah, everything you're saying, just I feel like I lived at some point over the last year. It's just funny to hear someone else doing the same things as me. Probably six or eight months ago I had a similar kind of… [44:23]

I've been working in tech for 10 years, I've made an amount of money, and over the last year, especially going independent, it's like, okay, one source of money is income through selling a product, selling my skills as a consultant. But you know, what, another source of income or a source of money is, growth in investments. So I started thinking of it as well, no, if I'm gonna work for myself, maybe one of the highest leverage actions I can take is smartly investing the money that I already have. [44:57]

Yeah, so, over the past year I ended up speaking to, a bunch of advisors and reading books and articles and about like diversification and tax loss harvesting and all the financial details and with the amount of money I have invested, like if I can get an extra of 4% gains through diversification or whatever, then that could, that could extend my runway of how long I can be independent by months or years even. [45:25]

So, it's, it's one of those things working independently and needing to proactively think about where your money will be coming from rather than just, semi passively taking a paycheck every two weeks. Is it really forces you to think differently about where your priorities are. [45:40]

Tejas Kumar: Exactly, and I feel like as engineers we're all capable of doing that. Cause we spend most of our careers optimizing one thing or the other. So we could optimize that, [45:47]

Carl Vitullo: Yeah, yeah. We spend our whole careers learning new skills and putting them to practice immediately. well, why can't one of those skills be financial literacy? [45:55]

Tejas Kumar: Exactly. [45:56]

Carl Vitullo: All right, well, I think that's a good place to end it. Tejas, thanks so much for coming out. This was isn't a great conversation. It went so many [46:01]

Tejas Kumar: I really appreciate it. Thanks for having me, Carl. [46:04]

Carl Vitullo: Yeah, thanks so much for coming out. [46:05]

Tejas Kumar: All right. Take care. Bye.

Wix team

Reactiflux — Tue, 17 Jan 2023 16:00:00 GMT

Wix Team: Tom Raviv, Omer Kenet, Peter Shershov

Carl Vitullo: Welcome to our latest episode of Reactiflux Office Hours! I'm joined today by three team members from Wix, talking about the evolution of web development, the golden age of frontend that we're in right now and talking about their experiences navigating the tech industry. [00:17]

The three of them each have very different entrances into the tech industry. I thought it'd be fun to have everyone compare and contrast, talk about their journeys. [00:26]

Joining me is Tom Raviv the head of developer relations and Team lead for stylable.io. [00:30]

Omar Kenet, head of product for Codux. [00:32]

Peter Shershov, the engineering team lead. [00:35]

And in the #q-and-a channel, we've got Joshua, one of the developer relations people [00:40]

Wix Team: Hey guys. Hey guys. How's it going? [00:43]

Carl Vitullo: yeah. The joining us partly in celebration of the recent beta release they have for Codux. But before we get into it Tom, do you want to start us off and introduce yourself? [00:55]

Wix Team: Oh, for sure thing. Sure thing. My pleasure. So my name is Tom Raviv. I originally started my career doing technical trainings for telecom companies and all sorts of legacy systems. From there I transitioned to Wix where I've been for the. Almost close to 10 years now. I started off as a script kiddy programming position, working on some applications for our internal frameworks and some very old systems at Wix at this point. [01:20]

Then got my bearings there. Learned a lot about programming, about working in a company, working in a team, working with other developers and other stakeholders. Then I did a bit of a switch went and helped to found the Wix Academy, which is an internal group within Wix that does. [01:37]

Developer onboarding trainings, boot camps progression courses and tracks for their developers later in their careers, as well as all sorts of activities that relate to community and engineering branding. So we organized the conference called you Gotta Love Frontend for a number of years as well as some meetups and all sorts of community activities. [01:58]

Did that for about two years at Wix and for the last six or so I've been with the group that I am now the group working on Codux and on Stylable. Started as a developer on Stylable, turned into a team lead and very recently took up the reins on developer relations for the group. [02:15]

Carl Vitullo: Very nice. Wow, that is, that's a long resume. [02:17]

Wix Team: It's been a really interesting ride at Wix. Yeah, and I think that's about me. Omer, you wanna take take next. [02:23]

Yes, I will. Hi. Hi, everyone. I'm Omer Kenet. I lead the product of Codux so it's a super fun time for me, obviously. Yeah, so I've joined Ws four years ago, so not as much as Tom, but quite a lot as well. [02:35]

I've joined after founding my own startup in very similar areas. We've been working on frontend toolings and code editing visually in several ways in my startup translating design files to code as well. A lot of connection between what I did before and what I'm doing now in my team, in in Wix. [02:55]

Yeah, it's a really great ride been going on for a lot of time now in this environment, yeah it's me. Peter yes. Hi. Hi I'm Peter. I'm also for four years already at Ws team lead of engineering. I started as designer 10 years ago actually on ads and I call it web apps as well at mainly on like ads and stuff like that. [03:17]

And after that add into coding html, js and actually angular at first after that react and type script as of now. And that's about it. Yeah, that's about me. [03:30]

Carl Vitullo: Very nice. Yeah. I'm curious to talk more about how you transitioned from design to software engineering. But yeah, before we get too deep into it Tom, I do you want to kick us off here talking about Wix and how they. Some of their origins and how they've evolved through the years. [03:47]

I know that they're one of the early sort of d do-it-yourself website builders. Does that, is that still how Wix thinks about itself? [03:54]

Wix Team: It's changed and it's progressed and it's definitely grown in scope over the years. Wix got its start back in the flash days. It's first, it's very first visual editor for website creations was based entirely on flash. And you could do all sorts of crazy things. You could have bats flying across your applications and you could do all sorts of timeline connected, interactive experiences. [04:16]

But flash went away and we had to find things to work with in its place. HTML five was definitely the way to go, the way the industry and the web were was moving to. So Ws did that and then, still stuck to that early idea of do it yourself, create your website for your event or for your small business or for your own personal use. [04:37]

But as time progressed and as Wix grew both in user count, but also in employee count the range of audiences and the breadth of capabilities that we were looking to offer really grew. When I joined Wix, I was like, employee number 500 or something. I think right now it's about 6,000 or 7,000. [04:59]

So that posed a lot of really interesting challenges in how do you scale that much but also how can you take a product like Wix and find. New audiences for it, find new use cases for it. And for Wix, that was developers and designers, and finding offerings that can fit in this entire spectrum of very simple, no nonsense kind of users that are only looking to do something visually. [05:25]

But on the other side of that, to something that's more complex and can really support larger businesses, larger needs more complex cases. [05:33]

Carl Vitullo: Sure. Wow. So you said earlier that you've been working at Wix for 10 years, but you were still employee number 500 you said. [05:41]

Wix Team: Yeah. Yeah, thereabouts. I think Wix was founded around 2008 maybe. So something like that, give or take a year. I joined around 2013. [05:50]

Carl Vitullo: Yeah. Wow. So it's already a mature business and you know here now al it is almost three times older is when you had joined. That's that's incredible. [06:01]

Wix Team: Yeah, but it's still, despite the growth and the increase of headcount and capacity, it's still very much kept. It's roots and it's startup spirit. And this sort of can-do attitude where everyone can really find their niche, find their spot, and take ownership of what they want. [06:19]

Carl Vitullo: Nice. Very cool. Yeah. So, And you said you. Came at this sort of, from a script kiddy background. What's been your experience from that hacker ethos into a large company and staying with Alar one large company for such a long period of time in your career? Yeah, I think that's pretty uncommon in the industry. [06:38]

How has that experience been? [06:39]

Wix Team: I've it's funny, I've listened to several of your previous episodes and it seems like there's a somewhat of a recurring theme where I got my first kind of chops in programming through gaming. Back when I was a kid all sorts of games would let you expand, program, add script, do all sorts of things. [06:55]

The communities were on IRC or other sort of networking environments of that sort. And it's where I started to dabble and try out different things. Only when I got to Wix, it actually transitioned into this real thing, a job where you actually learn and are expected, to perform and to deliver. [07:15]

But really I had amazing mentors and amazing people who I could draw both knowledge and inspiration from in terms of where I want to take my career and where I want to take, where, what I wanna do in the future. And I think that's really part of the reason why I've been with Wix for so long. [07:32]

It feels like I've found home [07:34]

Carl Vitullo: That's fun. That's really nice. That's a good feeling to have. Yeah. And if you've been there 10 years, I would, I'd hope it still feels, hope it still feels good. [07:43]

Wix Team: Definitely. Definitely. [07:45]

Carl Vitullo: yeah. I'd love to hear some more about what, how long has Wix been using React? [07:50]

Wix Team: And as I mentioned we started off with the Flash, then we transitioned to the HTML five. That was not React, re React was not around at that time yet. I think it was more based on MO tools and an internal framework that, that we had created at the time. But then around 2015, was it, right? [08:08]

Yeah. Yeah. So 2015 Wix started to explore new frameworks, new avenues, new tools that we can utilize. The web was, has started to pick up the speed and how things were being released. What capabilities were available to developers. And we went fully on board with that. React has served us very well over these last past years. [08:31]

And I think that's part of the reason why we've also based Codux around it. True, yes. Totally agree. [08:39]

Carl Vitullo: Nice. Yeah. And Peter, you said that you had. Work with Angular as well. Is there, I see a question in the chat. Is there a professional reason or personal preference? [08:48]

Wix Team: Hello. I was working in startup company that actually used it in the product like ler Gs actually first one. And yeah, had to learn it, was tough and also interesting that as like a starter project to me still. Yeah. I think that's what's up. I think back when it first came out, angular, it was really quite a breath of fresh air. [09:14]

It was trying to do something that, not necessarily anything. Similar to it has done the binding. The binding. Yeah. The, yeah. Two-way binding was like, oh my God, it changed everything. But also a framework that kind of covered you from end to end and really tried to provide a localization yeah. [09:35]

Routing as well. The whole thing.. Yeah. I loved it. And at first, and then I realized how how to say, huge it is. And maybe you don't need all the parts. Exactly. Yeah. The binding is it's amazing, but also, perhaps not worth it. Yeah. maybe. Maybe. [09:53]

Carl Vitullo: Yeah, for sure. Yeah, definitely Angular one, and I guess, react was competing with Angular one back in the day too. But I think that it came from a different era of the web where, maybe a little bit more framework focused, things like Laravee or Rubian rails that really did try to do everything all in one. [10:11]

And I think React was really a step in a different direction of saying and now it's that the reacts vision of being a low level platform upon which other things are built. I feel like that's, coming true now with tools like Remix or next, but yeah, I guess the, maybe that's a direction of poke. [10:27]

What's how are you thinking about things, products like Wix or like Codux in this, in the current, reality for the web ecosystem? [10:35]

Wix Team: Next.js You mean and Remix frameworks, like how we approach that? [10:42]

I think it's, first of all, it's, at the end of the day, it's what gets the job done, right? If you have a tool that covers your needs and is easy to use, will performs well in whatever metrics you care about, whether it's like things like actual performance in loading or if it's features or device support, or like new APIs. [11:03]

If you have something that kind of covers all of the bases you need, I'm all for it. If it's ring mix or if it's Next or if it's Wix it's okay. Use the thing that. Having said that, supporting things like Next and Remix and things that really bring a lot of tooling with them, a lot of integrations, a lot of thought and perhaps opinions on how things should be done poses a somewhat of a challenge for us. [11:26]

On the other side to, to create a system that's agnostic to, like all of these opinions and needs components are components in the end. If it has span other components in it we'll render it in the end. Regardless of routing assets and stuff like that. Yeah. [11:43]

Carl Vitullo: Yeah, for sure. Yeah. And I see that we've had a lot of new people join in the last couple of minutes. So let me just reintroduce I'm here with three team members from Wix. They are, they're celebrating a beta release of their new product, Codux. But we're also just here talking about the tech industry, how we've, how we got our starts. [12:00]

And just talking about the web. But yeah, I'm here with Tom Riviv, the head of developer relations and a team lead for their open source project stylable. Omar Kenet, head of product for Codux's recent beta release. And Peter Shershov, the engineering team lead. And we've got Josh, username, Alphonse helping out in the #q-and-a chat. [12:18]

One of the topics we had queued up here was the golden age of frontend development. Do you think that's now, do you think that was a different time? [12:26]

Wix Team: Oh, I think it's very much now, I think it started about. For luckily for me, about a decade ago there was some time where I feel like the web was in stagnation. There are all sorts of stories about ECMAScript for and how that got stuck in the pipeline. And there are all sorts of tales from like the CSS working group on how hard it was to create new capabilities like flex or grid and actually ship those to, to users. [12:55]

But things have changed and really the speed at which things, but, and by things APIs, tools, browser capabilities, all of those, even the language itself, if we're talking about Equi script six and everything that has come since it's. It's mad, it's great, it's wonderful. It does and can cause some fatigue because it's hard to keep up with the pace of everything that's going on. [13:21]

And you're almo like almost always in this situation where you're thinking, am I using the right tool? Maybe there's a new shinier one. Maybe there's a faster one. And running after that all the time is a bit tiresome. FOBO, and lots of people have talked about that issue and have offered various ways of dealing with it. [13:40]

But I think at the end of the day the proliferation of tools and capabilities on the web is fantastic and really helps drive forward everything that, that we can do as developers and the things that we can offer to our users no matter in, in what, like domain or area. And I guess like the fatigue is always better than not having enough options, oh, definitely [14:02]

Yeah. [14:03]

Carl Vitullo: for sure. Definitely a lot to keep on top of, but it's a, it's evidence of the boom times we're in that we have so much to stay on top of. [14:10]

Wix Team: And I think that like there, there's also been. Beyond just more things being added. There's been a lot of change in the mindset of how you approach things. If you look at it from like the 10,000 mile view we've moved from document-based development to component oriented development. [14:29]

And that's a very different experience. I think it really lends itself to scale, to growth, to even just for onboarding purposes, for learning pur purposes, getting people into very complex systems or very complex apps is, in my experience, a lot easier when you're talking about components than when you're talking about very dom oriented kind of development [14:57]

Carl Vitullo: Sure. Yeah. Yeah. And I think you know the audience here, react developers will be intuitively familiar with component-based development, but I'm not sure I have a clear picture in my mind when you say document-based development. Yeah. Could you, can you go into that? Can you dig deeper? What is document-based development? [15:15]

Wix Team: By document, of course, like the window document, in the browser. The dom. Yeah, the dom. And things like JQuery, where, a decade, 15 years ago, you had to use it because browsers were so out sync with each other. APIs were so lacking in what you could do, and third party libraries stepped up and tried to provide like the best that they could. [15:36]

And it was awesome. And really helped push the web forward. But at the end of at some point the browsers cut up, a lot of the functionalities moved in, and then the third parties could. Transition over to doing things that are like more about architecture and more about how you actually structure a complex thing. [15:55]

From like the beginning of the tool that you're using or the beginning of the language that you're using or components and your right. We saw it in in inquiry in the j query, the head UI as well, components. So it's like changing into other aspects as well. Yeah. [16:12]

Carl Vitullo: Yeah, definitely. I think one of the big challenges that I remember from the document-based era of development was everything applied everywhere, so it was, you had, you just had to be so careful about what class names you used, what selectors you used. And that's, that is still a concern now. But we do have a lot more tools that help us keep scope narrow, [16:34]

Wix Team: Oh, definitely, even Stylable tries to keep you safe in whatever way it can, it will name, space, everything in CSS that could possibly collide. Whether you're talking about classes, variables container queries, layers you gotta namespace things these days because the browser is a big place and global scope is dangerous. [16:53]

Carl Vitullo: Yeah, global scope gets messy quickly, for sure. Yeah. So all three of you have been working on on Codux or in a similar, problem space for a number of years now. What does it, how does it feel being a developer serving other developers? [17:09]

Big question. [17:10]

Wix Team: It's a great question. One that, I don't know, you could probably write a thesis about, I think like the first thing is that, You're both the developer and the user. So that means that on the one hand you have a lot of inherent knowledge about the domain. [17:26]

If, for example, you're a developer working for a medical company or for, I dunno, car insurance or something like that, you learn the domain in to, to, to a certain aspect or the things that you need, but you'll never be like as knowledgeable as a doctor or a surgeon or whatever. With developers, when you're writing for developers, especially if they're the users are using the same stacks the same technology stack and tools that we do then we do know a lot of what they know. [17:53]

And we do share a lot of their pain points or their successes or their approaches. But on the other hand, we also bring our biases. So if we have oh man, I don't like angular, I don't jQuery, I don't like from my own personal taste, then that will all of a sudden be reflected in that as well. [18:13]

And it's hard to balance that app. Yeah, I guess from my perspective as a product, working with the developers, building tools for developers, I get a bit of both, like the upside and downside. Like you have all of this knowledge right in front of you and people who are very deep into those concepts that you can learn from and shape the product based on what these people think and know and do. [18:37]

And yet, as you said, the bias part is always a challenge. People like what they like and many times really don't like what they don't like. And you need to play around with it and make sure that that you're getting what you need to get and put your filters on what are people's personal preferences and not like what's a common ground or what should be like the right approach I guess. [18:58]

So that's a lot of challenge for me. Really cool though. I think we're, at the end of the day, all of us are very passionate about what we do. And that can sometimes also be translated to like high energy interactions college athlete. We're, Al might come with a suggestion for a feature or a change to, to some aspect of the product. [19:21]

And we'll be looking at that and thinking and saying, no, this is terrible. You don't know what you're doing. But he does know what he's doing. Like he's been looking at the range of developers as an audience, as a group. And that's something that while we occasionally think about, it's not something that we necessarily have that much of a grasp on compared to him. [19:43]

Carl Vitullo: Yeah, it's easy to think I'm a developer. I'm our target customer. I intuitively know what other developers will want, that is still at the end of the day, anecdotal, it's your own preferences. And yeah, definitely easy to let that get in the way of, just as over time, you, if you don't continually update your perspective of, developers, not just what you want as a developer, you risk becoming increasingly out of touch, I think that's maybe a restatement of what you're saying. [20:13]

Wix Team: Yeah. Yeah. It is though a lot of fun, I have to say, because we work together in very early stages of shaping the changes and the product. Like it's not just talking about implementation. It's also like from day one. Discussions about what should we do, how should we do it? [20:29]

Like I'm talking both with the people who will implement the product and yet people who are so deep into the pain that we're trying to solve. The whole planning and figuring out what would be a right solution or Right. Even what should we solve? So it's all very early stage done together and that's a real good fun I think for all of us working together. [20:49]

Oh, definitely. Yeah. I agree. If you hear the product manager on the team lead of the engineering, we have our conflicts and our disagreements still in the end of it. It's our product is interesting a lot. And yeah, it's true. I think like an, another interesting aspect of that would be that, Codux as a product like it's very much. Primarily targeted for developers. And we're using Codux to build Codux. [21:13]

So even in that place when we're just developing the thing itself, we're both the users and the creators of it. And to a certain ex as extent, the same thing could be said about our designers as well and about the product managers as well. The they're building it, they're creating the specs. [21:30]

They're planning out the product, they're doing the research that's required, but then they also use it so they get this k you get this kind of immediate loop of dog fooding your own product. And I think it teaches you so much about what you can do, what you should. [21:43]

Carl Vitullo: Yeah, definitely. I know you actually using your own product is, it's the core of every product businesses, anytime someone gives advice to a product-based business, number one on that list tends to be actually use your product, understand how it works. So yeah, that's really, it's really cool that you have bootstrapped this, bootstrapped Codux into a place where you can use Codux to develop Codux. [22:09]

That's [22:09]

Wix Team: it's a testament of its capabilities. Like we're saying that you can use this to create complex apps, complex component, complex sites or whatever you want. And if you couldn't build Codux using it, then we've probably missed a Mark [22:26]

Carl Vitullo: Yeah, makes a lot of sense. [22:28]

Wix Team: No, I was just trying to say like it is like someone who would look at it from the side would be confused. many times. Like you could see us editing this visual thing, like this panel or something, and yet using the same panel to edit the next version of that panel. So you could look at it from the side and be like, wait, what am I seeing here? [22:48]

So for us it's like really an interesting approach and I did have the same experience with my previous startup. So it's so cool to, to see people like, figure out that this is what we're doing. It's oh my God, this is mind blowing and yet so confusing at the same time. definitely a bit trippy. [23:04]

Carl Vitullo: Very neat. Yeah. Yeah. Oer. So you said that you were, before you started working at Wix, you were building your own startup in the same problem domain. Is that right? [23:17]

Wix Team: Yep. Yeah. It was very similar in many ways. Very different in other ways. But yeah, it was like on the same problem space. We know that we're dealing with a problem that like the entire industry could feel every day, probably. So the startup had a different approach of how should we tackle frontend and collaboration and kind of heat up the process, improve our workflows. [23:40]

We were focused on translating design files into code. We had full on editor to create whatever you wanted to do with your website once it was converted from the design file, either Figma sketch, Photoshop those were days that were still used for ui. And yeah obviously sharing the same kind of vision towards How the future of web should look and how the future of frontend should look. [24:02]

That's what got us to Wix, I believe. [24:09]

sorry. We've also talked about like the range of users that, that a complete like Wix might expect to, to support or want to support from the very basic beginner level all the way to the most pro of pros the experts that do everything right down on, on the metal itself close to the core of the system. [24:27]

But even if you look like at the group of developers as an audience, even that's not a single thing, right? You have developers that are at the beginning of their career and you have developers that are much later and much more experienced, and those types of users really expect a different sort of experience. [24:45]

The beginners would need more handholding. They'll need things to be more verbose, whether we're talking about actual text in, in the product, in tutorials, in documentation and so on. But also like in how the product itself is shaped. Beginner use, like beginner level users might need buttons that are label labeled a certain way or certain actions that are exposed in a clear way. [25:10]

But this might come at the expense of being professional that works with a thousand keyboard shortcuts and can zoom all over the place and do things with 17 heat strokes and they're done. So there's a tug of war of balancing those two groups and finding where you can provide the optimal experience for both audiences and how they can fit it or adapt it or configure it to their needs. [25:33]

Carl Vitullo: Yeah. Very neat. Yeah. So Omar, how long had you been building that startup before you joined Wix? [25:39]

Wix Team: So I guess it depends on how you would look at it. We had a previous round to that startup, the same founding team and team members working on something completely different from our last startup called Rapid ui. started with something called Gono Go. It's really not in the industry, but it taught us a lot about the pain and drove us to, to the place where we wanted to solve it. [26:01]

We realized that there's a much bigger pain here that we can deal with such a bigger. Issue that we want to put our focus in. And we're so motivated to try and solve all of those things that we could feel on our own. And we did a complete pivot. We changed everything. We, even though we were doing pretty well, I have to say especially in terms of like early stage startup we just realized that it's a much bigger thing to, to handle and we completely transitioned to Rapid ui. [26:29]

Working on Rapid ui, I guess it was like around four years almost. We had users paying money for the product, getting value out of it. Obviously because of that we were got funded so we're doing pretty well a long time about that. So got very deep into the, those problems based, I think the first times we met like that when your company and our company met it was very. [26:53]

Immediately evident that there's a common language there. We were looking at the developer groups and developer experiences in much the same way and trying to solve a lot of the same issues, but in slightly different ways. Yeah, I and it was true both on professional aspect and like the personal aspect at the same time. [27:11]

Like we had a click from day one, I believe. All of us could feel it. And yeah, like the professional aspect we're working on such similar problems like technical problems editing code in, in many ways. And yet providing a way to write code freely. So there's always this kinda mix between the freedom that you want to give and both the startup and Codux give ultimate freedom. [27:35]

Like you're not, you were not, and you're still not limited in any way. And yet at the same time comes back to what Tom said earlier. How do you wrap these things with great experience? How do you make sure that you can cater different kinds of users and yet still allow the ultimate freedom? [27:51]

So both products had these similar problems and I think that both sides could really feel the value of being deep in those problems. Like we joined the company and it didn't take long or took very little time before we could start actually doing things, make changes, improve, I hope [28:08]

Yeah, it taught us a lot and we started so fast in weeks in our team because it was just like so aligned. Oh yeah. We like, had a common language immediately. It was just like jumping straight into the water and getting stuff done. [28:21]

Carl Vitullo: Very neat. Okay, so it sounds, so you worked at, worked on rapid. For about four years before you joined the Wix team, and you've been now been working at Wix for eight, four years as well, you said? [28:34]

Wix Team: That's true. [28:36]

Carl Vitullo: Yeah. Very cool. Wow. So eight years working in the same problem space. That's incredible. [28:41]

Wix Team: Yeah. Yeah. When you have the passion for that thing, doesn't feel like eight, like it feels from one hand, 80 and yet from the other it's like I can do it a lot longer. Every day there's a new challenge and usually challenges that I like tackling. So yeah, we like editors, what's up? [29:00]

Oh yeah. The, The UI experiences. [29:02]

Carl Vitullo: Very nice. Yeah. There you go. I'm trying to imagine what it might have been like to go from a small startup that, or I'm assuming small, but a startup that you're running yourself to being, it sounds like a acquired and joining, so like an aquire situation. What was that experience of going from, totally self-directed startup you founded to someone who works for a thousand, multiple thousands person company? [29:29]

Wix Team: Oh, wow. That was a big big day. a big change. Obviously it's, in one hand it's very different. Yeah, it was a small startup. You said it right? We were like seven people or eight. When maybe a bit more by that time, but very small. And I was like one of the founding members it was like, it was my thing. [29:47]

I joined a very special team. The company. Even though I guess regardless to the team, Wix is a very special company in general. We touched it a bit, but I know that throughout the entire organization people feel like they're part of this big thing and they can contribute to that big thing even though they're like thousands employees that, that do it. [30:06]

And especially in our team I would say that we are working as if we're a startup, right? We're working on new things, trying to find new technologies to solve problems for people. So we are very oriented to think as a startup. So it wasn't as extreme as we thought it would be very different in many ways, like day to day and all of that different organization, how it manages throughout the day to day. [30:31]

And yet at the same time, whips is such a great company to work for in so many ways. That just gives you the feeling that you're a lead role in this big thing. And I know that almost everyone in the company feel that way. So yeah you're not just a cog in the machine. You make an impact. [30:50]

If you want to, if you wanna take the responsibility and step up and do the things that you wanna do, then that's the doors are open. And I think I'll add something, just a small thing to what almost said, and that's the, yeah. Our group is somewhat unique at Wix and that we're very much focused on developers and on only developers for this point at time. [31:12]

And. This group is led by Nada Ajami, who is one of the co-founders of Wix. So it definitely has its place and definitely has its vision. And we're all along for the ride. [31:25]

Carl Vitullo: Nice. Yeah. That everything you've said about the culture at Wix sounds pretty rare actually. I've worked at, so I've, it sounds like I've been working about the same length of time as you have. I got my first job in 2012, but I have in that time rather than working at one company I've worked at I think nine. [31:43]

So yeah. My experience, my, my personal anecdotal experience is that the kind of culture you're describing is pretty rare in the industry.. That's pretty cool. [31:51]

Wix Team: you should drop a visit. Definitely [31:53]

Carl Vitullo: ha. [31:54]

Wix Team: Come see what's up. But you're very right though. Like I have to say I think it's one of the company's main pillars. Like we're gonna keep that vibe, we're gonna keep the atmosphere, we're gonna grow as a company, we're gonna grow as a product, but we're not gonna lose touch with the origin, and that, that's one of the most beautiful things in this company. So yeah. You should definitely stop by. [32:13]

Carl Vitullo: We have a good, sorry. have a good [32:15]

question from chat coming in. [32:18]

Fransen is asking how does the actual conversion of visually creative components take place to convert it into legitimate clean, react and CSS code? Yeah. So I guess asking about the process of taking the visual design and turning it into code that you can use yourself. [32:36]

Wix Team: So it's important to mention translating code design to code is not what Codux is about. That was my startup Rapid UI was about. Coded X's approach is very different. You are creating your components visually. You're not starting from a design tool or translating something into code. [32:54]

You're working with code since the beginning. It's always working with React and with TypeScript and with the styling solution that you choose. There's no translations at all actually. So we, you just worked with React. You may start your design off in in, with a mock or with a design tool or with something like that kind of lets you play around and explore the space of the problem and see what might work and what might not. [33:18]

But at a certain point you want to get to the real thing, and that's where Codux enters the picture and really provides. An experience that is code oriented, meaning your code is the source of truth, the files on your hearts, on, on your file system the code in your component. But wrapping that in an experience that's visual and that can actually do some things in a much nicer, leaner, more streamlined sort of way. [33:45]

Not sometimes writing code by hand, character by character is not necessarily the best way to describe a visual thing. And if you've ever created a very complex background in CSS that has like multiple layers and things like that, you might know what I'm talking about. Through the ui, you can do that very easily. [34:04]

But in hand it, like we've all used all sorts of builders on the web for shadows, for backgrounds, for corners, for all sorts of stuff like that. Because they work and they make our lives easier. So why not bring them closer to the table, closer to the code, and closer to our development experience? [34:21]

Carl Vitullo: Yeah, that makes a lot of sense. Little follow up from Roberto. Does Kod Oaks work with Tailwind? [34:27]

Wix Team: Oh, we've been, we launched our beta on December 5th, so just over a month ago. And I think that's gotta be our highest like the most requested feature, right? Yeah. Top of the list, that's for sure. We are working on supporting Tailwind as we speak. We as Tom said, we just launched a beta like not that long ago. [34:46]

We didn't support Tailwind. We launched. Launch. But we got so many requests for tailing and we actually believe that it can be a really good experience the way, like the Codux approach of editing and how tailing works. So we are working on figuring out the best solution and the best experience of using tailing within Kodak. [35:04]

So it's not gonna be too long before you'll sit in the product. It's gonna be very close, actually. [35:10]

Carl Vitullo: Very neat. Yeah. I can see how it might not be a sort of a natural extension. If you're already working on code, interacting with code from a visual perspective, then you know that you, that doesn't obviously backport, into working with Tailwind. So you'd, you to work with Tailwind, you would need to then operate on Tailwind Primitives rather than code, I guess is what I'm trying to say. [35:35]

Wix Team: Yeah. And it's a bit different from like the editing class names and like selectors and it's slightly a different approach. It's very similar in many ways, but the editing experience I'm using those classes in a lot of them on each of my elements usually to style them. Slightly different approach. [35:53]

Nothing that is too too different or too complex. We just want to give a really good experience when using tailwind. It's all so visual. And this is what we're working on right now. And I think in general, like if you're working with a design system, whether that's end or something of your own th those are places that Codux could really shine because you've already have a lot of the building blocks. [36:15]

Like you have the Lego pieces, and now it's just a question of how you wanna put them together and play with them and see them in various states and situations and really explore how you can create it and what you're trying to do. We currently have already scalable support also. S, css, and yeah, sass, sas, css and Stylable. [36:35]

All those come supported out of the box including the, like the modules version of CSS and SaaS. Sticking to that component oriented design kind of philosophy. So yeah it's really a question of what tools you prefer to use and what tools fit the problem space. [36:50]

And as time goes on, we'll be looking to add more and more support for new tools and new frameworks and new languages. Even like React is just where we're starting off. We'll be exploring web components, ve solid angular. I don't know. It's, it'll be a question of what the community wants from us. [37:09]

It'll be a question of how technically feasible it is. Although Codex is designed from the ground up to, to support and facilitate this. So yeah it's all about choice and en enabling the choice for our users. And obviously you have to start somewhere, right? You have to make those hard decisions of where do I cut it? [37:25]

Where do I say, okay, this is what I'll start with. And we'll get to all of those technologies and will support more and more. But you have to start somewhere. And we've decided. Like a while ago. This is where we're gonna cut the cut and we want to put it out there. And we wanna listen to the community. [37:39]

We want to get people's requests. And it took so little time to start getting requests, especially for Tailwind. I think that we're all happy to just make sure to put it out there as fast as we can and start getting feedback. This is where we are all about today. And I think if anyone had a chance to take a look at the very recent state of JS that just came out for 2022 react is still King of the Hill. [38:03]

That's what most people use, that's the most common solution out there. And it makes a lot of sense for us to start there. Even all, like all of the development at Wix is done using React. So it's really our breaded. [38:16]

Carl Vitullo: Very nice. Yeah. Should we pick up talking about sort of our different journeys through the tech industry? We were talking with, Omar was speaking before, but yeah, I'd love to hear some of the, peter, some of your story of transitioning from a designer to a developer. [38:33]

Wix Team: Yeah, it's tough. It's interesting, right? It's not the craft is how to say separate. Like it's not the same. But it's interesting. I actually applying it everything on, so coding and in interactive experiences. The, I like styling in css, right? It's same kind. Stylability is also thing of mind. [38:57]

But yeah, it's it's interesting. [38:58]

I think it's like speaking as a longtime friend of Peter I don't know a lot of people who has, who have that level of passion for interactive experiences. It's we get a an opportunity to create complex things. And with that comes the challenge of making them accessible. [39:15]

Yeah. Yeah. It's true. It's true. And accurate, I guess from my point of view, like seeing it from the outside. But all a lot of our people like are great, but once you have that passion for interaction, for the styling aspect of things I can feel that like really is affected from your background. [39:34]

I, I believe, thanks guys. I love. Yeah. Also if you think about your interactions with our designs, with our UX people Yeah. I have stakes on like sides, like the. In UX and in our other development teams. So I have my opinions over there and also there, which is interesting. Yeah. But yeah, it's true. It's sometimes hard to keep those up, Yeah. to to remember that you're the developer and in this conversation, I know it's speaking in the name of our designers, it's probably hard for them as well. [40:04]

It's true. It's true. But it probably provides value. Yeah, for sure. It's it's like you're talking to people who know their stuff and that always makes it Yeah. A nicer experience. [40:16]

Carl Vitullo: Yeah. I guess it's, I guess having. Crossed a barrier like that for teams like, a lot of the time design and development is very siloed. It just because it's very different domains, it's very different problem spaces with very different language that's been built up and, the jargon, terminology and tools. [40:33]

So I guess having started in one and progressed into a different division there, that can be, that can leave you in a position where you are able to speak to both teams very effectively. So I could see how that could be a very valuable spot to be in. [40:48]

Wix Team: I agree. Trade off as well. It's I have opinions on styling and stuff like that. Also on coding and algorithms and Yeah. [40:58]

Everybody against me in [40:59]

Carl Vitullo: remember which hat you're wearing. [41:00]

Wix Team: Yeah, I know. Even though like I'm a developer in the end of the day. [41:05]

Carl Vitullo: Sure. [41:05]

Wix Team: But in this era of kinda trying to bridge you said like you talked about different silos or something like that, like separated mindsets for design and development. [41:16]

I that's all changing, like these two are getting closer together. The tools try to bring them closer together, not just Codux obviously of the industries is full with these changes like design tools or prototyping tools are all of it is more oriented to be like more similar to how the implementation works. [41:34]

It's all trying to bridge and connect better to, to one another. I can feel it for many years, obviously with my experience, but you can see it throughout the entire industry. It is a big advantage. I think like it also it's a con, it's a continuation of the conversation we had earlier about like the massive growth of capabilities and features in, in The web and that problem space. [41:58]

But the thing is that progression has happened in separate silos. Designers used to work with Photoshop to create websites, and you would create, you, you were able to create all of these possible designs that you would never be able to implement because the capabilities just weren't there. [42:12]

So then you had either illustrator or stuff like that, and then Sketch came along and now Figma is the hot stuff. And all of those things are trying to of bring designers closer to the real thing. And similar things have happened with perhaps product managers and their mock prototyping tools or with QA engineers or automation engineers and the environments that they have to test and validate and make sure that things work. [42:38]

All of that. Exploded. All of those users or audiences have gotten new tools with new things that they can do, but they didn't go back and interlink. And that's where our industry finds itself now, trying to find ways of reducing. Barriers between stakeholders. So there's no reason I'm sure many people can relate to the experience of ping I call it ping ponging with a designer where you get a design and you implement it, and then you get it, give it back to the designer, and he looks at it and he is oh, yeah, that's great, but three pixels here are off, and that color of that background isn't exactly right and all of those things. [43:20]

So he sends it back to you and you fix that, and then you send it back to him. And now he's okay, that's great, but we've gotten a change in the spec and now we need to do something slightly different here. And you just keep going over and over, even for things that are like small or mundane and if only that person could do it themselves, right? [43:36]

So the industry is looking for new ways of onboarding stakeholders from different domains, providing them with tools that are familiar to them, that solve the problems that they need. Without compromising the experience of any of the other users, [43:52]

Carl Vitullo: Yeah. I really like what you said about getting stakeholders CL closer to. Closer to each other. I think that's a, I think that's a really powerful thought and a really good way of framing tools like this. [44:03]

Wix Team: We can proudly say that our ux designers work on codes in codes. Like they can jump into the product they can jump into the product and change whatever they want. Like they wanna realign, recolor, change, fonting, chase font, spacing. It doesn't really matter. It's all css at the end of the day, or Stylable at the end of the day in our case. [44:24]

But yeah, just give them, empower them, let them be in, in your part of the neighborhood and let them play. And I guess look at the same source. That's one of the biggest upsides of this whole thing. It's not just like the power to do on my own. It's like there are no separated sources that are created along this whole like, complex situation that you've described just now. [44:47]

A lot of sources of truth are created and that can cause chaos in many cases. So putting them all together in that one place just that can eliminate so much troubles and like process pain, yeah. Yeah. Just, having a new feature kind of request come out and then needing to update your prototype and then update your design, and then update the actual implementation and making sure that all of your QA and automation things are supporting this new feature. [45:13]

That's massive amounts of work. That could probably be streamlined in various ways. [45:18]

Carl Vitullo: Yeah. Makes a lot of sense. All right, we are, we're coming up on 7:00 PM here. We had budgeted about an hour for this. Anything you, any, anything else you guys would like to talk about before we get off here? [45:31]

Wix Team: Wow. I dunno, I think we've covered like a lot of our bases. We've definitely spoken about like the various aspects that we're interested in the relationships between stakeholders and the project. How do web got its shape shaped? Its path throughout the last decade and where we feel it's going. [45:49]

I can talk about Stylable or Codux or any of that for hours on end, but that's probably for another time. So yeah. Yeah. I think we've covered a lot of things.

Matt Pocock

Reactiflux — Mon, 09 Jan 2023 16:00:00 GMT

Matt Pocock and MapleLeaf

[00:00]

Carl Vitullo: I'm here today with Matt Pockock and Maple Leaf. Matt is a TypeScript educator working independently. And he has spent time at both Vercel and Stately, which are two companies that I've been keeping an eye on and ones that I think are doing really exciting work. Matt, could you tell us a little bit about yourself?

Matt Pocock: Sure. So I had a slightly mad 2022. I started the year at Stately working on the XState core team working on state machines and state charts. I changed from being a full-time developer into being a developer advocate and developer relations person. And I moved to Vercel and I was part of the team that launched TurboPack to the world.

So I was working on TurboRepo, so I'm interested in in bundlers, in kind of in state machines, state charts. But my real love this year is TypeScript. So I've been working on a TypeScript course called Total TypeScript. And if you've been following me on Twitter, you know that I've been putting out videos, putting out education materials, doing YouTube stuff. And a lot of that is really my first love.

My background [01:00] is as a teacher and singing teacher and voice coach. And so I'm kind of falling back in love with teaching again, but this time teaching people to code instead of teaching people to speak. So yeah, that's kind of me, and in 2023, I'm focusing on I, we launched the first module of the course in December and this year I'm planning on releasing more modules, kind of like really, really building out some quality free materials that's like a free beginner's course on the site. And also building out this paid course too.

Carl Vitullo: Very nice. It's so cool that you used to do singing and voice coaching. What a transition from that into software developer and developer advocacy. I really think of a lot of the work you've been doing on state machines and you're at the cutting edge of web development with things like Stately and Vercel and TurboPack. That's really amazing. I'd love to talk a little bit more about how you made that transition. But before we do that MapleLeaf, can you say a little bit about your background?

MapleLeaf: Yeah, for sure. I've been programming for a total of about 10 or so more [02:00] years mostly in the WebDev space. Reacting, just been hanging out in communities, just talking to people helping people out. Also just dabbling in whatever else catches my interest. Started out with an interest in game development and eventually just slid into a web when when I looked at it and realized like how ubiquitous the platform is and the tooling and like the feedback loops that a lot of stuff like that. And yeah, that's pretty much me.

Carl Vitullo: Yeah, makes sense. I think that's a pretty familiar story. And so you and Matt know each other a little bit, but this is the first time you're meeting in person, as it were, sharing a live space.

Matt Pocock: Yep. It is a privilege. Lovely to meet you personally.

MapleLeaf: Yeah. It's awesome to meet you too, Matt. And always good to see you Carl too.

Carl Vitullo: So what, what circles have you guys run in? Where have you had some overlap?

Matt Pocock: TypeScript, kind of subculture really on Twitter, you know, TypeScript Twitter and you know

MapleLeaf: A cult.

Matt Pocock: Yeah, it's a cult, but we know we're, we're welcoming [03:00] and you know, we like new people, new faces, and. TypeScript seems to just be everywhere on Twitch at the moment as well. So like Theo on Twitch and Primeagen on Twitch are constantly talking about TypeScript or mentioning TypeScript. It seems to be one of the hot topics to talk about alongside Bun, alongside, you know a bunch of other stuff, so, and solid as well. So yeah, I guess that's the circles we've been moving in.

MapleLeaf: Yeah. Pretty much same.

Carl Vitullo: Nice. Yeah, the web development, TypeScript, live community, the people really staying on top of everything. That's awesome. So Matt, you said that you were working on the XState Core team at the start of 2022. How'd you get involved with XState and how long had you been participating in Open Source before you joined the company?

Matt Pocock: Yeah, a lot of a lot of my open source experience was really with XState, and XState at the time kind of didn't have a very good TypeScript experience. A lot of it was, you know, the library was originally built in vanilla JavaScript, then ported it over to TypeScript and it's pretty hard to [04:00] do… what XState does is it does finite state machines and state charts, and those are really very config heavy ways to build logic in your application. So you provide like this big wall of essentially JSON to a function, and then that gives you a load of methods, gives you kind of like a, an event handler lets you monitor the state of your application.

It's really, really cool and like really an amazing solution for for complicated state and complicated applications. But the TypeScript experience was kind of, really bad because it's really hard to get inference when you are just dealing with an enormous object, basically. TypeScript lives off function calls and we needed a different api or a different solution if we were gonna solve it.

So I was working at a company at the time and we were using XState a lot and I wanted to be more type safe, let's say. And so I built something called XState CodeGen which basically used like an AST parser to look at the file in your [05:00] application where a state machine was, and then give that more powerful types.

So this was a really fun pet project that I've worked on for quite a while. And it meant I was coming into contact with really complicated TypeScript, like trying to work out how to build things, how to interact with the types that were in XState already. And so I knew the core code base really, really well and I started chatting to David Khourshid who's the main guy behind XState. You know, if we say state machines three times David will appear. And so yeah, and I kind of got involved through that and started doing more contributions to to prs, to reviewing prs, reviewing the documentation. And then when David started Stately, which is a company built around XState, building visual tooling for state machines and state charts.

When that happened, he basically said, do you wanna join? And I said, hell yeah, sounds great. And so I was with them for about a year and then I joined Vercel after that.

Carl Vitullo: Heck yeah. That's really cool. Wait, so you said that [06:00] you had written a tool that worked on the AST of the state machine code to generate types. Is that right?

Matt Pocock: Yes.

Carl Vitullo: Interesting. So it's, it's not doing type inference at a normal level that an average TypeScript developer would be familiar. You were actually parsing it out and then doing real code generation to create those types, because that's just how hard it was to work with types in XState at the time.

Matt Pocock: Yep, codegen at that level, gives you this kind of Thanos level power, you know, where you can basically snap your fingers and get whatever type inference you want. TypeScript itself has limits, but when you combine it with something like an AST parser then you can get this really cool type inference.

When I was at Stately, actually, we shipped this as part of a VSCode extension. So now if you have XState then you can have the VSCode extension and it will automatically provide you really beautiful types along with your your work. And so, yeah, it was cool to see that properly shipped and out there in the world.

Carl Vitullo: Oh, interesting. So instead of [07:00] fully changing the api, from the config blob to something maybe more function based, which TypeScript would be more ready to understand without a lot of extra massaging, by shipping this VSCode tool, you were able to keep the API for XState the same, but still provide a great types experience.

Matt Pocock: Exactly, because stability in the API was really, really key. So we didn't wanna move off version four, basically, XState is still on version four. I'm not involved with the core team anymore. So having that sense that the API was stable, that XState was stable, but also wanting to fix all of these type based problems with the api, it felt like type gen was the only answer.

Carl Vitullo: Sure. Wow, that's very cool. I've been aware of based tools for a number of years now. I've never probably gotten over the hurdle of learning how to use them. I'm aware of all of the crazy powerful things you can do, but you know, it's just, it seems like every time I try and actually get in there… I know the React team recommended an AST tool… Code [08:00] mods?

Matt Pocock: Yeah, that's right.

Carl Vitullo: Yeah.

Matt Pocock: Yeah, I'm interested in that right now actually I'm working on a VSCode extension. What it does is it basically sits in your VSCode and when it encounters a piece of TypeScript syntax that you haven't seen before, like you as a developer, it gives a little blue squiggly line underneath and you can hover over and see an explanation for that piece of code.

And all of that, that's based off an AST parser. So if it sees a TypeScript conditional type, it will just sort of log it and, and show you it. So I'm, I'm really interested in, in all of that work because when you get your head around it and you can understand it and you understand astexplorer.net and you understand all of the tools, you understand Babel which is what I'm using, it's amazing what you can get done. It really is.

MapleLeaf: I guess the hard part is getting to that understanding , because like when I dug into those tools myself, there's not really a lot of guidance. There's like basic tutorials in some places, but most of it you kinda had to like figure out on [09:00] your own to look at examples. But I guess that's programming

Matt Pocock: Yeah, it's also like VSCode extension development is like that as well. Like, because every time you Google something to do with, you know, VSCode extension, it will give you a VSCode extension that solves the problem. You know, so there's, there's no way to Google for it really. You basically have to live off a whole lot of examples and that's a hard problem.

That's a hard problem for a bunch of different stuff. And AST parsing is one of those, definitely.

Carl Vitullo: Yeah. Makes sense. That's very cool though. Having that other level of… insight into, or, you know, really access into the code, it feels like it just opens so many more doors for what you can possibly do. You know, really kind of meta programming, just programming at a different level, at a different scale even.

Matt Pocock: Yep, absolutely. Although if you can avoid it, it's always better to avoid it. For instance, I worked on a project before where we used GraphQL and GraphQL codegen, and that's a kind of similar kettle of fish really, because with GraphQL, you've got this [10:00] DSL, you've got domain specific language, which contains all of the types that you're ever gonna need from your backend.

So if you take those GraphQL files, you can turn them via CLI into TypeScript. You are having to run like a sidecar development process, alongside your dev server to monitor those, to change those over, and that always provides a slightly worse experience than if you were to just handle the inference by TypeScript.

So something like TRPC, for instance, doesn't need a dev script, it's just uses a really nice API to get inference back and forth between your front end and your back end. So that's something that I've learned is that if you can avoid it, then avoiding the codegen step is the way to go.

MapleLeaf: Mm-hmm.

Carl Vitullo: Sure that makes sense. Yeah. And that's giving me flashbacks to a coworker of mine talking about Go Lang pre generics and a, a number of years ago where he would talk about like, oh, I need some standard data structure. Let me write code generations so that I [11:00] can use it with the data types I'm using.

Matt Pocock: Hmm

Carl Vitullo: So yeah, avoid code generation unless there's no other alternative. Definitely seems like a pretty reasonable takeaway there.

Matt Pocock: mm-hmm. for sure.

Carl Vitullo: I'd love to hear more. So how long were you a singer and vocal coach?

Matt Pocock: I was a so singing teacher and vocal coach. I did that for six years. I got like a master's in it. I have like this whole other YouTube channel where I'm teaching people accents and stuff. So I'm like the only person on YouTube that has to do SEO against myself. I'm competing with the name Matt Pocock against a previous version of me, which is kind of Terminator.

I did that for a long time and it felt like a superpower when it came to development too, because I felt like I could explain things a lot better to non-technical people. I felt like I could get my ideas across better than other people could. It's felt like an amazing advantage and I think meant that I went from junior to mid to senior to lead a lot faster than than I expected to [12:00] actually, because it felt like I was being put in front of clients more. It felt like I was given responsibility more often because I could explain what I was doing, and obviously my communication skills were better, or, you know were good.

Carl Vitullo: Sure. Yeah. We have talked about career and advancement a number of times on previous office hours we've done, and I think that that's a point that we hit on pretty frequently is that moving from junior to senior, one of the largest ways you can do so is by having strong communication skills.

So it's, it's, it's cool to hear you echo that.

Matt Pocock: Yeah, for sure. It really paid me back faster than I was expecting it to, because I figured I'd change from voice coaching to developer and sure, okay, we'll see. I'll take a pay cut and I'll see what happens. And it felt like I just joined with the right language at the right time, like, JavaScript still is exploding, TypeScript still is exploding.

I'm kind of interested to see what you think about this idea. I think that TypeScript itself is becoming so ubiquitous that it makes sense to learn it [13:00] alongside JavaScript as a new developer coming into the space. I'm wondering what you both think of that idea, whether you should learn, you should obviously learn JavaScripts kind of to a really good level, but should you be learning the TypeScript syntax alongside it, or should you be using the JavaScript syntax?

What do you think?

MapleLeaf: Personally I think both paths are valid, but, and because of that, if I were to recommend one path, if the ever maybe my answer would change depending on the person, but I think it is definitely perfectly fine to learn TypeScript alongside JavaScript or even just TypeScript by itself. Especially if you're coming from a typed language.

Carl Vitullo: Yeah, for sure. When I think about how I learned, the first language I learned or was taught was C++, which is, you know, it doesn't get a lot more type safe than that. And I do think that learning such a rigorous language early on and being forced by a very picky compiler to [14:00] think in terms of types in advance, and needing to think about how they all fit together and how they get changed from one to another or et cetera.

All, all the things that you don't need to think about when you're doing JavaScript, cuz it will just either do it for you or just keep trucking along when you screw it up. I think being forced to think about all those before my code would even run was helpful in some ways. Obviously it can be a huge slow down when you're actually just trying to ship code, but I think when you're learning, it forces you to slow down and think about what will this code do rather than… even in my professional career, I find myself sometimes falling into a short cycle of not actually thinking about what is this code about to do. Just kind of like, make a change, save, see what it does. Oh, it didn't work. Make a change, save, see what it does. Oh, it didn't work.

So I think in that regard, forcing a little bit of slowdown and giving you an automated checker. Yeah, I think that, I think that could be a really powerful [15:00] thing to have when you're learning a new language.

So I, yeah, I think I agree with you. I think that learning TypeScript at the same time as learning JavaScript is a really good thing for new learners to do.

Matt Pocock: The issue is material, right? Because the material out there is all gonna be JavaScript focused. Like there's not that many people who are building like TypeScript as your first language material. And I think that's a shame, you know, like I might start thinking about doing that maybe sometime this year.

The IDE support is just gonna be so much better. And often what I find myself doing when I develop with TypeScript is I tend to spend a lot more time in my IDE and less time looking at the browser console. When it was purely JavaScripts I would basically make a change tab over, make a change tab over make change tab over, just like you're saying.

But when I'm working in TypeScript, it might be, let's say 10 minutes before I even tab over and I still get a sense of whether my code is going to work or not and what it's going to do. I feel less scared by the results of my code. I feel like [16:00] things are more predictable and I think getting into that flow and making that your expectation of how you work is really good because I think what TypeScript gives you, that JavaScript doesn't give you so much, is it gives you a really, really fast time to error, right?

The time from when you make a mistake to when you know about the mistake in TypeScript is smaller than JavaScript. Shorter than JavaScript, right? You are going to know almost as soon as you call a function wrong because it's gonna give you a red squiggly line. It's gonna tell you why you called that wrong. Whereas when you were working in JavaScript, you would have to tab over to the function. It might sort of accept what you're doing, not actually throw an error, but then the thing that you return isn't quite right, like you just wouldn't get that feedback the moment that you need it.

Whereas TypeScript is, is really, really good for that.

Carl Vitullo: Definitely. Yeah. I mean with JavaScript you miss an argument and it's just gonna keep on trucking until you get undefined is not a function or cannot read property off undefined. So [17:00] yeah, definitely I think you're absolutely right there about TypeScript, shortening that time to error. I think that's a really powerful way to think about it.

Matt Pocock: Yep. It's a feedback loop, right? And you know, as web devs, we love a good feedback loop. We want it as tight as we can possibly get, and I like my feedback loops within my own IDE. Not having to tab over, not having to switch context even, to lose sight of my code. I just feel so powerful.

Carl Vitullo: Definitely. Yeah, and I know I personally have a problem where, moving from IDE to browser may not be a large context switch, but you know, the browser has all of my things, it has all of my tabs open and, you know, maybe while I'm waiting for that hot reload to finish settling down, I tab over to Discord and suddenly it's been 20 minutes and I haven't seen what the changed my code did.

Matt Pocock: Mm-hmm. . Yeah. And it's about like the if, cuz I, I'm a bit of a productivity freak. You know, I like looking at ways that I can code faster or like do my [18:00] stuff faster. And one thing that I really like is that it reduces the minimum time it takes to do something. You know, like if you are gonna code something in JavaScript, you are building in a sort of minimum time that you're gonna spend tapping over, that you're gonna spend checking the browser console that you're gonna spend refreshing the browser.

You know, TypeScript removes some of those minimums. It takes you into a place where you can actually work a lot faster because your tools are working at the speed that you are. Like, sure, people say like, yeah, you're gonna have to fix these random arbitrary errors and stuff. And, and like you said, with C++, there's always a, like a piece of that when you're working in type languages, but when it's going well, my God, it feels so much better than JavaScript can. Is that your experience too, maple?

MapleLeaf: Yeah, definitely. Sometimes I get stuck on errors that I fix just just for the sake of fixing errors, but like most of the time it's stuff that I'm like, oh, that's right. It could possibly be undefined. Or, oh, maybe that key actually isn't there and it makes me think [19:00] about like how I'm actually coding and whether or not I can just make things structurally better just solve the problem in a different way.

Matt Pocock: Totally. It makes you think about data structure first too, as well. Like I mean, you can, you can go and blast your code base with any and sort of like patch it through and get a JavaScript-like experience. But often what I find myself doing is working at that kind of meta programming level again, it's like thinking about the data structures that are going through my app modifying them and often that little extra step before you start coding, or doing the types before you start working on the runtime stuff that can give you a lot of extra velocity going forward.

Carl Vitullo: Yeah, most definitely. Yeah. And I something that one of our last office hours discussed was, Retsam mentioned, he said that one of his TypeScript jokes is that the answer is always to use a discriminated union. And I had never heard it put quite like that, but I feel like that was one of my big personal TypeScript level up moments is moving from [20:00] thinking about it sort of in the way that I had thought about prop types in React.

Because before TypeScript was really prevalent, that was how I tried to do some degree of type safety in my web apps. And with that you can say here's a a, an object blob. These properties are optional. But what really changed my thinking was not , are these optional, but do these belong to two different types of objects? Is there some discriminator where when this is set to this value, then it has this shape and when it's set to this value, it has this different shape. And then once you start thinking of it, not as this is optional, but this is only present in some cases, for me, that really shifted how I thought about designing the data flowing through my apps and really shifted it towards a more robust and resilient form of data structure.

Matt Pocock: What you're describing there is, is [21:00] basically union types, right? And. Union types in TypeScript let you basically see into every possible future of your code, right? You know, your function might be called with this, or it might be called with this. And if it's called like this, then this could happen.

And TypeScript sort of ends up being like Dr. Strange, you know, like looking through all of these possible futures for the one that can possibly work or the one that can possibly fail. And when you think about union types like that, for those who don't know, there's a syntax in TypeScript that just lets you specify like string or number.

And a discriminated union is a way of specifying an object, which let's say it has a type property, which is called the discriminator. That type might be A or B. And what TypeScript lets you do is it lets you say, okay, if you pass something with type A, then it's got a property of something with a number, let's say.

And if you pass a type B, then it's gotta be something else with a string. And so this lets you be [22:00] really clever with, especially how you declare like component props, for instance. So imagine you had like a modal where for instance, you needed to pass like a create action to it. Like this is a create type of modal where you pass certain props it lets you be really, really smart with how you define these things. And TypeScript will make sure that all possible futures inside that component and outside that component are covered.

Carl Vitullo: Yeah, I really like how you said that it lets your code see into all possible futures. I think that's a really powerful way of thinking about it. I, I think that's very true.

Matt Pocock: It feels so nice to use as well.

Carl Vitullo: So how long has it been since you changed careers into software?

Matt Pocock: It's been about six years. So I, yeah, six years. I was interested in it while I was doing my my previous career, which was voice coaching. I saw most of my clients like one-on-one, so it meant that I had a lot of times kill kind of like in between lessons and stuff. And so I would be sort of like coding up these little example apps [23:00] and, you know, flashcard apps and eventually messing with that, with web audio APIs and like trying to make stuff that would make my lessons better in JavaScript, which was a ton of fun.

It meant I sort of had no production experience when I went and got myself a job. But I knew quite a lot of really weird things about the DOM and things about strange APIs and the web and that sort of thing. And it got me interested by what the potential of JavaScript was and especially the web stuff as well. It seemed like you could do some amazing stuff if you just looked in these weird MDN docs. And I think that intro pushed me into the weirder bits of web development really early on.

Carl Vitullo: What sort of weirder bits of web development do you think you were drawn to first?

Matt Pocock: Well, I think to go back to what you were saying before, you were saying that working in C++ gave you a sense that you needed to make the compiler happy, but it forced you to think in this very rigorous way about [24:00] what you were building and what you were coding.

When I was, when I started working on web applications, I sort of felt like there wasn't a overarching structure or, or philosophy to what I was building. When I was a voice coach. There are various competing philosophies about how best to teach voice. I was a proponent of something called the Estill method, which focuses on anatomy, focuses on all of the different muscles and things to do in the neck, whereas other people are focused more on imagery and, and focused on these high-flying ideas.

But there were ideas and philosophies that were driving what we were doing. In singing teaching, nothing really changes, you know, nothing had changed for like 20 years, let's say. And I was trying to be at the cutting edge of singing teaching, and finding it really hard because there was no cutting edge.

You know? There's no edge. It's a butter knife, you know?

Carl Vitullo: Right. Everyone's on the same page already.

Matt Pocock: Yeah, exactly. Or they're in their camps, you know? It's like if the framework wars just ended, and then everyone just[25:00] sat down. Whereas web development I found immediately exciting because I could see there was a discourse happening, there was stuff going on, but I felt like, React wasn't really opinionated enough for me.

I think React is wonderful. I still use it all the time, but it didn't give me enough. And I felt like Angular was too opinionated in some terms, or using the wrong abstraction. So what I wanted to find was and I was drawn to the weird stuff, to the weird ideas that people were having about how you should structure your code, how you should structure your logic.

And that's what I think drew me to state machines because this wasn't a way of thinking about code, a way of thinking about your application that is old, you know, it's like I don't know, 50 years old at this point. I think like state charts in particular 40 years old where David Harrell started it and that felt like a sort of singing, teaching pedagogy to me, you know?

So it felt like I was joining something that had a lot of academic thought behind it and let me think about my code in a way that felt [26:00] novel and felt like the right abstraction level. So I sort of answered your question there, but I totally sort of didn't as well. Apologies for that.

Carl Vitullo: No, it's that was a phenomenal answer. It got my brain whirring in a bunch of different directions, so I think that's the best kind of answer. But yeah, I mean, what you were saying about the schools of thought, people have been learning and teaching singing for millennia, even if it takes 20 years to thoroughly explore a specific thought about how you might go about doing it. We have had so many generations of people who have made serious effort, who have dedicated their lives to serious exploration of one specific niche of it. So

Matt Pocock: Mm-hmm.

Carl Vitullo: That's a thought I've had about software before is that our field is just so young compared to humanity, compared to all of these other schools of thought, or rather to all these other industries or things that people learn.[27:00]

So it's, you know something old in computers is what, at the oldest, about 70 years. Math concepts will go a little bit deeper, you know, you get into algebra or things like that, but, Yeah, like you said, you know, state machines, they're 40 years old. That's the earliest, or state charts at least.

So I think that's a really fascinating thing to contemplate is just how young everything is and how up for active debate everything is.

Matt Pocock: Absolutely. It, it's a very nice mindset to approach Twitter with as well. Nothing matters. Like this is all gonna change in about five years or something. And I think that's what's interesting about where things are at this particular moment is that it doesn't feel like things, especially in terms of React, haven't really changed much philosophically in the past four or five years, I'd say maybe can't remember when hooks came in, but hooks I guess was a slight change of philosophy and approach, making logic a bit more [28:00] composable, a bit more interesting.

But fundamentally the mental model of React hasn't changed at all really since its inception. And it feels like it's the dominant way of thinking now, components and structuring your app in a certain way. And, and I think the interesting thing about TypeScript is that it is bringing something relatively fresh to the conversation.

Even though it's been around 10 years, it's slowly convincing people that, okay, maybe these contracts for your components are actually really important and more important than prop types let you be. They let you be safer than prop types would allow you to be. So I think that feels novel and it's, I again, that's a philosophy I can get behind. TypeScript asks you to work slightly differently than you would work in JavaScript, as we've touched on before, it makes you think in a more domain specific way.

It makes you think more about the the structure of your types and which components or which parts of your app should [29:00] understand or should rely on different types in your app, let's say you're using Prisma for instance, and that grabs like a user type from your database.

Prisma uses a codegen thing. It's one of the good codegen things. It sort of prints a load of types into your node modules. Then you can pull those out. But should your nav bar be using the exact user type that's in your database or should it re declare it? These are problems that you basically don't need to think about if you're just using pure JavaScript, but TypeScript gives you this extra level of sort of philosophical thinking on top.

Carl Vitullo: Yeah, sure. And it's an extra burden of something to think about, but once you get that muscle memory of thinking of in terms of those as like, what data is going to pass through this, where does the type for it come from? And the mechanics of importing it and making that all work pretty fluidly. You don't need to check that the data is flowing correctly like you would in JavaScript once you have TypeScript all set up.

Matt Pocock: Yep. Absolutely. And that's something that [30:00] XState gave me as well, was a sense of I was sure that what was happening was supposed to happen. It sort of feels of a piece like TypeScript helps you prevent impossible data and finite state machines and state charts help you prevent impossible states. They feel of a piece

Carl Vitullo: Yeah, I like that. I don't think I'd ever quite heard state machines and types contrasted in quite that way, but I think that's a really powerful way to think about it. It's guarantees for your data and guarantees for your logic.

Matt Pocock: Exactly. And if you're using something like Zod as well, which I've been thinking about a lot, which is a runtime, sort of schema based validation library, then you can get these sort of runtime guarantees as well. Because TypeScript is not actually type safe. It just gives you the feeling of being type safe.

You know, you can just like destroy everything if you want to very, very easily because JavaScript just lets you do that. Whereas if you're using something like Zod, which gives you an element of runtime type safety as well, [31:00] or things like Yup or Ajv, then you're gonna get even more confidence and your app is gonna be even more robust.

Carl Vitullo: Right. Oh, sure. I see. Zod is a validation library for data. So TypeScript will give you type assertions, but those can have holes in them, whether it's from any or assertions or external data, and so Zod is a method of ensuring that your runtime matches your compile time?

Matt Pocock: Exactly. Yeah. So Zod is a library for ensuring that those two match it's useful for more mundane stuff too. So, like form validation, making sure that the things passed to your API endpoints are all okay. But if you want an extra level of robustness, it makes you think about the edges of your application more, so if you're contacting a third party API that you are sort of sure if you trust, but not sure if you trust actually.

Then you can actually just validate the data that's coming back with a schema validation like Zod. And that will make sure that if the thing that's coming [32:00] back is not quite right, then it's gonna fail at that point and it's gonna fail early without infecting your app.

Because you know, the hardest errors to debug are the ones, and this happens in JavaScript all the time, is the ones where you don't protect against the thing that's coming into your app and you suddenly get undefined as not a function. And like you suddenly just, it breaks everything.

Carl Vitullo: Right, right. That, that is almost exactly the example I gave a number of years ago when I wrote a blog post about failing early and

Matt Pocock: Yes.

Carl Vitullo: the, the perils of just saying, you know, like, pass this, or, you know, an empty object. Fail early is such a powerful concept.

Matt Pocock: Yep. And fail fast too. As we said earlier, like about times script, fail it in your IDE, don't fail it in your browser console. Don't fail it in production.

MapleLeaf: As much as possible For sure. And that's that's a lot. That's a pretty big motivation behind the stuff that I've been doing with Remix, for example, like finding out how to close [33:00] the "gaps in the type system", places where mistakes can be made. And I have observed that that's a place where I feel like people need to experience it and try for themselves before they see the true value in it. I've even seen Theo himself say he didn't see the power of TRPC until he spent a bit of time with it.

Matt Pocock: Absolutely, and this is a common thing amongst people adopting TypeScript is that they don't really get a sense of how good it is or how confident they feel with it until they try it. Because I think as a JavaScript developer, you're sort of used to feeling like you have no help.

You know, you are used to living in a kind of terrifying world and it's kind of nice in the wild West because you, you can kill anything, you know, you can just do whatever you like. Like you have complete freedom, you have nothing saying that you failed except, you know, when, you know, it fails in the browser or something, you know, it works on my machine, whatever.

Whereas TypeScript does give you like you get a sort of [34:00] sense of, okay, I have this kind of English teacher like watching over my work now and giving me like squiggly red lines whenever I get something wrong and they're like right there all the time. And people who are used to the Wild West don't like that.

But it also. Gives you this immense sense of power. Sometimes it feels like you are contacting a deity. You know what I mean? Like you are just like, how the hell can you know that? That's incredible. And TRPC gives you that feeling too.

Carl Vitullo: Yeah to extend the wild west metaphor, going down and mining for gold wherever you please, it sounds great for a while, and then at some point you realize, Hey, wait a second, my labor's being exploited by robber barons.

And then that's when you start seeing the value of institutions like OSHA so TypeScript is OSHA for programming.

Matt Pocock: Yeah, it's like the NHS absolutely.

MapleLeaf: I feel like there's also a pride element, like eventually you start to think less about like being [35:00] good and doing things the hard way just to feel good about it and more about just getting stuff done, even if it means having all of your tooling hold your hand along the way, you just stop caring,

Matt Pocock: Yeah, I like the feeling that I could turn up to work drunk and TypeScript would still like be fine. It would still prevent me from doing mistakes. And actually I think to be honest, like with tools like GitHub co-pilot with chatGPT, it's gonna be even more important to have tools like TypeScript that can hold the hand of experimental AI stuff before AI takes our jobs.

It's gonna be important to have guardrails so that you don't just spew out random code, cuz you are right Maple. Like, that's a really good point, you feel powerful when you code in JavaScript in TypeScript, you don't feel powerful, you don't feel powerless.

You sort of feel like, okay, I'm, I'm in dialogue with something. I'm pair programming with something. Whereas [36:00] JavaScript feels quite independent. Does that sound like a fair characterization?

MapleLeaf: Yeah.

Carl Vitullo: Yeah, I think that make sense.

Matt Pocock: Yeah. Well, like, so this then the feeling of using TypeScript, I love the idea that I can just not have to think.

And obviously this takes a while to get into the mindset of thinking in types and thinking about the flow of data through your app. But once you are there, then you just feel like you are having your hand held the whole time and it's a lovely experience.

Carl Vitullo: I think that I personally have found that how TypeScript has affected my thinking when I'm programming is largely through making me think, how can I make this auto complete better . VSCode gives me such a rich intellisense, a rich sense of what data is flowing through that when I end up deciding to go deeper on some specific type, it's because I have discovered a flaw in the intelligence.

Like it's, it's not telling me the right thing or it's not telling me the most specific thing it could, and that has been my [37:00] personal driver for trying to learn more, trying to get better, is hitting some friction point and thinking, Hmm, how can I use types to give me more information?

Matt Pocock: That's a lot of what I'm thinking of covering in my course too. Like a lot of javaScript if, even if we don't think about it in this way, is built around functions, you know, like functions, functions, functions. Everything in JavaScript is a function. Everything in React as a function.

And with functions, you are basically declaring a contract. You are saying this must be called in this certain way and it returns a certain thing. Even if you're not experiencing like that. And if we didn't use functions, like imagine that world, then you would be able to get pretty good inference on basically anything because everything would be static.

You would just have the stuff you've got and then the objects and like TypeScript will understand the objects that are there, the variables you've declared. But when you have a function, then you basically put a [38:00] barrier in that inference and you lose a bit of The dynamism that you can get just by understanding all the stuff that's in the file and inferring it and blah, blah, blah, blah, blah.

Except when you use generics. So generics let you pull in TypeScript inference to basically be able to infer the output of a function from the input of a function or infer things about the inputs from other things you've input to the function. So it gives you a lot of that dynamism and that's, I imagine that that's where you're going with that Carl with like you trying to get better and think about this stuff more?

Carl Vitullo: Yeah, that's definitely a part of it. It also makes me think of a distinction that has come up before in events we've done is the, the, the concept of like app types versus library types. And for the different approach that you have to come at the types based on what context you're writing them in.

And I think things like generics in functions is [39:00] one aspect of that. Because libraries might be used in so many different contexts, then they have to be written with types that are flexible enough to support all those different use cases, which I think is a real challenge.

Matt Pocock: It is. Yeah. Especially with most of the things people use libraries for, they're going to need some kind of dynamism in them. Data fetching libraries, the dynamic thing is what you're fetching or the arguments that you need for that. The form libraries, the the state of your form is going to be the dynamic thing, and each of these can be expressed in generics.

You are right in that there's this kind of divide between app types and lib types. And often if you're using an app, then you are going to need to basically just be a consumer of those library types. And often the most painful errors that you are going to get are when you don't understand those library types well enough or you can't read the declaration files.

A lot of what we think of as kind of like [40:00] the most complicated transcript areas to solve, There. When you interact with third party libraries and you are looking at types you don't understand, there's often this huge wall of declarations if you like, find in definition and stuff, and that can be the most terrifying experience for a new person.

I think this stuff is not as hard as it seems. It's an extra little learning curve, but the tools that we have make working with generics really, really nice. There's some stuff to learn and some new syntax that looks really, really alien.

But if you can be the person who goes, okay, I'm gonna add a generic to this function. I'm gonna make a generic table components that can accept any kind of data and render out a beautiful table. If you can be the person that adds that to your team, then that's a senior level job that you've just done. TypeScript and advanced TypeScript really puts you in a position of being able to enable your team members to give them a developer experience that they've could hardly even [41:00] imagine before.

And what that means is there's code that will depend on you, right? Or like depend on knowledge of advanced generics. But really, if you look at it and understand it and go through some of the material, it is, it's not as complex as it seems. And what I'm finding is there's a lot more use cases for generics in the application code than I really realized.

I've been looking at a lot of, kind of like, as part of the course stuff, I've been looking at a lot of open source apps and I've been using this AST parser that I had talked about before to scan them for the advanced generic stuff that they're doing. And there's a surprising amount there actually, even if you're building little libraries that can be used across your organization, then knowledge of advanced TypeScript is kind of like a prerequisite actually from making something that's good and that works. I know Maple, this is where you spend most of your time, right? Is thinking a lot about this stuff and, and your work with Remix too.

MapleLeaf: Yeah, definitely.

Matt Pocock: And what kind of like, is that affecting like your stuff at [42:00] work as well? Or like do you do any application level stuff with advanced generics or is it mostly library stuff?

MapleLeaf: At work, it's pretty simple since the stuff that I haven't the stuff that I work on doesn't get too deep in the weeds when it comes to TypeScript. It's definitely like more of my personal projects where I think about like, How I can take the abstractions that I have and how I can improve upon them, and that's when generics are more or less required.

Matt Pocock: Totally.

Carl Vitullo: Yeah, I definitely agree with everything you just said about if you can improve the developer experience for your teammates, that's like a senior developer moment. I really feel like that's been one of the driving motivators behind a lot of my learning and advancement up towards senior, you know, in the like three or four years it took where I felt like I was progressing from early career into like, no, I am senior, I am established, I know what I'm doing.

And just really looking for opportunities where you can [43:00] improve the experience just a little bit. Because every time you can save yourself five minutes on an ongoing basis, just by removing a point of friction, you're saving that time for everyone else as well. I think that that kind of focus of and skill development for developer experience really pays dividends over the long run. When people talk about a code base that's drowning in tech debt, I think that's what they're talking about is months or years of lack of attention on developer experience.

Matt Pocock: Absolutely. And one thing that's interesting about generics is that when you add a generic to a function, you're basically saying when people use this function, they won't need to annotate it in any way. So by you doing more TypeScript, you are basically saying, okay, every other member on my team needs to do less TypeScript.

They can work more in like just without, after annotating anything. You know, it's literally just JavaScript. I [44:00] find that kind of the most compelling argument for bringing a more advanced TypeScript mindset into your work, which is if you do it, other folks won't have to.

Carl Vitullo: Agreed. Yeah. A thought that I have put to words at various points in my career is that like, really one senior developer can support four or five junior or mid-level developers. And I think that the actual nuts and bolts the mechanics of how that support comes across is exactly what we were just saying.

If one person has the expertise to get the experience in a certain way, Then everyone else on the team doesn't need to think about it because it just works for them. I think that mindset and that approach to software development is, tying it back to another programming meme, maybe that's what a 10 x developer is, is someone who allows the other nine people on their team to work faster.

Matt Pocock: That's what a DX developer is definitely.

Carl Vitullo: DX, haha.

Matt Pocock: People say like abstractions by default get a bad rap [45:00] these days, like avoid hasty abstractions and all this stuff. But if you find the right abstraction and you build it in the right way or the right set of abstractions, you can save your team an enormous amount of time.

And like it's so satisfying to like, imagine that you've got a team of people that are building components that are super similar or building hooks that are super similar. If you can find a way to abstract out the stuff that's the same about them and you can find something that's DRY find something that works and you can use TypeScript to bring that all together in a beautiful DX and massively increase your team's velocity then, I mean, my God, that's, that's such a satisfying thing to do in your own career and have the congratulations from them and see that your work suddenly just got easier.

Carl Vitullo: Definitely, definitely. Yeah. That reminds me of one of my most memorable wins of my entire career. It was this sort of like [46:00] hacked together, rigged up server side rendering monstrosity. At the time I joined every time they made a change, they had to kill the server process and restart it. And because it was bundled with Webpack, that meant they were starting with a cold cache on every change.

I joined and eight people had dealt with a minute and a half long build every time they made any kind of change to the code whatsoever for months. And so I came in and I said, wow, this is unacceptable. I bet I could fix this. And me and two other new joiners who didn't have any assigned tasks yet, just spent three hours and just got a watch mode working.

Like all of the, all the only change, like we didn't change the code, we just changed the build process so that it supported watch and rebuild and that got the the rebuild time on changes down from a minute and a half to 10 seconds and. I still have that on my resume as one the biggest wins of my career because how many times do people run a rebuild a day? How many people are on a team? [47:00] How many hours a month did I just save?

Matt Pocock: Like as developers we're often one layer away from the people that we're actually helping. You know, like we're building tools for people that we don't actually see, you know? So often the way that you can feel a bit of reciprocity, that you can feel the impact of what you do is by helping your colleagues, and that's definitely been one of the most satisfying things in my career is, is focusing on that.

Carl Vitullo: I like that. That's a really pleasant way of thinking about it. The people you're helping are your colleagues.

Matt Pocock: for sure.

MapleLeaf: Yeah, definitely.

Carl Vitullo: All right, well, we are coming up in an hour here. Matt, thank you so much for coming out. This has been a really lovely conversation.

Matt Pocock: No worries at all. Lovely to meet you both.

Carl Vitullo: Yeah. Absolutely. Well, yeah I, one thing that I, I thought I might close with and I'm springing up this on you a little bit, but has there, have there been any books that you think have been uniquely impactful in your professional career?[48:00]

Matt Pocock: I'm not much of a tech reader, unfortunately. I know that there's a couple of really excellent books about TypeScript, like Josh Goldberg's TypeScript book Effective TypeScript.

Carl Vitullo: Any not related to technical topics?

Matt Pocock: Well, I'm reading a book about the Invasion of Sicily in 1943 which may not be to everyone's interest, but I, I find it absolutely fascinating. That period of history is just full of incredible high drama. So I'm gonna take my wife around there at some point and go, this is the bridge of Ponte, whatever that, you know, that took oh, so many people to take aren't you fascinated? And, you know, she'll be asleep in the car, so.

Carl Vitullo: Be your own historical tour guide. That sounds like a fun time.

Matt Pocock: Can't wait. Yeah.

Carl Vitullo: Yeah. And you're working on a course right now, right?

Matt Pocock: That's right. I'm working on Total TypeScript which is, it's at totaltypescript.com. We released the first module which is all about transforming types to other types. And the second module is dropping soon which is all about generics, actually. So an intro to generics. Then the third module is gonna be about advanced [49:00] patterns in TypeScript.

Carl Vitullo: Thank you so much for coming out. It's been really great talking to you.

Matt Pocock: Lovely to meet you

David K Piano

Reactiflux — Wed, 09 Mar 2022 16:00:00 GMT

# Q: I’ve tried a few times to introduce state machines, at least as a planning tool, in teams I’ve been on, but haven’t gotten much uptake. do you have any suggestions for how to help teams think in terms of state machines? – vcarl

Sure, one of the best first steps is to start planning by diagramming. Think about the following things:

What are the "modes" my app (or parts of my app) can be in?
What are all the events (user events, internal events, etc.) that can happen?
What should happen when those events occur?

You’ll soon start to realize that these can be organized under those different "modes" (which are finite states) and you can draw your boxes and arrows based on that to determine how your app is supposed to work.

Big topic, I’ll probably write a blog post on it

# Q: I understand the purpose of XState in vanilla JS and I have used to build a pure JS app , but it’s difficult to make a use case for it when writing code in React JS – amaankulshreshtha

XState shines for complex app logic. Many apps start off simple, but they don’t stay that way after you add many features, consider use-cases, fix edge-cases, etc.

It’s also a communication tool - sure, there’s many ways to manage state, but XState also helps you communicate state & app logic visually with the rest of your team.

Some common use-cases are for multi-step forms, handling sequences, complex components, animations, wizards, coordinating global logic with multiple components, all things that you can do with a state management library, but you’ll end up creating an ad-hoc state machine anyway (with none of the benefits of an explicit one)

# Q: What is a state machine? – Mujeeb

A state machine is a visual formalism that describes: "When I’m in some state, and some event happens, now I’m in a different state and these actions are to be executed"

# Q: Where do you see the future of XState going in terms of feature support/wider adoption/easier onboarding, etc? – iggy

We’re working on releasing an alpha of XState version 5, with much improved TypeScript support, an easier actor model story, and even more statechart features, as well as modularity and a bunch of other improvements under the hood.

We really want to support XState for server-side workflows as well as for other use-cases (think chatbots, home automation, testing, etc.) and of course we want to improve the Stately tools for visualizing and analyzing state machines with XState.

A docs rewrite is also being planned, with interactive examples and more beginner-friendly (and choose-your-own-adventure) guides.

# Q: Why did you found Stately, and what is its business model? – Bart

I founded Stately because XState (and state machines in general) has become too important to just be a small side-project, and the community around it has definitely grown. We also want to build amazing visual modeling tools related to state machines, statecharts, actor model, workflows, etc. and that requires a team… and we have an amazing one! (Also, we’re hiring!)

# Q: How do you think about Redux in relation to XState, does it make sense to use them in the same app? I’ve used the XState web app for planning, but have then modeled the state machine using Redux actions/state. – vcarl

You can use XState and Redux in the same app - their philosophies are a bit different. But machine.transition() is just a reducer, so it’s definitely possible.

Redux does not have a notion of declarative effects (they have a new action listener middleware which is similar), which is one of the big areas where Redux and XState differ. The state machine "philosophy" is that effects (what XState calls actions) should be declarative and part of your state, and not an after-thought.

Some more differences here: https://stackoverflow.com/questions/54482695/what-is-an-actual-difference-between-redux-and-a-state-machine-e-g-xstate/54521035#54521035

Also, using XState (and/or our Stately tools) for planning/diagramming and the implementing it however you’d like (library of choice) is something we love seeing - and we actually plan to support more state management libraries in the future with our visualization tools!

# Q: Are there any good guides on "scaling up" a state machine to more than something like a stoplight? e.g. a machine big enough to try to represent the state of an entire application, and splitting that up into bits and pieces – MapleLeaf 🍁

Yes, and we’ll be writing even more guides and examples on this on our blog: https://stately.ai/blog

Our own Matt Pocock did an XState docs speedrun that goes more in depth on how to "scale up" state machines and think about modeling for more advanced use-cases: https://www.youtube.com/watch?v=2eurRx-tR-I

# Q: My team had developed a multi step form in React Native, and we were using a counter to maintain the progress of a form, and we would pass that counter value to the next screen with the help of react-navigation. If we do the same thing with XState, wouldn’t that increase the complexity? – amaankulshreshtha

It would not; in fact, I’d say it make it clearer. Instead of doing counter++, you would do:

first: {
  on: {
    NEXT: 'second'
  }
},
second: {…}

Not that much more complex, and much much more explicit 👍

# Q: As a pianist, what would your perfect idea be for a desktop piano app? – ThimoLS

One of my first projects I’ve tried as a junior dev was a music theory teaching app… wrote that in Backbone!

# Q: What’s the hardest parts of creating and keep your company grow that you did face? – Ameen

Wearing so many hats and keeping up with so many meetings, and learning that development is a small fraction of the overall business. It’s definitely a new world, and I’m learning more every day. It’s been very fun so far though!

# Q: Any top tips for new developers starting their careers? – JolteonYellow

Find an area you’re passionate in and really dive deep into it. Contribute to open-source if you have the time as well.

# Q: How popular do you think/estimate XState will become in the community in the future? – Sam Samrichs

It’s still "early adopters" phase IMO, but it’s at almost 20k stars! It’s the "defacto" state machine library, at least for JS/TS, so now it’s just a matter of getting developers en masse to realize "hey, state machines are useful"

# Q: Do you have a demo with a multi step form with react-navigation. It will be of great help 🙏🏻 – amaankulshreshtha

I’m sure there’s one floating around - I collect resources and things other people have made here: https://xstate.js.org/docs/about/resources.html

# Q: What kind of app would demonstrate that you have some proficiency using React? – diego-felix

I’ve taught React Training workshops with Michael Jackson, Ryan Florence, Cassidy Williams, and talked at a few React conferences… does that count? 😉

# Q: How well does XState support dynamic states? I.e. when the states themselves depend on user input? – Bart

That’s under the domain of "extended state", which is represented in XState using context. So you can get as dynamic as you’d like with context + assign(…)

# Q: Your way to manage async state? – Piyush

With XState, "async" state is just an extra loading state that you can explicitly state. But if you don’t want that level of granularity, you can invoke any promise… and even observables, callbacks, or other machines! So it’s still async-friendly.

# Q: What changes would you make to state machine libraries like XState to make the interface more readable or understandable to newcomers and experts alike? – astronautshark

Our big bet is on creating visual tooling for this - visualize the XState code you write, or even create the state machines without using code!

# Q: How are you currently funding Stately, or what is the business model behind the company? Is the company going to sell tools, consulting, services, etc? – Redacted

We’ve (quietly) raised a small seed round for this to support our team. We’re improving our open-source libraries and tools, as well as creating apps & services, such as the visual editor (an "IDE" for app logic), registry, cloud-based workflow tools, etc. that will be free for basic use

# Q: If there were a re-write of routers for an SPA, would XState be the ideal choice? – amaankulshreshtha

It’d be an interesting choice! Routers are sort of like state machines, but you can go to any route at any time. But especially for multi-step forms, it’s useful to express routes as a state machine often.

# Q: State machines are fantastic! Why haven’t they been embraced in the "backend" of things? We get a lot of crazy events responses in the backend and a lot of the time, all we can do is, handle events with if `else’s and retry "stuff". It’d be instrumental in having a LONG LIVED state machine in the server. To compare, we can have an FSM for dealing with an AJAX request in the front end. Maybe on success, we want to transition the page into another state, and then different events can communicate with THAT event. We typically have to rely on databases tables and columns, but it makes it hard to see the "overall" image of what’s going. – dilraj

I love this question. They have been embraced, implicitly! Whenever you work with a workflow engine (many popular ones out there), they’re really basic state machines. There’s also BPMN which is like a higher-level, business-oriented state machine. With statecharts on the backend, I believe we can go further and express even more complex logic on the backend in a visually clear way.

# Q: I don’t understand what XState is exactly! Can you explain what is the main goal of XState? – maryamrmz

XState is a state orchestrator. Just like state management libraries (Redux, Vuex, etc.) let you manage state, XState does that and lets you orchestrate state, so you can clearly define what the different behaviors are in your app. This prevents impossible states/transitions, and makes the logic visualizable and robust.

You know how you’re not allowed to talk when this message box is disabled? That’s a state! You can haphazardly use a boolean for that, or you can make that explicit in a state machine.

So instead of littering if (!enabled) { … } calls everywhere, you’re reversing that logic and making it state-based. That’s what XState is for.

# Q: And what makes the XState different? I mean. Why people should choose XState? – maryamrmz

You should choose XState when you need to clearly define logic (what can happen when an event is received) for different states in your application, including which effects should be executed. Most state management libraries do not have declarative effects, which is a big reason why app logic gets so messy, because you have to handle that somewhere and it’s unclear where that should live.

Another reason to choose XState is to communicate app logic with the rest of your team, even if they’re not as technical - designers, PMs, etc. XState allows you to visualize and simulate your app logic.

# Q: Is there another design pattern apart from state machines that would provide complete control over the system? – amaankulshreshtha

I mean, … sorta? There’s petri nets 😂 But anyway, the question is not "should I use state machines or not?" because you already are, technically. Rather, the question is "should I make my state machines explicit, or keep them implicit?"

# Q: Do you have a rule of thumb for when the complexity in code starts to merit using state machines to model it? – vcarl

My rule of thumb is when I have more than 2 states and more than 2 events. If you start seeing this…

const [isFoo, setIsFoo] = useState(…);
const [isBar, setIsBar] = useState(…);
const [isBaz, setIsBaz] = useState(…);
// …

then please please just use a state machine.

# Q: I think a lot of more Jr. folks (myself included) have a hard time envisioning the journey from a blank slate to something like XState. What did your development journey look like? Any major roadblocks or difficulties? – DepartureAM

Do you mean creating a library like XState, or using XState in an application?

# Q: I used XState to help me "prototype" what my system was going to look like. Suppose, I was happy with my machine and wanted to deploy it (the project got deported before I got there), is it possible to get a real diagram like this once it’s out there in production? If so… how exactly can one see this? Or is it just for prototyping purposes?

– dilraj

With the VS Code extension, and some of the future tools we have planned, our goal is to have your diagrams from state machines be ✨ living diagrams ✨ that stay up-to-date with your code. So yes, this is possible and we’ll be adding this is possible and we’ll be adding even more features to this area in the future.

# Q: Can we get a VS Code extension to visualize a state machine if we write the code for it ? – amaankulshreshtha

Yes! And @dilraj this answers your question too: https://marketplace.visualstudio.com/items?itemName=statelyai.stately-vscode

Hasura Team

Reactiflux — Wed, 09 Feb 2022 16:00:00 GMT

# Q: What are your thoughts on upcoming Haskell alternatives such as Purescript and Idris? Do you think Purescript is a viable replacement for GHCJS for web development, and Idris might be for other purposes? What other alternatives do you have your eye on? – anonymous

Purescript is probably the most mature option for web dev imho, in this set of alternatives. Idris is not yet very mainstream and still a little bit of a research language. Elm is also something I keep any eye on and another really good option in this space. – tanmaig

# Q: Remix or Next? – Angelo II

It depends. 😄 But also, not joking. They optimize for different ends of the spectrum. If I was building something with lots of real-time data that needed lots of dynamic layout components (admin panels, etc) I'd have a look at remix for sure. The next ecosystem is still very robust and if it comes to delivering something I know will handle the 80% use-case, it's still my go-to. But I think Remix has a really interesting use-case for a highly opinionated stack – jmart

Adding to what Jesse mentioned, it depends on your use case. Server Side Rendering at the edge by Remix is going to be fast. But right now, Next.js with its ecosystem and the ability to do a combination of SSR, ISR, static export is easy to reason about. – praveenweb

# Q: I feel super low on mental health and my eyes hurt a lot because of screen time. Any tips on how to keep myself healthy as a programmer, especially my eyes? 🙏🏼 – alixsep

Consider maintaining your health as part of your job. It's a task like any other that can't be negotiated with.

First, minimize eye damage when you need to look at the screen. Make sure there's distance behind your monitor so your eyes can break from near to far. Make sure your resolution is high enough and consider a blue-light filter if the strain is really bad. Try to avoid working in dark environments as the contrast switching strains your eyes more. I'd highly suggest adopting pomodoro technique to force a screen break. There's some cool apps that will lock your screen up for you. – jmart

# Q: How can I build a custom GraphQL query using raw SQL in hasura? – Aki

By custom GraphQL query, if you meant hooking into what Hasura generates, you have a couple of options. Writing your own GraphQL resolver and adding them via Remote Schemas. If you prefer to write REST APIs and add them to the GraphQL schema, you can write a REST API handler and map them to GraphQL types to perform custom business logic.

Sorry, I just now saw the edited version. If you have a raw SQL query and want that to be exposed as a GraphQL query, you can either create a Postgres View or create a Postgres Function and expose it as a GraphQL API to the client. – praveenweb

# Q: socket io or ws for react websockets? – Angelo II

It depends on if you want to run the server yourself or not. If you are consuming, ws or graphql-ws if you are working with GraphQL subscriptions would be my suggestion – jmart

If you are using GraphQL, ws is a standard protocol to interact with APIs for realtime use cases. graphql-ws is the latest – praveenweb

# Q: if you don't mind me asking. what was your main motivation behind building something like hasura? – Mawlicious

Great question. It was a massive amount of frustration with how long it takes to build backends and this feeling that we're working at the wrong level of abstraction. 🙂

Tried lots of different kinds of approaches before we settled on the way Hasura works today.

This might be an interesting read: https://hasura.io/blog/how-hasura-works/ – tanmaig

# Q: why did you start coding? what is your motivation? – Angelo II

I'll let the others add their two-cents, but I grew up in a house with other programmers, and it seemed like a "good idea at the time" - wish it was more fancy. At some point, I realized I should go "all in" – jmart

# Q: What do you see as the perfect positioning of Hasura in the overall infrastructure? e.g. use it directly as backend, or place a backend between it for handling logic, authentication, etc. In the same manner, what would you consider the perfect "Hasura-stack"? – mees

Good question! I'd say it's really up to you. 🙂 We're building Hasura so that it can be the frontend / recipient to API consumers directly. However if you prefer having something in the middle, that's totally fair as well 🙂

Choosing a good Hasura stack depends on one of 2 use-cases:

Is your end deliverable an API?
Is your end deliverable an app?

I like a serverless stack for the logic/authz backend piece.

So something like AWS Lambda (or choose your fave serverless function vendor) + Hasura + Postgres DBaaS + (choose your fave authn SaaS vendor) would be my recommended Hasura stack! – tanmaig

# Q: Why did you choose Postgres instead of another “flavor” of othe DB choices? – Elsewhere

Postgres fit the majority of use-cases and was a very widely adopted tool that fit with the OSS ethos. But we support more than just Postgres today! – jmart

# Q: which database do you recommend? – Angelo II

Personally I'd go with Postgres for the 90% because it's a very good general tool. But there are some edge cases where you'll want something very specific for the job you are solving. That's partly why we are opening to having more than just postgres! You can bring in BigQuery or MSSQL, for example. – jmart

# Q: What language did you first learn? Do you still use it today? – Pod

I started with PHP / JavaScript (jQuery). I still use JavaScript both on the server and client. – praveenweb

# Q: Did you use apollo client or relay? if so, what was the reason you used that over the other? – BlueForced

I've switched away from apollo for my personal projects because it tries to own too much of the stack, I needed a more lightweight utility since Hasura does the heavy lifting. That said, I'm 100 having another look at Relay especially after their recent docs update. It's a great tool. – jmart

If you are starting today, I would use something like URQL for the GraphQL Client since its lightweight, easy to reason about client side caching and realtime subscriptions are nice to setup. Relay is opinionated about data fetching but is super powerful. It also depends on the underlying GraphQL server to have support for Relay spec and hence you may or may not have the choice. – praveenweb

# Q: What's for you the most important skill a programmer should have nowadays to be successfull ? – dzetah

Thinking. If you can think like a programmer (analytical, algorithmic) the rest is just about tooling. No amount of craft or language expertise can replace that. I know my languages pretty well but I'm surrounded by amazing developers who just "out think" me on a daily basis and it's awesome to see. – jmart

# Q: why would i pick GraphQL over REST and is it worth the transition? – Mawlicious

GraphQL is excellent when you have lots of different data types and origins and want to combine them in a single endpoint that you can distribute to lots of different teams. GraphQL allows a "self-serve" approach to data consumption that enables product teams to simply move FAST. If you have a legacy infrastructure that will only ever consume REST, then you might want to stick with that, but Hasura, for example, lets' you provide both! – jmart

# Q: What is Hasura? – 🥔🥔🥔🥔

Here's a slightly detailed breakdown of what Hasura is and aims to do: https://hasura.io/blog/how-hasura-works/

Easiest thing to do is to take Hasura for a quick spin - esp if you like playing around with GraphQL 🙂 (https://hasura.io/ and https://cloud.hasura.io/) – tanmaig

# Q: do you find Relay more data-efficient (makes less requests and uses less data bandwidth) than Apollo client or URQL? – BlueForced

I would say so since that's part of what the tooling is for. It looks at what you are using and attempts to combine it into the most resource friendly query and cache strategy. That said, you can certainly replicate that efficiency and perhaps surpass it with Apollo, URQL, et al, but Relay just does that almost perfectly out of the box. – jmart

# Q: what other services are competition to Hasura? And how do you differ with them? – f8_overcomer

While there's no direct equivalent to Hasura, there are perhaps 3 main types of services/technologies that Hasura overlaps with:

BaaS type products: Here Hasura's edge (and also downside in a way depending on what you want!) is that it doesn't take opinions on other things like storage, authn and is designed to provide the data API on new or existing databases. Today with Postgres-family / SQL Server / BigQuery and gradually with other popular databases as well. This is very impactful esp for teams that already have databases
GraphQL databases: We're gradually seeing databases that natively speak GraphQL becoming popular! This is awesome. Here Hasura's edge over them, is that a) Postgres is often a better option that betting on a new database entirely b) You can always use a GraphQL database along with Hasura + Postgres by bringing that in as a remote schema to Hasura! So you can use 2 databases simultaneously depending on your use-case.
DIY API: Here you're thinking about the choice of building your own API vs using Hasura. Hasura aims to give you an experience where you only think about your domain's data models and your domain's business logic (that could be deployed with, say, a serverless vendor) and not really the build/setup/deploy/operate/optimize lifecycle of an API server. I linked to this post above, but this blogpost might help in understanding how Hasura works: https://hasura.io/blog/how-hasura-works/ – tanmaig

# Q: Hasura has come a long way and I love using it, so thanks for that. What do you see as the areas in which you are still lacking, feature-wise, and what do you intend to work on in the near and far future? – mees

This is speaking from a personal perspective here. The biggest feature lack area for me and one where the company is focusing on is more databases. There's lots of different work loads you store in different data stores and getting them into Hasura and meshed with the API is a big focus. – jmart

# Q: Do you have any tips on handling authorization in a mid to large app in hasura? I have found that it can get quite confusing setting individual permisions for every field and worry about the security implication of "missing something" – roboticsound

This has indeed been raised in the past when the app gets complex with lots of permissions. The Hasura Console currently has a Permissions Summary view to give an overall picture of what permissions have been configured. Another way to think about security is to use the Allow Lists feature to specifically allow only a list of GraphQL operations to avoid exposing everything on the schema. But we are working on improving the UX around managing permissions in bulk so that you can apply them in bulk. – praveenweb

# Q: I'm a noob when it comes to scaling/provisioning, especially when I need to interpret "20 GB data pass-through". Could you tell me what kind of project are supported by the standard cloud offering of Hasura? By kind, I mean the size of the project, the number of users using it, etc. Thank you for your input 🙏 – binajmen

The standard cloud plan is a pay as you go plan that auto-scales as your app scales. This means apps of any size are good to be hosted with High availability and auto-scaling. The data pass through is dependent on your API usage and response sizes. If you are caching your queries, then that would help in reducing the data pass through usage. – praveenweb

# Q: what are your thoughts on postgraphile, and do you have any plans to allow [self-hosted] extensibility ala postgraphile's makeExtendSchemaPlugin to allow foreign data sources? – (d,f,g)=> {}

This might not be a direct answer to your question since I'm not very familiar with makeExtendSchemaPlugin, but on the theme of allowing foreign data sources and making that easy: We're working on something very interesting (currently named GDWs - GraphQL Data Wrappers, inspired by Postgres's FDW Foreign Data Wrappers ofcourse) that will allow people at Hasura, data-source vendors, and the broader OSS community to build Postgres FDW like extensions to Hasura in their favourite programming language and get the power of the Hasura GraphQL API!

We haven't talked about this anywhere yet 🤐, so you heard it here first and more news coming soon! 🙂 – tanmaig

# Q: are nested mutations in the roadmap? – roboticsound

# Q: Are there tools like Postman for GRPC? – Mehrdad

I'd have a look at https://stoplight.io/ – jmart

# Q: what led you to the decision to not use postgres RLS and policies to enforce authorization and instead create your own authz mechanisms? – (d,f,g)=> {}

Tanmai can add to this, but he wrote up about it here, too. https://news.ycombinator.com/item?id=20065529 – jmart

# Q: What was the reasoning behind naming it "Hasura", sorry for the weird question i typically have a hard time in naming – Mawlicious

The name Hasura comes from a portmanteau of Asura, the Sanskrit word for demon, and Haskell. Asura refers to daemons, or computer programs that run as background processes. Haskell is the functional programming language we used to build Hasura in. – praveenweb

# Q: As a founder @tanmaig whats "keeps you up the most at night"? and what are you most excited about? – Gabe

😄 Hah! Great question sir 🙂

What's keeping me up at night?

Oof, so many things! But broadly, I'll characterize them as the work that goes into "company building". As Hasura usage is growing in companies big and small, and as our team is growing, I'm working alongside everyone at Hasura to help them own different bits of Hasura (the product, the community) and keep building things that will push the needle for our users and keep adding value to them.

What are you most excited about?

In the short term: Streaming Subscriptions! This is some incredibly exciting work we've been doing to allow Hasura to stream massive amounts of data, or realtime events as they're being ingested over GraphQL subscriptions. The performance is :chefkiss: and the experience is incredibly exciting 🙂

In the longer term: GraphQL Data Wrappers - per my comment earlier! But more on that soon, and I'm trying not to let too much of the cat out of the bag before we make an announcement 🙂 – tanmaig

# Q: Are there any good (and modern) resources to learn relay you'd recommend? – BlueForced

We wrote this a while ago and can be a good resource - https://hasura.io/blog/deep-dive-into-relay-graphql-client/ and of course Relay's official docs have a simple getting started guide too. – praveenweb

# Q: What were the primary motivators for moving away from haskell? Did it come with all the expected benefits or were there unforeseen setbacks? – rabbit

The core graphql-engine is still written in Haskell. Or do you mean something like how GraphQL Data Wrappers could be built? – praveenweb

# Q: If a friend would ask you about which Postgres DBaaS to choose, what would be your answer? 😇 – binajmen

If they are testing it out and hacking around, I'd say go with the built in Heroku integration. If they are wanting to kick off a serious project, I'd suggest Aiven or Fly.io - if they have investors who might get mad, I'd suggest having a look at an AWS solution. 😄 But Aiven and fly.io are my hipster picks for the moment. I've also been happy with raleway. – jmart

# Q: Do you usually suffer from over-dedication, and if so how do you deal with it – Mawlicious

It's hard to answer that as folks working in a startup! We're so aligned to our mission and there's a tremendous amount of blood and sweat put in 🙂

I think about it as productivity and sustainable productivity. That's what we've got to be able to do to both be happy and do the best for our users!

Not a direct answer, but hopefully helps! – tanmaig

# Q: I've been studying the 4 day (32 hour work week a lot lately --> https://4dayweek.io/benefits) and I've seen it work at quite a few startups including my own (increase in productivity and happiness). Have you every considered it for Hasura @tanmaig? Would love to know why you think it would work or it wouldn't in your org. – Gabe

We do atleast one 4-day week a month - and we've been doing that for over the last 2 years now I think. So that's been our baby step so far. 🙂 – tanmaig

Tabnine Team

Reactiflux — Wed, 26 Jan 2022 16:00:00 GMT

Q: What advice would you give to students studying CS in university today? – HomemadeToast

I think one great tip that really has helped me is to build fun projects on the side. There's nothing like building something you enjoy and have fun with beyond the standard curriculum. That's just one tip off the top of my head 🙂

Q: Will Tabnine be available for Vim? – BSK

Thank you for the question! Tabnine is actually available for Vim as well as many other IDEs! You can check out the different Vim installations here: https://www.tabnine.com/install/neovim

Q: What is the best way to learn React? I'm getting started but on my own. – Billy

I think this question gets asked a lot. I'm no genius in React myself, but when I was getting started I built a site I really needed. This ties back to my previous answer.. there's nothing like building something you're truly excited about.. that would be the greatest way to get the ball rolling. That of course coupled with great resources.. one I loved was TheNetNinja's stuff. He has some really great videos. Worth checking him out, as well as Sonny Songha who does awesome builds.

Q: Most of your value proposition seems to be around 'team level AI' and privacy. How does that still benefit individual developers compared to Copilot? – Kim

Kim.. that's a great question! Thank you.

You're definitely right about Tabnine providing the most added value for teams collaborating on projects. The great thing currently about Tabnine for individuals is that they can still connect their GH repos and have Tabnine train a custom, private model, for them as individuals. This works really well and has been getting great adoption, beyond the Teams product. Privacy wise I think I'll dive a bit deeper later, that's a whole topic I'd be glad to cover!

Q: How is tabnine different from copilot? – dhavall08

Copilot is great and we're excited to have Microsoft in the market, as its great market validation for us, it shows that AI assisted software development is here to stay, which is something we’ve believed in for a while, but it’s nice to see that a tech giant like Microsoft also shares this vision. In terms of how they differ, each tailors to slightly different crowds. Tabnine offers team models and is great with anything privacy related, whereas Copilot is using slightly heavier models. One of the biggest differences is definitely Tabnine's team product, while Copilot does not offer. Licensing wise, Tabnine is trained only on fully permissive open source code, whereas Copilot is trained on all the code on GitHub. So, naturally, Copilot will sometimes give stronger predictions, but its a tradeoff game.

Q: When will PayPal be accepted as a payment method for tabnine? – Togira

Unfortunately, I don't think it'll be coming in the near future. I hope that will change but as of now that is the case. We can hopefully find a creative solution, maybe write to support and they might be able to help..!

Q: Why I should use tabnine? I don't really see the advantages of ai completions yet. For me it's because the code or solutions are not neat enough – M4rcinek

Well, this is something we are constantly working on making better for the user. It is really, really hard to give great predictions that are easy to consume and speed up developer experience rather than slow you down. We have made many improvements to the models and to the UX in the past months and I urge you to give it a shot! I also got you guys 50% off Tabnine Teams for your first 3 months if you want to give it a shot at https://tabnine.com/promo/reactiflux

Q: what do you suggest me to do as a developer to both keep up with my job and have healthy life? what I mean is I am currently completely damaging my health by using PC for long periods of time and my social skills have gotten very bad. my eyes also see a bit blurry. any tips? – alixsep

Vitamin D is a big one here, that's just my first tip! You have to get outside, and take breaks. I absolutely love my job, but still make sure to step outside every once in a while (I know it's hard in the winter..!) but it's super important. Remember – you can't do your job reliably over a period of time if you aren't healthy – mentally and physically.

Q: Tabnine is a very unique type of program. It being "AI" powered, I imagine there is some Neural network in there. Can you explain in short how such a program works? e.g. which steps does it take to go from a bunch of text to a single suggestion? Or is it more like a black box? – mees

I can touch on this, but of course it's just a very general overview. Tabnine models were trained on MILLIONS of lines of code from all over the internet. These models are constantly evolving as well. When you type in your IDE, the client interacts with the model and "asks" it what would be relevant to what you are doing. There is of course a massive neural network in this, and managing memory to deliver suggestions reliably and quickly is a tough task, which is why we use Rust for most of the engine. (sidenote: we ❤️ rust)

Q: Hello Ron, thank you for your time. Do you think bots can beat humans at poker reliably? Do you think a bot can reliably figure out if a human or a bot is playing poker? – alpha_ulrich

Haha great question..! I don't know about Poker specifically, but AI is rapidly evolving. Look at how it plays Chess, for example. Seeing as Poker is also a game of emotion and "mind games" I don't know how quickly AI will be able to beat humans.. but hey, I have no idea and am excited to see what the future holds!

Q: I have bought tabnine about 4 months ago. I have to say the free version is actually better than the paid one. I have so many usless suggestions and the good ones ive had when there was only one, were far better. It feels underwhelming :( – Origin

This sounds weird to me, I'll be honest. Please DM me and we can maybe look into it to make sure you're getting the right experience! 🙂 I'll be happy to help.

Q: What do you do to stay active and overcome social media distractions? – Billy

As I said earlier, get your sun! And the best way to stay productive and overcome social media.. is pretty harsh but.. keep the phone out of the office. That's the only way I've found effective.

Q: Long time tabnine user. Couldn't live without it, but with the future release of github copilot: why should I stay with tabnine, and what does tabnine plan to offer in the future to stay competitive? Thanks – Roboto

That's a great question Roboto, thank you. We are doing a lot to stay competitive, including working on integrating into other places in the development cycle (coming soon!) as well as providing stronger, next gen models. As I said earlier, two of the serious differentiators are our Teams product (training custom models and learning from your team's practices) as well as privacy and licensing. I have to say that custom models trained on specific repos are doing really really well and I invite you to give connecting your GitHub repos a shot! I think you'll be impressed.

Q: If I use TabNine, how much of my code goes back into training? – alpha_ulrich

None. Yep, that's right, I said none. We don't train on your code. The only time your code is used is to improve your LOCAL model. We don't take any of that back, and in fact, we have no idea what even goes into it. It is a fully automated process, and the code is encrypted on its way out and deleted immediately after, making for a secure and safe experience.

Q: Why don't you train with our code if we give you permission? Is that something that can/will be added in the future? – ImDarkk

There are so many great, public sources of truth out there to improve our universal models. Your code is used only to improve your experience. We don't want to run the risk of infringing your privacy, and the same goes for licensing. When training you a PRIVATE model, your code is used for training but that is only for you. As I said, no one, not even Tabnine, sees the code going in.

Q: If I use tabnine on my laptop and on my pc with the same account, lets say I use it 90% on my pc and only 10% on my laptop, will tabnine offer me better suggestions on my pc since it's being used more? and if that's the case, is there something I can do to sync the models? – Togira

That's a good question – I'm not sure actually, I'll have to check for you! You can DM me, but I think if you have cloud enabled, your models may sync

Q: what type of network model do you use in tabnine (transformer, rnn)? – lapfed255

We're using transformer models. It's actually quite tricky to effectively utilize RNNs these days as they're quite slow and cannot digest the massive amounts of data a model like this needs to see. There are other reasons for why transformer models are great, but yeah, ever since they entered the game, the whole space has taken a huge leap forward.

Q: Is tabnine integrated with VSCode – alpha_ulrich

Yes..! You can get Tabnine for VSCode right in the marketplace or at tabnine.com/install/vscode 🙂

Q: How do you assure code quality? Of course open source projects are full of great stuff, but on the other hand control over the code is more fuzzy. – czyzu1710

That is a great, great question. There are some trade secrets here that unfortunately I cannot share, but we invest a great deal of time ensuring code quality. Making sure you train on quality code is probably one of the most important aspects. Or rather, giving the proper weight to great code. Otherwise, you'll just get GIGO (garbage in garbage out)

alico Actual: Q: will ai write better software than humans in the near future? – Leafeon

Well, the short answer is no. AI is evolving and will continue to assist us in many aspects of our lives, including in software development. The main reason I don’t think AI is going to be replacing developers anytime soon is mostly because much of what a developer does is understanding the spec and intent of the project. AI can do specific tasks but where it still lacks is in that aspect. The way we see it is that AI and the developer are a team. The AI won't be writing better software than the dev, it'll just be making their experience much smoother, allowing them to focus on the important and creative parts of software development.

Q: Is there any chance you will integrate blockchain tech into your model by allowing people to "mint" code that they wrote so that the model can learn from them and maybe even reward them with some incentive (crypto, etc.)? This seems very interesting to me. This way, no code would need to be stored on any servers, mitigating much of the costs on your end. – HomemadeToast

That isn't currently on our roadmap, but sounds mega interesting. I am a fan of blockchain technology, and this could be really cool.

Q: Will TabNine have block code generation based on comments, like Copilot? Or it already does? – lapfed255

You guys are going to have to stay tuned and hold tight with this one..! I promise you won't be disappointed. The short answer is that you should look forward to better models, longer completions and more this year 😉 But that's it, no more spoilers!

Q: Does TabNine get data from our code to train itself? – JS_Artboy

Nope. None. I answered this a couple questions ago, Tabnine does not and will not train its universal models based on your code. There's enough excellent code out there for us to not need to infringe on your privacy.

alico Actual: Q: how much does ai reduce development or debugging time, or otherwise improve the coding experience? where can i go to find information on that – Leafeon

That's a great question! I don't know about AI as a whole, but Tabnine specifically has shown to save between 15-25% of developer's time, and writes between 25 and 35% of their code..! if you're using Tabnine, you can see the insights inside Tabnine's Hub, it's pretty cool. (click on Tabnine in the VSCode status bar and you'll be taken to the hub)

Q: How do you think Tabnine goes with learning how to code? IE if I'm learning to code will it help me to improve my skills or the opposite, slow this process down? – czyzu1710

Czyzu, that is a great question. We have a bunch of students using Tabnine and actually provide them with the option to get some of Tabnine's premium features using their student email. From what we've seen, it is helpful to many intermediate developers and can definitely help when starting out, it's kind of a matter of preference. I urge you to try it out and see for yourself 🙂

Q: Does TabNine support Solidity or Vyper? – alpha_ulrich

Hmm.. not too familiar with those. My guess off the top of my head is no, but you should check at https://www.tabnine.com/install

Q: How much of the tabnine codebase is written by tabnine itself? 🤔 – Jasper

Hmmm. Short answer is I have no idea, but I'm guessing it's also around the 20-25% mark. Again, most of Tabnine was written.. well. with Tabnine 😅

Thank you all for having me and for asking great questions! It was really fun and I had a great time. @Gabe thank you for setting this up. If anyone else has more questions – please DM me or write them in our Tabnine discord server -> https://discord.gg/QzQjrMmagd

Nikhil Nandagopal

Reactiflux — Mon, 13 Dec 2021 16:00:00 GMT

# Q: Hey Nikhil, what was your biggest chokepoint during appsmith development so far and how did you overcome it? – Nomish

Hey! Great question. I'd say that performance was our biggest bottleneck. Building an entire IDE in the browser and evaluating JavaScript of an entire application brought apps to a screeching halt. We tackled this by moving evaluations to a worker thread and by implementing a subtree algorithm that would only evaluate the widgets that changed

# Q: What mainly inspired you to reach where you are today, Nikhil? – Topnex

I'd definitely say my mom had a huge role to play in this. She is one of the hardest working people I have ever seen and she set the bar really high for me in that regard 🙂

# Q: What do you see as the most common (or relatively frequent) use case for your toolset? – Fork501

A ton of internal tools are built on Appsmith today. Pretty much anything and everything that used to be built with Django Admin and Bootstrap templates. Some of our top use cases are things like customer support dashboards, inventory management tools, CRMs, generic admin panels, and some teams even integrate GitLab with Appsmith to trigger their CI/CD

# Q: Hi Nikhil, how would you put into words what low-code design is and what is unique in such systems? – sharathkumar

Hey Sharath 👋 low code design is unique in that it's very meta. You're designing a framework that should allow its users to build and extend it how they see fit. We've had to invest in a lot of different areas here.

We made our widgets plugin based so that anyone can contribute and add a widget to the system
We made our data sources are integrations also loosely coupled with the core underlying platform so that we could add/modify data sources with little to no effort.
We designed the platform to enable running JavaScript anywhere so that developers never feel like they are without an escape hatch.

# Q: Great tool! Why did you opt for support of GraphQL so early in the game? – ShubhankarKG

We decided to support all forms of REST APIs early on because we knew that teams had lots of internal APIs already created and creating a broad REST plugin like Postman would make the tool useful to a lot of developers. This came with GraphQL support out of the box since GraphQL is a type of REST API but native support is still lacking a lot in the current tool. We're working on this right now in fact 😄

# Q: Hey Nikhil, I am Vik. I have heard many developers being kinda scared from no-code. Can no-code harm the code community? – Vik

Hey Vik 👋 I've heard this fear too and I really disagree with this mindset. In my opinion, no-code / low-code is just a new abstraction of existing programming frameworks. It in fact helps create more developers and more opportunities for developers by lowering the barrier to built applications. Today we all love frameworks like React / Next.js because they make our lives easier. while if we looked back 10 years ago, it wasn't really very easy to build rich web applications! I see a lot of developers who don't trust no-code in terms of flexibility and performance, but I really think tools like hasura and appsmith are the future. Do you think that at some point these tools will become as natural a choice as Laravel/Node for example? Technically speaking, what is needed for this barrier to be broken?

# Q: How does AppSmith compare to something like Retool? – eggtarts

One of the biggest differences between Appsmith and Retool is that we're an open-source platform. We really believe in building a tool that developers can easily adopt, extend & use without ever having to worry about vendor lock-in. Retool makes that really hard to even get started with. We're also very focused on the developer experience and have some awesome built-in features like

Native Debugger inside the platform
Javascript snippets & documentation built-in
Self-hosting for everyone
Intelligent autocomplete

We also believe that the best software is built-in teams and on that front, we've enabled real-time collaboration through comments & Git Integration on the platform. Teams can now build apps together!

# Q: If I wants to copy AppSmith and built a company around it. If possible, What do we need to built one apart from oss code and a great team? – AKA

I think the community is an essential piece of the puzzle here and a community can only gather around a unique product or point of view. Simply copying the code because it's open-source wouldn't help and would probably in fact deter you because you'd spend most of your time trying to fight against some of the decisions that go against that unique outlook!

# Q: Hi Nikhil, with tons of alternative to Appsmith, how do you make sure to stay ahead of the game ? – AnonymousSlogger

Hey! We really believe that the only way to stay ahead is by being focused and differentiating our product. While there are quite a few tools out there, you'll find that very few of them are open source, almost none are developer-focused and absolutely none have a community like ours 🙂

# Q: Hey Nikhil, thanks for being here! I see a lot of developers who don't trust no-code in terms of flexibility and performance, but I really think tools like hasura and appsmith are the future. Do you think that at some point these tools will become as natural a choice as Laravel/Node for example? Technically speaking, what is needed for this barrier to be broken? – BL4CK

Hey! Great question. We also believe that no-code is too in-flexible to build apps and that's why we built Appsmith as a developer-first low-code platform. You can write code in a full-fledged JavaScript editor inside Appsmith! We believe that code is an essential part of application building and is the best way to express logic (validations, workflows, conditional chaining, transforming data etc.). What we don't like is having to deal with writing a lot of boilerplate for static HTML elements, dealing with boring styles, configuring data sources, and creating CI/CD pipelines. Appsmith takes away all the boring stuff leaving us with doing what we love the most - Writing Code! 🙂 I think technically speaking one of the most crucial elements is improvements in the way apps are run in the browser. This is one major bottleneck to improving the adoption of these tools.

# Q: Hello Nikhil, Thank you for doing this Q and A. How did you get this idea for developing appsmith? And what's the advice you would give to youngsters following your path? – memehunter

Hello 👋 I started Appsmith because I hated building internal tools. I've built them at small and large companies alike and the one thing I always noticed was that they were dreadfully boring to build because they were essentially CRUD apps that were custom to the business. They also looked terrible because they never got any design / product bandwidth so I could never really be proud of my work. This got me thinking that there had to be a better way to build custom internal tools.

In terms of advice, I'd tell you what we tell everyone who joins Appsmith - Be proactive & coachable. In the early days of your career no one expects you to have all the answers but being proactive to find the answers and taking feedback to improve goes a long way in getting people to trust you. This, in turn, leads to more opportunities to work on more exciting projects and learn more!

# Q: Where is custom logic stored in appsmith? The DB? If so, How do you version without checking in the code? – Scottmas

Hello! Yes, pretty much everything including the page layouts is stored in the DB. The code is returned to the client that passes it to a render engine and creates views as well as an evaluation engine that runs the code to generate the current state of the app. This is then bound to the views. We're currently working on an integration with Git where users can check in their code to their own Git repositories! https://github.com/appsmithorg/appsmith/issues/3199

# Q: What are your views on WebAssembly and it’s future ? – AnonymousSlogger

I haven't used WASM personally but in the words of my team: "WebAssembly is awesome!". Anything that helps improve performance is a big leap towards richer web applications and that is a future I'm excited about. It's also really cool that it lets us run other languages in the browser which can be a game-changer for python devs using Appsmith 🙂

# Q: People learning DS just to get through the interviews, with no passion. How do you take this – AnonymousSlogger

It's an unfortunate by-product of the software world today which is why we try to refrain from this in our interviews. Appsmith interviews connect problems that we actually solve inside Appsmith. The things that we optimize most for are

High Agency mindset
Love for what we're building

It was great engaging with you all! Do check out https://appsmith.com/ 🙂

Erin Fox

Reactiflux — Wed, 08 Dec 2021 16:00:00 GMT

# Q: Hello! So I have an associates degree in website development, can I get a remote job in react, if so what should I study to make myself more valuable? – 匚卄卂几

You definitely can get a remote job that uses React. Many jobs now-a-days are remote first and use React! I would study JavaScript fundamentals and then dive into tutorials, etc on React.

# Q: Hi @erinfox I'm not familiar with your work, how would you describe your day-to-day at convertkit (which I'm also not famliar with)? – (d,f,g)=> {}

For the past year and a half I've been a full-stack engineer at ConvertKit. Our product is a Creator Marketing Platform that helps creators earn a living online. Whether thats digital commerce or email campaigns. I am on the builder squad so I work on the email editor. It's a lot of fun. Oh and I am remote! (I focus on react and rails lately)

# Q: We’ve struggled a bit with RN in a monorepo environment. Any experiences with working with monorepos and the tooling around RN regarding that? We tried rush and quickly changed to lerna, which we are using now… – Rintsi

Ah yes, I only have experience with micoservices with RN. The smaller repos worked well for us when launching the app. I would look into Infinite Red and their blog posts. They should have more information on monoreps

# Q: What about the big issue when working with React and other backend API which is the interface. There is no way to integrate typing and signature in the IDE. Is there some way to achieve this? – shadoweny

I only have experience with Node for the BE with React Native, and at the time it was my first job! So I am not as familiar with architecting it.

# Q: What's the biggest challenge you've faced working on an email editor? – (d,f,g)=> {}

Oh my goodness. So many! Honestly.... tables 😂 We write react components for our web version (email editor and landing pages) and then we have to make sure it looks good within emails. ESP are wild. We use Litmus A LOT to check our components and write a lot of tables. It's not the most fun... but we got to do it.

# Q: What's your thoughts on TailwindCSS? – op

I LOVE TAILWIND. We use it at ConvertKit and the developer experience of it is fantastic. There is a bit of a learning curve to get it rolling, but once you get it its fast and fun. (But I would learn basic CSS first!)

# Q: How important are complex algorithms on your day to day basis working full stack with react? Is it necessary learning some of them in detail before applying? – honeypot

There are definitely some complex functions and algos happening in our code, but I would not say I write them everyday. It's good to go over them when applying for jobs, but I would ask the hiring manager for the job you are applying for to know what to expect before learning something you won't need to do right away.

# Q: Hi Erin! How do you deal with prefernce differences between developers on your team? For example, one developer likes arrow functions and another doesn't? Thanks 🙂 – Louis

Great question! We all have our favorite ways of writing functions and editors. We try to keep things uniformed and the way we keep it that way is through code reviews. All PRs are reviewed and approved by 2 other engineers. That when we give feedback and come up with solutions as a team.

# Q: Javascript or typescript, and whay? – mazin

I have been avoiding Typescript.... so I have to say JS alll the way. (for now 😂)

# Q: What is your ideal stack for a react native app? IE. Component library? state management? Querying? expo? testing? Styling? Etc – AriK

oooo love this question. Let's see..... RN, Storybook, Tailwind, GraphQL/Apollo, JS Testing Library, and expo is sooooo nice too

# Q: I'm curious how much control over visual design someone working at a larger company with an already established product has. How much visual design is left to do? Do you have someone telling you exactly what something should look like or is that something you decide? – Jooooo

At ConvertKit, we get a lot of say on designs when we are coding a new project. Most issues come from sticking with the design system or pushing back on what the designer wants to form a compromise. Usually larger companies have small teams with room to have the communication. Overall, it depends on the company and the way your workflows are. Some are loose with it and others are more uniformed.

# Q: What is your thoughts on remote work? Do you prefer it to working in the office? Does it affect your teams communication and productivity? – KNDRK

I actually hated remote work at first. I was 1 of 2 remote workers on a team of about 20, and the rest were all in the office. It took working at ConvertKit and learning how to do remote the right way to fully fall in love with remote work. I love the flexibility. I am not sure I can go back to in office!

# Q: Hi! what’s your favourite thing about working with RN and your most hated thing about working with it? – simon

I love mobile anything. I believe it's the future for about... everything. That's what I love about RN. It's scrappy and the fact that any JS/React engineer can hope over to write mobile code?!?! That's amazing. I dont like..... that not enough people use it

# Q: I would like some general advice regarding how to migrate from react web to react native. I have been working with react web for the past 5 years and will start at a new work in a couple of months are they run their app I react native. What to consider? Pros and cons (in general), resources to learn that you prefer? – vhlongon

Ah! Congrats! You're about to expand your knowledge so much. I learn RN first, and then moved to Web. The biggest struggle for me was syntax (no more divs, now it'll be Views). I think you will be able to make the mobile switch easily. There's a lot of patterns with both React & RN. The RN docs are fantastic. They were not this good when I started out. There's also a GREAT Frontend Master's course for RN.

# Q: For a rn app you are building alone, why use graphql + apollo over something like Rest + react query? – AriK

It depends on the size of your app. I have a silly little cat app I made with Expo that does not use GQL/Apollo since it just a small thing. But I can see using that combo for more enterprise apps.

# Q: What's your view on React with Rails backend...I tried it once but user authentication and managing session was a pain...Do you think express is better? – Lateef Azeez

At ConvertKit we use React and Rails. We use Devise for authentication. It's a magical mystery box that comes with a lot. I would look into that to see if it could help. I haven't tried express with that mix before.

# Q: What process does your team follow to determine what is added to the component library? – kelseyblake

We try to follow our design system components as much as we can. We have a "frontend" slack channel where we talk about components and if it is reusable enough to add to our component library.

# Q: From your experience what are the pros and cons of using expo or a react native barebones project? Which use cases those 2 approaches fit in general? – vhlongon

Both projects I've worked on started off with Expo, then ejecting it so we can go the next level. Also depends on the project!

# Q: You mentioned GraphQL and Apollo. What do you use for authorization? – Rintsi

I think Apollo has authentication and authorization that help with your app control access. I would check out there docs as I am not as familiar with it.

# Q: Do you think crypto will be essential for any developer in 2022? because it's been a while that I've seen crypto coding abilities in every new job required skills. as a react developer who hates typescript and crypto? what do you suggest me to do? force myself to learn them? – alixsep

My advice is to do work you are excited about. If that's react, great! If that's crypto, great! The skills you get from them will help you out throughout your career.

# Q: Who would be more desirable, especially in a company like ConvertKit, an expert nodejs developer or another front end? – Weismann

Hmm I would have to create my own option and say a Rails expert 😂

# Q: I'm looking to create a typescript react component library, but there seems to be few resources on best design practices for components. Have any resources or things to keep in mind? Its difficult to use bigger library source repos like Bootstrap/MaterialUI as they seem a bit otu of reach for an individual dev. – msrobinson

Oooo good question. I would look at tailwind for inspo, and think about using Storybook for the library. "Best practices" is a hard question since everyone has their own thoughts on what is "best"

# Q: Preferred state manager (s) nowadays? And any significant difference from web to RN? – vhlongon

I still like React Hooks! I still think they are so fun to write and with useContext and useReducer.... :chefs-kiss:

# Q: Followup (kind of). What are your thoughts on typescript vs javascript for creating front-end apps. Does static compile-time checking outweight run time errors, or does the dynamic development process outweigh the overhead of type creation? – msrobinson

I have zero experience with typescript so have to lean towards JS all the way.

# Q: Thoughts on Svelte? – Level

Haven't used it, but it sounds great! Anything about improving UI sounds worth a try

# Q: Have you used styled components ? I understand you like tailwind, but do you see any downside of using it? Particularly for me was that lack of ergonomics to work with dynamic values (create dynamic styles base and props, etc). – vhlongon

I've used style components before and think they get the job done. We try our best to keep everything with tailwind, but there are times I have sticky css situations where style components would be helpful. It's hard to commit to one and they both have positive and negatives. (Not the best answer haha sorry!)

# Q: How have u solved problems around folder architecture and structure considering scale – ayo

I thought I was good at folder structure and then I started learning rails and it's a hot mess! It's much easier to organize your own projects than huge a monorepo. Lately, I'm all about DDD (domain driven design) and try to map everything out folder-wise first.

# Q: I’ve worked 7 years as a full remote. What do you find to be the most challenging thing in the way of working full remote in terms of team dynamics? – Rintsi

I think the hardest part is getting lonely. I love my team but sometimes I need some face-to-face interactions. I'm an introvert, so it feels against the rules to say that! But learning how to balance remote work and in-person things is hard for me.

# Q: Favorite programming paradigm? Object Oriented, Procedural/Imperative, Functional? and why – msrobinson

Functional! It's madness, but I like it.

# Q: What would be your suggestion to someone who want to learn Rails (currently on Nodejs)? – Lee

I hate when people says this, but read the docs. The rails docs are great. I have trouble finding (updated) Rails tutorials or post. If anyone has some, let me know!

# Q: Working with RN, do you find you ever have to dive over to the native side to adjust components that don’t quite do what you need or do you stick more on the JS side of the tracks? – simon

Totally. I think that's part of the beauty with RN. It has the flexibility to create "native" components. Sticking on the JS side is the goal, but in the end, you might have to dive deep. But then you get to learn so much more!

# Q: Is your email editor open source? – teut

It's not 😦 that would be real cool if it was though. Maybe one day

# Q: Hi Erin! How do you approach version control inside your team? i.e. what platform you guys prefer, branch organization, workflows, commits messages or something you specially want to highlight – MilDeBuñuelo

Sorry! Missed this one. Hmmm we do most of our communication on GitHub and when we need to update our design repo version we deploy it pretty quick. We aren't the best at keeping up with versioning, and it's something we and I need to learn more about to keep up to date. Always something to improve with!

Ali Spittel

Reactiflux — Wed, 17 Nov 2021 16:00:00 GMT

# Q: Hi @aspit! I guess we've all seen the "developer advocate" term thrown around a lot - what exaclty does a developer advocate (at a company?) do? – BTM

Oh that's an awesome question, and I think it differs a lot at different companies. What I do is to try and be the voice of a developer internally. I have my team advocate for different developer personas. For example, I used to be a teacher at a coding bootcamp so I advocate a lot for new developers.

I'm on new products from day one giving advice on what developers would need to see to make the product successful. Then, before launches I do audits of those features to make sure they're something I would personally be very happy to use and would make my life easier as a developer.

Then I share how to use these things with the public, creating content through various platforms, giving talks, etc. And always make sure to take any feedback I get from that to the engineers and PMs building our stuff 🙂

# Q: How do I start learning AWS? – Priyank

A Cloud Guru is my favorite resource for learning Cloud stuff. Egghead.io has great stuff too -- I have another course with them coming out soon!

# Q: How did you learn how to code in JavaScript ? And what are your suggestions on how to learn it efficiently – staticalliam7

I learned JavaScript specifically because I was a backend engineer and our frontend devs kept leaving the company! So I taught myself JS in order to fill in the gaps. My advice would be to build stuff as much as possible -- don't get stuck in the tutorial trap where you're reading/watching stuff and never going beyond that. Challenge yourself to make projects and learn all the steps to build them. Then you have something for your portfolio too!

# Q: How many components does a typical major React website such as Netflix or Facebook have on average? A range such as 100's or 1000's? – Ev1dentSnow

In my experience, thousands or even more than that.

# Q: What was the most difficult thing you’ve had to learn? – kristalshards

C++, it was so hard to do manual memory management!

# Q: Hello Ali! Actually recognize you as a twitter follower. Actually what I'm curious about. How does having an online following affect day to day work? Do you think it has caused more or less scrutiny on your work? – BreadDog

Ooh that's a really interesting question -- I think it changes it -- a lot of people feel like they're entitled to criticize my work even though they only see a tiny % of it. 75% of my job is internal, 25% is external but some people think my job is to tweet or something! But it also allows me to build up awesome connections both with co-workers on different teams and with the general public!

# Q: What do you think best describes the difference between a Library and Framework – Reian Viloria

Oh -

Library: code you can use that someone else wrote that makes it so you don't need to reinvent the wheel

Framework: Makes it so that you have to write your code in a certain structure

# Q: Is the dev advocate sort of a part time side job with social media related stuff or main job where you have your own coding responsibilities? – Spark ✨

I explained above what I do as a developer advocate! I code more as a DA than when I was a senior software engineer though. I build out a lot of demos to test our products and to teach them. So lots of lines of code to do that, it's just different code that doesn't go into production. Much more greenfield code than brownfield.

# Q: Ey thanks for popping by. I've been in the software industry for too long now, and there's always been one looming question. It's not intended rude as I think it's common knowledge at this point but: Why is are AWS interface features and educational materials so bad? I've learned a lot of things throughout my career, and anything touching aws seems to always end up being a headache and a half. Is it a factor of teams being split up? a lack of developer feedback? Rate of change issue? – Austin

I definitely can't answer for AWS as a whole, but I try really hard to make a great developer experience for Amplify for both resources and our interfaces. Please let me know if there's anything from Amplify you're looking for or that we can improve upon, that feedback is wildly valuable to me!

# Q: How much time do you spend on coding per day, and how do you manage your time for maximum productivity? – Hinn

I'm a manager now, so I do write a lot of code but also manage people and do developer advocacy work as well. I would say I probably spend ~2 full days a week coding. I wrote a blog post with my full productivity workflow -- sorry for the plug but there's so much to write here https://welearncode.com/productivity/

# Q: Do you think rust is the future? – xjoe

I'm not sure! I like that it's being used to speed up so much tooling. I'm also really excited for WASM and I know that Rust is a big part of that ecosystem right now as well

# Q: Recommendations for finding a mentor? – Hache

I'm not sure I've ever had an official mentor 🙂 BUT I always learn so much from the community and get so much value from having dozens and dozens of people to learn from.

# Q: What would you recommend to a junior frontend developer who’s been recently hired? – kristalshards

Take notes. I use Obsidian personally to link bits of knowledge to itself.
You only get to be new once. Use that as an advantage. Ask lots of questions, and audit the onboarding process for the next person. If you're on a developer product, then audit the learning process of it. That feedback will be so valuable to your co-workers.
Stay hungry. Keep learning and growing. Especially when you're new to the field.

# Q: How will Amplify and AWS fit into the metaverse – AEM_XR1

HAHA no clue on that one, sorry 🙂 We do have VR libraries though (shameless plug)

# Q: What do you think about Next.js? Would you use it in a production-grade applications? Also, incredibly inspired by you, thanks for many interesting tweets and talks – mic0

I ADORE Next.js -- it's so great. I would for sure use it in production, in fact our docs team is at work! I use it for the majority of my code now. Thank you so much!

# Q: Do you think the rate at which web frameworks come into then lose popularity is slowing down? – lazyb

YUP I was an engineer in 2015/2016 when it seemingly was new hot framework everyweek. Now we've stabilized to a few main contenders, and a huge React pull ahead.

# Q: Do you think we are moving towards serverless in general? – denik1981

YES I love serverless. I spent the first few years of my career manually deploying stuff to servers, and it's so much work and requires so much knowledge. Now I can type up a Lambda Function, push it, and I have a live app I don't need to worrry about nearly instantly.

# Q: What advice you gave to mid-level engineer to accelerate in his career more wisely and timely – ZeeshanKazi

T-shape your knowledge. Be an expert on something, but also have shallow knowledge on a lot of topics.
Know your worth. Switching jobs is okay and is often the easiest way to get promoted.
Keep a "wins" document that logs the awesome stuff you're using. Use that for promos/writing/combating impostor syndrome.

# Q: How to write the most optimal/performace optimized react code? – alixsep

Oh good question -- I'm personally using SSR and SSG a lot so that the pages pre-render. OH also lighthouse tests aren't perfect, but I always run them anyways to just see the lowhanging fruit I can optimize

# Q: Have you tried svelte? – lazyb

Yes! It's really great. I want to use it more. Right now though, when creating educational content so many developers are in the React world, I feel like I can help the most people there.

# Q: What do you think about react native. Will it keep growing or fall due to limitations. Do you think it’s better than making native apps. – tinglyracoon6

Ooh so I am not at all a mobile dev so I don't feel super qualified to answer here, BUT I've been hearing amazing things about Flutter and that community (shameless plug I'm hiring a Flutter dev if anyone's interested)

# Q: How to master react fast? – alixsep

Don't focus on the speed of learning. Focus on incremental progress. But basically build things. Build a lot of things that really challenge you. Maybe a React shopping cart for ex.

# Q: What is your advice to enhance your own skill level? At my team/company I have the best knowledge in web/cloud development and I struggle to enhance my skills – Browork

Teach. I stand by the fact that you have to know something so in-depth in order to explain it thoroughly and simply to someone else. Lead internal workshops or create public-facing content if you want.

# Q: Typescript or dart 😁 – lazyb

TS!

# Q: Have you ever been freelancing? If so, do you have any tips? – mic0

I used to do some freelance work. My big recommendation is to have a page that explains what services you offer and pricing so that if it isn't going to work on either side then you don't need to waste a huge amount of time on calls. Plus know your worth here, especially if it's a side gig. What price do you put on your freetime?

# Q: How to mange Components in a large codebase .Bcz it's been hell even to memorize during work.? Is it any tool out their.Directory structure makes them complex to mange... – ZeeshanKazi

I would get really good at your text editor's search functionality. Memorization is overrated!

# Q: What do you recommend for new programmers who want to learn? I feel like I'm just stumbling around from YouTube tutorial to Youtube tutorial trying to figure it out along the way. – ShrequilleONeal

Sorry to keep sending blog posts but I have a series on moving past tutorials: https://dev.to/aspittel/moving-past-tutorials-8-tips-for-problem-solving-3e0p

Also, on the science of learning: https://welearncode.com/learning-tips/

# Q: Besides coding I also make music. (Hiphop). I wonder if that would hurt my chance for being hired. what should I do? hide it? or no let my music be there? – alixsep

You don't want to work for an employer where you have to hide part of yourself. Don't hide it.

# Q: Any tips for someone young trying to get hired? – fish

Yes! I was 19 when I got my first programming job -- I cold emailed a startup telling them I liked what they did and would love to intern for them (paid). That turned into a full-time job a few months later. Get involved in the community. Build a portfolio. Don't rely super hard on online job apps - as a hiring manager you often get hundreds of applicants.

# Q: Arrow functions or normal functions? – mic0

arrow! I'm an 👵 and was writing JS before ES6 though 🙂

# Q: What would you recommend someone learn who has a good understanding of react. What would you ask them learn next, i.e next steps? – ball_gladder

Ooh a testing framework, how to build component libraries/design systems, maybe data viz -- but it depends on their interests and what they know outside of React

# Q: Hi, I’ve been using React from around version 0.13, so have a massed a lot of components, can you recommend a way to manage and maintain these for use in multiple projects? – 0.5Xer

Build your own component library!

# Q: If you had to say, what are a few of the largest drawbacks to something like AWS Amplify? – Elsewhere

Before this week I would have said the ability to color outside the lines, but we launched CDK integration this week so that's solved! It's an opinionated framework which has a lot of pros, but some cons as well. Build times can take a while, we're working on that but that's one drawback. Also, it's built for frontend/mobile developers, so if you don't fit inside that persona there are other options that may be better.

# Q: What your opinion on Redux? ) – Aleksey Kozin

Used Redux for many years! It's amazing, but I would definitely read articles about why you may not need it first. Now a days there are so many other tools

<a href="#what-are-the-"perfect"-projects-for" name="what-are-the-"perfect"-projects-for"># Q: What are the "perfect" projects for young developers to have in their portfolio to get the job? – Lucas

I like games -- they require a lot of logic. Also complex UIs like shopping carts, table filters, etc. Make yourself do something full stack so you can show that you'll be able to communicate with devs on the other side of the stack.

# Q: I've noticed you've mentioned in your blog profile you're into code art? any starter recommendations? i'd love a new creative outlet. (also have you seen react three fiber? looks crazy cool) – Austin

SO COOL -- I love P5 to start out with, it's really user friendly. I've also done fun interactive stuff for things like offline pages for sites. Always fun.

# Q: Do you think amplify will add support for users to login using a web3 wallet e.g MetaMask? – lazyb

Forwarding on that request to the product team 🙂

# Q: What is your favorite text editor? – Slayer

VS Code! I've been using it for like 5 years at this point, way longer than any other one I've used

# Q: What to expect the first month as a junior dev? – kliff

First, get your computer setup with a dev environment! Then ask your manager for a low hanging fruit ticket. They should give you something early on that will help you learn the code base, but isn't too far outside your comfort zone. Then on to maybe a larger issue 🙂

# Q: What is the biggest issue of modern web development? – Aleksey Kozin

I think pushing the limits of the web. Apps like Figma are doing this with WASM -- there's no way you could build that with normal JS and have it be useable. I'm excited to see what more companies can do in that realm. Building really cool things that are still performant

# Q: I'm a 2 year VueJs dev that started learning React recently. Do you think it's hard to grasp React coming from other frameworks? – Silviu

Yes! A ton of the knowledge from one converts from one to the other. The first is always the hardest.

# Q: Does working on a one-man project actually harm your coding skills? (given there are no code reviews and the scope is a lot smaller than it would be in a real business application) – Jonny

It goes both ways -- I was a one-woman team for parts of my career and it allows you to do everything which is a challenge you don't get in large teams/companies. But yeah it's more difficult to learn/get reviews. I think a balance of both is really good and if you are the only person at a company make sure you're getting involved in the community/have mentors.

# Q: Do you think decentralised systems, like decentralised graph database GUN (https://github.com/amark/gun), have potential to replace Cloud in the future with rise of Web3? – Aky

My former boss Nader Dabit is really into the web3 space. I think it's cool, but there are a lot of issues to resolve.

# Q: What are some examples of junior dev "Task" how much should you know for the position? – kliff

I would say at first, well scoped issues, fixing bugs that are constrained to a small part of an app, features with clear definitions.

# Q: An extension to my last question: What is the best way to get "good" clients as a freelancer? Thanks for your questions, they are incredibly helpful. Take care and stay safe everyone – mic0

Build a brand. Be known as The Person for a small thing. If you have that reputation people are more likely to already trust you on that topic!

# Q: What tips can you give for a junior react developer? 🙂 – Bete

Oh similar to the ones above for jr developers generally, but keep learning. Don't silo yourself to just React, don't build your career on one technology. go beyond that!

Ahmad Awais

Reactiflux — Wed, 13 Oct 2021 16:00:00 GMT

# Q: How's your code run on Mars? – Piyush

Honestly, it's through open-source. I made a small teeny tiny PR in bootstrap core that went to mars — the kid in me was super excited about it. The bigger idea here is that when you help others, create open-source, it can do wonders. If you'd like to read more about this — I blogged about it here → http://awais.dev/marsc

# Q: What was the first stack you mastered/picked up? – parrottttt

I started blogging almost 20 years ago. So back then it was all static HTML and CSS. Seriously, people used to email me the comments on my blogs and I used to generate new HTML files from there and cowboy coded via FTP, on the production site.

Later on I started studying PHP because the idea of building forms that would allow people to submit comments on my site live was literally out of this world at that time. Started with LAMP stack, then WordPress. Then I went to college for Electrical Engineering — though I never liked the firmware development, assembly lang, verilog — and all that stuff. Finally, switched to Node.js and have never looked back.

# Q: How can we access local json file in React? – ROFL

You'd want to host that file somewhere. That's where Node.js can help — even on your local machine. In my https://nodecli.com/ course I taught developers 20+ different ways to build projects with Node.js, and most of them were locally hosted as that's where they are most useful. Like a CLI.

And of course, JSON is an excellent format for creating a database — so I recommended and personally use this project called lowdb which is a simple to use local JSON database (supports Node, Electron and the browser). Check it out https://github.com/typicode/lowdb

# Q: Is it possible to generate React codes automatically by some site that will convert HTML to React? – KoddyDev

Of course. You can create a form. Take the input, process it on client or server with JS or Node — and print out the React transform. You can use regex for this but some sort of AST grammar would help you a lot in the long term. @Padmanabh[he/him]

# Q: Why did you decide to get involved with the NodeJS community committee? – maistho

I believe in the Node.js ecosystem. The software part is amazing. It has done wonders for the JavaScript community. But it's not only the software that makes things work. There's a human aspect to it. Lots of great software out there in the last two decades has suffered an untimely death because it was just software — and not a lot of people cared about it. Node.js Community Committee which is now merged with the Technical Committee took care of that.

It focused on community-facing efforts. Meetups and catered to resources like the official docs, mentorship and outreach initiatives helping developers learn Node.js in the best most preferred way possible. This also helped us in two ways, get feedback from the Node.js community and make things inside the Node.js ecosystem better based on that. It's an idea close to my heart so you can connect the dots. 🙂

# Q: What's the elevator pitch for Rapid API? – rah.codes

Imagine if you need an API, you Google that, land on GitHub or some outdate docs site — you have no idea if that API still works and if you could use it right away or worse if you have to host it by yourself? That's the main problem RapidAPI solved several years ago. Now we have a lot more products. So RapidAPI is like GitHub for APIs, you can buy an API "pay as you go" model and use it or sell an API to a hub of 35K+ APIs and 3+ million developers.

Here's a one liner description for all our products as of 2021:

RapidAPI Hub 35K+ APIs for developers (find, connect, use, pay-per-use). Imagine GitHub for APIs, how cool?! 3M+ developers.

RapidAPI Provider Monetize your API and sell on the world’s largest API Hub.

RapidAPI Client (Paw) A full-featured HTTP client. API Design and Development tool.

RapidAPI Testing Comprehensive API Tests on schedule/demand in the cloud.

RapidAPI Enterprise Hub Enterprise white-labeled version of API Hub.

RapidAPI Teams Share and collaborate on internal/external APIs with your team.

There's a lot more to this, and I'm always hiring — you can read about why I joined RapidAPI and what I'm doing here and who am I hiring for on this one blog post → https://awais.dev/hiring

# Q: What's new about CLIs, I mean we have libraries like prompt. What are the difficulties that a normal dev would face when building a CLI tool – Piyush

That's a great question. Here's the quick version

It generally takes a lot of time to build small automation tasks, that's why I created create-node-cli https://github.com/ahmadawais/create-node-cli— a CLI for creating CLIs. And obviously it takes a bit more to make something serious. Improving CLI UX is another thing. As users we seldom don't know what's the right UX but we can definitely appreciate a good user or developer experience. Knowing what's what and how's how — makes everything slow and hence we end up either not automating something basic or hate on whatever automation we build.

More often than not people don't realise that Node.js and JavaScript are actually somewhat different. Like the event loop is a lot if not completely different. I did a workshop on creating CLIs with Jason and a lot of people found that useful in helping translate this concept, when you have some time do check it out. https://www.learnwithjason.dev/automating-tasks-with-node-clis

# Q: Aside from nodecli, what other courses did you make? – Deleted User

tl;dr: You can find all of my courses/books at this link → https://awais.dev/courses

I have a couple of courses and books, and I definitely want to create more — teaching is fun, it's a genetic bug in me (both grandparents and both parents are teachers). I created a course on teaching people my VSCode workflow https://vscode.pro/ and going to create a course on Next.js soon at https://nextjsbeginner.com/ — fingers crossed.

# Q: I took a look through your website and noticed you contribute to WordPress. My question is how do you envision the future of WordPress and its cohesion with reactjs? – corey

Great question. I spent over a decade in the WordPress community — contributed to all sorts of things from the WordPress core code to Customizer, default themes, WooCommerce and other excellent community projects. I joined the WordPress community when Contact Form 7 was launched in 2007 (which is why it's called CF7).

To this day, I still use WordPress. It's an excellent piece of software and has a big community. I do have concerns. Around 2016/17 I was working on the Gutenberg project where we helped Facebook relicense the React.js and GraphQL as MIT licensed open source projects — that was because React was added to the WordPress core.

React is powerful. With frameworks like Next.js — WordPress has suffered a lot. With Next and React you can do the same things, only better than WordPress. I feel like it's because WordPress has not invested a lot in the developer tooling. You see at the end of the day both User and Developer Experience matters a lot. If you try to build something with WordPress, PHP, JavaScript, React — the tooling is extremely messy. Developer experience sucks big time. It's a big driving factor that is making developers move to React.

^But all of that said, WordPress can be an excellent database or a headless CMS — the hosting scene for WordPress, with companies like Kinsta is far ahead the game. You can have tens of millions of users using your application and you'd still end up with a less than thousand dollars per month bill. Same can't be said about many modern headless CMS's and AWS costs of doing things all on your own. Pros and Cons, meh. ¯\_(ツ)_/¯

# Q: Being quite active as an advocate for software development and open source, are there any notable impacts you hope to see in software development/community come out of this? In other words, are there any specific things you are hoping to inspire through your actions as an advocate? – S3BAS

Oh, that's a fantastic one. Yes, most definitely. I have been doing this thing for almost ten years now—building, teaching, and improving the software for developers. Or as I often say, "Helping companies understand developers" and "build software with developer-led growth."

I believe that developers are modern-day decision-makers. Engineers/devs are running the show. It helps a company by listening and catering to the audience they serve the most. Building a feedback loop and improving software based on that feedback instead of your gut feeling makes a big difference.

I also believe that software that enterprises only use could potentially be lousy software. That shouldn't be a goal to strive for. Tech native approach for a developer-focused company serves all personas better. It's been proven by the likes of Stripe, Twilio (last I checked, that had jumped from $1B to $63B market cap in a couple of years), GitHub (before and after acquisition — significant difference).

One idea that I have been pushing a lot for a couple of years is that there needs to be a separate Developer Experience (DX) department. This is where we build the front end of developer-focused products. Back-end/full-stack engineers work on the product, designers/product design the product, and the DX team builds the layer that interacts with developers. It consists of all things like frontend, a CLI, docs, and the entire user experience of the products. This way, DevRel won't be stuck creating patches to fill up the UX/DX holes with documentation, and we'll all end up with excellent products. I hope someday, more and more companies will realize this. That'd be a fun world to live in as developers. 🦄

# Q: How do you take problem solving as a challenge and what problems did you face at an intellectual level while developing for Rapid? – JS_Artboy

As a developer I love to go down the rabbit hole of fixing a small bug which takes hours but is totally worth fixing. It's been the same here at RapidAPI. Helping developers understand how APIs work and building a community closer to them was one of the challenges me and my team had to solve this year.

We've built a community of API Developers on Twitter (that's where most of developers hang out, right?) — over the year over 9.3 Million developers have read/learned from our API content there — you can check it out here → https://twitter.com/Rapid_API/

Moveover, we have launched projects like https://rapidapi.com/learn to help developers learn APIs.

https://rapidapi.com/courses — to help developers learn through videos by watching some of the best developers on YouTube.

https://rapidapi.com/guides — for if you prefer written content with open-source code projects. And it's just getting started.

Netlify Team: Cassidy Williams & Jason Lengstorf

Reactiflux — Wed, 08 Sep 2021 16:00:00 GMT

# Q: What are the future plans of Netlify? – Deleted User102200

our current plans are to help grow the ecosystem to be as strong as possible — we're especially excited about supporting the development of OSS frameworks and tools that help developers build more performant, accessible, and usable projects for the web – jlengstorf

# Q: Is Netlify working on collaborating with Vercel on some of the base specs for platform features like deployment structure, config files, ISR, etc, or is this purely competition so there's no value in collab? – jescalan

Netlify has submitted several upstream PRs to Vercel repos, and we're definitely open to more collaboration! our stance is that we should strive to be the tide that lifts all ships — that means working with the community to get the best possible outcomes – jlengstorf

# Q: Will Netlify ever have any support for non-jamstack based sites, e.g. Express on a node server? I'm curious on your thoughts on whether or not Netlify is hard set on "JamStack everything". – MapleLeaf 🍁

You're right that there are fun opportunities for things that go beyond what we've generally described as "Jamstack". As the category matures we're seeing lots of potential and desire to expand into things that execute "on demand". Serverless functions, On demand builders, and Edge Handlers all blur the edges into where you looking. Personally I'm still very keen on "pre-generate as much as is practical". – philhawksworth

# Q: For complex projects in React how you guys split complexity? – Yandex

I personally break up Context components into their own folder, hooks into folders (which I organize differently depending on the project, sometimes in just a hooks folder and sometimes in a components folder), and then presentational components in their own folders. Grouping things by functionality tends to help a lot! – cassidoo

# Q: Are there any opportunities for students to grow and refine their skills at netlify? – aarush

we have a lot of opportunities to grow your skills on Netlify; it's free to deploy and test things, so you can build web and serverless projects as you learn and to build/host your portfolio. We do not currently have any formal programs for students in Netlify the company, but it's something we try to partner with the community on – jlengstorf

# Q: Cassidy how many keyboards do you currently type from? – Arkadiusz

37, but that's only when my 3rd hand is working well. Otherwise, 5. – cassidoo

# Q: What do you use to deploy serverless apps guys? Terraform / serverless framework or something else? – zerubeus

we offer a no-config serverless option in Netlify! you can use Netlify Functions to deploy them using the same git-based deploy flow as your web apps (you can put your frontend and serverless functions in the same repo, too!) https://ntl.fyi/functions – jlengstorf

# Q: How important is teaching and mentoring for a web developer? More specifically, is it advisable to invest time into teaching junior developers, as opposed to learning new things / building projects. – syncerax

I think this is incredibly important, truly one of the most important things that you can do in your career. Definitely balance your time, of course, but giving back to the community and "paying it forward" is what keeps this industry going. Plus if they're actually on your team, you'll get much better code coming your way that you'll ultimately have to review 😅 – cassidoo

# Q: Hello, I have a question about frontend architecture. Do you have any suggestion on how to have many reusable modules reusable across project, without having many npm packages (too much work on maintenance / upgrading imo). – Nipp

one great approach I've seen is to us Nx (https://nx.dev/) — this lets you do "packages" without having to formally publish them, and it's really nice if you combine it with CODEOWNERS

I have a Learn With Jason episode on it if you're interested in learning more! https://www.learnwithjason.dev/faster-static-site-workflows-with-nx

– jlengstorf

# Q: I'm in college, how important is competitive programming and leetcode etc for interviews? Also any tips to get started on freelancing? – Deleted User

Meh, it's good practice, but I wouldn't say "important" is the right word for them. They're helpful, but not necessary. I really like Leetcode and Hackerrank for practicing for interview prep, but it's kind of rare to see that stuff make you a better developer. – cassidoo

# Q: Does Netlify usually have remote openings contemplating places such as South America? – Cuca

ABSOLUTELY! we are a fully remote company with many team members in South America! https://www.netlify.com/careers – jlengstorf

# Q: What makes Netlify special? – Deleted User102200

Me(mes)

...more seriously... I think you'll get different answers form different folks. But for me, the genuine desire to make it easier for people to build a better web runs very deep at Netlify and I enjoy experiencing that with all of my colleagues. Before I joined, I was an avid Netlify user and it transformed my ability (personal and professional) to execute on the web. That mission is very much still core.

– philhawksworth

# Q: Can we expect support for express and node backends real soon? 😅 – nothingButSyntaxError

I would suggest you check out https://jamstack.org/ for why we don't do that! We're strong advocates of this style of development, which involves separating out services on purpose 🙂 – cassidoo

# Q: I have a crazy feature request. I'm all in for the serverless functions, but I'm facing some situations where I would go for the traditional server. So it would be super cool if we had something like a traditional server deployment just right in the same project along with the functions and also with same ease of writing and deploying. – discoding

this is an interesting idea! I'll bring this back to the team for discussion. When I need a server right now, I usually use render.com or DigitalOcean – jlengstorf

# Q: Any advice for beginner developers trying to get themselves noticed in the big world of React and application development. Or advice for more experienced developers trying to remain fresh and relevant? – Sean22

For beginners: Learn in public! Write down somewhere what you're learning and what you're doing. If people see your growth journey somehow, that can lead to jobs. Now is a particularly good time, too, because of React 18 Alpha, there are very few people who are making content around that now.

For experienced developers: Following newsletters, keeping an eye on communities, and continuing to build is super helpful!

– cassidoo

# Q: What advice do you have to give to new developers looking to get into the world of distributed systems, any cool project suggestions for us to build and learn? – BaluBabu

we're not really experts in distributed systems (meaning @philhawksworth, @cassidoo, and myself) so we'd defer to an expert for advice here – jlengstorf

# Q: I saw the announcement today that Netlify is sponsoring Astro, which is awesome news! I'm curious if Netlify tracks statistics on the number of sites using the various build technologies like Astro vs Vite vs Webpack vs Next, etc. To keep an eye out for up-and-coming frameworks. – IanVS

Yes! We're super hyped to partner with various open source frameworks (we're also MVP sponsors of Nuxt). We do keep an eye out for this, and run the State of the Jamstack community survey to see what's up and coming. Results for the latest one are coming soon! – cassidoo

# Q: What's up with the fear of Angular in web dev? 😂 – Deleted User

People are afraid of making money – cassidoo Actually though, we've got a bunch of Angular blog posts here 😆 https://www.netlify.com/authors/tara-z.-manicsic/

# Q: Is there a newsletter you could recommend? – gregoirevda

Shameless plug, my newsletter is at cassidoo.co/newsletter!

I also like Frontend Focus, Jamstacked, React Status, and Bytes!

– cassidoo

# Q: If a frontend developer is exploring backend for last six months and doesn't want to give up on frontend in which he has years of experience, what career role should he choose from learning and growth perspective. – taleymirza

Follow your heart (but actually though, it's kind of up to you what you want to do, we can't really tell you that!) – cassidoo

# Q: Was writing technical blog posts one of the biggest boosters in your tech career? If not, what was it? – Arkadiusz

It helps a lot! I think it's a lot of different things that boosted my career. Teaching and writing though are definitely my favorite ways of learning. You cover cases for other people, instead of yourself, and that gives you a deeper understanding! – cassidoo

# Q: Does Netlify have remote openings in Africa? more specifically Ghana?. If not are there any plans on that, and if yes, how does one get on board? – scarrexx

We hire anywhere, and our roles are listed here: https://www.netlify.com/careers

Granted, be aware of time zones, the more east you get, the rougher your meetings might be 😅

– cassidoo

# Q: What tools (like postman) do you guys use for your day to day development? – BaluBabu

VSCode and vim (I like a weird combo), Netlify CLI, Stack Overflow, and prayers 😆 – cassidoo

# Q: Have you seen much use of WebAssembly at Netlify internally or by users? – almibe

we're seeing some usage, including internally at Netlify. It's still fairly light and a lot of what we're seeing is experiemental or proof-of-concept, but it seems like a really exciting space to watch! – jlengstorf

# Q: Getting started with web dev freelancing, any tips? – Deleted User

Keep increasing your rates until you find a sweet spot! – cassidoo

# Q: I'm curious about JAMStack what is it? – BaluBabu

Jamstack is an approach to web development that focusses a lot on decoupling the UI from the backend. Pre-generating the front end and then serving it as static resources makes hosting, deploying, scaling sites a lot simpler than it once was. I like this summary here: https://jamstack.org/glossary/jamstack/ – philhawksworth

# Q: What is good DX at Netlify? – juniornjay

good developer experience is making great decisions by default on behalf of developers, but not removing any of their autonomy to reach into the config and customize things if needed

I've written about this in a longer format, too! https://www.jason.af/progressive-disclosure-of-complexity

– jlengstorf

# Q: How do you manage your time and the motivation to produce so much content? – jd

A strict calendar and a todo list are really important for me, and I write down a lot in Obsidian! A lot of projects can be demotivating (I have many unfinished ones lol) but if you keep working at them, you'll get a lot done 😅 – cassidoo

# Q: Do you foresee launching any more backend services like Identity? I think they’re great! – Oli

Oooh that's a tempting one! the entire ecosystem is already flourishing so nicely that I think it is more likely that Netlify will be trying to make using existing tools and services really slick and friction free. So perhaps thinking of integrations and wrappers rather than specific Netlify-grown services is a good bet. – philhawksworth

# Q: Rust seems to be becoming more and more popular. With the ability to use it in the browser via wasm, do you think it is a useful language to start learning for frontend development? – Fouad

I'm at the "I don't know" phase for this language right now. I know a lot people are loving its speed for frontend stuff, but I haven't tried it myself! – cassidoo

# Q: Linux or MacOS which you guys prefer? – Deleted User

screams in Windows

Honestly for web dev, it's kind of all the same at this point. Do what you prefer! I use mostly Windows and MacOS.

– cassidoo

# Q: Do you think Elixir,Go is a good next step for a competant Nodejs developer for backend dev, or is anything anything else? – BaluBabu

Yes! I've been seeing a lot of companies move more and more towards Elixir and Go 🙂 – cassidoo

# Q: Does the (headless) CMS have anything to do with the framework used to build the actual frontend? Ex. Can I use Ghost (which uses Ember.js) as my CMS and create a frontend using Gatsby? – syncerax

The whole concept of "headless" means you can use anything with anything! So yes, use those to your heart's content ❤️ – cassidoo

# Q: Who is maintaining the Gotrue Api at Netlify? – juniornjay

one of our internal engineering teams maintains it, but we're a little understaffed right now so active dev is on hold. We're hoping to get more folks hired soon so we can pick it up in earnest! – jlengstorf

# Q: I looked around the Web but couldn't find the React micro example to understand the core functionality of react. Any suggestion? new to React. – vjr2nd

I have an online course for it if you don't mind the shameless plug, at cass.run/rrc, otherwise I recommend going through the docs! – cassidoo

# Q: Do you think the whole micro-frontend approach will get more attention and be used more? – BaluBabu

I do! We see big companies and projects adopting this sort of architecture quite often, and being very pleased with the agility and portability it brings them – philhawksworth

like docker or something like laragon? All of these buzzwords get their 15 minutes of fame and bits and pieces of it end up being used a lot, lol, so... Yes and no 😅 – cassidoo

# Q: Thoughts on Redwood js? – Oli

It seems cool! I haven't built with it yet but they're doing a lot of interesting things it seems like. Plus they give away free stickers on their website, which totally won me over. – cassidoo

# Q: What developer enviroment do you mostly use on windows cassidoo like docker or something like laragon? – Swift

Nah I don't do any of that, since I'm mostly on frontend doing serverless style development, I don't really need Docker or anything! I use the Netlify CLI but that's about it. – cassidoo

# Q: What happened to Netlify Stories? 😂 – Deleted User

some ideas are too powerful to live – jlengstorf

# Q: What advice you give to someone without experience in any company and who is self-taught for the last 2 years? Most of the companies want people with experience – claudiu

Apply EVERYWHERE. Truly, it's a numbers game. Literally apply to more than 5-10 jobs a day. Get your foot in the door! A lot of these places don't hire you not because of you, but because of other outside things. – cassidoo

# Q: In your opinion Is IT certification relevant or should people not bother and focus on projects / writing / other thing that show their skills / insights? – Arkadiusz

Meh I haven't seen it asked for much at companies, it's more of a "nice to have" than a requirement. I'd personally focus on projects. – cassidoo

Sorry to be the first to use the phrase... But I think this is a classic for "it depends"! 🙂

Depending on the sector you want to work in, or employers you are targeting, you might find it more or less valuable. I don't think that they should be sought "by default" without identifying a need for a specific knowledge and accreditation.

– philhawksworth

# Q: Do you guys work with backend stuff on top of your frontend role? – juniornjay

Sometimes, mostly in the form of serverless stuff though on my end. I left the backend life long ago 😆 – cassidoo

sometimes! I mostly find myself using tools like Hasura more than I'm building true backends, but I spend a LOT of time writing serverless functions 😄 – jlengstorf

I think the boundaries are blurring more and more! I find myself at "the back of the front end" a lot, plumbing together systems with front-ends. It's one of the joys of so much decoupling in the architecture these days for me! – philhawksworth

# Q: What can you NOT do when going serverless? – kanerva

rub your belly and tap your head at the same time, so difficult – cassidoo

streaming chunked responses won't currently work, and stuff like subscriptions / WebSocket connections don't work – jlengstorf

# Q: Do you provide a CI step to extract all graphQL queries at build time to validate them against the schema? 😅 I’m looking for a solution to that – gregoirevda

You could do this with a Netlify Build Plugin, in theory! – cassidoo https://www.netlify.com/products/build/plugins/

# Q: Do you think Hasura could be used for a highly scalable production app? – Jamie

absolutely! it's in production for quite a few companies at large scale now – jlengstorf

# Q: What's your most controversial linting rule opinion? (a la .eslintrc) – OrnithopTyler

Linting should be dusted out and never used again (I don't actually believe this, it just sounds controversial)

– cassidoo

# Q: Whenever I’m coding and hit the M key, it registers as an N and vise versa. How do I fix this? – Jimothy

Reprogram your keyboard – cassidoo

# Q: What is the most unique or interesting serverless function you've ever seen? – IanVS

So many possibilities! I had a ball recently using serverless functions to generate, store, and render custom conference lanyards for Jamstack Conf. .... Cue a picture of me as a cowboy... Https://jamstackconf.com/badge/SZ5oRHd4lwtF – philhawksworth

This lanyard project is so dang fun https://jamstackconf.com/badge/8mW6ik4TcQGU – jlengstorf

# Q: How relevant is learning about security for web developers (especially in the context of Jamstack)? There are so many different security implications to consider while deploying a website. It's quite overwhelming! Is there any way Netlify helps here? – syncerax

I think it's good to know as much as you can, but what I like about building on Netlify in a very serverless, decoupled way is that I can pull in something like Auth0 or Okta or Stytch and get all the security without having to implement it myself 😆 – cassidoo

# Q: I'm teaching a React course and would like to do interactive code examples preferably even embedable in markdown. Any suggestions? – Haaxor1689

Not sure what platform you're using, but Scrimba is pretty good for interactive code, and you could also embed a CodePen or CodeSandbox that way, as well! – cassidoo

# Q: I dont know if this is relevant but do you guys have any idea for self hosted object storage solutions we can use to build say a firebase storage clone? – BaluBabu

Check out Supabase: https://supabase.io/ – cassidoo

# Q: I was just hired as a junior developer but I work alone and no one to really bounce ideas off which is the only bad thing about the job. I have had to do a lot of learning recently and picked up the MERN stack. Was there any other stacks that you can think of to build internal web apps that is beginner friendly? – Centrax

I'm a fan of Jamstack (I know, what a surprise!) because you don't have to deal with servers or any kind of deployment — you can build locally with Netlify Dev & the CLI (https://ntl.fyi/dev), then deploy it by pushing to GitHub. I like this because it lets you focus on one area of expertise instead of requiring you to learn lots of things at once – jlengstorf

# Q: What does React have that solid js doesn't? – xoldyckk

Mostly age, experience, and a large community. It seems like you can do quite a bit with Solid, from what I've seen! – cassidoo

# Q: Do you have any suggested full stack learning materials/courses for a beginner? Like the whole shi-bang! I’m having trouble stringing together front end and back end from separate resources. – Eterneon

FreeCodeCamp is great, and I've seen a lot of folks have success with https://scrimba.com/learn/frontend – cassidoo

# Q: Does serverless codebases get hard to manage in the long run? Specially if you have multiple ones in a single project. – juniornjay

Depends on how you organize it. I've seen quite a few people break those up into multiple repos for this reason! – cassidoo

# Q: Any advice for non US devs looking for remote roles? – juniornjay

At Netlify? It me!

Netlify hires globally and we have an ever expanding non-us contingent. I've enjoyed seeing more folks arrive in my timezone and even in my city! (https://netlify.com/careers)

But generally, I think that we are lucky that the market is feeling more and more international and distributed. So there are plenty of opportunities. If you find a role with a company/team in a different time-zone to you, be mindful of finding a culture which is respectful and aware of working across timezones. That has made a huge difference to my quality of life!

– philhawksworth

# Q: Do you think it's still relevant to teach class components in React basics class? – Haaxor1689

I think they're good to be aware of, but should not be used as a primary way of writing React. I personally don't teach them. – cassidoo

# Q: What other companies or persons do you follow in tech to get your news/current events? – JasonHoku

@jlengstorf lol – cassidoo

I follow @cassidoo – jlengstorf

# Q: Are there some use cases that you think Jamstack isn't mature enough to handle yet? – syncerax

We're seeing everything from huge SaaS dashboards like Twilio to the kiosks at Popeye's to the apps running in Peloton bikes using the Jamstack, so I don't think there's anything you can't do. At its core, Jamstack means decoupling the frontend and precompiling pages whenever possible — that doesn't mean you can't ever use other tools; it's about good defaults, not dogma – jlengstorf

# Q: Any drawbacks to having a monorepo? – Jamie

Things being very closely intertwined in a monorepo can be fairly difficult to maintain over time. If you build it in a strictly modular way, you'll do well. – cassidoo

# Q: What mistake(s) do you see most beginners do? – kanerva

Not asking enough questions 🙂 – philhawksworth

# Q: Lightning round: useEffect() a source of love or bugs? – Arkadiusz

Love, especially with subscription-style functions, but also pain and agony if you mess up 😆 – cassidoo

# Q: Redux vs UseContext, which one is better and must be used often? – BaluBabu

both are great! the "better" option is the one that the team maintaining it is comfortable keeping healthy and iterating on over time – jlengstorf

# Q: Any cool projects out there that interest you guys? – BaluBabu

I mentioned Supabase earlier, I think the fact that it's open source is so cool! – cassidoo

# Q: SQL or GraphQL? – Edaz

REST!!! 😜

Answering this with another answer to the question about interesting serverless functions usage: https://canyoutell.me/sql-or-graphqL

– philhawksworth

# Q: SQL vs query builder vs ORMs. How about from a freelancer's perspective? – xoldyckk

I like ORMs for large teams. I think there's value in matching the level of effort to set something up vs the amount of time it's expected to live.

Do you reuse that code between projects? do you need to maintain it? are the projects temporary launches (like a marketing campaign) or app platforms? all of that factors into my decisions about architecture – jlengstorf

# Q: Which form lib you prefer overall? Formik/final-form/hook-form/other? – Haaxor1689

Reach UI components to make forms is my favorite, personally! – cassidoo

real talk: I love plain ol' forms with the built-in FormData API – jlengstorf

# Q: What would you consider is the next step for a dev working with React for 4+ years? – BaluBabu

Understanding how to build reusable libraries is difficult and worth knowing! – cassidoo

# Q: What would you say are topics/concepts junior devs struggle the most with? – Haaxor1689

the initial hurdle of "thinking in code" is a big one. Anything that doesn't have a clear analogy in real life. Abstract logic is really hard! – jlengstorf

Eve Porcello

Reactiflux — Wed, 11 Aug 2021 16:00:00 GMT

# Q: Can you share tips or resources to enhance performance in a React app? – orjiace95

I would highly recommend checking out the docs to start. This will take you through the profiler tool which I highly recommend. I also recently saw this article from Codementor on this!

# Q: What's the hardest part of getting a new company/team to buy in to GQL? – iggy

I'd say that dispelling rumors and myths about GraphQL is the hardest part! A lot of people think that getting started involves huge architectural changes but you can start incrementally by wrapping your existing REST endpoints.

I'd also recommend some sort of internal training/ lunch and learn/ etc that is led by someone on the team because sometimes it's hard to get everyone onto the same page without a communication plan! People tend to like it when they get started!

# Q: What to learn after mastering react? Node js or Next js? – ROFL

Great question! I think Node and Next.js are always excellent things to learn. I feel like a lot of people go for React and skip out on learning Node.js really well and this is always a nice contribution to a team. Of course, I'll shout out GraphQL here too which can work really seamlessly with Node.

# Q: Heya! How important do you think it is for a junior dev to have a coach available to them to guide / correct? – pawzi

I think it's super important to have some sort of person on the team to connect with and ask questions to. Equipping people with documentation is important but having a designated mentor to ask questions to makes people feel much safer! Office hours is a good way to deal with this too so that the senior doesn't get overwhelmed!

# Q: What do you think are the most challenging things on managing a small business – Deleted User102200

So many things are hard haha! I think the hardest is managing cash flow at the beginning. When I started my business I didn't have a lot of startup money, so we just ended up doing almost everything by ourselves. Deciding how to delegate and what to outsource is tricky, but staying focused on what you're great at can really help the business grow.

# Q: Can you give us tips to make React programming better? – TirupatibalajiTheDev

The way I got better at React was working on projects. I took a lot of tutorials but picking something I was interested in (usually skiing) and building that helped me to learn things that I wouldn't have found out about in just a limited tutorial. That's how I learn about everything really.

# Q: Which library do you think is best for Graphql development in server side node? – Spark ✨

My favorite is Apollo Server, which just released version 3.0. It's excellent! Highly recommend!

# Q: What do you think is the right path to take when a major, and very widely used package, seems to hit a wall and not offer updates? Do you try to fix the issue yourself a fork and run with it or do you wait for someone else to take it over or do you find some other package to do the job? – Giles

This is so hard! In the past I've usually looked to another library to do the job. That always is a painful transition though... How do you usually handle this?

# Q: Opinions on the state of GraphQL client libraries? Apollo, urql, or using cached fetch wrappers like SWR/react-query etc? Do you have a favorite – Chem

I have played around with all of these but the one I have the most experience with is Apollo Client. I like how this works with several different client libraries! Every version gets a little better but caching GraphQL on the client remains a tricky problem!

# Q: What advice would you give to someone who wants to start a career in teaching? – elise

I would recommend getting started with teaching at meetups/local events (online works too of course!) or volunteering to teach groups (Women Who Code, local groups, etc). This gives you a sense of how to start breaking down content and seeing what resonates with an audience. From there, there are a ton of directions to go in: teaching all day workshops, making short videos, writing blogs? One way that I got into teaching was working with companies who staffed instructors on classes (DevelopIntelligence and Silicon Bay Training). They handled all of the logistics and I just showed up to teach! It was a great way to get more experience in the classroom while getting paid. Get in touch anytime if I can ever help with anything!

# Q: Which approach is generally better for Graphql development on server side? Code first or schema first. – Spark ✨

I like the schema first approach but if you do have a data source that is particularly strong, then code first might be a way of accelerating your GraphQL adoption!

# Q: What is the most significant advantage of GQL over REST? – josmithua

I think one of the strongest advantages of GraphQL over REST is the communication factor. GraphQL's schema gives us a type system for the API that you can enhance by writing good documentation. It tends to help teams really understand the fields and types that are available which is great for building apps quickly!

# Q: How do I get my first clients (for web development) and how do I price projects? On what basis should I charge? – penguin

This varies based on your location and what you're offering, but I would start out always by pitching a higher number. Your project will take longer than you think almost every time, so building in time to go over your estimates is important. It's so hard, but value your time and try not to sell yourself short! Try to collect 50% at least up front too 🙂

# Q: What is the easiest part of teaching/training technical people... and what is the hardest part? – Gabe

The easiest part is that it is a very fun job! Getting to meet people and spend some time learning about their challenges is the easy and fun part.... As for the hard part, I'd say teaching a class that works for a variety of people can be a challenge. There will always be some newcomers and then more advanced folks in a class and managing their expectations/giving everyone something to learn is really important. For that, I usually have a baseline of curriculum for everyone, then lots of extra credit assignments for folks who want to go deeper!

# Q: Did you ever face any issues as a woman in a STEM field? If so, how did you overcome them and what advice would you give to other people belonging to groups which are marginalized in STEM? – chase

Thank you for that question! When I was starting out in this career, I would go teach a lot of classes to almost 100% white male groups, and there would often be folks in the class who didn't think I should be teaching it. This can be intimidating, but the way that I got over this was to be extremely prepared! Prepared for any pushback, prepared for any question. I have also been lucky to have advocates that helped vouch for me. As I have done more in my career (created classes, wrote books, etc), people are more willing to listen too. I will say that it is still tricky to manage at times.

# Q: What advice would you give to a small software business which is trying to train fresh graduates in web frameworks from scratch? What are the most important things to teach? – syncerax

Sounds like a really cool program. I'd recommend not skipping out on teaching the fundamentals of JavaScript and browser-based things like CSS, HTML, etc. From there, I'd pick a track if you can. Maybe teach React really well instead of Angular, React, Vue, everything at once! Keeping focused usually helps people not drown in the sea of information. Pairing them up on projects is a great way to keep them engaged and problem solving too!

# Q: Do you most of the time build things from scratch or use third party libraries, when and why? – endrits079

I got into my career using a lot of vanilla JavaScript but today I use a ton of React and GraphQL frameworks! I don't think there's any reason to avoid frameworks particularly ones with a lot of community buy-in or those managed by a relatively stable foundation group like GraphQL!

Thanks! 😄

# Q: How to stay healthy as a programmer? specially how to protect our eyes while giving our best? – Baby

This is an awesome question. Thank you! Lately, I have really been prioritizing my physical and mental health over everything. Between teaching classes, creating new classes, and working on projects, I was burning myself wayyyy out! Planning meals and fitting in even a short walk has been so important to bringing some balance back. As far as eyestrain goes, taking breaks from screens is so important! Does anyone else have any ways of being nice to our eyes as developers? I'd love to steal your ideas!

# Q: For more junior level engineers, do you recommend personal projects or open source as a better source for learning? – Saturday

I think either approach is great, but sometimes I hear from junior devs that they feel intimidated by open source projects or their maintainers (PS I have been in this career for over a decade, and I think it's intimidating to jump into an open source project too!) I'd say whatever feels fun. If you're working on a side project, you probably aren't getting paid (at least at first), so pick the thing that seems the most fun and will contribute to your burnout the least!

# Q: Hi Eve, thanks for taking the time for these today! What's your take on GraphQL ORMs (mainly Prisma & Hasura) as far as specific use-cases where one or the other really shines or stumbles? – winter40

As far as I have observed from consulting with companies, the place where Prisma really shines is for mapping existing datasources and getting people up and running with GraphQL at lightning speed! For Hasura, this is the case too, but there's something magical about their realtime usecases. A lot of people love Hasura for subscriptions/realtime stuff and I agree with them!

# Q: How to strike a balance between creating higher quality content and creating content faster? Thanks! 😄 – syncerax

Hahaha, excellent question! I think the best way to keep content consistently good but also consistently coming out is to build small projects and break them down into content that can be repurposed for blogs, talks, videos, in-person workshops, many formats. Trying to set reasonable goals is good too. This varies from person to person, but maybe a once a month blog post that you know you can make happen each month vs. once a week could be a good way to keep things quality and consistent.

# Q: When do you think a junior web developer should begin learning GraphQL? – archiyopp

Anytime! I think learning about the Query Language is good for anyone: developers, managers, anyone who works with data. We teach a free workshop once a month online about it if you ever want to join https://moonhighway.com/graphql/everyone. I just pushed some new dates for September and October!

# Q: What do you think of Hasura? – david

Love it! The creators of Hasura are some of the most genuine and driven people and they're in it for the long term. I don't think there's any danger of that project going away anytime soon, and I know a lot of folks at big companies who are making big bets on Hasura!

# Q: What is your favorite drink and cookie to warm up with after a day on the slopes? – Giles

Welllll if you ever find yourself in Olympic Valley California, I highly recommend the chocolate chip cookies from Wildflour Bakery. They are legendary! Pairs nicely with a nice Northern California IPA! Or hot chocolate! 😂

I think there's a ton of potential for GraphQL to be used for all sorts of awesome things. The plugin ecosystem, we see it used for content platforms like Gatsby, GraphCMS, etc. There's also a ton of exciting stuff about GraphQL being used for the blockchain. Check out The Graph Protocol if you haven't already!

That went so fast! Thanks for being such a great group to spend some time with! Feel free to reach out with any questions anytime - DM me here or eve@moonhighway.com!

Jenn Creighton

Reactiflux — Wed, 30 Jun 2021 16:00:00 GMT

# Q: Based on your Twitter bio, I see you're doing React stuff I'm a Vue developer, but my job requires me to learn React. What's the best way to learn React & React Native, as well as the best practices? – avi12

Excellent question! I learned React by building applications with it - lots of trial and error. But that was 6 years ago and now there are lot more resources. I'm a big fan of Egghead & Frontend Masters. But the React team (specifically Rachel Nabors and Dan Abramov) are working on a huge revamp of the React docs. I've seen a sneak peek and it's amazing work. That'll be the go-to Learn React source in the future.

# Q: What are the main points companies can pick up to make the work environment feel more inclusive for women, POC etc. (my bad, didn't read the topic list!) – ThimoLS

No worries but I am going to skip this since it's not something I can answer. White women are really diversity…

# Q: Hey Jenn! I'm right now a C# Asp Net developer and have been working on building a GraphQL API using Hot Chocolate. The ability to be able to automatically generate GraphQL from C# types have been very useful, so what value proposition is there to create a GraphQL API in Apollo Server (and JS/TS) instead of C# or any other strongly typed language with automatic type generation in graphql? – Dreamplay

There's value if you want to work in JS / TS for both the front and backend or to do server-side rendered applications. Apollo Server lets you get up and running with a GraphQL backend super quickly. But if you're comfortable in C#, no need to force yourself into JS / TS.

# Q: I want to contribute to React repository but the large code base is very overwhelming for me. What would you suggest a beginner to get started with it? – Deepayan

I love this question. It is a super overwhelming codebase. If you want to contribute to a large project like that, start with the docs! There are usually lots of small ways to contribute there without needing alllllll the knowledge you'd need for the other parts of the codebase. And also, please please please don't contribute because you feel like everyone else is. MOST ENGINEERS DO NOT CONTRIBUTE TO OPEN SOURCE. And it's totally fine. Doesn't hold back their careers at all. Only do it if you are super interested and can manage the amount of time required.

# Q: Hi! What are your main testing techniques to use for react native applications? – romulo_developer

I'm not as familiar with testing React Native apps but for React web apps, my go-to is React Testing Library + Cypress.

# Q: Hi, I recently got hired for quite a big project and it seems quite overwhelming to me because there's so much new stuff, do you have any tips for me to feel more comfortable? – HiddenIpex

When I feel overwhelmed, I tend to break down what I'm doing into small pieces. As small as possible. And I keep lists of things I've learned, things I need to learn - just to stay organized. Two other tips:

Try to remember that no one knows everything and not knowing means you get to find out - that's the fun part!
Reflect once in awhile on what you've achieved. Otherwise you'll get stuck looking at the long list of to-dos without appreciating what you've done so far.

# Q: What are you thoughts on esbuild that claims build times enormously shorter compared to webpack? – parvez

I'm excited about esbuild. Webpack has a large share of the "market" but new bundlers are always welcome IMHO. esbuild is on my shortlist to try out for new projects, for sure. I'm not just looking at build time too. I'm looking at developer experience and ease of customization.

# Q: What's your most exciting upcoming React 18 feature? – Kim

TBH I'm excited about the realization of the long-awaited Concurrent Mode - though that's no longer what it is, it's Concurrent APIs that you can opt into. We've been waiting on this for a long time. React 18 itself isn't going to be packed with new features. It's lot of work under the hood but as React 18+ are released, we'll see more features I'm excited about like Suspense for Data Fetching.

# Q: Any tips for newer developers on which languages to learn prior to C and PHP? – Soul ✞

Wish I could answer this but I know JS and… that's it. Yup. One language. (And I've built an entire career off of it.)

# Q: Do you have a personally great example of GraphQL being used to combine a bunch of disparate APIs together that we can all see? – SuperSheep

I don't! But Kurt Kemple, dev rel manager at Apollo, might. Reach out on Twitter and he'll be happy to answer you.

# Q: When would you use react hooks approach instead of class component's one? – romulo_developer

Class components were once the bread & butter of React but hooks replace them. Opt for hooks + functional components. The lifecycles available in class components are being deprecated so continuing to use them isn't the best idea.

# Q: What can I do to get hired for my first job as React developer? – Hessa💜

Understanding JS fundamentals is still the best option for getting hired as a React dev. Study those. Learn why React does what it does. You don't have to go to far under the hood but some understanding here is key to interviewing for those positions.

# Q: How do we handle mutation permissions with GraphQL? For example, when you fetch a list of entities, how to you know which entities you are actually allowed to modify it? – Bleuet

If you are working with Apollo, most people use an Apollo Link to handle validation and custom logic. But if this is for a specific mutation, there's no option to avoid some duplication of logic on the frontend because whatever cache you are using needs to know how to update itself. An annoying part of caching data but a necessity.

# Q: How much have you played around with strong-typed languages and do you miss working with them when you work in JS/TS? – Dreamplay

I've written a small bit of Swift (wouldn't say I know it) but whenever I work with another language, I miss JS. I know it so well at this point that it feels very natural.

# Q: Hello, I am currently making open source MERN projects for my portfolio in order to find a job. Which things should I focus on code-wise? And does the design matter for projects like these? – Tariq

Focus on whatever interests you most. Projects are a great way to learn what part of the stack you like the best. Whether the design matters depends on what kind of role you're going for. As a frontend dev for most of my career, design did matter to me.

# Q: What are a couple of your favorite Content management systems? and what are your thoughts on Progressive Web Applications, and react native, do you think one will be used more than the other? – Briann

I don't have a favorite CMS but on the topic of PWA vs React Native, I've leaned towards React Native in the past. But the choice is super dependent on the use case, the engineers building it, how you want to handle deployments, etc. And that's how it should be. One shouldn't "win" over the other one - it's about finding the best one for that particular use case. Most of what I've seen is that an engineer or two champion one or the other choice at their jobs and lead the charge.

# Q: How can I encourage my team to learn/grow in the area of component architecture (absorbing some of your talks on the subject, for example) without being a jerk and implying they write bad UI code? – andrewpomeroy

I hear from folks who share those talks at work or watch them as part of Lunch N Learns - that seems to be an effective option to get a team talking about component architecture. Leading by example is also effective and what I've chosen to do in the past. But like the old saying goes "you can lead a horse to water but you can't make them drink." Sometimes it just doesn't work. If you can get other engineers interested though, keep the conversation up! Share resources, ask for input on your components, etc. It'll hopefully become part of the culture 🤞

# Q: As someone who moved into React and React-Native from a totally different field (nuclear science) and started their own firm what tools or methods do you find are the best to attract new high paying, high quality clients to maintain growth? – Dax

I'm not sure exactly what you mean. I've also never worked as a consultant for longer than a couple of months. If I do meet potential clients, it's through interviews! Weird, I know. But if I interview at a startup, sometimes there's interest in me consulting. Tools-wise, TypeScript and GraphQL are great additions to most projects.

# Q: Do/will you and your team use TypeScript in React projects? Why? – Heng-Hao

I have. I'm not a super big fan of TS but it does have its benefits. The problem is that TS can add complexity. Which is the opposite of what it's meant to do! I find a lot of React engineers overindex on TS, creating complex types and generics. So if you want the benefits of it (documentation, less mental overhead, autocompletion, etc) try to use it lightly.

# Q: With the addition of Recoiljs, how do you feel that will affect the state management ecosystem? – SuperSheep

The state management ecosystem is so vast. It can be overwhelming to newbies. I don't have specific Recoil thoughts. I like seeing new options on the table. But I also know how difficult it is to make a decision about the data fetching layer of your app. You could spend years understanding all the differences. What I tend to focus on is if it meets the need I have (data fetching? ✅ ) and how it feels to use the library. Is it confusing? I worked with Redux for so long, I didn't realize until I started on a new team, that a lot of engineers struggle with it. So we started researching a new library that would be easier to get started with. (We didn't land on one before COVID happened and that business didn't last.)

# Q: I'm working on ONGOING project, i'm currently on sprint 9 (Giant project)… there are a lot of BUSINESS RULES on those folders, its too difficult to undertand the project overall… how do you think i could debug a big project without any kind of documentation, chart flow, or a Read-me explaining the code and the flow of the project? Where could I start? – Daniel

Here's my advice for debugging anything: learn how to use Chrome's developer tools really, really well. (Or Firefox! But I use Chrome.) Being able to log, pause execution, examine variables and loops, etc is the best way to understand what the hell is going on. Jon Kupperman has an excellent deep dive on Chrome devtools on Frontend Masters - highly recommend.

# Q: Why do you choose react over vue or other frameworks? – Floofy Boi

The truth? Because you want to work with it. 🤷‍♀️ Yes, there are maybe some solid technical use cases for each framework but the truth is, JS frameworks these days are pretty good. Vue is great. Use it if you want. Use React if you want. I've found that React works well with my mental model and how I think about building things. Vue, less so. But for someone else it's the complete opposite. Use what speaks to you.

# Q: With the growth of graphql ecosystem, do you think Apollo as a client will remain relevant? I prefer doing my data management through redux and selectively calling APIs – ashesh

Obviously, as a previous Apollo Client maintainer, I'm biased here. But yes, I do think it will stay relevant. Besides the fact that Apollo Client is used heavily by huge companies, it does its job well. It's more fully featured. The community loves it. And Apollo Client is continuing to evolve. I'm very excited for the future of the project (but I also know the "secret" upcoming features 😉 ). And hey, if Redux is working for you, go for it. It's all good.

# Q: Hey Jenn, what do you think that could be a next step when it comes to career to someone who already has a good knowledge of React(mostly Native) leaning towards Mobile Development? – Deleted User

Hard to say but as some general career advice, once you get some experience, the world is your oyster. As an engineer, you can do anything you want. Learn anything you want. Be anything you want. I've been a frontend dev, OSS maintainer and my next step isn't either of those two. I go where I find I'm interested and can keep growing as an engineer.

# Q: What would you consider to be a good code sample or project(give examples maybe 🙂 ) which you can use to apply for internships or other oppurtunities as I recently got rejected for MLH fellowship for not having a great code sample? – Deepayan

Games make great sample projects. A lot of people build tic-tac-toe or something similar. I built a Tamagotchi. I learned a ton. And it even inspired this talk

Sentry.io Team

Reactiflux — Wed, 21 Apr 2021 16:00:00 GMT

Talk with Sentry devs

– Join Sentrys Discord community to talk shop with the team.

# Q: Is there any plans to redesign the UI of the Sentry dashboard in the near future? - @fruityoyo

A: Hey I focus on the performance product so I can answer this one. Dashboards recently got an overhaul where you can create and edit dashboards however you like with discover queries. But we want to further improve the experience around managing dashboards since it can become hard to manage once you add more and more of them, so you can expect to see a new dashboard manager coming soon. (And even earlier if you go to your organization settings and enable early adopter). For those unfamiliar, you can see more of what dashboards in Sentry are here: https://docs.sentry.io/product/dashboards/.

– wmak

# Q: If a beginner knows nothing about Sentry, how would you describe Sentry.io? - @GautamArora

A: My normal "answer for grandma": Computer programs have bugs, but normally the only way the programmers find out about them is if you hit a bug and email them about it, but almost no-one does that. We write code that other programmers can include with theirs, so that anytime there's a bug, it sends us a report, and then the programmer can log into their account and see all the bugs and find out where they happened and how often and all sorts of other data about them, so they can fix them.

– lobsterkatie

# Q: If a beginner knows nothing about Sentry, how would you describe Sentry.io? - @GautamArora

– lobsterkatie

# Q: Will you or do you support URI reporting? (CSP reports, HTTP errors, etc.) - @Syntax

A: Yes we do https://docs.sentry.io/product/security-policy-reporting/

– Evan

# Q: Is there a way to get the latest release for a given project from the Sentry API? - @zpr

A: I don't think we have an API endpoint specifically for that, but you can see the full list of release endpoints we support here: https://docs.sentry.io/api/releases/. But we're open source! So if you're looking to add this for something you need we can work with you to add it https://github.com/getsentry/sentry/.

– wmak

# Q: What are the future goals of Sentry? - @bereket

A: So we've definitely been focusing pretty heavily on our application monitoring product. Realistically from a users perspective errors take more form than just an uncaught exception. A poorly performing product is just as bad of an experience as the product having bugs. We've built out an entire tracing and performance product (https://sentry.io/for/performance/) to help solve that, and is something we're working very hard to push from something that's already very good, to being world class

– Evan

# Q: How much boilerplate is involved with including Sentry to a project? - @Ari Chayo

A: It depends on how customized you want your setup to be. In the simplest case, after you install the SDK, you can do

  dsn: "your dsn here"
})

and all unhandled exception and promise rejections will be captured. There's a LOT more you can do, though - both to control what the SDK captures and what data is sent along with your events. https://docs.sentry.io/platforms/javascript/

– lobsterkatie

# Q: Which skills should a frontend have to work at Sentry.io? - @raerpo

A: You can see our job postings here https://sentry.io/careers/, and we call out React, Typescript specifically in the job postings, but I think interpersonal skills like being collaborative and communicative are just as important.

– wmak

# Q: Should I worry about memory pressure if I record a lot of breadcrumbs? - @Dzetah

A: So there's a maxBreadcrumbs option on the SDK you can set if you're seeing issues with memory, and more information on this setting here: https://docs.sentry.io/platforms/javascript/configuration/options/#max-breadcrumbs. But we use Sentry on Sentry.io and haven't had issues with memory, even though we record a lot of breadcrumbs.

– wmak

# Q: What is your elevator pitch to prospective companies that may be open to using Sentry? (I ask because I'm trying to get my product owner to use Sentry for our project) - @BoHo

A: The short and sweet answer I have for this is: if you're not doing anything to monitor errors, how do you know if your users are having a good experience? Logs can help, but won't give you much insight into impact. Sentry can tell you how "bad" an error is. Is it something just affecting one or two users? Is it affecting your biggest customers? etc. I would also recommend checking out our Sandbox (in nav header) on https://sentry.io/.

– Evan

# Q: What advantages do you get by capturing all these unhandled exceptions, and what interesting things do you do with this data? -@Ari Chayo

A: We have a tool called Discover https://docs.sentry.io/product/discover-queries/ that allows you to build nearly arbitrary queries on error data that you can use to aggregate interesting information from unhandled (or handled) exceptions to find out what segments of your users are having bad experiences or are leaving your site because of errors.

– wmak

# Q: I am in the market for a tool like sentry. My "must" is for the tool have correlation (or end-to-end) tracability, from click on a button in react all the way to the exception in dotnet core backend. Is that something Sentry offers? - @Las3r

A: You're in luck! Our Performance Monitoring product does exactly that. Here's some docs about the general idea: https://docs.sentry.io/product/performance/distributed-tracing/ And here are the docs for your platforms: https://docs.sentry.io/platforms/javascript/guides/react/performance/ and https://docs.sentry.io/platforms/dotnet/performance/ If you have a more specific question, I'll be happy to answer.

– lobsterkatie

# Q: I thought it was pretty crazy when I learned that all of Sentry.io is open source and you can set up your own On-Premise installation which is basically self hosting the entire infrastructure for the web app. Aren’t there some considerations of people doing this instead of paying for a subscription? What is the benefit of offering this? I think it’s a great thing but really so few tech companies do this. - @MikeMK

A: I think its a mix of things, self hosting is "free" but isn't "free" since users still have to maintain their on-premise installation. And we regularly have customers migrate from self-hosted to SaaS sentry. It's a give and take IMO, we get to build something that's open source, and get contributions back from our customers occasionally. And the customers who can't use SaaS sentry for whatever reason can still use our software.

– wmak

# Q: Is there a way to use a NOT operator when filtering issues? I haven't been able to figure it out and that would be useful. - @Jim

A: Yes! if you had a query like message:"the world is broken" you can exclude errors with that message by prefixing with an exlamation eg. !message:"the world is broken". You can read more here in the docs: https://docs.sentry.io/product/sentry-basics/search/#exclusion.

– wmak

# Q: What's the best way to give feedback on a normal day? Here's mine: It's kinda confusing that the "We recommend you update your SDK" prompt link leads neither to upgrade instructions, nor to release notes. - @Misamoto

A: The original goal of the upgrade your SDK prompt was that we have a lot of customers on older versions of the Sentry SDKs that don't support our performance features (which often are auto-instrumenting and just work out of the box). You're right that it doesn't have upgrade instructions (which I actually don't think is too bad, since the docs it links to include install instructions). We cut showing a changelog due to time constraints, and we considered that it would still be valuable to at least let users know there are new versions. But to your point, this was a time constrained feature that we want to make better.

– Evan

# Q: I don't know if you know a ton about this but: how did Sentry originally present itself to the public and grow so much? - @bereket

A: That's looong story and I'll refer you to our blog post about our founding

– lobsterkatie

# Q: First off, hats off to the amazing work with the TypeScript migration, and thank you for sharing your process and takeaways with the rest of us. You said you're seriously considering introducing end-to-end type safety between the backend and frontend. What are some of the tradeoffs you're weighing? What will your decision about pursuing this come down to?

A: End to end type safety is definitely something that we're still figuring out "how" we're going to do it. Our backend is python, so sharing types there isn't an option. Likely how this will look in the near term is having a master list of endpoints which is typed on the frontend, with another python3.x typings file on the backend, that we just keep in sync through either some automated review tooling, or through human word. We actually don't run into too many type errors like this, so it might end up on the backburner for a while. We mention graphql in the blog, but oooof, probably not any time soon.

– Evan

# Q: What happens when there is a bug in the Sentry platform? Is it terrifying? What happens when your platform for tracking bugs has a bug in it? How do you handle testing and such? Seems like it could be stressful! - @MikeMK

A: Yes, it is terrifying. I think anytime there's a bug in any production system it's terrifying. But fortunately we have Sentry monitoring Sentry, so we can usually identify the bug very quickly and get a fix up before customers start feeling pain. Sentry has a pretty large set of unit and integration tests, along with snapshot tests so we don't break the UI, so we're not usually that stressed by bugs.

– wmak

# Q: How’d you come up with the name Sentry? - @Sysnomid

A: It's from Starcraft (lol - as are a lot of tech companies founded in the late 00s). Our original SDK was actually called 'raven'. It was kind of backwards because ravens dropped sentries...not the other way around as implied by the old raven sdk being a consumer of Sentry.

– Evan

# Q: I'm loving Typescript, do you do too ? Was the transition easy for you with such a large codebase? - @Dzetah

A: I can say with confidence, at least anecdotally, wrting TypeScript has made me feel some non trivial 2x % more productive writing software. In general, I really like it. Our transition was not easy, it took a good 18 months. But was it worth it? Hell yes it was. I just refactored something last night where there were a lot of indirect props being used through the code base. Before TypeScript, knowing if it was safe to remove a prop was a real chore, not so much now. Checkout the full blog post for more nitty gritty.

– Evan

# Q: Where do you see sentry going in the next 3 years, and how has the pandemic been for you? Have you seen increasing or decreasing adoption of Sentry? - @mortuie

A: Sentry is going to go more into the Application Performance Monitoring space. We're hoping to tie errors and performance together better. Especially when you think about the fact that some users will just treat a slow site as a broken site eg. "I waited more than 2s...time to try something different instead!" I believe our users think our product is great, so we've been seeing increased adoption.

– wmak

# Q: We have been using Sentry to monitor our react app, but the error stack is hard to read as it shows the compiled code. What's the right way to upload the map file so that the error messages can be readable? Any sample/example repositories/documentation would be helpful. - @JohnWick

A: Source maps! There are some docs here: https://docs.sentry.io/platforms/javascript/guides/react/sourcemaps/. It's a slightly finicky process, but here are the keys:

Get your bundler/transpiler to generate source maps.
Use either our webpack plugin or sentry-cli to upload them
They are matched with events based on release value, name, and dist value, so:
- You have to set the release in your Sentry.init and mark it on the maps when you upload them
- Same with dist, though this mostly only applies to mobile SDKs, so you can likely ignore this unless it comes up on its own.
- As far as naming goes, you're looking to have the name of the files either be an exact match to the URL of the erroring script, or the URL with scheme and hostname (http://some.site.here/ <---- but nothing more than this!) replaced by ~. (You can control the name of the uploaded files with webpack-plugin or sentry-cli).

CLI docs: https://docs.sentry.io/product/cli/releases/#managing-release-artifacts. Webpack plugin docs: https://github.com/getsentry/sentry-webpack-plugin/blob/master/README.md

– lobsterkatie

# Q: Which tool are you using to generate those diffs ? I'm currently looking for something similar. - @Dzetah

A: Built in house! https://github.com/getsentry/action-visual-snapshot We used to be using Percy but we though "hm, we can build this better and not pay 10s of thousands a month". It's open source too!

– Evan

# Q: As someone who is just starting off the journey of learning JavaScript, what are your favorite TypeScript resources? - @r_escribble

A: I went through the course at https://www.executeprogram.com/ when I was first learning TS, and found it super effective, because it really forced me to think about every line of code.

Now that I'm an everyday TS dev, I tend to rely on a combo of:

The TS docs, which are pretty well-written: https://www.typescriptlang.org/docs/
The TS playground: https://www.typescriptlang.org/play
Code completion and linting in VSCode
Google, which inevitably takes me to stack overflow

– lobsterkatie

# Q: Did you use anything before TS? we use like a mix match of JS doc + ts types. How did you find that in comparison to TS if you did? - @mortuie

A: Mostly JS docs and propTypes. But our JavaScript SDKs were actually already written in TypeScript before the Sentry application, so we did have a bit of a head start in knowledge.

– Evan

# Q: What was the toughest thing you guys had to do when writing react? - @sticks

A: Maybe not the most difficult, but one difficult thing has been finding the right balance of reusability in our components. We've also been stuck on an old version of Reflux (yes reflux) for a long time now, and are actively trying to figure out how to do non-local state management in a more DX friendly way. I was looking at react-query the other day, which looks nice. We're also adopting hooks now which is great.

– Evan

# Q: You've linked https://github.com/getsentry/action-visual-snapshot. Any other useful things from you that aren't your main platform you think would be worth looking into? - @Misamoto

A: This might be a bit more specific, but I just built this little service to generate charts on the backend via an API https://github.com/getsentry/chartcuterie. Unfurling Sentry links into charts in Slack is coming soon. Here's a tool we wrote to do releases better: https://github.com/getsentry/craft. Last one I'll share: great python library we wrote to mock requests responses - https://github.com/getsentry/responses.

– Evan

# Q: What's the most effective way you (Sentry.io team) see to get into coding? - @Jimmy

A: Folks at Sentry come from all different kinds of coding backgrounds - we have CS grads, people who are self-taught and have been doing this since they were 12, career-changers who went through bootcamps...there's no one right way to learn. You have to figure out what works for you - following tutorials? In-person classes (assuming covid ever ends)? Writing a project and then looking things up as you need them? Going to a meetup? Try a few options out and see what you like.

– lobsterkate

# Q: Is Sentry hiring?

A: We're hiring a ton across all our teams, in 3 major tech hubs (San Francisco, Toronto and Vienna). You can see more here: https://sentry.io/careers/#openings. We're a fun group of people, leave our egos at the door, and build great products for developers!

– wmak

I will say that (no lie!) I love working at Sentry. It's been a great place to grow as an engineer (I'm one of those career-changing bootcampers). It's full of super smart people who build awesome stuff, and we really do not take ourselves too seriously. Come work with us - it's a great team!

– lobsterkatie

Max Stoiber

Reactiflux — Wed, 17 Mar 2021 16:00:00 GMT

# Q: I see people talking about using css vars instead of theme file with context in styled components… What's your opinion and what do you think is the best practice for projects? – Yann

Whether or not it makes sense to use CSS vars depends on your team, whether you have e.g. designers who don't know JS too well, and how dynamic your theming needs to be!

# Q: Whats the best way to practice? – DJ Turkey

I don't really "practice" coding per-se, although I'd really love to know if anybody else does — kind of like sports people 🤔 I just build stuff I like, and get better by looking at my code from a couple months ago and realising "Damn, what I did there was really confusing/unmaintainable!" 😬

# Q: What is the difference between software engineering and computer science, and is it easy to transition between both? – JakubGamer

I unfortunately don't know how easy it is to switch between them, as I've only done very little computer science in my career. I didn't study or anything, I've mostly just written code 🙂 I do think CompSci is it's own discipline, I doubt I could "just" switch to doing that full-time

# Q: What are your thoughts on React for building simple static websites? – de2290

I love using React, personally! It just fits really well with my brain and works the way I think, so I'd much rather use it than anything else, even for static sites and other stuff

# Q: In React Native, you can use Styled Components but can't do nested styling at the minute. Why isn't it currently the case? And do you guys plan to change this and allow nested style in react native as it is available in react.js? – Vi

Unfortunately, that's just a limitation of ReactNative, it simply does not have nested styling so we also cannot support it

# Q: What is your opinion on Stitches? Do you think it will influence styled-components and the broader ecosystem? – Christoph

This is a fantastic question! I'm extremely excited to see a bunch of innovation happening in the CSS-in-JS ecosystem again — it feels like that kind of stagnated over the past years.

Personally, I'm keeping my 👀 on Stitches from Modulz & Compiled CSS from Atlassian, I think both of those have the opportunity to really change the CSS game once again. Would recommend checking them out!

# Q: Is there any planned version for bedrock REST friendly, if not, why? – simply

No. I have exclusively used GraphQL for the past five years and don't plan on ever using REST again (unless I have to). GraphQL's developer experience is simply miles ahead of REST, between Prisma, Nexus and GraphQL Codegen there is no way I can move quicker any other way 🙂

Bedrock could certainly be used REST-ful, of course — it's "just" a Next.js app after all. However, you'll loose out on a bunch of the benefits of the tightly integrated stack, so you're likely better off building your own foundation.

# Q: I’ve been coding with React for the last 6 months now working in a company for 4 of them, and I feel like both improved and not improved at the same time. What advice would you give a new starter like me to improve myself in a better way in React? – yemirhan

Congratulations!! 🎉 I also feel like I haven't gotten "better" at React itself ever since I learned hooks 🤣 Most of my growth has come from moving up and down the stack in related areas like learning more about how to build APIs, how databases work, how to scale backends, how to build design systems, etc.

I think React, once you understand it deeply, is really simple. I just realised recently that I look at the React docs maybe once every month, if at all!

# Q: How do you read an open source project's code and contribute to it? – Aslemammad

This is really difficult!! Mainly, don't be discouraged when you don't understand everything immediately — particularly if it's a mature project that's been worked on for years. It can take a while to get familiar with the standards & conventions, and understanding the different pieces and how they work together. Take your time!

# Q: Can you use something like Next.js to build a big dashboard application like Stripe? – adebiyial

Yes. 🙂

# Q: What would you say about those who bully me and demotivate me to code? – Deleted User

Don't worry about what anybody else says, they're just jealous because they haven't found anything they enjoy doing as much as you love coding! Ultimately, I think everybody wants to have their "thing", the one thing they really love — and once you find it, the people that haven't yet get jealous and pull you down.

Ignore them and hang out with folks that are excited for you instead! Like the Reactiflux community 😉

This is fun! Trying to type as quickly as I can so I answer all the questions 😊

Sidenote: shoutout to the moderation team for keeping this civil! I know how hard it is to moderate a community of any size, nevermind one as big as this 👏👏👏👏

# Q: What’s your opinion on Box component like implementation (like in material UI), vs atomic CSS frameworks like tailwind? – HHK

I recently wrote about why I think Tailwind is awesome, and the interesting thing is that it has nothing to do with it being atomic CSS: https://mxstbr.com/thoughts/tailwind In fact, I would not be surprised if we're seeing a fantastic system like Tailwind but implemented as not-atomic-CSS in the near future!

# Q: What are your thoughts on SvelteJS? – parvez

I haven't been able to use it so I can't say much, except that it looks really exciting. I love watching the JS ecosystem evolve and get better — people complain about "framework fatigue" but honestly, I love nothing more! Please keep innovating! I don't want to be stuck using the same tools I'm using today in fifty years — that would be really sad to me

# Q: Do you recommend CRA or SSR (Nextjs) for dashboard admins (behind authentication wall, why? – simply

I would likely recommend CRA because SSR / SSG are unnecessary for that use case and only add scaling problems. Why endure long build times / server side rendering server troubles if you don't have to?

# Q: As someone who sporadically tries to contribute to OSS (just doc modifications et all), what are more ways I can find projects / repos to contribute to? – _binarynumber

I think the best contributions are the ones that are already sitting on your hard drive right now! While existing projects could always use more manpower, you are already writing code every day — and if you wrote a piece of code, you likely didn't find a suitable open source project that does what you need.

So why not make that happen by publishing your own code as a library? 🙂

# Q: I've been struggling with authentication in React for a while now. Typically I'd save my token in local storage but I don't like this enough as it is barely exposed. I know you should save insensitive data. But I see many big applications don't even do that. Instead they use cookies. How do you do yours? – adebiyial

100% cookies for everything, specifically stateless ones:

Stateful authentication requires a database query on every request.
Stateless authentication only does a database query when the user authenticates.
Stateful authentication allows you (or your users) to revoke sessions.
You cannot revoke sessions with stateless authentication.

At Spectrum, I initially implemented stateful authentication but it started affecting our performance too much since it's overhead on every request and we were hammering our database unnecessarily.

Switching to stateless authentication made scaling a lot easier, and we never even revoked a session or implemented that for users while we had stateful authentication.

I've used stateless authentication ever since, hence why it's in Bedrock as well!

# Q: What's the best way to find ideas for something one would want to build for their side hustle? – _binarynumber

Same answer as to your last question: which problems are you encountering in your day-to-day life? What keeps annoying the everliving hell out of you?

If you have a problem, it's very likely somebody else will as well! (note: verify this before building your solution) So, why not solve it for everybody?!

# Q: In your opinion if you were to create a web ui framework, how would You go about approaching it? – SilentOS

I would never dare to try, hahaha! Kind of ties into my last answer, I don't have any problems with React or other current-gen web UI frameworks, so i wouldn't even know what I'd do differently — at which point, why even build a new library?

I'd rather solve unsolved problems, like we did with styled-components way back when 🙂

# Q: What's your opinion on CS degrees & surviving without it in the industry? – _binarynumber

I don't have one and I don't plan to get one 🙂 I think you can be a perfectly competent programmer without one. However, if you like learning about CompSci a CS degree is likely the best way to learn more about it! I just don't enjoy CompSci that much, I'd rather just build stuff 😉

# Q: Is it better to spend time on big open source projects, or small open source projects that may become influencial like react boilerplate? – JakubGamer

Hard to say, better in what way? I don't think they're exclusive: you'll likely learn a lot when helping to maintain a big open source project that's going to be helpful when building your own from scratch!

I personally maintained KeystoneJS when it was already big, and it taught me a lot of things I then used to grow and maintain react-boilerplate and styled-components

# Q: Do you think react-boilerplate has a future? Do you plan to work on it anymore? – Simon1709

I haven't used react-boilerplate in many years because I haven't had the use case it solves, so I also couldn't maintain it anymore. Instead, I've passed off maintenance to a team of maintainers who actually use it and know how best to improve it — but honestly I have no clue how that's going!

# Q: Do you have any opinions on tools that generate graphql apis, like Postgraphile and Hasura? – (d,f,g)=> {}

I've tried Hasura and found it... lacking for anything serious 😬 But that was a year or so ago, so things might have changed! A lot of people have tried to solve this problem (GraphCool, Reindex) and a lot of people are still trying to solve it (GraphQL Portal, StepZen, Hasura,...). Time will tell if anyone will actually figure it out...

# Q: Do you reasonML getting bigger and making more of an impact in the react community? – ivoryblakk

I definitely hope so, ReScript is awesome! I haven't personally had time to dive into it, but it's high up on my list of technologies to learn 😻

# Q: What do you think about webassemby and its intégration in react – thmax

I have never used wasm so I unfortunately can't say 🙂

# Q: What do you think about making our own code reactive instead of using reactive library or frameworks, OR just using the reactivity of the frameworks? – rohit2sharma95

I've played around a bit with CycleJS and RxJS, but it's never quite clicked for me unfortunately. I think in React now, so those frameworks are very different to the way my brain works. 😬 I wish I could understand them better!

# Q: Why don't you go work at a FAANG company? – Todor

Great question! I recently had to decide what I want to do next in my life after leaving Gatsby, and had some job offers from well-known companies that would pay me a lot more money than I ever dreamt of making.

However, when I sat down and had an honest conversation with myself about what I want in life, I realised that those jobs would only make me unhappy.

Very personally, here's what I wrote down in my own, private notes. (I didn't think I'd be sharing this, so excuse the raw-ness) If you look at the list of things I value, you'll very quickly realise that most of them are in direct conflict with working at a big company 😬

That's why I want to found another startup! It's going to make me much happier, even if I make less money.

# Q: I feel that my projects with styled-components are unorganized, what pattern would you recommend for me? Something like RSCSS or BEM for css – Edgar Marques

https://stackoverflow.com/a/42996969 🙂

# Q: How your new experience as investor is going? – simply

It's an expensive hobby, I'll tell you that! 🤣

More seriously, it's just a really fun way for me to following other entrepreneurs journeys. Being a fly on the wall as they figure out their own path is incredibly satisfying and fun. I try to only invest in startups that could benefit from my experience / audience / knowledge / etc so I can maybe even help them avoid a problem or two that I've already seen 🙂

Will definitely have to dial back my investing now that I don't have a job anymore though 😬 (more context for those curious: https://mxstbr.com/investing)

I have (un?)fortunately never had to do that, so I don't really have any tips or advice here!

# Q: Does bedrock have multi-factor auth and/or support for social logins or passwords. Magic links can be inconvenient for users that use password managers so it would be nice to have options here :P – Sonicrida

Absolutely, Bedrock just uses Passport, so you can use any of the 500+ authentication strategies that Passport supports! 😻

# Q: How is your rock climbing going??!! – Gabe

I HAVEN'T BEEN ABLE TO GO IN SIX MONTHS AND I HATE IT!!!!

I've probably lost all of my muscle and skill 😦 I was projecting my first 7A (indoor) but couldn't finish it in time before we went into lockdown — now I'll definitely have to work my way back up there.

# Q: Given Tailwind's recent addition of a JIT compiler (+ related community projects), which also supports dynamic CSS values (e.g. top-[113px]), what remaining use cases do you see for a CSS-in-JS implementation of Tailwind? In other words, what could a CIJ implementation do that the JIT compiler couldn't? – MapleLeaf 🍁

The JIT compiler is so good! I'm so glad they built that, however I still don't think atomics CSS is the best way to expose their (fantastic) design system. I can't wait for somebody to find another abstraction for it 😉

# Q: Does Bedrock play well with Serverless (e.g. Azure Functions)? – SuperSheep

Bedrock uses Next.js API routes for all the backend functionality, so it's basically fully serverless already! (depending on where you host your product)

# Q: I'm using styled components and making a styled component for a line of CSS here and there is getting pretty tiring. Is this the way it is meant to be used? – IndecisiveQi

Nope! That's why support the css={} prop on any DOM element 🙂 https://medium.com/styled-components/announcing-native-support-for-the-css-prop-in-styled-components-245ca5252feb

# Q: What are your views on the rise of the rapid decentralization, and would you ever work for the blockchain technology? – Deleted User

I have literally no clue how the whole blockchain thing works. 🙈 I don't own any crypto (or plan to, for that matter).

# Q: How did you decide the price of bedrock? – IndecisiveQi

I calculated how much time it took me to set it up, then made it 1/100th of the amount of money I would've made if I had freelanced during that time instead.

Just kidding, I wish I had been that smart about it. I just YOLO'd the price. 🤣

In fact, I think I made it way too cheap. By now we'd probably be at 1/500th the amount of money I would've made as a freelance during that time 😬

# Q: Why bedrock name? :p – simply

Nope! Been very focussed on Bedrock at the moment 🙂

# Q: I appreciate your personal motivation list for wanting to run a startup. Was agency something you lacked at Github with spectrum (and a reason why it seemed you left pretty soon after joining)? – Sonicrida

Yep 🙂 Anytime you work at a large company, you are very constrained in what you can do. You have a job, and doing anything outside of that job is not endorsed.

However, I enjoy variety: I like doing a bit of marketing, a bit of sales, a bit of customer research, a bit of design — not "just" pure engineering. I did not have the agency, the freedom to do that, hence why I left and am starting another startup! 🙂

# Q: What will you do different with your next startup compared to the first? – Gabe

Fantastic question. I always compare starting a startup to surfing: one moment, you've caught a perfect wave and are surfing along into the sunset. The next moment, the wave smashes you into the floor face-first, water swoops over you and you're gasping for air.

That's what it feels like to build a startup. It's an emotional rollercoaster unlike anything else.

A lot of what success in startup-land is about is managing those emotions. When things are great, be excited but know that it's going to get worse. When things are bad, be sad but know that it can only get better. Going to try to even out those waves a lot better than I could at Spectrum 🙂

# Q: Will gatsby StaticQueries ever get support for variables? – esimba

Unlikely, just based on how they work: the compiler won't know what those variables will be!

# Q: How did you get that sharp jawline? – Deleted User

Have my parents to thank for that! 😉 They're the best 💜 In case you haven't seen https://www.youtube.com/watch?v=ifq3xhik8tE yet, would highly recommend watching just to get to know my amazing parents.

# Q: Can't wait for bedrock but out of curiousity is it built on top of blitz js or is it a custom setup? – AllanP

Bedrock doesn't contain custom abstractions like Blitz, it's just a collection of open source tools made to work really well together! There isn't even that much to learn, if you know Next / GraphQL / Prisma, you pretty much know Bedrock 🙂

# Q: When will Gabe stop asking you to give answers, doesn't he know that you're a human and you get tired too? – Deleted User

🤣

Please don't! I'm loving this, this is super fun 😄

# Q: As a somewhat novice freelancer, do you feel Bedrock would be too much for me to handle, or would it be like developing SaaS with training wheels? – Elsewhere

Hard to say, that depends on your level of experience with React / Next / GraphQL 🙂 I wouldn't recommend Bedrock to a beginner, as it's likely to be overwhelming — try to build your own version first, realise how difficult it is to make it work well and then buy Bedrock 😉

# Q: Is there any question you wish you had an audience plant for so you could shill something? 👀 – iggy

Hahaha I appreciate that! I don't have anything to shill outside of Bedrock, but I feel like I've already shilled it enough with all the questions about it 😬

# Q: Are you sad about spectrum being shut down? – simply

Yes, very. I poured my heart into Spectrum for a solid two years, so seeing it be shut down definitely makes me sad. 🙂

However, it's definitely the right decision: GitHub discussions are fantastic and a much better replacement than what we had.

# Q: There are a lot of rumors going around about React being bad at SEO. Is there anything you do in conjunction with React to optimize SEO in your projects? Or anything you would say on the matter of SEO utilities in conjunction with React? – JasonHoku

Bullshit. Spectrum was built with React and had the best SEO of any real-time chat app I've ever seen 😉

SEO is just a matter of that, optimizing for search engines. You're going to need SSR / SSG, but once you have that whether you use React or anything else doesn't matter.

# Q: What do you think about startups and the obsession with raising money. – adebiyial

Here's the thing about raising money: it's only useful for a specific type of company, a startup.

Startups === growth. If you're taking money from investors, you're essentially saying "I'm going to do everything I can to make this a huuuuuge company". That's a fine goal if that's what you want to do! However, if you don't then that's also perfectly fine! I've been enjoying watching indie hackers like Tobias & Timo Lins of https://splitbee.io/ do their thing without any outside investment and without being forced into growth at all costs 🙂

Personally, I do want to try to build a huuuuge company in my life, so I'm definitely going to bring investors on board for my next company. However, that's just a personal choice I've made for myself, not something everybody needs to do 🙂

# Q: What's in the future for styled-components? I really enjoy using it and can't wait for potential updates. – Okhai

We have some distant plans to rework the core again to make it even faster & smaller but honestly... it's mostly done! It's really stable, bug-free and just works the way it should.

I would keep my eye out for new libraries that are up-and-coming like Stitches and Compiled — those are really driving the innovation nowadays!

# Q: As a student I already tried different working environments (startups, freelance). Now I would like to try an internship in a large company but even with side projects it's still difficult to get an interview, do you have any tips to stand out – Maji

Yes! The best thing you can do to stand out is to show that you understand "business". Specifically what I mean is, write something like "Increased sign-ups by xx% by spearheading an initiative to rebuild our frontend" and stuff like that.

Demonstrate that you can have business impact with your work, and any company will immediately want to hire you 🙂

# Q: What do you think about remix run? – simply

I'm excited about Remix! I can't wait to see where it goes and all the innovations Michael and Ryan are working on 😻

# Q: In a battle royal of the mods who would win? – Elsewhere

Me. I'm a mod right now, I think 😉

# Q: Does the location matter for building a startup? – simply

No. You can build a startup from anywhere. However, if you really want to take investment and build a startup startup, you have to know the right people — most of whom are still in San Francisco. Not at least spending time there is going to make your life a lot more difficult, unnecessarily.

However, for anything other than raising money: LONG LIVE REMOTE 👑

Yarn Team

Reactiflux — Wed, 10 Feb 2021 16:00:00 GMT

# Q: What are some of the advantages of (collabing) open sourcing/source projects in terms of reputation, business and enjoyment? – JakubGamer

Interesting large question 🤔 I think it depends on the project and the investment you put into it - professionally working on Yarn was a pretty good ice-breaker in interviews, since you basically can talk about allll sorts of interesting stuff that relate to your interviewer. In terms of enjoyment I simply really like working on a project I'm proud of. – arcanis

# Q: Original question was deleted – unknown

I almost always wrote open-source. A long time ago it was phpBB scripts for users of a forum hosting, now for JS developers 😄 some projects receive more attention than others, and Yarn already had a decent following when I joined it. It's been great to have a project with an actual community, although sometimes it can be a bit heavy too - I've spent more week-ends than I can remember fixing stuff. Double-edged sword. – arcanis

# Q: What's next on the roadmap for yarn? Any distinguishing features from npm? – nick

We focus a lot on the developer experience and internal infrastructure, I think a bit more than the competition (but I'm not objective ;). I find it important to spend time making sure that others people can build on Yarn, almost more than writing Yarn myself. For instance, with Yarn 2+ the plugin system lets you use our API to write your own features, without having to wait for us to merge them. People have already used that for super interesting experiments! – arcanis

We're planning to release Yarn 3.x quite soon (aka whenever we finish implementing the remaining breaking changes and features we've planned). You can see a list of breaking changes here (https://github.com/yarnpkg/berry/issues/1406). Other than that, we're working on supporting the "exports" field and the ESM resolution inside PnP and quite a few other feature requests in no particular order (many of them from the issue tracker).

We already have quite a lot of distinguishing features from npm (you can check the documentation for yourself and see them, particularly on the features page (https://yarnpkg.com/features) and on the CLI page (https://yarnpkg.com/cli)). We're constantly implementing new things that npm might not have or that it might do in different ways that we don't think would make sense for us. – Paul Soporan

# Q: Why did you decide to make package manager? – JakubGamer

I didn't! Yarn already existed when I joined the project, although the whole team rotated since then 😄 – arcanis

# Q: After quite a long period, what’s your opinion on the yarn 2 release announcement? Why did it receive such negative feedback and what could be changed to avoid that? How did you feel personally at that moment? – Vlad Kosinov

It's complex. On one hand I think we should have better communicated on the "It's perfectly fine to use Yarn 1 for as long as you want" thing, on the other hand there's been a lot of reactions from people who mostly had prejudice and didn't really try to understand what we were doing. But the great thing was that a lot of people understood it, and a few of them even joined us since then as core contributors! – arcanis

# Q: Can you explain yarn check? Any enlightment on fixing its failures? Not sure, if flattening out duplicate sub-dependencies relates to this, Hints on dealing with security warnings in sub-dependencies will help. – bruce

We deprecated yarn check a long time ago - this command doesn't really make sense: you shouldn't have to "check" that your project is correctly installed - it should be correctly installed! If there is a problem, then it should be reported at install time, not in a separate command. – arcanis

# Q: What does the road going forward without node_modules look like? Are there plans to work with other tooling developers (i.e., node, npm, webpack, rome, etc) to build a new standardized format when not using node_modules? – samsch (she/her)

Plug'n'Play is already a standard, we spent a lot of time describing its public behaviours so that others can implement it as well if they wish. In fact, pnpm recently added an experimental support for it! So now two package managers out of three support it natively 🙂 but yes, we work with a lot of project to try to get everyone onboard. For instance Webpack 5 supports PnP out of the box; same with Parcel, Rollup, etc. – arcanis

PnP basically works with most packages out-of-the-box unless they explicitly hardcode node_modules or if they use native implementations that we can't mount our patched zip fs layer on top of. This means that there's not much for us to do in the case of toolchains (like webpack), other than make sure that they work with PnP, since it's strictly the package manager that controls the generation of node_modules. Regarding other package managers, pnpm has already adopted PnP (via a config setting), but we aren't aware of any such plans for npm. npm also has their own tink initiative, but I'm not up to date to be able to comment on it. Regarding Node, it would be nice if Node natively supported Zip archives and if we could use the ESM hooks it now provides to lower the amount of monkey-patching we do (unfortunately there aren't any hooks for CJS) – Paul Soporan

# Q: what motivated and justified the decision to make such big breaking changes with yarn v1, and how do you feel it has impacted the adoption rate of v2? – (d,f,g)=> {}

It made adoption harder, of course - which I'm actually half proud of: it shows that we care more about doing the right (and difficult) thing than user growth. It also answers what we believe justified it: we truly believe node_modules weren't the right approach, and wanted to offer something more (while still providing escape hatches when needed, for instance with the node_modules linker which allows you to migrate projects while still remaining on typical node_modules install if you so wish). – arcanis

# Q: What drove the decision to make React more dependent on Yarn instead of just working with NPM? – Creation

I don't think there's been a decision or anything. People had problems with one approach, so they used another. There certainly wasn't a shadow cabinet 😂 – arcanis

# Q: How do I convince my team that npm is not the same as yarn? – jœl 🎲

show them this nice thread of tips @arcanis has compiled (https://twitter.com/arcanis/status/1300442490265362432)
show them the features page
show them differences in the commands each package manager supports

– Paul Soporan

# Q: Do you want to spend a lot of time perfecting and polishing out your first open source projects, worrying a lot about other people judging your code negatively, or is it more important to just get started with open-source? – JakubGamer

I don't care too much how people in general feel about my open-source code. Those who can complain are those who invest to make things better, so I tend to listen to my fellow contributors far more! Of course you still need to stay open to interesting external ideas, that goes without saying. – arcanis

# Q: Do you have upcoming plans with the new releases of Yarn. Do we have a special to look forward to? – pinkie

We are going to release Yarn 3.x soon(ish) - you can read more details on another answer above. As always, we're always looking for things to improve and implement – Paul Soporan

# Q: As a lead maintainer, how you do avoid looking at the massive codebase and going "gotta write everything from scratch" again mind-set? (I personally suffer a lot from this) – Hansi

I'm the bad person to ask this, I already did it once 🙃 but it was in insight dangerous, and it only worked both because I'm extremely stubborn and pushed through, and because I found great contributors to take co-ownership of various parts. Now I think we're happy of the general architecture, and refactorings on the 2.x+ have been very incremental. – arcanis

# Q: What are your thoughts on npm 7 supporting yarn lock files too? – SferaDev

A fact rather than a thought - it doesn't currently support v2+ lockfiles and it turns them into v1 lockfiles, so… not completely happy 😄 (especially since it's impossible for npm to support Yarn 2+ lockfiles because it doesn't have enough information to manage Yarn's dep tree - caused by the difference in architectures) – Paul Soporan

I think Yarn used to be called kpm (for kittens package manager), but the name wasn't "cute" so it got a fancier label 🧶 no idea for the logos – arcanis

# Q: Do you think that open-sourcing works is an essential on the path of starting to earn money from coding? – JakubGamer

Absolutely not - I think open-source is an horrible way to make money (but great way to get some good learning experiences) – arcanis

# Q: What do you expect the lifespan of yarn to be until something else replaces it? – Todd

I personally think that Yarn won't be easily replaced, we are commited to keeping up to date with the ecosystem, especially since we now have a modular architecture in Yarn 2+ which allows us to easily add support for new runtimes like Deno or even other languages like Python – Paul Soporan

How nice would it be to have only one package manager to rule all your dependencies (and in darkness bind them 💍 ) – arcanis

# Q: Do you forsee an acquisition at some point happening with yarn similar to what happened with npm? – Todd

We're not a company, so that'll be difficult! Yarn was created to be a community project, and no single entity really owns it. – arcanis

# Q: Are there any plans on improving "yarn link" specially when it comes down to frontend projects and their issues? (still v1 user here, not sure if it has been drastically improved on yarn 2) – SferaDev

I'm not familiar enough with the specific issues frontend projects have with yarn link, but in v2 we've improved it a lot and made it use a new protocol called portal: which correctly follows peer dependencies – Paul Soporan

# Q: Any tips around asking employers to consider allowing some of your time towards an open source project? – trousered

It can be difficult. Usually the best answer is to find an overlap between the project you want to work on and what the company needs. For instance, Datadog, my employers, lets me spend some time on Yarn because it's a core part of our infrastructure, and a lot of improvements would benefit us directly or indirectly. But of course that's only a small part of my assignments, so I have to spend part of my own time on it. – arcanis

# Q: Is the package registry mirrored from npm or another or does it use the npm registry? – niwla23

We use the Yarn registry which is a simple CNAME to the npm registry - https://yarnpkg.com/getting-started/qa#why-registryyarnpkgcom-does-facebook-track-us – Paul Soporan

# Q: Is Yarn capable of supporting a truly massive monorepo? (not google scale but, say, an insurance company) – trousered

I think we have at least two users I'm aware of (ie that found our Discord) that have something like a thousand workspaces. We even made performance improvements specially for this use case, so I'm somewhat confident you can make it work 😃 – arcanis

# Q: Yarn workspaces are a very powerful feature. Do you see them continuing to evolve or take on new shapes in the feature? – Todd

Something we're investigating is multi-project support - which means having Yarn manage multiple projects with their own workspaces at once. This area also includes split linker modes in monorepos, because our current architecture makes it hard for us to implement support for per-workspace node linkers (e.g. using n_m for a single react-native workspace and pnp for all other workspaces) – Paul Soporan

For sure. We use them in our own monorepo, at our companies, and myself in my side projects. I'm sure we'll find ways to refine some rough parts of the experience over time. For instance, quick tip, Yarn 2 features a publishConfig.main field in the package.json that lets you pick a different main when you're developing locally, vs publishing the resulting package. It's super-handy when working with tools like ts-node or babel-register! – arcanis

# Q: Original question was deleted – trousered

Probably not, it'll be one or the other. We investigated it, and the conclusion was that it would require to abandon far too many assumptions to be worth the cost of implementing it straight into the core. It's still somewhat possible by dropping some requirements (for example by accepting having two lockfiles); perhaps we should document this option somewhere. – arcanis

# Q: What is a rule/principle you follow when writing code and why do you find it helpful? – Muffinoota

I don't think I have a particular golden rule, except perhaps conventions around how I organize my code. That makes it easier for me to find my way around when I come back months later. – arcanis

I'm not the right person to answer this question because I'm pretty much still a beginner in the JS ecosystem and I don't have the necessary experience yet - but generally I (should) try (more) to think in advance of the MVP and improve from there, because otherwise it becomes a mess pretty quickly – Paul Soporan

# Q: How do you balance continuing to add new features and growing the complexity of the code, while still ensuring you have enough man-power to support future releases for years to come? – Todd

We try to be really mindful of the code complexity. That's at least in part why we made it so that Yarn 2 can be extended via plugins: this way, unlike 1.x, we don't have to merge features unless we're ready to maintain them for the foreseeable future. It was a huge problem before because if you wanted a feature, the only reasonable way for you to use it was to wait for us to merge it … which in turn increased the complexity more, and more, and more.

Plus, plugin systems also constrain us and make it very obvious when we're doing some unfathomable thing that will be a pain to maintain.

And if you have any questions or want to know more about our progress, please feel free to join our little Discord community (https://discord.gg/yarnpkg) or to follow me on Twitter (https://twitter.com/arcanis) 😃 – arcanis

Wallaby Team

Reactiflux — Mon, 18 Jan 2021 16:00:00 GMT

# Q: Does the debugger work with asynchronous code or when fetching from APIs? – vansaltzman

A: Yes - the debugger works with asynchronous code and when fetching from APIs.

– Simon McEnlly

# Q: When these projects began scaling and getting attraction, did you have to deal with any conflict of interests for the future of the projects?

ie. times when you had to straight up say “no” – dilraj

A: Definitely. We have to do this often now but earlier on it was much more challenging to say "no" to one request and "yes" to another. We try and balance working on features that are going to help the most number of people; when we're not sure exactly what that will be, where we can, we gather stats and measure. Obviously the effort involved in supporting a feature requirement, etc. plays a big part in that decision as well.

At the same time, we are pushing ourselves to make revolutionary changes to our product and the ecosystem so are really trying to think about big features that are going to be game changers for everyone.

– Simon McEnlly

# Q: How would one go about “testing” things in the larger ecosystem of your application. For example, suppose you wanted to run daily “tests” to make sure there is nothing fishy in a database table. Could I leverage Quokka/Wallaby to achieve this result? – dilraj

A: Wallaby and Quokka are the tools that provide tons of value with immediate feedback when you type your code/tests. So faster your tests are - more value you get from our tools. Longer running tests, such as e2e tests, or database tests, may still run with Wallaby, but the value of running them with Wallaby comparing to running them as a part of your CI/CD pipeline, may not be as substantial as with faster tests.

– Artem Govorov

# Q: Are there any plans for editor agnostic tooling? ie something that would work with vim? – DFG

A: Unfortunately each editor has its own API and own way of doing things that can't avoid. I think we'd need a public standard API for editor extension development to support this. Out of interest, which VIM editor are you using?

– Simon McEnlly

Follow-up: I use vim 8.2

# Q: I bought a licence for Quokka on black friday, but I've yet to really get into using it as I was doing a lot of Gatsby. I'm going to try it out in a CRA app project now. Are there any common gotchas? – Cloudbop

A: f you're using Quokka with Gatsby/CRA, there can definitely be some gotchas. Gatsby in particular adds some its own runtime functions that aren't available in node.js by default (which is how Quokka is running your project). You may run into this when using Quokka and will need to avoid this in your code. The other big gotcha for create-react-app is that many people expect quokka to work with code like:

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

However, in this case, when Wallaby runs your code, nothing actually happens, all you've done is declare a function and not execute it. You'll need to also call Welcome({name:'me'}) with some sample props (e.g. at the end of your file) in order for Quokka to run your component.

– Simon McEnlly

# Q: 1st of all thx for developing Quokka, 2nd I am trying to configure it with React but still fail on it, any suggestion? – Linz

A: Quokka should work with Create-React-App without any config (Quokka has an internal preset for CRA specifically). If it doesn't work for you for CRA, or you're using some other React template/setup, please share the details at https://github.com/wallabyjs/quokka/issues, we are happy to help.

– Artem Govorov

# Q: I wanna use it on existed project do I need to create new one? – Linz

A: Yes, you should be able to use Quokka without any config on an existing CRA project.

– Artem Govorov

# Q: I think part of my confusion is regarding the Component runtime. So I should create a dummy component in Quokka (with dummy props) to test it? – Cloudbop

A: Yes - you'll also need to create a dummy component in order for the code to execute.

– Simon McEnlly

# Q: Is it possible to integrate it with other parts of runtime, like Redux? – Cloudbop

A: If you're using Quokka and want to use Redux, then you have to set up redux prior to Quokka executing your code. This can/may be a little tricky, depending on your project setup. You might normally see this code in your App entry point, etc.

– Simon McEnlly

Jared Palmer

Reactiflux — Wed, 13 Jan 2021 16:00:00 GMT

# Q: What were some of the biggest pain points you ran into while developing Formium? – JosNun

A: The hardest part was build the recursive logic engine. It is a mix of all the business logic, all the React performance tricks I know of, and also UI..

# Q: Is there any plan in reducing the amount of issues on GitHub? React Hook Form for example has less issues compared to Formik – NoLongerMe

A: Despite Formik's popularity, it is still maintained by a very small active group of people. I only have so much time to write open source nowadays, and the vast majority of issues don't impact day to day usage.

# Q: How far into a project do you prefer to be before you attempt to raise capital? – Roboto

A: Raising capital is always plan B for me. I largely agree with Paul Jarvis' "Company of One" philosophy. I had the opportunity (and still do) to raise capital from several VC funds for Formik/Formium but decided not to. Maybe one day I will, but right now I am happy to work with our enterprise customers and raise money the old fashioned way--through sales.

# Q: How has react hook form influenced Formik? – joel🎲

A: A lot of form libraries have effectively copied/cloned Formik's API. I am flattered by this. It means that I got it "right."

# Q: Does concurrent mode help with the performance issues you've encountered, and would it have been easier to optimize performance with a different framework? – Vanishy

A: Over the course of 2020, I wrote the form builder around 4 times. Most recent iteration is with Recoil. Not using concurrent mode at the moment in any meaningful way.

# Q: Did you write v0.1 in 1 week or less? Jk. Still, what was the thought process and timeline behind developing for ex formik? – SLCH

A: Ian White and I wrote Formik v0 in a day and refactored it over the course of a month or so before open sourcing it in 2017.

# Q: What is your opinion on free things on the internet? To what extent is it ethical to monetize things? – JakubGamer

A: There are only 3 business models in the world.

I pay
You pay
Someone else pays

# Q: Why did you use yup instead of defining native validations, Its complex and sometime makes things more confusing speaking from a beginner perspective. – Raizel

A: We looked at a few validation libraries on GitHub and liked Yup the best since it looked like PropTypes. The app we were working on had very complex validation logic so we knew that native validation wasn't going to work.

Formik was never meant to be for beginners. The expectation is that people know how to write forms by hand in React already.

# Q: How do you see formium evolving over the next several years and how do you think about it in the broader context of the form builder landscape? – bfine

A: I expect Formium to evolve into a few different areas. Obviously form building, but also storage and analytics. I think it's going to be the missing piece between hand coded forms and traditional form builders.

# Q: What would you say to entry level developers who are torn trying to choose between learning 20 different frameworks? – Big Jumbo

A: I learn new tools/frameworks when researching or solving a problem. This is my guiding light. For example, right now with Turborepo, I am learning all about build systems and graph theory. Frameworks will come and go, what matters is learning how to solve problems.

# Q: What do you think is the best way to start earning money as a programmer are? (topic of monetization) – JakubGamer

A: There isn't a "best" way. I'd say the question comes down to "how do you want to spend your day?" If you can't just spend every day like that, then your first step is to get to the point where you can do that. You'll need to figure out what you can do, what you're willing to do, what you enjoy doing, and what people are willing to pay you to do. Once you figure out this you have some choices. For example, there is the instructor/content route, this is the Kent C Dodds / Wes Bos approach. This can be fairly successful but earnings are pretty much capped at 1-2m / year. It's really hard to do more than that selling courses (without a staff). Another route is consulting. You can make a lot there too, especially if you can charge on project value (vs. hourly rates). The other route is IC at a company. Startups pay less, big tech pays more, finance pays the most. But, for me, the only way to really really change my universe is to own equity in something, like a product or a company. I'm extremely comfortable having done consulting for years but have hit a local maximum where the only way to the next level of stuff for me and my family is equity. I don't really need to work right now. I have infinite runway at the moment. So the only thing to do is build products that can scale.

To "start" earning money, I'd say start writing and making open source projects. These will set you apart from other peers and allow you to charge more than market rate. It also opens a lot of doors regardless of your education.

You can then transform that into courses, consulting, events, and products

or... just have cooler stuff on your resume.

# Q: What excites you about react in 2021? – kdichev

A: I am insanely excited about server components. They are going to make development a lot easier and also faster. Can't wait to see what abstractions people build on top of them.

# Q: Do you think Formik is necessarily siloed into being non-beginner friendly, or do you think the gap could be breached to be both beginner friendly and still technically powerful/flexible? – samsch

A: I think that it could be for beginners with enough documentation. However, very few contributors want to write docs and examples.

# Q: How would you differentiate an open-source/free project to one that you should monetize and what are indicators that a project might have a financial future? – ~~goomy~~

A: I think open source has changed a lot. In the past, before VC money got involved, it was a lot more collegial. Now, everyone wants to monetize instantly. Unfortunately, this just isn't possible. Some projects are extremely suited to monetization while others are not. It totally depends on how or if you can add value and charge for additional IP. One of the things I am doing with Turbo that is going to be different from my other projects is building for enterprise from Day 1. In addition to the CLI there is going to be an on-prem server and potentially a SaaS service as well. The CLI will still be open source and is still 10x faster than lerna even without a server, but the server can crank it even faster. I also am collaborating with enterprise on Turbo already, before its even out yet. I am specifically building for these customers--knowing that the solution will be generally popular ahead of time.

# Q: What made you decide to start companies based on developer tools instead of more consumer or business focused companies? – DylanVann

A: Not intentional at all. I am just better at making the level builders than the games themselves I guess.

# Q: Can you recommend any reading material or videos on being a successful software developer in business? – LilMicro

A: I would read all of the Basecamp books, Company of One by Paul Jarvis, The Making of a Manager by Julie Zhou, Ask, Zero to One. Then also Patterns of Enterprise Application Architecture by Martin Fowler and all of the Paul Graham essays.

# Q: How would you recommend a student in college try to break into the industry? Projects don't seem to be enough at the moment. – incredible

A: Build a breakable toy for yourself like a blog or a CMS or a todo list app or a calendar. Something small. Something you can do. Use it to learn about the tools you're interested in. When it gets good or if it sucks, either way, you'll have something to show for it. You can add it to your github or launch it as a product or write some blog posts about how you built it.

# Q: How would you recommend getting an internship as a full stack developer? I'm going to be a freshman in high school next year, but I haven't really been able to start this process. – hello world

A: The best way to get internships/jobs is networking. Find the person you want to be on LinkedIn, Twitter, GitHub, etc and figure out what you need your resume to look like to get their job. DM them asking "how do I get to where you are?" and ask for some advice on what they would do if they were in your shoes. If you can get them on a zoom or call or do that. Then send a thank you note that day. It should end with something like "Please let me know if there is any other person or team member you think I should speak with. Thanks again." Hopefully they connect you with someone else. Then rinse and repeat.

Stephanie Morillo

Reactiflux — Tue, 15 Dec 2020 16:00:00 GMT

# Q: What is keypoint and main important thing in Project management? – WARR!0R

A: Most important thing is tracking your work and staying organized. You're juggling 100 things at once at different stages in the production lifecycle. You need to be aware of what's going on

# Q: How do you cope up with not divulging into ongoing politics at workplace and maintain a personal blog as while being honest to write about how inefficiently workplaces are being run and manages? – butterscotch

A: I try my best to keep it generalized. You have to be mindful because everything you do, someone in your workplace may find out about it. Extract the learnings: are there specific characteristics, scenarios, etc? How do you address those? And try not to include ANY specific information about your workplace situation or scenario.

# Q: Are you using any software for tracking, or multiple tools? – Roboto

A: At work I use Azure DevOps Boards, which is like Jira. I use Jira for my side business as well as Airtable. I use email HEAVILY also.

# Q: How to market myself as a developer? – PythonDiscorder

A: Whew, there are lots of ways. Here's a video I recommend you watch where I give LOTS of tips about personal branding and marketing yourself: https://www.youtube.com/watch?v=frWlMUv59kY

# Q: What should be the preferred way to blog? Using sites like dev.to or hashnode or on portfolio site? Or in both and link the site? – Spark

A: Great question — the most important thing is getting started ASAP; worry about blog platform later. Don't spend all your time spinning up a Gatsby site if that's going to take you away from actually blogging. After you start blogging, then look into a platform. I prefer owning my content and having it hosted on a platform I control, but I do cross-post to places like DEV Community. Here's an article I wrote on how to cross-post without messing up your SEO: https://www.stephaniemorillo.co/post/how-blog-post-syndication-works

If you're using your real name online, you have a personal brand. The difference is:do you want other people to define it for you or do YOU want to define it for you? People find full time jobs as a result of blogging, speaking, etc. It's how people describe you to others.

# Q: If the project’s progress is not going well. Then What will you do? – WARR!0R

A: I will immediately involve the stakeholder. First, I'll talk to my developers and analysts to understand what the issue is. If we can't hit our milestone I'll set up time to talk with the stakeholder, let them know what's going on, and we'll either revise the scope or the timeline. I communicate with my stakeholders constantly; not just when something bad happens. So they are usually amenable to changes.

# Q: Does Product manager require knowledge of programming like Project Manager? – zBarriz

A: Not quite, but if your company is building products like developer tools then yes: many product managers will likely need to have some engineering experience.

# Q: How to find blog topics to write? – ganesh

A: There are 4 ways to find new topics; 1. write about things you know 2. write about things you want to learn 3. write about things OTHER people want to know and 4. repurpose existing content. Here's an article about this; https://changelog.com/posts/4-sources-of-endless-content-ideas

# Q: Any recommendations for a legal, sustainable, balance when working for closed-source/enterprise shops, but wanting to maintain a publicly-visible presence? – hitjim

A: Great question. Try to keep things high level, maybe about the industry or the scope, but never related to technologies that are proprietary. I keep a pretty strict boundary between work and my side stuff, even the topics: I don't do content marketing in my day job, which is how I avoid any conflict of interest.

# Q: Should every developer blog? If so, why? – Level

A: I think every developer should blog if they want to. If you hate writing, blogging will feel like a chore and you won't keep it up. I think every developer should become a better writer. This means writing better emails, better docs, better tech specs, better PR review comments. Any capacity to write is an opportunity all developers should invite. It's crucial for moving up in your career. If you can't communicate effectively, it'll hurt your growth.

# Q: Marketing/branding for developers

I've worked on a large project for a non-profit that involved GPS data, tracking and heatmapping. I know of other opportunities that could use a similar setup and I want to sell this to them, but I don't know where to begin.

Any thoughts on marketing something like this? – Roboto

A: Start writing about it. Use it as an opportunity to teach people about the field. What are best practices? What do they need to know? People buy from people they trust, and if you haven't given them a reason to trust you yet, you need to focus on that. Or maybe do videos —whatever format works.

# Q: What's the best platform for a developer to get noticed by recruiters? – Monis

A: LinkedIn is still a place where lots of recruiters go in search of potential hires. Consider getting your LinkedIn profile and resume written by a professional resume writer who can help your profile stand out.

# Q: Any advice for a developer that wants to transition to a developer relations role? What to do, what to focus on... Thanks! – thislucas

A: Yes! Developer advocates do a ton of jobs: they are marketing, customer support, community management, product, and engineering all in one. You have to be comfortable with context switching and comfortable figuring out a path forward when it's not always clear. You'll be expected to write, deliver talks, and promote your work among other things. Sam Julien wrote a great bookon the topic called "Getting Started in Developer Relations": https://learn.samjulien.com/getting-started-in-developer-relations

# Q: I'm expected to become a manager (Product or Project) in the future with my developer background, Can you tell me the opportunities as well as the salary of both positions? – zBarriz

A: For salaries, please refer to sites like Levels.fyi. It varies by company, years of experience, and country. If you want to be a PM, make sure you're known for your writing skills. Practice managing meetings effectively, providing status updates, offer to help your team manage its backlog, etc. Also talk to people on the business side of the house. PMs are intermediaries between eng, product, UX, marketing, and more. Talk to PMs at your company for opportunities to shadow them and ask them what helped them. I'm a Technical Program Manager, actually; here's an article that explains what I do: https://medium.com/insiden26/what-does-a-technical-program-manager-do-with-meysam-sarabadani-9f9e6005e9ed

# Q: I know where to find developers. I know where to find creatives. Where do I find the intersection? I do both, and I make tools dedicated to creative power users (video editors, game devs, meme junkies) but I don't have a sense of community, meaning I lack peers and users. Are there particular forums, publications, chat groups, etc. that you'd recommend? I know how to reach out, but I don't know where. – paarth

A: Interesting question; as someone who exists at the intersection, too, I don't quite know. 🙂 Actually, one place to check out is Indie Hackers: www.indiehackers.com

# Q: Knowing that you can never be satisfied with a perfect UI and since there are endless choices of frameworks before to create a personal blog site, how can one get rid of these confusions and procrastinations and just start with a minimal setup? What counts as a minimal setup/MVP according to you? – mihirs15

A: My blog used to be a static site, but I decided to move it to a dynamic site builder (Wix) years ago because I grew tired of having to take a lot of steps to make an update. It helps to recognize what your own needs are and to select based on your needs than based on nice-to-haves. EVERY platform has its drawbacks, so learn more about them and find ways to circumvent them or address them. And you can always optimize your site over time; no site is ever 100% complete 🙂

# Q: Is it a good idea to have a tech blog for an early stage startup? If so, what kind of content is good to have? – woohoou

A: Yes, absolutely. Your company should be blogging from the very beginning. As for topics, that depends a lot on your field, your audience, and what the goals of your content marketing strategy are. But you need to have a place where you share interesting content with your audience frequently.

# Q: What are your thoughts on the rise of substack and paid content gating? It seems like a great way to grow as I'm seeing a lot of new blogs spread a lot on the platform. Personally I love that it doesn't force you into make all posts accessible to paying readers. – Sonicrida

A: I think it's great that platforms want to help creators get paid. Content is sadly very underappreciated and undervalued. If you want to start a Substack to attract a readership, it's a good place to start. It helps to manage expectations, though; everyone on Substack isn't making a living from their writing, so you need to be VERY clear on your goals. I started my email list on Substack and left because (1) Substack actually takes out a huge chunk of $$ on fees (2) their analytics isn't great (3) you can't segment your audience. I moved my email list to Mailchimp which is way better for me. It also incentivizes ppl to join my list cos only subscribers can see my content.

# Q: What do you think about developers streaming programming, such as on Twitch? Is this a good way to grow your audience, or are there other benefits other than just putting yourself out there? – statico

A: I love the idea of developers streaming on Twitch! Again, as with blogging, only stream if you like it and can sustain it over the long haul, not cos it's a fad. Watch as many streams as you can. An awesome book on building an audience on Twitch is Build Your Dream Stream by Ashnichrist: https://streamcoachbook.com/

# Q: Do you think that including your blog to your portfolio is relevant? I mean is it helpful during an interview ? – WonDErV

A: It sure is! The recruiter may pass it onto the hiring manager. They are already Googling you anyway; why not point them to your blog and showcase your writing skills, your interests, and your projects? 🙂

# Q: What’s the difference between Product manager vs Project manager vs Program manager? – WARR!0R

A: This article explains it the best: https://medium.com/insiden26/what-does-a-technical-program-manager-do-with-meysam-sarabadani-9f9e6005e9ed Note that every company defines these differently also.

# Q: What are your thoughts on navigating tech Twitter? To me, it feels like there is a lot of drama on it which can be off-putting to newer content creators that want to break in since it can be a good tool for spreading your content. I think it's necessary to use it but so you have advice on how to make the experience more pleasant to those that are getting started with it? – Sonicrida

A: Yes — start by being intentional about who you follow. Follow the accounts that create content you like and will engage with. Mute words and phrases, and mute people as necessary especially if you're being harassed or seeing people just be mean to each other. And treat people on social media the way you want to be treated; whenever you engage with a new account you've never interacted with, be frieendly and polite. Recognize that some Twitter users have different threat models than you do; accounts with lots of followers, women, people of color etc. tend to get harassed a lot more than others. Try not to get involved in any arguments, etc if you can avoid it.

# Q: I've just realized that I have more technical posts than projects for my portfolio, would that be an issue in face to find a job? What's better? – WonDErV

A: There is no better; it just depends on your goals and what the expectations are from jobs you want. Look at job descriptions and see if they specify anything about your portfolio and talk to other developers to understand the right balance.

# Q: From your experience as a PM, how do you set the roadmap for devs when they need to manage many different conflicting priorities at once (for example: feature requests, support tickets, refactors, usability fixes etc)? – mihirs15

A: Oh great question! Our team does quarterly roadmapping sessions and our backlog is split into: 60% epics (projects), 20% bug requests, and another 20% on small feature requests. We're very collaborative; our sprint planning sessions are weekly and we have daily standups. So we are always in sync and we make changes at a moment's notice.

# Q: Any advice for a project manager turning dev next year? I wanted to up my tech skills and fell in love with building so I’m making a switch! – ericbible

A: I haven't made that jump, so I can't offer much help there — sorry!

Follow-up: Would you recommend writing about the transition? Lessons learned as a pm?

A: Yes, I recommend writing about it. 🙂 I wrote a similar article earlier this year when I made the transition from content strategist to technical program manager: https://www.stephaniemorillo.co/post/11-lessons-ive-learned-as-an-engineering-pm

# Q: In the beginning I am focusing on just writing good articles on sites like medium to get good at content creation. I have found marketing articles is a challenge. I am not able to reach many people. Please provide advice for this. – gsobti

A: I have two articles that address this in more detail. Would recommend you bookmark them: https://www.stephaniemorillo.co/post/how-believing-in-magic-can-help-you-promote-your-content and https://www.stephaniemorillo.co/post/how-to-increase-your-reach-on-social-media

# Q: Has there been times when the expected estimates have gone wrong? How do you correct your estimates later on (as a team, both dev and PM side)?

How do you ensure that neither the devs are overloaded and yet you're able to achieve things when these estimates totally go wrong? – mihirs15

A: Yes, this happens frequently. It's hard to give exact estimates. When we do quarterly planning, we give a rough estimate based on the scope of work as we understand it. Then, when work begins, we update our estimates on a weekly basis. It's hard to provide exact estimates for the work we do since it's dependent on many factors. But we came up with a matrix for estimating effort, and we communicate that to the stakeholder. We let them know when we are working on things in the upcoming quarter, but we never give exact dates; there are only a few instances when we do, and those projects almost always tend to be worked on first. The framework/matrix has helped us communicate effort without time in a way that is flexible but still informative

# Q: What advice do you have for someone with no experience and minimal education trying to land their first job? I've followed all advice regarding my resume and have been working on personal projects but I'm still finding it difficult to get word back, maybe I need to release more content? – Zenthos

A: This would be a great question to ask in dev.to under #discuss or #codenewbie. Lots of early career programmers can give you advice!

# Q: Has there been times where you found it hard to stay productive or have you felt burnt-out? If so, how did you overcome that situation and how do you maintain the productivity level? – mihirs15

A: Yup! I wrote about this on my blog: https://www.stephaniemorillo.co/post/but-what-if-they-forget-me-here-s-how-to-write-when-real-life-gets-in-the-way

And here's a blog post on prioritizing when things get overwhelming: https://www.stephaniemorillo.co/post/how-ruthless-prioritization-is-helping-me-stay-focused

# Q: Cool. While I'm coming up with a question out of my ass. You seem like a social person. Are you also so tired of people expressing mock-surprise at finding a developer who can speak to people and gasp enjoys it? What can we do to change the cultural attitude of seeing developers as isolated tinkerers. – paarth

A: LOL yes! I think we need to VALUE COMMUNICATION. My entire career I was told everyone can write and communicate well; that's not true. Communication is how we extend knowledge, show respect to our colleagues, and show that we are dependable. It's a skill many aren't taught to exercise. So start by being that developer; the one who makes communication a priority. People will start to pick up on your habits and do what you do as a result of your communication style. Entire teams have adopted my processes and my workflows because of how I communicate. Take writing seriously; learn as much as you can, always seek to improve. I have a blog post coming out tomorrow about this topic and encourage you all to read it. It will be published at 8AM ET tomorrow. 🙂

Michael Shilman & Gert Hengeveld

Reactiflux — Wed, 18 Nov 2020 16:00:00 GMT

# Q: Hey! I have been a huge storybook fan for years and have seen it grow and change, especially in how easy it's become to write stories -- is there an idealized "final form" for storybook? in terms of ease to use, set-up, author, integrate, etc. – Mike Bars

A: We added args in 6.0 as a stylized way to edit stories with controls and manage story data. i think the current target is "edit your components with controls" and then snapshot the stories. that will be a pretty good DX that will also allow non-technical stakeholders to contribute.

– shilman

# Q: What do you think of open source project who use mailing list as way of communicating such as GCC(Gnu compiler collection). Do you believe it make it harder to have newer contributors and it making it harder communicating with the maintainers to these project? – Vincent's

A: Personally I've never understood how those even work to be honest. Email isn't a way of comms I use a lot. I only occasionally stumble upon these when searching for cryptic stuff on Google, but other than that they've always felt very "closed" to me. But I grew up using forums (phpbb et al). I continuously find myself wanting to go back to forums as community platform. Even for in-company comms.

– ghengeveld

I can't imagine doing it over email, although I suppose there is some benefit to that for a more "formal" exchange. But we use Discord for Storybook community 🙌 and it's great to keep it casual.

– shilman

# Q: What are some features you've always wanted to add to storybook, but haven't had the time/bandwidth/priority to implement? – fox

A: Biggest two for me are live editing a la playroom and interaction tests built into storybook. We're going to spend a bunch of time on Storybook for app development next year and that will bring a bunch of new stuff. Working in the frontend space is like drinking from the firehose, so I expect there will always be 10 new ideas coming in for every 1 we can actually execute on. I'm sure all the team members have their own laundry lists.

– shilman

# Q: Thank you for the Q&A. When building a design system, what is the established way to use it across multiple projects without impacting the development process? We used our design system as an npm package and it was not ideal because changes have to be published to npm first before we can use it. – HTlili

A: We use NPM for our design systems. It's far from perfect (the more you use it, the more you hate it!) but it gets the job done and is ubiquitous. I think there are a lot of nice packages out there like auto for streamlining the process.

– shilman

Check out relative-deps by Michel Weststrate (author of mobx)

– ghengeveld

# Q: What is the nicest feature you'd like to ship in Storybook 7? – Yann

A: Storybook 7.0 would be a major release. In my experience those x.0 releases are pretty boring from a feature PoV. The interesting stuff should get released in a minor release, because that's the "new stuff but not breaking" semver change. Looking at what major new features we'd want to add, I'd say make it more integrated with your IDE. Make it easier to use with low-code/no-code tools. That sort of thing.

– ghengeveld

I hope we can make Storybook super fast by 7.0. We're focused on performance these days. I guess you could call it a bugfix, but I think it's a feature. 😛

– shilman

# Q: How hard is it to keep up with the issues? – -Roman-

# Q: I see often on big open source repo have a lot of issue(1k+) and lot of PRs. How do you manage that many issue? I know you can have more than 1 maintainer but tthere's no way that 10 maintainer can go through all of these issue and pull request right? – Vincent's

A: I spend probably an hour every day reading and responding to issues. It's manageable to keep up to date on them. Actually fixing them is impossible for a project of Storybook's size and adoption. We use stalebot and get a lot of grief for that, but it's the only way we can keep things under control. I'm hoping to organize the community better in 2021 to help scale up our maintenance efforts.

– shilman

# Q: Hi guys, thanks for the good work. Do you think Storybook is worth the investment for solo projects? Bedankt! – Weijland

A: Natuurlijk! Storybook is a tool for local development. It's supposed to make your life easier as individual developer. Sharing your Storybook is of course very helpful for a team as well. Storybook allows you to focus on individual components so you can think more clearly of it's API and various features and edge cases.

– ghengeveld

# Q: Are there any high level plans to integrate storybook as a tool for designers? Or similarly, plans for integration with common/popular design tools? – Mike Bars

A: There are a bunch of addons for connecting Storybook to design tools, and even a few commercial products for this, https://www.contrast.app/ which is really cool. We'll keep doing a lot in this space. Next step here is to make a catalog for all our addons to make them easier to discover and install.

– shilman

Definitely. While our target audience is UI engineers / front-end developers, we also focus on team collaboration, the most obvious of which is collaboration with designers.

– ghengeveld

# Q: What is the biggest challenge that you have to deal with when you have a big open source project such as yours? – Vincent's

A: I think we have a quantity vs quality thing. In a very tight, focused project you can make sure everything is beautiful. The biggest challenge in Storybook is the huge surface area and huge contributor base. It's a beautiful mess. We are spending a lot of time trying to get it under control and make it more beautiful and less mess.

– shilman

# Q: What games do you play? 😄 – -Roman-

A: Currently Rise of the Tomb Raider. Previously C&C Red Alert remastered. Also want to get back to VR gaming because my Valve Index is collecting dust after finishing HL Alyx.

– ghengeveld

"Merge the PR with dubious tests" 😅 🔫

– shilman

# Q: Are you earning money with this? Ff yes, how? – AdrianC

A: Not with Storybook. We run Chromatic, a SaaS platform for visual regression testing on top of Storybook. Storybook is 100% open source and not owned by Chromatic. We just happen to employ the top Storybook contributors. Not really a coincidence of course. 😉

– ghengeveld

Yeah. Check out https://www.chromatic.com/ which is a tool for shared storybook collaboration and testing in the cloud. We have a bunch of big customers and are growing fast.

– shilman

# Q: Suppose you've been working on some community OSS service for a while and you find out that there's another vetted engineer (that's also apart of the same community and is well respected) that actually did your entire work in about about 2 days . My question is, where is the best place to cry?

[Seriously though] How can these 2 parties collaborate? We hold very similar values but have a different vision (of what this product could be). I need their support, but I don't know what to do next..., idk why I am stressed lol, but this project is really dear to me. – dilraj

A: I try to keep my head down and push forward. In Storybook's case we've reached out to everybody else in the space to try to collaborate. Our attitude is "open open source" (the more the merrier) and we think this is the winning strategy.

As for the emotional side of it, life's a roller coaster. Good stress management through exercise, meditation, etc. is something that will pay off dividends in OSS and every other aspect of life.

– shilman

I've been there. I built React Async (https://react-async.com/). It's kind-of popular. But React Query blew it away. Where do I cry? In a Discord Q&A. Also I contacted some devs that are building similar things, in an effort to collaborate. In the end we had good talks, I made some friends and we went our own ways.

– ghengeveld

# Q: How to start on big projects like storybook? I mean for a developer like me that nobody knows who am I. – Rouzbeth

A: We love new contributors. Fix an issue that's bothering you, or jump on our discord to get involved with the community. We've helped a bunch of people merge their first OSS PR's, and that's actually one of the more rewarding part of working in OSS.

– shilman

# Q: I’m a designer, what benefits can I get from Storybook? Is it a competitor to Framer? How is the customization ability of component styling? How do I collaborate with the team? – Ray

A: Storybook is less of a prototyping tool and more focused on production systems. As a designer there are a few benefits that come to mind:

Make sure that your designs are implemented exactly to spec
Synchronize the implementation with the design (lots of design actually happens DURING implementation)
Sandbox for making visual tweaks without having to set up the entire application environment, because Storybook captures isolated component states, so you can tweak styling etc. without having to know the full system.

– shilman

# Q: What do you think of GraphQL? – -Roman-

A: We use it extensively at Chromatic. I enjoy it a lot because it allows me to just think in terms of the domain model and actions/tasks to be done. I don't want to go back to the days of considering PUT vs POST and the best way to design your URLs and how to deal with overfetching. Regardless I do think it's a bit heavy sometimes and would be the first to ditch it if something better comes along. (Although I have better things to do than switching frameworks.)

– ghengeveld

Love graphql for all the reasons @ghengeveld mentions, but wish it was more built into the language and type system. currently feels like adding N more levels of abstraction to an already complex stack.

– shilman

I second that @shilman

– ghengeveld

# Q: Do you have an elevator speech? I have a new project and I'd like to give a try, but I must convince to my boss. – AdrianC

A: I'd say the best way to convince your boss is to tell him everyone is using it these days. Which is somewhat true. We have very very big names in the customer base, and we know of a lot more that use Storybook internally.

FYI LEGO is using Storybook 😉

– ghengeveld

IMHO it's a best practice at this point. Many of the UI's you love to use were built in it including the new Twitter UI, Slack, Spotify, Squarespace, etc. To me the strongest argument is the adoption by the best teams in the industry.

Why did they adopt it? It's the best way to manage the complexity of modern component-based UIs, and allows you to build & use components like LEGOs (like they were supposed to be!). Not only that but you get a bunch of testing for free when you use it.

That's a horrible elevator speech. 😂

– shilman

# Q: How did storybook take off? Did you guys actively advertise it? – Hums

A: This was before my time, but I know Storybook almost died when Arunoda abandoned it. Luckily at that point there were plenty of people very happy with it and willing to work on it.

The first version of Storybook was written by some guys in Sri Lanka. I think they got so much stuff right. There were other tools in the space, but the story concept was really simple and the right way to think about components. The main architect, Arunoda, already had a following, so he got it to first base. When Norbert and I took over the project we just kept pushing it forward pretty much in line with the original vision. We released consistently and pushed it into more frameworks (Vue, Angular, Svelte, Ember, etc.). We've only recently started marketing it (content marketing) and up until now our marketing was pretty minimal. Most of the success so far has been product-driven.

– shilman

I have to add what Norbert did right was not take the lead and "own" it, but encourage and help others to get involved. He did that because he actually planned to step away from Storybook after 6 months or so. But he stayed.

– ghengeveld

Yup Norbert did a great job recruiting people early on. I'd still say that the adoption was due more to the product itself. My attitude about Storybook is that it's just the right way to do things, and in 10 years this will be an indispensible part of the UI toolchain. If we don't build it, somebody else will. (And they probably will even if we do build it!)

– shilman

# Q: Do you read technical books? Which one would you recommend?? – AdrianC

A: Not much. The only one that stands out to me is Mythical Man Month, which I think is great because the essays are all from the 1970's and 80's but still mostly apply today.

– shilman

Not really. Only thing I can recommend (not a book) is Functional Programming Principles in Scala by Martin Odersky on Coursera. I learned a lot.

– ghengeveld

# Q: What state management library/API do you like most and why? – vakon

A: React.useState. It works for most purposes. There's very few things you cannot accomplish with that. But I'm hardcore and I guess I like the pain and suffering it sometimes give you.

– ghengeveld

Hahaha @ghengeveld was going to say the same thing about useState. Great minds.... 🧠

– shilman

# Q: React supports instant change(s) while development, the hot reload feature which isn't in native Android / iOS dev.. What things make it to achieve hot reload? – Dipak Bari

A: LOL that's above my pay grade. @ghengeveld ? BTW we're going to support iOS / Android / Flutter in storybook next year. 🤯

– shilman

The trouble is that we don't have anyone with the expertise needed to make native mobile development a first-class citizen. I'm a web dev, always have been, and therefore don't really care about native mobile. We'd love to see that change, but it's a lack of expertise / experience. That's why it's been up to the community to handle this part.

– ghengeveld

# Q: How do you make the content of your website hard to scrape. – LYC_thedude

A: I don't think we do ... 🤔

You can nest your contents in a bunch of iframes whose URLs and structure are randomly generated... 😉 I really don't know

– shilman

I know of sites that put random letters in between their words but hide those letters visually. So it's spans and spans and spans and spans... Don't do that.

– ghengeveld

# Q: What's the next feature we can be excited for? – -Roman-

A: I know several teams are building playroom-style live editors for Storybook, which I think is pretty exciting. At a high level, we are going to add a bunch of stuff to make Storybook great for app development, so you can organize full pages in Storybook, which will make it easier to collaborate with PMs and Designers .. this is more of a direction, but will manifest itself in a bunch of new features.

– shilman

I think this will be the addon gallery.

– ghengeveld

Nader Dabit

Reactiflux — Wed, 30 Sep 2020 16:00:00 GMT

# Q: Will React-Native be able to match native performance in the near future? – Joel

A: React Native will probably never be able to beat Native performance, and overall it will be somewhat slower than native in the grand scheme of things because it's still an abstraction on top of native. React Native continues to improve, but the native platform also continues to evolve so RN, or any XP platform, will almost always be slightly behind and somewhat slower.

The value is still there though because of all of the other great things you get out of it.

# Q: Your Amplify content is awesome, but I'm wary about costs since it seems like an abstraction of multiple AWS services. Any tips on tracking these expenses? – rahsheen

A: Amplify (the framework) is actually free, you're just paying for the individual AWS services in the same way you would if you created them with something like SLS framework, cloudformation, or the console.

If you use Amplify hosting, it's the only "service" that costs money.

You can track your expenses with billing alerts .

The reason so many people are using Amplify is that it's providing a better UX than was available in the past, and they do not want to pay the additional money that a lot of the serverless service providers out there add on to their abstractions that are actually just built using AWS anyway but at 10x the price.

# Q: Do you think knowledge of Data Structures and Algorithms is important as a developer having ~1 year of experience or doing more projects will help? – yhpez

A: I have never taken any true Data Structures and Algorithms courses at a university, though I have taken free courses from Stanford, Harvard, MIT, etc.. that are available online.

This lack of knowledge has made me fail various job interviews, but others it has not.

I would say it's always better to know more, but not knowing them does not mean you will not land a solid job if you keep improving your skillset everywhere else.

# Q: Since you've been heavily invested into Next.js lately, have you thought about adding people from the Amplify team to collaborate as contributors to the Next.js core? – marbiano

A: We've started building out more investment into SSR support across all modern web frameworks, including Next but also Nuxt, SSG frameworks, and future tech like Remix (to name a few).

I think collaborating / contributing to these projects is something we should / can definitely consider. AWS has recently been investing a lot more into open source contribution. I will definitely see what our team can do to collaborate more individually with these projects going forward.

# Q: Can you give the good starting points related to doing open source contribution? Going through new big complex code bases which are different from your current work and complex? (like, you're a developer using those APIs vs actually understanding those APIs)? – mihirs15

A: I would say find something that you're already using and spend some time digging through a feature that you're very familiar with.

Start small like documenting something that was not documented or not documented well, and then move on to functionality.

Go into the issues and try to find something that looks like you can manage and see what you can do. I would even suggest reaching out to OSS maintainers and asking for good first issues if they are not already flagged into their issue tracker.

# Q: 👋🏾 When is part 2 of the Next.js Amplify tutorial coming out haha I loved the first one. Happy to see you here! – Sonicrida

A: Hey, working on it now! Should be out early next week.

Also working with CSS tricks on a comprehensive Next.js on AWS tutorial, an end to end guide for everything from data to auth to deployment with custom domains and cache control.

# Q: What are you most excited about in the React ecosystem? – mihirs15

A: I'm still really excited about the innovations around hybrid frameworks like Next, Remix, and what we will probably see a lot more of in the future. I'm also excited about the stability we've seen with React. It's been really nice to have a somewhat stable ecosystem over the past few years after the JS fatigue of the mid 2010's.

# Q: In your opinion, will the react-native platform for desktop applications be in a stable version soon? I think it will be used a lot, what do you think? – Alessandro Marra

A: I think that for any large project in the React Native ecosystem to be successful, it will take either a considerable effort of the community or a large / capable company adopting it and leading it. Because of the level of abstraction that is React Native combined with the instability that we often see, for a platform to survive and thrive and continue to be stable it just takes a lot of time, money, and effort. So the answer is no, not on it's own or by a slight community effort, only if there is a leader / company willing to take the lead on it long term which from what I can tell right now is maybe no? (though I do see React Native Windows seems to be well maintained)

# Q: What is your go-to technique when comparing trade-offs between similar functioning libraries/frameworks? – mihirs15

A: I first try not to use any libraries that are maintained by anyone unless absolutely necessary, then I try to find one that has 1. a solid track record of maintenance already or 2. that is maintained by either a trusted community member or a large company. I rarely will use something new in production unless it meets one of those criteria, and almost never will use something that has been around for a while that does not meet those criteria.

# Q: Do you think PWA is the future in terms of native apps and will it overcome android/iOS apps in terms of popularity? – yhpez

A: It seems that PWA is merging into just "web" in the sense that almost all of the capabilities there are often built into modern web apps (with the exception of the app on the device screen). I think that native will continue to serve a purpose, hybrid (RN + Flutter) will continue to serve a purpose, and web will continue to serve a purpose. So basically I don't see any winner take all any time soon, but I do see the success and prosperity of all three platforms continuing for the foreseeable future unless something significant happens with app distribution in App Store / Google Play store.

# Q: AWS’ documentation, resources and tutorials from the past 2 years have been amazing. Does AWS have plans to make minor/major changes to the AWS console UI to flatten the learning curve at all? Or make it any more friendly for beginners or is it something that we just have to deal with? – dilraj

A: There's a large effort internally going pretty far up to focus on improving the on-boarding process and DX of AWS as well as focusing on lowering the barrier of entry to new developers. Amplify, CDK, and HoneyCode are all playing a pretty large role there. I think these will be the entry-points to help lower the barrier to entry in the future along with a few other services / projects currently in the works. It's a big priority and we have already seen a massive number of devs new to the cloud or interested in serverless / Jamstack development on-boarded through some of these technologies platforms already, and we are doubling down on them now and in the future.

# Q: What do you think about the concept of react-native web and technologies like it? – Dreamplay

A: I think these are amazing technologies, but like a lot of things in the React Native ecosystem need / require a lot of investment / time / work to keep them up to date with the changes in the React Native framework itself. As long as there is a concerted effort there in one of these projects to maintain and improve over a long period of time they will probably continue to improve and be more of a viable solution for companies looking for those types of solutions.

# Q: Do you have any advice for low-income students looking to learn React Native but who don't have access to hardware resources such as physical devices or computers capable of running emulators? Mostly considering the case where students are interested to test their apps on iOS after having it work on Android. – Mike Bars

A: Unfortunately not with real devices, but AWS and Google have free tiers for things like "Device Farm" that allow you to run tests on real devices in remote facilities.

# Q: Regarding the AWS CMS, I am thinking that Amplify is great but it is missing a lot of CMS features, and to turn Amplify into a headless CMS perhaps.

It is one the reasons we are still using at me company and for personal projects other CMS or headless CMS such as Strapi, Contentful to manage content instead of using AWS entirely as I usually use AWS to manage content and database. 🙂 – juancarlosjr97

A: Yeah I think most AWS services are lower level and would allow you to build your own CMS (and it would be cheaper), but you would not get the good velocity and DX out of the box like you do with some of the really great options that are out there now (like the ones you mentioned). It's actually something we're considering adding as an offering though in the future as part of Amplify, but not this year.

# Q: How do you decide on betting on new technologies? – Yusadolat

A: I'm a huge fan of this topic! I spend a ton of my time reading (audio books, physical books). I spend a lot of my time learning tech (books, courses, videos, focused learning time). I think all of this learning goes into how i choose a new tech. The more you understand about the world and how the systems work in the world, combined with your technical expertise and the understanding of the current tech ecosystem and how it fits into your current skillset, the easier it becomes to make these choices.

At the end of the day for me it's about spotting patterns and spotting opportunities for huge upside. To me it's about really well executed abstractions that enable me to do 10x (or so) more that I was able to do before, or to enable me to do something I wasn't able to do before.

Add to that the future growth and demand of that tech + how much money I may be able to make from it (this is why I focused on React, RN, cloud and not some of the other hyped tech that you see some people investing in) and I usually place a bet and go all in. You should treat it kind of like a balance + a gamble, spread your bets and be sure not to go bankrupt, but have a few bets placed that "if" they hit, you are set up for massive success.

# Q: What kind of changes do you think should be made to interview process when interviewing candidates for Frontend Engineering roles?

The rounds mostly focus on Algorithms and trivia JS knowledge mostly.

So, should it be more live coding oriented stuff and if so, what are some of the topics one can ask so that it is feasible to wrap the pair programming interview in 1 hour or so? – mihirs15

A: IMO the big problem here is that many companies do not tailor the interview to the position, so they end up asking the wrong questions. Are data structures and algorithms important to know? it depends. Like you mentioned, many front end developers will never need to know anything about them. If you are working on some really advanced system, you may need them, but if you don't then it should not be part of the interview.

The thing I've learned more regarding interviews / people over the past few years though is to focus on hiring for capability vs current knowledge. If you find someone who is capable of just getting shit done and learning what they need to, that's all that matters. If they can google their way around and find the answer, then who cares what was in their brain the minute before, at the end of the day they solved the problem. Technical interviews should be tailored to finding problem solvers and people who can get shit done vs things they have memorized to pass the interview.

Unfortunately, we're not there yet as an industry but there are smart people trying to solve this.

# Q: I've always wondered what the key differences are between Azure, GCP, and AWS; Would you be willing to outline some of the quantifiable differences for a end user? – doge

A: I would say that they are all similar in certain ways but they do indeed have tradeoffs that are worth considering. I unfortunately am biased since I work at AWS so I would probably recommend finding one solution (maybe a serverless API), and implementing the same service in all 3 clouds. Then go into the consoles and play around with the service. Do this 1 or two more times for other services. This will probably take you a day or 2, but after that you'll have a good idea about which you prefer and which you should focus you time on learning more about.

David McCabe

Reactiflux — Wed, 02 Sep 2020 16:00:00 GMT

Author of Recoil

#**Q:**What would you think it's the best way for someone who's a junior to learn and get better in a certain field (like React or some other framework) – Grincek

A: Do lots of projects. If you aren't sure which way is a better approach to doing something, try both quickly.

#**Q:**What is the draw of using recoilJS over redux or similar libraries? – dantalksalot

A: Ease of use, makes it easier to create fast apps that have lots of different pieces of state.

#**Q:**When react concurrent mode will be officially released? – ARKA160

A: No official release date. The new facebook.com is running on concurrent. Upcoming releases of React will help with making existing code compatible. You can try Concurrent now using the experimental release (not in production).

#**Q:**Is Redux a must for state management? Or is an app better off without it. – koqkito

A: Is redux a must: No

#**Q:**What are some good projects for a developer who already feels comfortable with react and needs to advance but doesn't know how? – Ozu

A: Try to build more complex projects? I don't know.

#**Q:**What resources did you use to learn react? – antoniodinkins

A: I started learning React when it first came out, the only resources was the official docs, which were pretty good. I was trying to build a single-page UI for a company and just had to learn on the job.

#**Q:**State persistence seems very unstable/in flux right now, which is one of the drawbacks. What's your roadmap for this functionality? – Kimmain

A: There is a temporary API you can use now. We are experimenting with the permanent API. Soon but not sure exactly when.

<aname="#not-react-related" href="#not-react-related-but">#**Q:**Not react related, but what does it take to work for Facebook? – Raeven

A: If you want to know about passing the interview I think there is a lot of information about the process that's published by FB recruiting. When I interviewed the experience was exactly what I was expecting based on the material I was sent.

#**Q:**How frequently do you use useMemo/useCallback in your components and what rules you have for when to use them? Do you automatically use them in most cases? – Josephdo

A: I generally only use these after observing that a child component's rendering is causing a performance problem.

#**Q:**Will Recoil have the ability to integrate with a design platform like Storybook? – TylerSnow

A: I do not know enough about it to say. I would expect so since it's apparently compatible with multiple different view libraries.

#**Q:**What were your experiences hunting for a job as a junior? – Grincek

A: When I was first in the industry I would go to meetups, find people using open-source software who needed some tiny modification done, put in the needed patch, and then they would hire me for contract work. This is probably not the best strategy in a strong job market though.

#**Q:**How are families garbage collected? – frederik.batuna

A: I am currently working on this, hope to release it soon. Meanwhile you can manually delete using useResetRecoilValue.

Oh by the way, I forgot to mention, Recoil 0.0.11 is going to be released very soon. We were planning to release it yesterday but found a significant bug at the last minute. So probably in the next day or two.

Recoil 0.0.11 has much better performance, experimental Concurrent Mode support, and some other improvements. Upcoming releases will then address memory, performance, and syncing with external storage and servers.

#**Q:**How well does Recoil pair with Immer? – parichay28

A: Haven't tried it, expect it's a great pairing.

<aname="#if-youre-going" href="#if-youre-going-to">#**Q:**If you're going to use Recoil, should you manage your entire state there? Are performance implications if you do? If not, how do you decide what goes into "pure local" vs. managed in Recoil? – Thandathere

A: Great question. Using recoil vs local state does have some performance overhead. On the other hand, if you're using transaction observation for app-wide facilities such as persistence and URLs, that only applies to Recoil state.

#**Q:**I’ve seen that React is in the front-line, when we talk about SPA development. Could be React the future of web, like HTML is for the browser? What do you think? – D4vi0h4ck3r

A: React is a language in many ways, it might make sense to implement that language lower in the stack.

#**Q:**What is the reason behind giving everything a unique key in Recoil? Doesn’t this modularity way more difficult? – yuchimake

A: They're used for persistence, logging, debugging, etc. I would like to find a good solution to statically ensure uniqueness, this is a major weakness currently. However, I haven't seen it be a problem in practice even with projects using hundreds of atoms written by many people across different teams.

#**Q:**There are a lot of state management libraries. Each have their own strengths and weaknesses. Can you tell something about the (fundamental) weaknesses of Recoil? When would you not use this? – mees

A: Relay has a much more sophisticated approach to server-owned data. By knowing the queries statically it's possible to start executing queries while the client is still downloading the code. And it can handle mutations. Recoil's async stuff is limited to time-invariant data and fetch-as-you-render.

#</a?>**Q:**Is hooks the future? or classes would hang around for a bit. I honestly find classes cleaner and structured. – Raeven

A: There is no plan to deprecate classes. However, hooks have huge advantages both for the developer ease of use and implementation. I have not known anyone who's really gotten the hang of hooks to ever look back. They do have a substantial learning curve, though.

That being said, I think if you were learning React from the ground up as hooks-only it would be simpler than learning class components. Hooks more closely model how React actually works, making it easier to write non-buggy code.

#**Q:**In one of the early interviews you did, a question was asked about you speaking with the react team and how receptive they were to possibly introducing concepts from recoil into react. How have those discussions progressed since and are there things that you'd like to see coming from that? – Sonicrida

A: React has to work for a much broader class of apps than any specific state library does. Parts of Recoil are not applicable across all apps (e.g. async stuff), while the basic need to share state across components is fairly universal. There has been work to try to make the Context API more flexible which would obviate this need. I don't know when this is going to happen, though. The Concurrent Mode is an area where the React team is doing a lot of work to make it feasible for more apps. I'm really excited about the work there. We'll continue to see some incredible stuff unlocked by that project in the long term.

#**Q:**When you were first started working on Recoil (early), how did you manage tasks/hitting goals when working with 1-2 people? Is a TODO.md file with a to-do list good enough or was there something a bit more sophisticated that helped you manage things in the long run? – dilraj

A: Coordinating work: at FB we use Workplace by Facebook, it's a great product http://workplace.com/

#**Q:**What is the best use-case for selectors and would what is the benefit of using over handling that logic in your component? – cagethem

A: Advantage of selectors versus handling in component (which I take to mean having a memoized value in the component that you recompute when certain props change): Selector graph can hit different parts of the React tree rather than only whole subtrees. It can also change shape: You can have a conditional dependency. This is hard to do otherwise because of the Rules of Hooks. (Selectors can be less restrictive because they are pure functions)

#**Q:**Is there a suggested naming convention for keys to ensure uniqueness? – Amr

A: You can prefix by module or product area. If prefixes are too specific it can make extra work when refactoring, if you need your keys to be stable across time.

#**Q:**Did you build Recoil as part of your work at FB? Is this something you get to for work, or is this purely a side project? – Thandado

A: It was an on-the-job project. We created Recoil in order to help with a specific app internal to FB that had major performance problems. We decided to make it a separate library since we thought it might be useful in other situations, which turned out to be true. Would not have created a state management library if I hadn't had to due to the specific requirements of this app.

#**Q:**What can we expect more from recoil in the coming future (short and long term)? – parichay28

A: Expect better performance and memory management in apps with large atom families. A more robust implementation of async selectors. APIs for developer tools. APIs for synchronizing state with external storage, URLs, servers, etc. A big part of the performance stuff is eliminating places where Recoil copies data structures. Instead we need to share structure.

#**Q:**Is there an ETA for proper React-Native support? The ongoing PR seems to be a dead in the water for a while :frowning: – Kimbit

A: We had some back-and-forth with various people about React Native support, but unfortunately I don't think a consensus emerged about the best way to do it. Nobody has expressed a willingness to maintain it and unfortunately none of us has expertise in it. I would be very happy to merge a PR that people with knowledge of the area agree is a good approach.

<aname="#whats-your-opinion" href="#whats-your-opinion-on">#**Q:**What's your opinion on the future of React Native? – Grincek

A: I don't have any special knowledge of React Native. I know FB continues to invest in it and build important apps and experiences with it. It seems to me that the work React team is doing generally, such as concurrent and a lot of performance-related research, would benefit RN even more.

#**Q:**There was a lot of interesting discourse in the few months after recoil came out where many users thought that it was an official react state management library which seemed to cause some drama on social media and a bit of trouble in regards to Dan and some of the more active team members on social media having to clarify that it's a separate project a ton. Do you feel as though this is something that could've been managed better with the release of recoil and something that should be taken into consideration whenever facebook releases other possible experimental react packages to cause less confusion within the community? – Sonicrida

A: Regarding communication about "officialness": I don't know how this could have been managed better. It seems like a certain small number of people are going to jump to wild conclusions no matter what you say.

#**Q:**Since Recoil seems to be a state management library for exclusively for React, has there been any talks about whether it should come in as a default dependency with create-react-app after hitting npx create-react-app my-app in the future? – green_lantern 🪐

A: I think the majority of apps are fine with just React, so I don't personally see a need for that.

#**Q:**What about recoil integration with Relay? – ARKA160

A: The typical way to use both together is for Recoil atoms to be passed into Relay query variables.

I highly recommend Relay for the types of things it's designed for. They have done a lot of really sophisticated work and it's getting better very quickly. If you haven't used it in a while give it a try.

#**Q:**Will there be work done to reduce Recoil's bundle size in future? – voldemort

A: This was not a goal for the specific apps we were designing with Recoil. If somebody wants to make it smaller-bundled there is probably low-hanging fruit for that.

awaiting more questions, but I guess I'll say more about bundle size. The original use-case for Recoil was apps that download large blobs of data to the client, so there wasn't any gain from optimizing initial page load since we were just going to have to wait a long time for queries. However as more different apps adopt it it makes more sense to try to reduce it.

#**Q:**Any recommendations for other libraries/patterns to use alongside Recoil for – _Mark Mstate _management use-cases that Recoil is not suited for?

A: Use Relay for most server-owned data.

#**Q:**Do you think other front-end libraries are gonna adapt JSX? – Grincek

A: I don't know. I think it's pretty simple to make a plugin to compile JSX to whatever your library needs.

#**Q:**How is your current experience working with Facebook? Is the work fast paced or is it more demanding now that many people are working remotely? – Poot

A: Cannot recommend FB highly enough as an employer. You get to work with people (not just engineers but also management, ops, facilities, etc.) that are both highly competent and well-aligned. I have not found it to be high stress at all. Rather, the ability to move really quickly feels terrific.

If you're thinking about applying to work at FB, do it. Study hard and then give the interview a shot. I don't think you'll be sorry.

By the way, the interview process at FB is based on the ability to write real practical code, not textbook problems.

For the UIE/front-end recruitinng pipeline, you get questions about building good performant UIs in the browser.

#**Q:**What was the toughest thing or challenge that you faced while building Recoil? – Spark

A: The most technically challenging thing with Recoil has been supporting changeable selector dependencies. This has been the cause of most difficult bugs in Recoil and is very hard to think about. I mean that you can do:

if (get(a)) {
  return get(b);
} else {
  return get(c);
}

and your selector will be subscribed to only b or only c, according to whether a is true.

#**Q:**Any tip for aspiring state library authors about concurrent mode and useMutableStore — have you had much trouble with the APIs? – jfinity

A: useMutableSource is quite easy to use and actually made Recoil a lot simpler versus what we were doing before.

Brandon Bayer

Reactiflux — Wed, 01 Jul 2020 16:00:00 GMT

# Q: I'm really excited with the update on 0.16. What is your vision for a 1.0 release? – Thanda

A: Definitely authentication and authorization built in and working awesome! That's the main thing. Other things like likely will also be in place are installer recipes (same as Gatsby) and plugins. The current prisma code will be extracted into a plugin and then we'll also have other plugins for things like fauna, etc.

And of course some sense of stability :D

# Q: When is it safe to begin developing my next SASS with Blitz? and/or make a course for it? – jacktheturtle

A: Well, we already have several folks building SaaS apps with it and running in production, so I guess it's up to you and your appetite for risk :D

That said, overall it is fairly stable, at least once you deploy it to production because at that point it's mostly Next.js core code running which is already battle tested.

# Q: How does blitz.js being a monolithic framework fit into the microservices architecture and how can it be scaled? – nikhil

A: Good question. You can deploy Blitz to a server as a long running process OR to serverless.

If you deploy to a server, then you'll have the same traditional monolith scaling path to walk.

But if you deploy to serverless (AWS, Vercel, etc), then each query and mutation (server code) will run in a serverless function. So your backend will scale seamlessly, automatically, and independently. So most of the monolith scaling issues go away!

# Q: What do you think is the downside of your product? – shtan

A: It doesn't come out of the box with GraphQL. The whole point of Blitz is to eliminate the API layer from your dev flow. So you don't have REST or GraphQL. Just import server code into your frontend and go!

So if you absolutely want GraphQL in the mix, then you should try Redwood. But you should still give Blitz a try. 😉

# Q: What are your suggestions to a non designer front end dev on creating UI? – Piñata

A: Buy and read https://refactoringui.com/!

# Q: I just learned about Blitz and it looks like my dream framework — Next.js, TypeScript, the goal of recreating a rails-like experience. but i also love GraphQL and the TypeScript types you get from graphql-codegen for end-to-end typed queries and resolvers. are there any plans for Blitz & GraphQL? – statico

A: Awesome! See my last answer about GraphQL.

As for end-to-end types, you get that for free in a Blitz app! And one super awesome thing about Blitz is that all the TS types are statically available. You don't need a separate process to compile types on the fly like you need with GraphQL.

# Q: What feature have you had to cut that you really wish you could have put in, but is perhaps against the design principles of Blitz? – Thanda

A: I would love to have an automatically generated GraphQL API. This is possible, but the work required to do this is huge.

# Q: Have you tried phoenix + live view? What do you think about moving state from client side to server side? Do you think it's a pattern that will stick?

https://github.com/calderajs/caldera-react – searchableguy

A: I've never actually tried this. But I think it's great for folks who don't like Javascript. I don't think it's ever something that will come to Javascript and React because.. well, we like client side JS. 😉

# Q: Are you looking to have Blitz be fully security audited before releasing auth features? – samsch

A: Not before releasing the features, but once they are released we'll definitely try to get this accomplished. Rishabh, the CTO of Supertokens is leading all the auth work. He's super good and does this for a living. So we're off to a good start at least :)

# Q: Could you share your motivation behind blitz.js and the vision you hold for it. – nikhil

A: Fullstack React app development today is too hard and too complex! Building fullstack apps with Rails/Laravel is so simple and fast because it's all one thing without many moving parts. I love that DX, but I don't like templates and want to use React.

So Blitz is the DX of Rails/Laravel but with everything we love about React.

Blitz will eventually have EVERYTHING you always need for fullstack apps including sweet integrations for background processing, emails, etc

# Q: Is it necessary to learn any database language with React or GraphQL will be enough? – Vradhi

A: Blitz doesn't use GraphQL, so you don't have to know that. We use Prisma 2 by default for the DB migrations and DB client. Prisma is super easy to use, but you'll still need to know a bit about database modeling. Eventually we'll have nice docs on this.

# Q: How do you manage to be a full time OSS contributor (how do you make money)? What was your path like, any tips? Feel free to ignore if this is too personal/off topic. – JackFlapper

A: I have a part-time indie consulting gig that pays all my bills (I've been an indie consultant for 3 years). I typically work around 20-25 hours/week on consulting and 30-40 hrs/week on Blitz.

I'm working on getting sponsors for Blitz so that I can focus 100% on this and not have to do consulting. I currently have Fauna as a $500/mo sponsor. Eventually we'll have other folks work on Blitz fulltime too!

You can also help sponsor yourself here on Github sponsors :) https://github.com/sponsors/blitz-js

# Q: When referring to it, is it blitz, Blitz, Blitzjs, Blitz.js, etc? – Thanda

A: Whatever you want haha. Official is "Blitz.js". But usually I just use Blitz.

# Q: With what blitz.js trying to achieve does it force the developers to do server side rendering and not use the client side rendering? – nikhil

A: Yeah, there are no stupid questions!! Blitz doesn't force SSR. Client-side rendering is the default, but you can choose SSR, client rendered, and static (like Gatsby) on a page-by-page basis. So they can be all mixed in your app however you need.

# Q: Can you talk about what it means for Blitz to be inspired by Rails for people who aren't familiar with Rails? – MrLeebo

A: Well overall it means being super productive for building fullstack apps. It means having conventions so you don't have to re-invent things like a file-structure on every new app. It means leaning on code scaffolding for rapidly building things without writing all the code from scratch. It means all the code being in the same app and you only have one thing to develop and one thing deploy (monolithic).

And then also the part I already talked about with getting rid of the whole API part of your architecture. Most people greatly underestimate or simply don't know how much time they waste on data marshaling in a traditional React app.

# Q: Share some tips and required knowledge to start a Open Source project the right way (or a way that is less painful and relaxing) – nikhil

A: Well, it somewhat depends on what you are building (tiny tool vs a framework like Blitz), but one thing that worked amazing for me was to build the community first and then write the actual code.

When I first announced Blitz, there was no Github repo and only a couple hundred lines of prototype code on my computer 😂. But it was enough that people got excited and wanted to help (I was explicit about asking people for help).

# Q: According to you what are some competitors to Blitz.js and how do you plan to make blitz.js a popular name in the community – nikhil

A: Redwood is the only real alternative to Blitz. Well, Blitz is already quite well known, but I'll keep tweeting about as much as I can! haha. I'm also talking at as many conferences and podcasts as I can. Marketing is essential for an open-source project to be successful.

# Q: Recently creator of Redis stepped away from it. Then there is Guido. Maintaining OSS is getting difficult partly due to politics or dealing with contributors, or community. What are your thoughts on that? – Piñata

A: We're following the model of Ember where it has full community ownership and isn't a project driven by a single person on team. And we'll take problems as they come :)

# Q: Extension to @Piñata's question: Do you think it's ok for oss contributors to be judged by their personal tweets (and other social media accounts)? Where should the boundary between open source work and personal life sit? – Yugiohxlight!

A: Yeah this is tricky, especially in this climate of hyper political correctness. I don't have a good answer for this Q&A, but I'd love to have a longer discussion about this on a call or something :)

# Q: Could you explain what do you mean by data marshaling? – nikhil

A: That means moving data around, directing it, formatting it, transforming it, fetching it, etc.

# Q: Redwood's Cell component really comes in handy during development, does Blitz offer something similar? – zacksparrow

A: No, because unless I'm missing something Cells will be obsolete with React Suspense for data fetching. We have Concurrent mode enabled by default for Blitz apps, so you use and for handling those things which is super nice!

# Q: What does Blitz have in mind for React Native? – chadnehemiah

A: We want to have first-class integration with RN so that you can import server code into a RN app just like you do in the Blitz frontend. So you can share the same Blitz backend all without having to write your own API.

# Q: Can you give more details on how you built the community first? – avpalmeira

A: Um, I just tweeted lol. Also, I used my marketing skills. Honestly I am just trying to solve the right problem at the right time. 🤷‍♂️

# Q: Not a technical question, but on a human level - what inspired you to build Blitz (again outside of the technical need) and what motivated you to take on such a large task? I'm particularly interested in the first step where you ostensibly saw the need for Blitz, saw that it didn't exist and then said, I will summon the energy to build this –

A: Honestly I feel like this is one of the things God created me to do. It's actually a fulfillment of a prophecy to me 5 years ago :)

# Q: Do you think the downward trend of Rails is justified when it can still resolve MANY of the problems people have building modern fullstack apps? – dilraj

A: I think yes. Rails is nice, but it's super hard to make great dynamic UIs (jQuery anyone?) and the mobile app story is lacking. Whereas with React you have React Native and can share you code The hurdle is much less here.

# Q: I'm a barely proficient js programmer (I hesitate to even say "developer") who had a previous life as a barely proficient Rails programmer. What can I do to help Blitz.js? – Thanda

A: Great question! :) Best way is to go through this guide: https://blitzjs.com/docs/contributing

Then look for issues on the main repo and on the website/docs repo that are labeled good first issue. Usually these are fixed within an hour of being created, so you have to move fast! :D

# Q: I saw that there is a Blitz slack. Is that a permanent home, or is it possible to bring that over into a Blitz.js discord server? – 😄

A: Will probably move to Discord once they add threads :)

# Q: Could you share some key points that one should keep handy to decide whether to choose react.js, next.js or blitz.js for the next project? – nikhil

A: If you have your own database, then use Blitz! If it's more of a content site connecting to another CMS, then use plain Next.js.

# Q: Definitely wondering about the React Native story here. Is that already in place or is help needed? – rahsheen

A: Hasn't been started yet, but you're welcome to start exploring how to do this! We can connect in the Blitz slack if you want.

# Q: Let's say we have a fanfiction.net type website build upon Blitz and have lots of filters options, so will Blitz still be a good option to manage all the complex stuff needed? (I'm a noob sry)

Like around 100k stories with lots of genre's and tags and everything filterable possible. – EvilSpark

A: I think so! I mean, Blitz doesn't yet have a feature to write all your code for you, but it does do all the boring stuff for you so you can focus on the code that actually makes your app unique. That actually adds features for your users :)

# Q: What is the status / plan for using Blitz with Firebase? For any of Deployment, Auth, DB, or metrics? – Thanda

A: You can use firebase with Blitz today. Nothing hindering you there, but not sure about deployment.

Typically, a Blitz app won't use firebase because it'll have everything you need built in, like auth, DB, etc.

# Q: Can we compare blitz.js with django? – nikhil

A: Yeah, basically the same thing, just different languages :) I literally have the django auth docs open right now as I'm working on Blitz auth :)