Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.Links:McKayla’s Code Review WorkshopsTrisha’s TwitterTrisha’s WebsiteJobs at JetbrainsTalk to “Why reading code is harder than writing code“Felienne Herman: Teaching ProgrammingBecome a Patreon of the PodcastShow notes:Coming soon.

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.Links:Michaela's Code Review WorkshopsMartin's TwitterMartin's company TopmindOpen Tech TableShow notes:Martin and I studied at the same University. And already back then, his main goal was to start his own company. So, with sweet ~25, or something like that he started Topmind - which, BTW, I have been part of at the beginning.Since then, many years have passed, and Martin took what was once a one-man-show (after I left), and developed it into a dev shop with 5 full-time engineers and several freelancers.Martin explains to me, how over the course of ~15 years, he built a successful company by following his curiosity, passion, and by following a strict niche-down strategy.It was really great to connect again with Martin, and he shared tons of helpful advice for others that also want to build their own company. And all of that in a region that's far from being Silicon Valley!   I hope you enjoy this interview as much as I did.Best,McKayla

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.Links:McKayla's Code Review WorkshopsCodeStreamYC Combinator Show notes:As so often, I start by asking Peter what brought him to where he is today. Because, when you look at Peter's CV, you see that he graduated in Computer Science, but that instead of building software, Peter started out building whole software companies. Peter gives me a quite surprising answer. He says he was it was a dream of wealth and money. Yes, Peter wanted to become a founder, because he thought this is how he becomes rich and can live a good life. Peter does not completely answer my question, whether he managed to realize this dream, but listening to him, there is no doubt anymore that he found the right path for him. And yes, Peter's companies are successful.Which intrigues me. So, I want to know how he decided to start CodeStream, his current startup. CodeStream is a collaboration software for developers. It allows developers to connect and talk about different artifacts right within the IDE.Since Peter builds tech businesses for over 25 years, I wanted to know how their software development processes have changed over time. For example, I imagine that for the first startup he probably had a waterfall-based software process. And I guess that now they follow more agile processes. Peter explains to me that indeed some of the processes were more sequential at the beginning and one time they spend months developing a feature that really hurt their company's success. They only realized that after releasing it and it took them months to recover from that problem. Nowadays, CodeStream is very agile. He pushes code to production or test environments several times a day.CodeStream is a system that integrates with many other software systems, such as different IDEs, issue trackers, or planning software. So, I really want to know how they handle all the different integration points. How much of the software is universal, and how much is customized for each integration system?Peter says, that they knew from the beginning that they will have to integrate with so many different systems. They knew this ability will define their success. So, they spend a lot of time making sure the architecture is well-designed for that job. The main challenges come from integrating with the different IDEs, because the IDEs are rapidly evolving.As Peter has been in business for so many years, I want to know how much the tech stack has evolved. And yes, even for CodeStream they changed already from plain vanilla JavaScript to a tech stack including React. But what about the team culture? How does he make sure the company as a whole is successful? Peter says openness and transparency are what defines his success. He heavily promotes the social aspect of working together. People should not only build software, but they should also know they are part of something bigger.Even though CodeStream is quite remote, Peter makes sure that the team comes together a lot to socialize and stay in connection. They spend the money that they save by not having office, on travel.I also heard the CodeStream is going to be open-sourced. So, I want to know what motivates Peter to go along that path. Peter says, that, well quite frankly, this is what is popular right now. But also, open-sourcing gives them the ability to stay closer to their customers and the developer community. So, by open-sourcing their system, people get the opportunity to collaborate with them and learn from their software system.  Another motivating factor is transparency. Peter says, as they are newcomers and a startup, businesses do not trust them yet. By open-sourcing people can see what the system looks like behind the scenes, what happens to the data that is shared, and how does the process really work. This helps them to earn the trust of their users. Another thing that interest me is how did Peter get funding for this idea?He says, that before this startup, getting funding was a soul-destroying activity. Because, when you are going to look for funding, 90% of the time, people will say know, Peter says. But Peter also explains that this does not say something about your startup or idea. Most of the time it says something about the portfolio of the investor. And a "no" mostly reflects that your type of company does not fit into that portfolio.But, Peter also tells me that by being part of the Y Combinator made a big difference. Looking for funding after having a YC badge, made this experience so much more enjoyable and looking for funding was much easier. I end this show by asking Peter for advice he would give to new founders. First of all, he says, that if you think about becoming a founder - just do it. It's the best thing in the world. Yes, when Peter talks I can clearly hear that he made the right choice and that he is very happy with his path.But, I also know many founders that are going through rough times, especially at the beginning, Times in which nobody seems to be interested in their product. Times that it's hard to come up with the right pivot of your systems. Times in which you doubt everything. So, what does Peter have to say to those people?Peter says, that he learned that most companies are initially having a hard time. They fail, and fail, and fail until at one point they succeed. Even companies like Airbnb were close to shutting down several times at the start. But, it's all about not giving up and working your way towards success. Peter says, if you haven't found product-market fit yet, then you have to do only two things: talk to customers and build product. Don't focus on marketing. Don't think about hiring.Talk to customers and build product.Yes, I agree. And we close the interviews here. I hope you enjoyed it.Cheers,McKayla

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS. Have a look at Michaela's Code Review WorkshopsLinks:Troy’s WebsiteHave I been pwnedTalk: Hack your careerShaming for bad security OWASP Top 10 Web Application Security RisksShow notesWe start by talking about data breaches, and Troy tells me that he gets information about data breaches several times a day. More data on breaches than he can actually handle. When I asked him if people somehow got a data breach fatigue, he said, well, companies are nowadays more judged on how they handle the data breach than on whether they have one or not. So, it’s important that companies handle those well. Not like the negative examples from Uber and Equifax. Troy explains to me that from his experience he sees that often lawyers give the guidance to not react or publicly share information about a data breach. But that’s not a good strategy, Troy says. Because the ones that break into the website, they feel anonymous, so they will not keep it a secrete. They do not fear the consequences. But the companies will, so they should proactively manage data breaches. Then we talk about data privacy and Troy’s approach to sharing his personal data online. I have seen Troy in front of the camera with his son, for example, so I wonder if he has any restrictions on what he shares. Which things does he keep private?Troy says, data privacy is very personal and that there is no right or wrong answer. Everybody should do what feels right to them, and also evaluate on a case per case basis.After discussing this, we hop over to good security practices. I’m in particular interested in what Troy thinks software engineers should know about security, data privacy, etc. He tells me that the best thing is to start with the OWASP Top 10 web application security risks. But then, I tell Troy that, sometimes in my code review workshops, software engineers tell me that they do not need to look for security vulnerabilities or risks, because, that’s handled by others. By experts. So, I ask Troy if he encounters similar mindsets in his workshops, and how he handles such pushbacks. Troy tells me that he made a whole career out of this attitude and that he encounters this quite often. He thinks it has to do with complacency. He says that security is something that we all have to stay on top of and that’s relevant for everybody. Also, implementing good practices, like making code resilient to SQL injections does not take any more effort. Contrary, practices that help you make your code more resilient can save you time and money in the long run. Another area I ask Troy about is what he advises organizations to do to make sure they implement security throughout the whole development lifecycle. How can organizations get the new DevSecOps lifecycle right?Troy also tells me that education, for example in form of workshops, such as his security workshops or also my code review workshop, is an excellent way to make sure developers are aware of best practices, and follow good and proven strategies. Another thing is automated analysis. After talking a bit about regulations and their effects – or non-effects- to enforce data privacy, we switch gears and I talk with Troy about how he started his career as a security expert and thought leaders.I want to know, what started all, and did he foresee his success back then. Well, turns out Troy started writing his blog over four years before he made the move to self-employment. He says it took a lot of effort and time to build his online identity, but he knew that this gives him freedom and peace of mind in many cases.He thought about, what if he does not like his job anymore, or the employer wants to get rid of him.So he started blogging and building an online portfolio. And, four years later, it happened. Troy wasn’t happy anymore at his current job, and the company made a few roles redundant. So, he took the chance to start his own business and never looked back.It was really inspiring to talk to Troy. I hope you enjoy this episode as much as I did.Best,McKayla.

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.Links:Dan's twitter profileDan's Decade in review blog postReact BlogJustJavaScript websiteMaggie Appleton: Co-creator of JustJavaScriptShow notes:We start this episode by Dan explaining to me how he landed a job at Facebook. Turns out that Dan, who is originally from Russia, wasn't so interested in working at a large cooperation at first. Only after he worked on React for a while he thought about this possibility because he thought it would be nice to work together with the people he already knew from his open-source collaborations. So, one day, at a conference, he run into a collaborator, who ask him if he wants to interview, right there at the conference for a Facebook position.Dan said yes, and the rest is history.Well, not so fast. Obviously, I ask him all about his personal interview experience - and in addition, about what he expects from in a successful candidate when he is interviewing himself. To my surprise, Dan explain that there are quite different types of interviews at Facebook for front-end and backend engineers. He says, the front-end ones are less computer sciency. So, he did that one. Another topic I really enjoyed talking with Dan about, were the software engineering practices at Facebook. I still envision Facebook as this hacker place following the hacker mantra: "Move fast and break things." But Dan tells me that things have changed. At least slightly, and that they have now more rigor in their process. He also tells me about why at Facebook they prefer integration instead of unit tests, and how their processes are designed to empower engineers. Dan tells me that Facebook has no strict code ownership, and that he thinks that's such an empowering move. He also explains that engineers have a lot of freedom and rights, but they also have to take the  responsibility for their actions. Another topic we deep-dive into is Dan's new JavaScript course, called JustJavaScript. He explains to me why he started to work on this course, and also about the new teaching concepts that he uses and experiments with to correct invalid mental models that intermediate developers have about JavaScript.  Finally, he talks about React's future - especially the new concurrency support. Well, yeah, I really enjoyed talking with Dan, and I can say that talking to him definitely satisfied my curiosity a bit - at least for today.

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS. Links:Courtland on TwitterIndiehackersIndie Hackers PodcastRosie SherryShow notes:In the beginning, I talk with Courtland about his journey to create the indie hacker community. I actually thought he created it right after graduating from college. But that's far from what happened. For many years, Courtland started all kinds of businesses with varying degrees of success. In 2016 he then quit his day job and had a runway of one year for building a profitable business (giving the cost of living in San Francisco). Courtland tells me that the first six months of this new journey to building a successful business weren't really productive. But as he realized that he runs out of time and money, he made a plan.He wanted to start something that he knew will be successful and brings in revenue within a short amount of time. So, he thought about all he had learned from his previous attempts and came up with a multi-phase action plan. Yes, this time around, Courtland had learned that he should start small, and incrementally make his way towards the successful business he had in mind.He explained that he started with the interviews on the website because when there is content on a website, people come to that site. Then, he started the mailing list, because it's easier to start a mailing list when you have content. Then, he contacted sponsors that would be a great fit for the website. It took Courtland only a few weeks from the initial idea to having the first sponsorship deal locked in.He never intended to start the podcast. But after several requests from the community, he gave it a shot. Now, it's one of the most successful parts of the business.Well, I talked about so much more with Courtland, like why he build the website and community functionality from scratch or whether or not he still is a founder. So, have a listen to the podcast or read through the whole interview in the transcript notes. Let me know how you liked in on Twitter.Cheers,McKayla  

Links:Laurie's websiteLaurie's twitterGatsby careerShow notes:We start off with Laurie describing her day-to-day work at Gatsby. Turns out, Laurie works fully-remote from her home office on a variety of things. Somehow, the tasks she describes sound to me like typical developer relations or developer advocacy tasks, but Laurie explains to me that there are, next to the similarities, fundamental differences.Laurie also tells me about how she started to blog and how that somehow lead to her making a connection with Gatsby. Even more, Laurie suspects that her blogging endeavor leads her to get that awesome job of hers.When Laurie joined Gatsby, she suddenly became an open-source maintainer. This means, she has to through contribution of the community, and decide whether they are accepted or rejected. She also has to give feedback to the contributors on what they should change in order to get their contribution accepted.Laurie explains to me, what mechanisms are in place at Gatsby to make the code review process smooth and a pleasant experience for everyone.We also talk about her many conference talks, her work as an egghead instructor and her online presence on Twitter.Because Laurie managed to build a community of over 10,000 people on Twitter in a relatively short period of time.So, I hope you enjoy the interview as much as I did.Cheers,Michaela

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.Links:Suz's websiteSuz on TwitchSuz on TwitterShow notes:We start the episode by deep diving into Suz's current role at Stripe (0:35). She explains that she is a developer advocate, working with a lot of different folks at Stripe. She is responsible to make sure the Stripe terminal product is a great experience for the customers. Therefore, she currently works on reducing the time it takes a new customer to use the terminal for the first time as much as possible.I ask her how she connects with the customers, and she explains that at Stripe, UX teams reach out to customers for different reasons (2:25). For example, the team might reach out when they see the customer is using the software in an interesting way. Then, UX researchers try to understand more about the customer, by booking sessions with them. Other employees at Stripe can participate during such sessions and learn more about the usage of the product and the customers.This sounds fascinating to me (3:46). Especially the part where Suz explains that customers are quite interested in participating during these sessions. We both think it has to do, that the customer clearly values the product and see that they benefit from making it even better.In the following minutes, Suz tells me about her positive interview experience at Stripe (7:35). She says Stripe reached out when she just started at Microsoft. But, because she did not want to leave a job just after having started it, they tabled the conversation. But after 2 years working at Microsoft, she was ready and reached out to them again to continue the conversation.She says it was quite a standard interview process, including coding assignments and a full-day on-site interview (9:11). But all interviews were done in an emphatic way, and she felt she always knew what people are looking for and what is expected of her. Even more, she felt she got a great understanding of how her job will look like through the interview.We move on to a very interesting, but probably also stressful part of Suz's life (13:00). Her time at Microsoft. Because I follow Suz already quite some time on Twitter, I also saw a tweet of hers about leaving Microsoft. She said that this job and the team haven't been a great fit for her.I was unsure if Suz is ready to share her experience with all of us, but it turns out she is. So, during the next few minutes, we talk about her experience joining Microsoft as a developer advocate.Suz explains that the organization structure wasn't very beneficial for the developer relation teams to actually make an impact. Teams weren't really working with each other. It seemed more like teams were working against each other. The way, the teams interacted with each other, often forced Suz into conflict situations and into disagreements where she had to argue a lot with product teams. She tells me that during this time she became less conflict adverse, but the experience was still far from positive for her.So, Suz actually moved from the sales organization to the developer division. This way, she hoped to have more impact and fewer conflicts. Still, also this move turned out to not be what Suz expected. Unfortunately, she still experienced a lot of gate-keeping, power struggles and what she calls corporate games.But Suz is determined to give it a fair shot, so she did not quit, but tried to learn and figure out how she effectively can make an impact. But after ~2 years trying to make it work at Microsoft, Suz was ready to move on.So, she interviewed with Stripe, and got her next great job (20:00). But this time around, Suz asks though questions during the interview process. She really probes to see if the company culture is a good fit, and isn't afraid to ask to speak to even more employees before signing on. But getting a new job is a stressful situation for Suz. Similar to when I worked for Microsoft, Suz is on a working visa. This means that she cannot simply quit her job. Instead, she has only a small time window in which she can transition from one job to the other without needing to leave the country.After that, I wanted to know more about software engineering practices at Stripe, and I start with my favorite topic: code reviews (24:30). Turns out for compliance reasons every line of code is reviewed at Stripe.The conversation about code reviews naturally brought us to talk about mentoring (28:02). So, Suz explains to me about her experience mentoring junior developers. I ask her how all started and how she engages with her mentees.We both haven't had many mentors during our 15+ years of experience in this industry (31:28). So we discuss this a bit and think about how we proactively can seek out mentors or just observe people and learn from people that are ahead of us.Finally, we move on to live coding - a topic that is super fascinating and also terrifying to me at the same time (42:38). We spend the next 10 minutes deep diving into this topic. Suz explains to me what live coding is all about and how she started. I get all kinds of anxieties when listening to her. She started and overcame anxieties with a lot of practice and preparation at the beginning. And the, she grew into it. Somehow this eases me as well, and who knows, I might try it as well soon.Suz explains how she uses live coding to build a community and to help people get started with open source (54:00). When she describes it like that, I can see the many benefits this kind of exposure brings. Well, most likely this kind of interaction will become even more powerful in the next years, with a generation that loves watching videos.

Links:Charlie's websiteLook mum - no hands: A talk about brain-controlled interfacesAtlassian's career siteAtlassian's team playbookBrain-sensor startup NeurosityGoogle Dev ExpertMozilla Tech Speaker

Links:Allison's WebsiteAllison's Parent Driven Development PodcastGithub's website