Like what you see here? Our mission-aligned Girl Geek X partners are hiring!

• See open jobs at CodeSee and check out open jobs at our trusted partner companies.
• Does your company want to sponsor a virtual Girl Geek event in 2021? Talk to us!

Transcript of CodeSee Girl Geek Dinner – Panel Discussion:

Angie Chang: I’m glad we are still finding the opportunities to get together and hear from amazing Girl Geeks about what they’re working on. Tonight, we are having a panel of female founders of dev tool startups who will be sharing about their stories and what some industry trends are and really educating us in that space.

Michelle Ufford: Women innately just want to help. We want to help solve other problems in other people and when you’re in dev tools, you get to interact with your customers a lot more than you might be in more of like an external facing product role. I think that there’s a strong opportunity to recruit women to dev tools.

Renee Shah: I love the connection too, between new dev tools and getting more women and under represented groups in the dev tools world. I wouldn’t have thought of that.

Shanea Leven: We need to be able to just support more women in developer tools and there just needs to be a few pioneers to just say that it’s cool!

Marissa Montgomery: You can get started whenever you want, even if you just want to start it as a side project. You don’t really need anyone’s permission. Invest in the people that are cheering for you. I would say go for it if anyone wants to.

Shanea Leven: We just need to say, “This is what we’re doing. Hey people, come join us.” Learn from all you amazing women in what you do and just have some people to say, “Yes, let’s all do this together.”

Angie Chang: And then we’re going to have three JavaScript engineers talk really quickly about some things they’re working on or have worked on.

Karin Goh: A lot of my days definitely spent in Chrome Dev Tools, so I just wanted to share some tips and tricks that I’ve learned along the way that have really helped me get my job done on a day to day basis.

Palak Goel: Ember.js is an open source free JavaScript client side framework, which helps us in building web applications. There are different kind of other JavaScript frameworks like React and [inaudible] that you might have heard of.

Pearl Latteier: My goal is to answer for you two questions. First, what is a progressive web app? Or PWA as the cool kids say and why might you want to build one?

Sukrutha Bhadouria: Hi, I’m Sukrutha. I am CTO of Girl Geek X, I also work at Salesforce as an engineering manager by day. Super excited for tonight’s virtual dinner, or should I say “dinner” in air quotes, not the virtual part. Obviously, with Covid and everything, we have taken it virtual, but we used to have these in real life. Angie, how does it feel to be doing these virtual dinners?

Angie Chang: It feels good. I’m glad we are still finding the opportunities to get together and hear from amazing girl geeks about what they’re working on.

Angie Chang: Tonight, we are having a panel of female founders of dev tool startups, who will be sharing about their stories and what some industry trends are and really help educating on that space. And then we’re going to have three JavaScript engineers talk really quickly about some things they’re working on or have worked on.

Angie Chang:We are going to move on to the panel portion of the evening, we have four panelists, actually three panelists and Renee who’s going to be our moderator tonight. Renee is a principal at Amplify Partners where she focuses on developer tools and infrastructure startups. She graduated from Harvard and also an MBA from Stanford GSB. Welcome, Renee.

Renee Shah: Hi, guys. It’s great to be here, thank you for having me. Angie, are we ready to kick it off?

Angie Chang: Yes.

Renee Shah: Great. I am so excited to moderate this panel just because we have so many fabulous women on it. Without further ado, I thought that all of our panelists could introduce themselves and talk about their path to becoming CEO.

Shanea Leven: I can go first. I’m Shanea, I am so excited to be here with really great personal friends and people who are inspiring me every single day. I’m the founder and CEO of a company called CodeSee and we are a code comprehension platform that helps professional developers quickly explore, understand, visualize, and reason about their codebases. And we’re just really, really excited to help JavaScript developers really understand, onboard into new codebases, really understand how it works with our new system. We’re really, really excited to be here and chat about our journey. Michelle, why don’t you go next?

Michelle Ufford: Oh, sure. Hello, I am Michelle Ufford. I am the CEO of Notable, which is a early stage start up that is focused on collaborative Jupyter Notebooks for data driven enterprises. I am very excited to be here, this is actually my first talk as a CEO officially. This is going to be fun, thank you.

Marissa Montgomery: Hi, everyone. I’m Marissa Montgomery and I’m the founder of Instantish. We’re building an issue tracker that is for small teams that move quickly and it’s different in two ways. One is that it’s designed for everyone in the company to use, so not just engineers or designers. The second thing is that integrates really closely with Slack. Yeah, also excited to be here, thanks.

Renee Shah: Great. Those are wonderful intros and my first question would be, other than building something meaningful for the world, which all three of you are doing, what do you love most about your day to day?

Shanea Leven: Okay. I get a chance to talk to developers just like everyone here, basically every day. And I get to hear about their problems, I’ve personally experienced their problems. The same problems that we’re solving and as we’re building CodeSee, understanding large scale codebases is exactly what everybody else deals with. I get a chance to not only learn a lot, but just build something that I know that my people need, essentially. That’s probably the most fun.

Michelle Ufford: For me, it’s everything. I feel like I am having the time of my life, living my best life and that sounds cheesy, but it’s true and even the hard days. There’s a lot of long days, a lot of hard things and challenges that come up, but yet it feels different. It feels different because we have built such an amazing team, it’s such an positive environment and it’s really much more focused on problem solving and how can we rather than focused on all the reasons why this might not work. It’s been such an extraordinary experience.

Marissa Montgomery: I feel very much the same way. I just feel very creatively fulfilled every day with what I’m doing. It’s cool because as a CEO, you obviously wear many different hats, like you’re hiring. I code probably three to four days out of the week still, so I really enjoy that. Also, just working with an awesome team and getting to talk to customers is really exciting and inspiring.

Shanea Leven: I think all of us have probably worked at big companies before. I feel like it’s just this really awesome transition to be able to not be at a big company, but then you get a chance to create your own company. It’s a really awesome experience to be a part of that.

Renee Shah: I can imagine. Got what you love and maybe in the opposite fashion, what do you feel like is most misunderstood about being a CEO in dev tools or just an early stage CEO generally?

Shanea Leven: I think, for me it’s a lot about the sales aspect of it. That you don’t just get to code every day, because I get a chance to code and I get a chance to work on the product just as much particularly, at this stage, as any other person in the company. I think that particularly if you’re venture-backed like we are, I actually get a tremendous amount of help often by a lot of people. When we were raising, I texted Renee and Michelle very often. It’s not you have to do all these other things, sure there’s new things that I’m doing like learning about HR, learning about accounting and finance, but those are all just a really great opportunity to learn new things. I think that part is misunderstood, particularly when you’re building a product for your own market. The “selling” part of it is just like you’re just talking to your people, essentially.

Michelle Ufford: I would agree with that. I think that what I did not fully understand was how much of the job is really just communication and translation between your engineers and your potential customers and your investors and your advisors. It’s just a completely different way of communicating and even though I got into a pretty good place, in terms of speaking with engineers and with business leaders. It is very different when you’re trying to do sales calls. The way that you approach it or the types of things that you talk about are very different and you really have to shift and evolve and then yet, still be able to go back and talk to the engineers and business leaders. I think that was something that was unexpected, but has been very positive.

Marissa Montgomery: I would definitely agree with that. It’s a lot of context switching and when I envisioned building a company, I envisioned spending a lot of time just designing and coding with the team, but it’s a lot of communication and finding the people that are most excited about your product and communicating really closely with them and keeping them updated. Also, I was surprised just at how much time hiring and interviewing takes up. Obviously, a super valuable exercise and great use of time, but that was definitely something that surprised me.

Renee Shah: Those are great answers. I wouldn’t have thought about how much selling and hiring and just overall… I thought my cross-functional communication days were Google only, but it sounds like they keep going. Because a lot of the folks on this call are technical and we had some fantastic technical talks, I would be curious what trend everyone is most excited about in the dev tools world that’s upcoming. Marissa, do you want to maybe kick us off?

Marissa Montgomery: Sure. I don’t know if this is a trend or maybe a theme, but I’ve been really excited when I see the blending of the different stages of the engineering life cycle. You’re discussing what work you want to build, you’re creating issues, you’re writing code and then there’s the whole PR and code review process ,and then deploying and monitoring. It’s been really cool to see, there’s the typical concept of linting where while you’re in your IDE editing your code, you have this tool that’s making suggestions that you normally catch in code review, which is a later stage.

Marissa Montgomery: I’ve been seeing a lot of interesting things like that, like design linting and it’s been cool to see GitHub’s code scanning feature as well, which is they scan your codebase, I think it’s opt in, obviously, but they scan your code base for secrets that you might have published publicly which you would have caught much later. It’s kind of cool to see new tools and features that blend those stages together.

Shanea Leven: Michelle, you want to go next?

Michelle Ufford: Sure. For me, I’m a data person, it’s the convergence of the data and machine learning and data visualization with dev tools. I find that really exciting because when I was doing a lot of development work, there was so much stuff that was tedious, it was just the routine stuff or just trying to track down and understand the codebase or all of these things that were tedious and were not really value add to the company. I thought, man I just wish I could get to the cool stuff a lot faster. I see with the convergence of these things and I think of the kinds of dev tools that Marissa and Shanea are building, I think we’re going to see that you get more time to spend on the fun stuff and less time worrying about, why did my codebase break again?

Shanea Leven: Yeah, thanks. I was actually about to mention that I am actually very fortunate to get to ride this trend. As new types of people, women, under represented people, get into engineering, our dev tools need to evolve with it and I get a chance to build a developer tool to help people learn how large scale codebases work, so that we can spend more time building the things that we were meant to be building, as opposed to spending 60% of your time figuring where this line of code is. Actually there are a bunch of startups that are popping up in that space to really help you understand and build features faster and help you understand in a very different way than traditionally you’ve had to understand a codebase because you’re — traditionally, the way that you get it in your head is you read code one line at a time, you hold it in your head, you imagine data as it flows through your system.

Shanea Leven: That just doesn’t work for everybody. I’m excited to solve a problem like that because I’ve personally struggled with that problem of holding whole codebases in my head and I see that as a starting trend as these tools start to merge together. How we add visuals, how we add visualizations and just make it easier for people to comprehend so that we can do our jobs better.

Renee Shah: I love the connection too, between new dev tools and getting more women and under represented groups in the dev tools world. I wouldn’t have thought of that and that’s a nice segue too, of just what do you think we can do to get more women in dev tools? And maybe, Michelle, you can kick us off.

Michelle Ufford: Okay, so I have a theory. You guys tell me if you agree or not. I believe that we actually will see more women in dev tools, we’re seeing a decent surprising amount there, because women innately just want to help. We want to help solve other problems and other people and when you’re in dev tools you get to interact with your customers a lot more than you might be in more of like an external facing product role.

Michelle Ufford: I think that there’s a strong opportunity to recruit women to dev tools, but we need to make sure that we are supportive of them and we are explaining the problem space to them and the opportunity in a way that really resonates for them. I think a lot of this stuff is more like a language barrier, I know I’ve had many conversations with females about what does dev tools really mean and once I explained it to them they’re like, “Oh, that actually sounds more fun than this other stuff that I’m doing.” I think there’s a real opportunity for us there.

Renee Shah: Shanea, what about you?

Shanea Leven: I’m quite prolific in my thoughts. Basically piggy backing on what Michelle said, we need to be able to support more women in developer tools and there just needs to be a few pioneers to just say that it’s cool and it’s really awesome, particularly with dev tools — I think they are basically force multipliers because you enable developers to do something better to enable their end users.

Shanea Leven: We just need more women in Dev Tools. Snowflake had the biggest freaking IPO ever and it’s like, there’s no women there on their founding team. We just need to say, “This is what we’re doing. Hey, people come join us.” Learn from all of you amazing women and what you do and just have some people say, “Yes, let’s all do this together.”

Renee Shah: Totally.

Marissa Montgomery: I would… Sorry. Yeah, I definitely agree. There should definitely be way more women in dev tools. I get really excited when I meet female founders, it’s super exciting to me, all of you. One thing that I think is helpful too is talking about the different between a sponsor and a mentor and I think a lot of people talk about how they think, “Oh, I should mentor this person to help them get to the next stage of their career, to find the confidence to start a company.” And it’s really about sponsoring them. Talking to their manager about the great work they do, putting them up for opportunities. If they’re starting a company, advocating for them when you’re talking to other investors to get funding. Stuff like that.

Michelle Ufford: Can I just add on one more thought? This is just more generally with women in technology and something that I think that we really need to do is, we need to have real honest conversations with our leadership when we’re not happy and be willing to walk away. Being willing to leave that job or leave that team because it’s not a good fit, rather than leaving the industry, which actually might be a good fit if you were on the right team. I think that there’s a lot of people that just feel like, “I’ve got this job, I’ve got this team, I’ve got this project, I’ve made a commitment. I have to see it through.” The reality here is that employment is a two-way street and they need to be treating you well and you need to be performing for them and if one of those pieces is not working, then it’s not the right fit for you.

Shanea Leven: Yes, snaps.

Renee Shah: I love it. I can see in the comments, you’re getting a “well said.” Totally agree with that and I can’t think of a better group of three women to lead the way, especially for female CEOs and just CEO in general, let’s be clear. When I think about early stage startups, I’m also fascinated. You have incumbents that you’re competing with, you have other early stage startups and in dev tools particularly, you have open source projects as well. Which aren’t mutually exclusive from companies, but they’re there. What do you see as the biggest threat to early stage dev tools companies? As leaders, how do you think about mitigating those threats? And maybe, Shanea, you can kick it off for us.

Shanea Leven: Yeah. I think, honestly… Okay, this is going to be spicy. I think that the thing that’s the biggest threat is just the reputation of our industry. A lot of companies do a lot of really shitty things and there’s a lot of things that could be threats. I can talk about the big companies. I’ve worked for the big companies, I’ve worked for Google and all the places, but I think if we don’t do the things that require creating a good business.

Shanea Leven: If we don’t think about our users, particularly in developers, if we don’t think of all of the different types of developers or we aren’t thinking about the people that we’re serving or the teams that we have in our companies and making sure that we support them, that’s the biggest threat to early stage companies. There’s plenty of opportunity, there’s plenty of things left to build.

Shanea Leven: There’s plenty of problems that need to be solved. We need to be able to get a group of people together and support them and make sure that they can live their best lives building solutions for the world and not doing really kind of shitty things to them.

Renee Shah: Yup. Marissa, what do you think?

Marissa Montgomery: Yeah, I definitely agree with that. I’d also say, something that came to mind for me was just focus and discipline for companies, but that’s not a threat, like a certain trend or something. Especially with developer ttools, you have so many choices with what stack you use, which services you integrate with and there’s a lot of different things that you could build, but I think it’s important, especially in the early age to simplify that mentor model for the user and really double down on what your product is best at.

Michelle Ufford: I agree with both of those. What I’ve seen is it really comes down to two really big things and there’s a lot of different threats like the team that you build and who you choose as your investor. There’s a lot of potential challenges, but there’s a huge opportunity in the marketplace and what you really need to do is make sure that you are really thoroughly understanding your customers.

Michelle Ufford: You cannot assume that just because it worked at that one company or two companies that you were at, that it’s true of the general industry and so having lots and lots and lots and lots of conversations with potential customers and not even that you’re trying to sell to them. You’re trying to understand the problem space and if this idea that you have really makes sense for them.

Michelle Ufford: And the second piece of this is really making sure that you have a business model that’s going to work and it’s going to scale. I think that a lot of people have these really great ideas, but there’s no really good way to monetize them and if you take that time to think about it up front, you can kind of shift the business in a direction that would be more viable.

Renee Shah: I think those are all great answers. Just doing a lot of up front work and understanding the dev tools industry and being really focused. Awesome, awesome answers. Sort of similarly and piggy backing on that topic, I’m sure a lot of folks on this call would love to be CEO someday. What is the one piece of advice you have for a new founder? And maybe Marissa, you can kick us off.

Marissa Montgomery: Sure. I guess I would just say, you can get started whenever you want, even if you just want to start it as a side project. And you don’t really need anyone’s permission and there’s going to be people early on who try to reduce your idea or dismiss it. Probably more people than are excited about it, but just listen to the people who are excited about it and invest in the people that are cheering for you. I would say, go for it if anyone wants to.

Renee Shah: Michelle, what are your thoughts on being CEO and your advice for new CEOs?

Michelle Ufford: I think trust and transparency go a long way and you need to find partners and advisors and potentially invite those advisors to be investors in the company. If they are people that feel like they are up front and honest and direct with you and people that you can trust just to give you the truth, I think that is so huge to find those right partners. People like Shanea and Renee who have given me advice as we were starting. I think that those things are so incredibly valuable and it makes all of the difference.

Michelle Ufford: The other piece of this is really, don’t try to do it alone. Go and find a network of support and find out people who have done this before because if you pull all of that information, you’re going to find a lot of very common themes and those are really good lessons for you to learn vicariously through others, if you can.

Renee Shah: Yeah.

Shanea Leven: I’ll speak to that. The advice that I would give, because I would say very similarly to what Michelle said. Most of us are really just learning as we go and that’s very similar to if you’re a CEO or you’re a junior dev.

Shanea Leven: In addition to what hasn’t been said, what has really, really helped me besides my support system, it’s reading a lot. I read a lot, I listen to Audible a lot and getting frameworks and getting information in as quickly as possible has really helped me to grow my career and I didn’t just one day decide to be CEO. I kind of stepped up over time and grew over several years until I had the confidence to do it. And the same things that I do today are the same things that I did five years ago.

Shanea Leven: I think that all the things that we’re talking about today, finding your support system, being transparent, actually communicating your needs, are relevant at any stage whether you want to be a CEO today or if you are just getting your first developer job.

Renee Shah: Yeah. I think all of that is well said across the board. You made me think of something, which is just how much content there is out there right now. Whether that’s articles and podcasts and Twitter, and I think it’s an awesome time to learn, particularly in the dev tools space. Very curious what everyone’s favorite thing is, your most helpful thing is to read, whether that’s for company building or just to your domain specifically. Open to recommendations and maybe, Michelle, I’d love to hear your recommendation first.

Michelle Ufford: This is a great question. I don’t have any one source that I go to, in fact I try to aggregate across a variety of sources just so I can make sure that I’m not missing something. I would say some of the ones that I enjoy reading the most would be articles on Medium, taking the time and just liking the stuff that you like and you’ll continue to get good recommendations.

Michelle Ufford:There’s also something called Stratechery, if you’re not familiar with that, and that has been also just something that I really enjoy reading and hearing Ben’s thoughts on it.

Renee Shah: I’m a big Ben Thompson fan as well. I’m right there with you. Shanea, what about you? What’s your favorite thing to read?

Michelle Ufford: She’s muted.

Renee Shah: Oh, yeah I get it. I was in that boat earlier on the panel.

Shanea Leven: I was trying to move my chair and not disturb anyone, so I muted myself. Actually, what I’m reading right now is not related at all to dev tools, so I’m going to share anyway. Unapologetically Ambitious is what I’m reading right now, it’s about… Her name is escaping me, but it was just released. She was a female CEO of color at a tech company. She used to work for IBM, and it’s just about how to be…unapologetically ambitious.

Shanea Leven: I’m not really podcast person because it sounds like talk radio without the music, but my very first podcast that I actually really love is by Bethenny Frankel, she just launched a new podcast [Just B]. She had SkinnyGirl Cocktails and she’s had some pretty amazing people on. Bozoma Saint James from Netflix, CMO Netflix and she’s pretty famous. Mark Cuban was on there and it’s just a really awesome, just fantastic person to listen to, very entertaining while I run. As far as business and how to just live your best self.

Renee Shah: Love it. We all need to be a little bit unapologetically ambitious.

Shanea Leven: For sure.

Renee Shah: Marissa, what’s your favorite thing to read?

Marissa Montgomery: My go to recommendation, it’s kind of a timeless book. It’s High Output Management by Andy Grove and I actually read it once a year, every year. I’m probably due for my re-read. It just has such great advice in it, I especially like the first chapter where it talks about this manufacturing process. I think it’s called the breakfast factory and it’s really cool because it talks about how you assess quality at each step and I think it’s just a great framework for thinking about any sort of process. And then it also has a great section on one on ones and how they’re really under valued as a management tool and it talks about different strategies for how to invest in them. Every once in a while, I’ll still Google some notes and re-read the notes and re-read the book.

Michelle Ufford: Actually, Marissa, you just made me think of another book that I absolutely love, which is called Principles by Ray Dalio. If you’re not familiar with that, that’s just a book that really describes different principles that they use to articulate what the goal is at Bridgewater so everybody has clarity. When you really, truly break it down, it’s like this makes a lot of sense because there’s so much miscommunication in the organization, that by defining your principles up front. Everybody knows, here’s how we’re going to make decisions and here’s how we’re going to operate. Saves a lot of confusion and misunderstandings down the road. If you’ve not read that, I would recommend it.

Renee Shah: I’ve read Principles too and I will +1 that one. There’s a question from the audience, so I want to ask it, which is, “there’s a perception that dev tools should be free, at least for individuals.” I totally agree with that. “How do you tackle it and get your first customers?” Shanea, do you want to kick us off?

Shanea Leven: Yeah. I agree. It’s weird because in order to get customers at all, you have to meet their expectations. If everyone determines that it should be free, then you should have some free component. What we do, what we’re playing around with is our data flow, which is our first visualization, is going to be free. It’ll be based like a credit and usage system that they’ll be an amount of credits that you can use, just try it out, understand what’s going on and then they’ll be features for larger teams and enterprises that features that most individual developers don’t give a crap about. And then those things are things that you pay for. That’s basically how I would tackle it.

Renee Shah: Marissa, what do you think?

Marissa Montgomery: Oh, sorry. The question was about free tools?

Renee Shah: Right. Is there a perception that dev tools should be free and what do you pay for? Is it an open core model, bottoms up?

Marissa Montgomery: Yeah. We have thought about offering a free tier. One thing that we have done until then is we invest in open source projects, which is really just energizing because anyone can contribute and give feedback and ideas. That’s been something exciting. These projects are geared toward solving the larger problem that a lot of our customers face, so it’s kind of like if Instantish can’t address that problem completely right now, at least we can give you these resources or free tools in the meantime. It’s one of our company values, is just generosity. So when you’re doing something, not always thinking about how is this going to directly lead to revenue extremely quickly, it’s more about proving to our customers that we’re on their side and actually trying to solve their problems. Even if that’s doing some free tools. I’m just really excited about open source in general, so definitely wanted to incorporate that.

Renee Shah: Michelle, I’d be very curious to hear your thoughts as well.

Michelle Ufford: I agree. I think that there is certainly a perception that dev tools should be free and I agree with Shanea that they should be up to a point. There is this expectation, but I think that also, we should look at giving away dev tools for free in a different light. Which is that we really need to level the playing field here for small/medium sized businesses. In our case, we’ll be giving away a community edition that’s going to be fully functional Jupyter Notebook that’s very collaborative and it’s meant to be good for a single individual or good for a team and then you can grow all the way up to the enterprise.

Michelle Ufford: When you’re in that single person mode, you usually don’t have a lot of support. You don’t have a lot of understanding from management about why you need to buy these things. It’s not really until you start growing that you’re able to get those types of budgets behind you and then you got other companies that are non-profits or that are small businesses that just don’t have the money or can’t afford it at all. And yet we need to give them the same kind of tools so that they can continue to compete and stay in business.

Michelle Ufford: I’m a strong advocate for open source, I’m a strong advocate for some sort of freemium type of model for a lot of these dev tools or generally just software tools in general.

Renee Shah: It makes a ton of sense. I know we’re about at time, so I was going to get to our very last question, but I want to read a comment from the audience first. Which is, “Marissa, Shanea, Michelle, keep speaking, building excellent companies. You have the right stuff to grow and create.”

Shanea Leven: Aww. We heart you.

Michelle Ufford: Thank you.

Renee Shah: My final question, which I am actually personally dying to know the answer to is that, any tips or tricks to hire and sell? Because I certainly see it with the companies that I work in and I think those are the two of the absolute hardest things to do, particularly at the early stage. I couldn’t think of a better group of people to crack that for us. Michelle, maybe you can start off with your thoughts.

Michelle Ufford: Sure. For both the customer selling and for hiring when you’re in this early stage, it comes down to transparency and spending the time. If you have somebody that is an amazing employee, that’s at some company that it’s a very prominent company and you’re trying to recruit them or just some place that they are that they’re not quite sure that if they want to make that leap, especially in today’s times. You need to give them all of the information so that they can really make an informed decision. It’s not really about pushing them one way or the other, it’s about really laying out your case and saying, “Look, here’s why I think this is a great opportunity. Let’s talk about the company and the company culture. Let’s talk about the team. Let’s talk about the customers. Let’s talk about what this is going to look like in the next year, in the next five years, in the next 10 years.” When you take that time to answer all of their questions and really lay out your case, we’ve been very, very successful with recruiting taking that approach.

Michelle Ufford: Similarly with customers, the same thing. Just being transparent about where we are, what our goals are and trying to find things that are win wins for both of us has been very effective as well. Also, on taking the time with customers, take the time to research them, take the time to read their blog posts or watch their videos or trying to understand the business. If you’re in the super, super early stages and you really need those customers, take the time to personalize your demos. It’s going to take time, but when they look at those demos, it’s going to feel familiar. Now they’re not sitting there trying to understand, what is this all about? They can see things that feel familiar and they can immediately start to grasp the benefit of your product.

Renee Shah: Great tips all around. Especially the piece on personalized demos, that’s one I haven’t heard yet. I’m going to definitely hang on to that in my back pocket. Shanea, what do you think?

Shanea Leven: Funny story, I definitely stole Michelle’s job description. That was the key piece and everybody that we interviewed loves it by the way. I think that it’s our responsibility as people on call that grow into leadership positions to create culture from the beginning and we have had heavy time and energy put into making a good interview process and making sure that it’s fair, making sure that we are bringing in people who are kind, self-aware, who provide good feedback and good communication skills in addition to their tech skills. Because as we decide to grow the company, we want to make sure that we actually walk the walk, is that the phrase? Walk the walk of having an inclusive culture and we have turned down some really awesome people because there has been some red flags in our interview process.

Shanea Leven: Just personally and it’s really, really important to us and I think that that carries over, not just in candidates, but also in our customer calls. The way that we do business, the people that our customers interact with, they can clearly see that we desperately care about our people and really care about the problem that we’re trying to solve and that just makes everything a lot easier, to be honest with you. I think that’s generally kind of the way that I’ve approached things throughout my career, before building a company, if that makes sense. Even on just teams.

Renee Shah: Marissa, what do you think?

Marissa Montgomery: Yeah. I would definitely agree with that. Authenticity goes a long way in showing that you care about your customers. Selling was definitely something that I had to adjust to, I’ve never done it before. I’ve been in engineering all my career, so it was very different and I try to default back to just listening as much as possible. Which is interesting because sometimes I’m really excited about talking about features that we’ve released and things like that. I think just listening to the people that you’re talking to as much as possible is always a good thing.

Renee Shah: +1 to everything, and I see a question. I’m assuming Angie will give me a warning if we’re very over time, but I may just get this one question from the audience so that they can participate too, so actual last question — “would love your insights on pivoting your business. How hard is it when you try to love the problem you are trying to solve?” I’d be curious because I actually don’t know this, but I actually don’t know if any of you have had to pivot, so I will just let the first person, if somebody wants to just chime in.

Shanea Leven: I had to, not necessarily pivot, but because I have experience in products, we did a lot of, “What could we build to solve this problem?” first. And so we initially had an idea and then we pivoted before we built it, which made it a little bit easier. In the event that we talk to our users and we talk to the developers and they were like, “No, this is hella stupid. You shouldn’t build this.” We would have absolutely thrown it out without question and built what is important for them and I will still do that today. Everything that we built, I could probably throw out tomorrow and start again. We just need to make people happy. We just really want to make people happy.

Michelle Ufford: I do think that there’s something to that, do what you love or love what you do and I couldn’t be an astronaut, so I decided to be in dev and to love that and it’s really worked out well for me. It actually was a conscientious choice for me to sit there and say, “This is what I’m going to do. I think this is a great career and I’m just going to really go with everything and really embrace it.” It’s been really great. I think that whenever you’re trying to start a company, you have to have the same mentality. You truly have to love what you’re doing or you’re going to be miserable. If you’re not finding the right problem space or if something doesn’t feel right, I think you just need to continue to try to solve that problem and pivot until you can find something that works for you and for the market and for your customers and as a business model.

Michelle Ufford: The way that I’ve seen it in my experience has been that there’s always a path forward, always. You just need to sit there and take the time to look at it, think about things from different perspectives. If you can’t see it, go talk with others, get their input and see if that opens up your eyes, but I truly believe there’s always a way forward.

Sukrutha Bhadouria: Thank you so much, ladies. This was super insightful for me and to everyone else. I’m sure you’ll be able to get a chance to look at the amazing comments that everybody had to share. Thank you all.

Angie Chang: Why don’t we get right to it? Our first lightning talk is from Karin, who is a Senior Software Engineer at Salesforce and she graduated from UC Berkeley with a degree in Computer Science and minored in Human Rights. We’re really excited to welcome her to give a quick lighting talk, so welcome.

Karin Goh: Hi. Let me share my screen. Cool. I’m Karin, I’m a Software Engineer at Salesforce, where I’ve been doing front end web development for about two and a half years. A lot of my day is definitely spent in the Chrome Dev Tools, so I just wanted to share some tips and tricks that I’ve learned along the way that have really helped me get my job done on a day to day basis. For those of you who aren’t really familiar with what the Chrome Dev Tools are, it’s sort of like a browser in built IDE that allows you to explore everything that’s on your page. This is everything from the DOM to your source code to all the network requests that are going out among a lot of other cool things.

Karin Goh: I’m just going to jump straight into a demo. This is a super simple web page that I have. It’s just a bunch of inputs and some buttons and it’s sort of like a calculator, except instead of adding numbers, we’re adding strings based on these different inputs. For example, if I take these two things and I hit this build query button, we get some output. Straight off the bat, it looks a little suspicious because we’ve hit na here and eu, but we’re seeing two na’s. What I would do from here is I would open up the Chrome Dev console and you can either do that by doing command shift I or what I personally usually end up doing, is right clicking and hitting inspect.

Karin Goh: Now that I have this open, I can use this nifty little tool and sort of explore all the different elements on my page and so what I usually like to do is select the button that did the thing that looks incorrect. If we look down here, we can also see the console and some suspicious looking things and you can actually just click straight on these things and it’ll take you to that line of code and you can easily see what’s happening. In case you have a lot of things, for example, there’s just a lot of noise because I clicked the button a lot of times, you can actually filter this. And this is really helpful because you can just really filter by type or even by source file. If you’re working in a large codebase, you probably have way more than just the one file and you can see exactly where your console logs are coming from.

Karin Goh: But back to the bugs that we’re trying to figure out. In this case, I know there’s only one file so it’s definitely somewhere in this demo.html file, but if you’re new to a team or you’re new to the code, you might not know where to look to actually fix this bug. What I like to do is I actually, again, like to go to the button and I think a really easy way to figure out where the code is, is if you go over to this event listeners tab you can actually see a whole list of all the event listeners on something. In this case, I just have a simple click function and I can jump straight to the code. Then from here, what I would do, is I would stick a break point in, and you can do that just by clicking on the line number. You can also make this a conditional break point.

Karin Goh: Other things you can do are adding logs, so if you don’t have a console.log statement, but you want one, you can actually do that straight in the console here. I’m going to go ahead and click this button and now we can see that our debugger is paused. From here, we have some pretty basic IDE functions, so I’m just going to go ahead and step into my code. Now we see a whole bunch of stuff appear. These are all my variables and my local scope, this is pretty badly written code so there’s a lot of things here and they’re pretty poorly named, but we’ll just go with it. You can also see the call stack.

Karin Goh: Again, this is really simple code, but if you’re working in a more complex code base, this becomes really helpful because you can just jump around and it’ll take you straight to that line of code and it’ll open up the file so you know exactly where it is. We’re going to just jump ahead and now we’re trying to figure out why it says na twice instead of the expected eu. Again, this is pretty trivial code, you could probably eyeball it, but you could also just step through it and what I like to do personally, is add these watch expressions. You can actually see the variables down here, but obviously there’s a lot here and I know that can become pretty overwhelming. If I know I’m looking for something in particular, I’ll just go ahead and add it up here.

Karin Goh: In this case, I want index list. There’s also a console down here, so theoretically you could type what you want to look at every time you step over a line of code, but that becomes pretty inconvenient if you’re really stepping over a lot of code. You can also hover, there’s a lot of ways to view the same information and there’s definitely easier ways and harder ways, but there’s a lot of ways. This is sort of how I would begin to approach a bug if I had one, just looking at all these different things, looking at what’s happening with variables, stepping through code, stepping through my call stack. That’s sort of just an introduction of what you can do there.

Karin Goh: One quick thing I want to show, also, is sort of how you can play with these DOM elements and style them straight in your browser. From here, you can actually just drag and drop your elements in case you want to see what it looks like somewhere else. You can also pop over to styles and you can do CSS straight in there. For example, if I want to change the color of the button, you can see here it’s green now and I can just sort of play around and it’ll immediately update. You can also update classes or edit HTML. There’s really just a bunch of really powerful stuff you can do straight in the browser so that you don’t have to keep going back and forth between your IDE and the browser. You can also force state, so this is helpful if there’s something that’s only happening when you’re hovering.

Karin Goh: And there’s definitely a lot of really cool things to explore in the Chrome Dev Tools console. If you haven’t already, I would highly encourage everyone to explore all the different tabs, all the different buttons. They also like to hide things in the little things, so just definitely look around. There is lots of neat things you could do. Hopefully that was a good introduction and you learned something and you’ve all been inspired to use the Chrome Dev Tools more. If you have any questions, you can ping them in the Zoom chat or you can connect with me in LinkedIn. Thanks.

Sukrutha Bhadouria: Thank you, Karin. That was awesome. Our next speaker.

Palak Goel: All right. The topic of today’s session is UI automation with Ember.JS. Before I talk about testing what exactly is Ember.JS? Ember.JS is an open source free JavaScript client side framework, which helps us in building web applications. There are other different kind of other JavaScript frameworks like React and [inaudible] that you might have heard of. A very important aspect of development is that we want to make sure that every time we are bringing light to the production, the existing functionality is working as is. There are no regression bugs introduced and in order to do so, either we maintain a manual checklist and execute those test cases every time we are going live or we’ll be a little smart and use all those online infrastructure and tools that are open source and automate these test cases.

Palak Goel: Talking about testing. Ember provides three types of test out of the box, unit, integration and acceptance. Unit test actually forms the foundation of your test suite. Whenever you are writing tests to actually test the method, you’re actually writing test to test your code, those kind of tests they fall into category of unit test. An example is like, you might have a function in your [inaudible] which is taking a string import and string has comma separated numbers and after taking that as an import it is stripping the numbers on the string and returning the sum.

Palak Goel: If your unit is like a lot of possible combinations around this method that you can have. Like the import can be empty string or that import of the string can have decimal numbers or fluid numbers or it doesn’t have numbers at all. If you’re actually testing your method with various combinations, those kind of tests they would fall into category of unit test. If anywhere you create unit [inaudible] like model or [inaudible], adapters in your web app and Ember auto generates the file for you.

Palak Goel: You would have to definitely build those test cases on that. Talking about the integration category. Whenever you’re developing a web app, you will be adding component to your applications. An example is like, your web app can contain an image tile where you click on the image and it enlarges and you click again on that image and it restores back to its normal size. If you’re having test cases around a component, a single entity, those would be categorized under integrational rendering test.

Palak Goel: The code category application or the acceptance test, they actually refer to test where you are actually mimicking the user interaction where you are actually mimicking the user story and automating that as your test case. I’m going to give you an example of how can we add an acceptance test case. I have this web app in my local, it’s a super simple web app, it has Super Rentals home page and there is about and contact. You click on about, it’s going to land you on about page. You click on contact, there’s contact page. On Super Rentals home page, you can see the listings of a few different properties.

Palak Goel: Let me tell you the source code is available online on GitHub, so in case you want to explore it after the session, feel free to download the source code and explore it for yourself. Here is the source code for this app and this is where test resides. There is this folder called test and as I mentioned that there are three categories, unit, integration, and acceptance to categorize the test. Let’s try real quick automating a scenario where if a user types about, we want to make sure that he lands into the URL is about and that this about page gets [inaudible] and let’s say that it’s this contact us button on this particular page.

Palak Goel: How would we automate that scenario? First things first is that under acceptance test you would have to create a test file. Either you can create via manually new file or you can use the power of EmberCLI that gets installed when you set up Ember on your end. You would have to install it explicitly. We’re just going to run this command. It’s a simple, simple command which is going to create a file for you. I named my test file as about. You could name it anything you want. This is how the test file got created with a boiler plate called [inaudible] into it. I want to explain these three statements that we have in our record and so the first thing is importing the [inaudible] Q unit. Q unit is the actually test framework that comes by default with Ember.JS.

Palak Goel: There other testing frameworks that are available in market you can use it too, but this one is default. What it does is like you see that there is a third method, this third method has support from Q unit. There are other things that Q unit support is like organization of test, maybe you want to label your test or you want to skip your test. All those organization of test cases, all that support, you can get that from Q unit. The second package that we’re importing over here is Ember test helpers, this is a super important package because it provides you support to mimic all those user interactions that I talked about.

Palak Goel: For example, you want to mimic a click event in your test, that click event comes from this Ember test helper package. A really important point about this is that this package makes sure that whenever an event is run, all these events are asynchronized, so whenever these events are run, it makes sure that Ember is returned into it’s synchronized state. Before execution under the step after the event would make sure that even that has currently been executed is completed. There is a promise that is being returned and then only you move to executing another line. This particular set of line set of application test is helping and [inaudible] the application instance and all these interaction helpers that I just talked about in Ember test helpers.

Palak Goel: You get this test case and what this test is doing is it is just visiting this about URL and making sure that the current URL is this one like /about. You can add test case further and you can just make sure that, as I mentioned we want to automate the scenario where contact us button is getting rendered on this particular page. I have this code already, I’m going to just copy paste it to right [inaudible]. What this set of code is doing is it is finding the DOM element, which is referring to contact us button, this is the CS selector for this particular button and once it finds a button, it is clicking on this particular button. Once you click on it, it is going to navigate user to this particular link so we can add in a solution for that also that user gets navigated to the current URL after the button is clicked is getting in touch.

Palak Goel: One more thing is like the current URL, this support is also again coming from Ember test helper and it is asynchronous helper. This supports both synchronous and asynchronous. Since I’m using this click, I would have to mention that we that we are… We have just created a simple test case where we are trying to automate that if user lands on this about page, there is this particular button and if he clicks on contact us button, he gets to getting in touch page. Now, before I wrap my session up, let’s see how can we run the tests. There is this particular command and where tests are [inaudible], this is going to spend the server [inaudible] and all those test cases that are here in my project are going to run.

Palak Goel: Just going to execute this command and the support for this particular command also comes from CLI. This is how the test server looks like and imagine I had 28 tests including all integration, acceptance, and unit test cases. They all ran in a few milliseconds. If you notice that I have this set of code where I’m mentioning them with you, this helps in actually scoping of your test cases. If you do not want to run all your test cases and you just want to filter out by a particular [inaudible], you can just click it from here and then maybe just apply it just to run the particular test file. That’s what I had, I’m going to wrap my session up now, but let me tell you whatever I just said, it’s very preliminary information, but I hope this can act as a primer and everything that I showed you is open source.

Palak Goel: It’s there on GitHub, the source code file at Ember is open source. You just go ahead and download the source code and install Ember at your end and keep exploring. That’s it.

Sukrutha Bhadouria: We’re going to hand over the mic to Pearl next. Pearl, I’m going to do your intro. Pearl is a Senior Front End Developer at Propeller Health in Wisconsin Madison. Welcome, Pearl.

Pearl Latteier: Thank you. What a fantastic panel. I was really thrilled to be able to hear your experiences.

Sukrutha Bhadouria: Can see your screen and we can see your video and hear you so go ahead and get started.

Pearl Latteier: All right. Well, I’m thrilled to be here and thrilled to have just heard that fabulous panel. Let me get started here. My name’s Pearl, I work at a digital health company in Madison, Wisconsin, so a couple hours difference, so it’s almost my bedtime. I won’t doddle. Whoops, sorry. Technical difficulties.

Pearl Latteier: In the next five to seven minutes my goal is to answer for you two questions. First, what is a progressive web app, or PWA, as the cool kids say, and why might you want to build one? I’m not going to talk about how to build one, there’s no code in this presentation. We don’t have time for that, but I’ll point you to some resources to get started.

Pearl Latteier: What is a PWA? A PWA is a website, this website that I’m showing you is a PWA. It’s also the site for a conference that I’m organizing, so you can take a look at that later. But getting back on track, a PWA is a website that can act like a native mobile app in some important and interesting ways. For instance, a PWA is installable. Here’s an image of that website that I showed you installed on my laptop and you can see it looks like any other app that you would have installed. You can also install a PWA on your device’s home screen, it will live like any other app you’ve got on your phone in a little icon and when you click the icon, it will expand without the browser Chrome around it.

Pearl Latteier: It will display just like any other app will display. Not only is it installable, but PWAs work offline and this work offline stuff is super important. This brings us to the heart, really to the magic, of the PWA. The superhero of the PWA is the service worker. A service worker is a web worker, like Spider-Man, but unlike Spider-Man it’s written in JavaScript and it acts as kind of a proxy between your web app and the network. In our normal day to day, our web applications interact directly with servers on the network.

Pearl Latteier: You can drop a service worker in there that can mediate those interactions. Service workers can intercept network requests and this means that some pretty cool things can happen. For example, say your web app makes a request to a server and you’ve got a service worker, the service worker could see that request, pass it onto the server and then when the server responds, the service worker can take whatever assets are in that response. Images, data, HTML, CSS, it can take those assets and tuck them in its cache. The service worker has it’s own cache and it can put assets there and then the next time it receives the same request, the service worker could say, “Oh, well I already have the assets that I need to respond.” So it can just respond with the assets in the cache.

Pearl Latteier: And that’s pretty huge, that means that your application can respond to a request without making a round trip to the network. It can even respond when there is no network access at all. I think that this is super exciting, I think the implications of this are pretty huge. A service worker can make your web application super reliable, regardless of network connectivity, and it can also make your web application super fast. Because the service worker can serve assets from the cache without having to make the round trip to the network, it can load almost instantly if it has the assets it needs in the cache.

Pearl Latteier: Even if you don’t really care about installability, a progressive web app can really help you have great performance. I think that’s pretty cool, right? This is just only scratching the surface. Service workers aren’t the only tech involved in progressive web apps and there’s a lot more that service workers can do. But enough about service workers, let’s talk about you. Should you build a PWA? PWAs aren’t the solution to every problem. For instance, if you need to interact with device APIs that aren’t supported by browsers, then it would make a lot more sense for you to make a native app.

Pearl Latteier: But if your use case allows it, a PWA can be a great alternative to a native app. First it’s a lot cheaper and easier to make one web application than multiple mobile apps plus a website. And in addition, if you’re a web developer rather than a native developer creating a PWA is working with a completely familiar web stack. It’s HTML, JavaScript, CSS. Even if your target isn’t mobile and using the progressive web app techniques can make any web application quicker, more reliable, and installable and all together more awesome. There are lots of resources out there for getting started. These are a few that I would recommend, I would start with the free course on Udacity. It’s a good course and a great place to start. If you have any other questions about resources or anything else, we can do what a good service worker would do and take it offline. Thank you.

Sukrutha Bhadouria: Thank you so much, Pearl.

Angie Chang: We are now going to roll into breakout sessions. We’re going to get off the Zoom and go to a Zoom meeting where the breakout sessions can commence. We’re going to have girl geeks in groups of four to six. This is the feedback we got last time, which is that people like to meet in small groups so we’re going to be doing that! Just follow the link in the chat, it’s also in your email that you received when you signed up for this event. So we will just click on that and head over and meet you at that Zoom meeting. Which is again, the link in the email that confirmed this event at about 5:00 Pacific Time. I’ll see you on the other side!

Like what you see here? Our mission-aligned Girl Geek X partners are hiring!

• See open jobs at CodeSee and check out open jobs at our trusted partner companies.
• Does your company want to sponsor a virtual Girl Geek event in 2021? Talk to us!