In this show, I open you the doors to companies and thought leaders around the world. With my guests, I discuss software engineering best practices and pitfalls, and how they strive to build software people love.
Running a successful dev shop with Martin Gratzer
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
How to Succeed In Building Developer Tooling with Peter Pezaris
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
What developers should know about security with Troy Hunt
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.
Bad Tests Are Worse Than Product Issues with Dan Abramov
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.
Starting a profitable business in six weeks with Courtland Allen
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
Making Gatsby easy to understand with Laurie Barth
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
Done playing Microsoft's corporate game
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.
From Consultancy to Product Company with Charlie Gerard
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
Parent Driven Development at Github with Allison McMillan
Links:Allison's WebsiteAllison's Parent Driven Development PodcastGithub's website
Troubleshooting Systems through Observability with Charity Majors
Links:HoneycombCharity's websiteChristine Yen: Co-founder of honeycombPost on engineering management: the pendulum or the ladderPaper about Scuba - Facebook's Scuba data management system for real-time analysis Show notes:We start of by Charity explaining why she founded honeycomb. It all happened during her time at Facebook. She actually thought she will - after leaving Facebook - go on to be an engineering manager. But when she thought about how to engineer systems without all the tools and systems they had at Facebook, she realized that there is a big gap in the market. At Facebook, she relied heavily on a tool called Scuba. Scuba is Facebook's data management system to analyze and understand real-time data. Well, turns-out, outside of Facebook such great tools aren't available, or are not affordable. And because investors literally knocked at her door to fund her - after leaving Facebook - Charity took this chance and started honeycomb. In the early beginnings they literally just had four slides, an understanding of a problem (debugging and troubleshooting highly complex systems), and the desire to make an impact.Over the next year, Charity and her co-founder Christine Yen went all heads-down and figure out what exactly they want to build and how to talk about it.It was a long and painful process, but at one point they decided that the term observability is what describes best what they have in mind. (6:30)Charity explains that through observing the output of a system an engineer can actually infer what is going on internally. So, finally they knew themselves what they want to build and how to talk about it: they tried to build a system they let's you understand any state the system has gotten itself into, even if you have never seen this state before. And such systems can have a big impact on people's life - especially for Site Reliability Engineers, DevOps, and Developers. Charity and I talk about how to make on-call experiences better, and how developers are nowadays more and more needed in the operations phase of a system. (7:40)Because even though we have Q&A departments, manual testers, dedicated operations peoples, Charity explains that also the engineers have to spend their time operating the systems. She says that nowadays there is no way to build reliable and maintainable systems, if the developers do not spend time actually understanding and analyzing how the system behaves in production. She also explains why staging areas are a bad idea, and how those falsified environments just contribute to us learning the wrong signals, and destroying our ability to make good judgments about the behavior of the system when actual in production. (15:00)Charity also tells me that she thinks almost every developer should try out management at least for some time. She says that this experience gives engineers a new perspective and many valuable skills that make them better engineers, even when they go back to engineering. (25:07)Later Charity fills me in on their tech stack, and also explains why code reviews and communication are valued so highly at their company. (29:35)Charity is a big believer of transparency and openness when it comes to sharing incident reports (33:37). Sharing revenue numbers on the other hand isn't something that's common in her market, and so, it would be a competitive disadvantage, she says (35:19).In the last bit of the interview, Charity shares with me how she found her first investors, and how they feel much more stable, secure and on the right track with this second round of funding. Well, I really enjoyed talking to and learning from Charity and really admire her openness. Thank you Charity for being on my show.
Making Git faster with Derrick Stolee
Links:Derrick's Twitter accountWebsite of the Git projectWebsite of GitGitGadgetLinus appoints Junio Hamano as the Git maintainerBrian Harry's post about the largest Git repository Show notes:First, we talk about how it comes that Derrick, as a former professor, is now working for Microsoft as a principal software engineer. (0:10)Derrick explains to me that even though he wasn't a "sophisticated" programmer when he applied for the Microsoft role, he has decent experience building tools to solve his own problems. (2:40)During the interview process, Derrick stayed humble, curious and open-minded, he explained. (4:19)When I wondered how his work as a former professor for theoretical mathematicians shaped his mindset as an engineer, he explains how he breaks down problems, similar to solving a mathematical theorem. (5:55)Even though Derrick was a professor when he applied, he went through quite a typical interview process (for that time), including live coding, whiteboarding, and some "higher-order" questions, such as what has your biggest success been? (7:33)I ask what was the first project Derrick was asked to contribute to when joining Microsoft. And he explains that his team was/is responsible to help the Windows team be able to use Git. And for that, Git must be made faster. (10:29)Well, if he makes Git faster to work with Windows, I wonder if there are other projects out there that are large enough to also benefit from, for example, the Virtual File System for Git. Or is this improvement really specific to Windows? (13:37)Derrick explains to me how his work for Microsoft and his contributions to the open-source system Git interconnect and also how they differ. (16:27)Derrick seems to be in a very interesting position. Because, he works for Microsoft, but not solely on projects that Microsoft owns. In contrast, he works on Git. An independent open-source system, Microsoft has no authority over. This means that Derrick always has to look out for win-win-win situations for every enhancement or change he wants to introduce to Git. Also, he has to show why a change to Git is beneficial for both, for Microsoft and for the open-source community. (19:13)Well, Derricks's Twitter profile says that he makes Git faster, and after talking to him, I now understand that he actually works on algorithmic changes to the underlying Git system to make that happen. So, I ask him what other changes he introduces when he sets out to speed up Git. (21:28)Another thing that I want to know is whether such a mature and widely-used system can even be still improved. Derrick assures me that there is still plenty to work on. (23:49)But, he also explains that changing such a system must be taken one step at a time. Maybe things are interconnected, and many side-effects must be considered. They are working collectively on a new version that will increase the performance substantially. But, as this changes fundamentally how Git works, things need time to cook. (25:44)Because all the problems Derrick explains to me sound so exciting, I wonder how outsiders, like you and me, could contribute to this open-source system. (26:49)Derrick explains that quite a few people contribute to Git, and fills me in who is contributing to this open-source project. (28:40)Now, we start talking about software development processes. Derrick already mentioned code reviews before, but now he explains how code is reviewed through the mailing list. (29:50)After that, Derrick explains how they mainly use end-to-end tests when testing Git. (33:03)I ask Derrick if there are differences in the way he develops software at Microsoft and the way he develops software for Git. And yes, surely there are differences. The biggest one is that if you work on something internal, it's already decided that the feature is relevant and anticipated. So, you just have to work on making this feature the best it can be. In open-source it's different. Here, everything starts with the need to justify even the smallest change to the community. (35:50)Derrick explains that there is no roadmap for the development of Git, and that at any given moment, the community and the maintainer of Git decide whether or not a new feature or a bug fix is implemented in Git. (37:55)Even though the mailing list is actually THE place to be when you want to contribute to this project, there exist smaller sub-communities around Git that communicate also off the mailing list. (40:09)But, the main decision power lies in the mailing list and the community there.(42:16)Well, Derrick fills me in how that works at Git. He also explains that no single patch is ever merged without the maintainer (or in seldom situations like vacation a representative of the maintainer) having reviewed the patch. The merge is also always done by the maintainer. (44:34)I'm curious about how to become an open-source maintainer, and how much authority such a maintainer has. Is an open-source maintainer elected, or selected? How much say does a maintainer have? (46:06)Well, it seems a maintainer is like a founder of a company or the captain on a pirate ship. Quite some authority, and no election process. The best way to become a maintainer, therefore, Derrick says, is to start your own open-source project including a community. (48:09)Well, I learned a lot, so I thank Derrick for his time, and he lets me know that if people want to start contributing to Git, they can send him a message. Because, starting to contribute to Git can be difficult and daunting, so he is there to help ease the start for new ones. (49:37)
Developer Number One with Alper Kemal Koç
Links:Alper’s Twitter accountKuika the startup they are buildingShow notes:Alper starts by explaining to me why and how he joined this startup. (0:50)How did they find a business opportunity? (2:07)How did he choose the right technologies for building this idea? (3:02)Alper explains to me that he first build the apps they want to build, and then, they build the software that can generate the apps they first build (4:27)Did the technology they used or the solution they built change over time? (4:52)What are the engineering methodologies they use at a startup and did that mature over time? (7:08)- Alper explains to me that they developed and still evolve their methodology in an iterative process.- They tried all kind of processes and methodologies and always reflected on how it fits their current need.Alper mentions that how they do things in Turkey is different than how people do things in the Netherlands. Of course, I want to learn more about that (10:06)Has testing been a part of their software engineering process from the beginning on?- Well, it has been tricky, Alper says. And it evolved over time. But finally they came up with a great tool that helps them to detect regressions and saves them a lot of time. (11:55)And do they do code reviews? (14:48)Are they still doing retrospectives and changing things as rigorously as at the beginning? (16:42)Alper explains how they always strive to make the processes and practices enjoyable and beneficial for every team member. (18:16)Alper says that one of the most important thing a engineer does is to say that he can't do something. That way, the whole team can find a solution. (20:00)At his startup, engineers are allowed to work 20% of their time on something that interests them. One of his employees decided to build a wedding invitation app. Alper says, this is just such an valuable experiment, because this employee knows exactly how is is to be in the customer shoes. (22:00)You want to listen to feedback from customers or lead, but at the same time you have to be careful that it isn't misleading, Alper says. (25:16)Alper learns every day at the startup, but most of the technologies they knew from previous experiences. (29:36)So, how did Alper get the first customer? From their personal network, he explains. (37:22)Alper also talks about their investors and their relationships. In fact, they are very involved in the company. (38:23)Did they have troubles hiring for their startup and how did they overcome those challenges? (41:45)
Getting a remote job at Automattic with Leif Singer
Links:More about LeifHow Automattic Hires DevelopersThe Automattic CreedOpen Positions at AutomatticDetailed Show Notes:Leif switched from an academic career to industry (0:50)He explains his reasons for the switch, and we discuss that it is difficult to choose where you want to live when you want to become a professor (2:47)Leif got his new remote job in the industry at a startup called IDoneThis (3:20)The startup was sold, and the team discontinued, so Leif found himself again looking for a new job (3:50)Well, as luck would have it, Life got in contact with Automattic, the company behind WordPress.com (4:09)Leif applied and interviewed for Automatic although he wasn't familiar with the company's tech stack (4:40)Leif explains the interview process at Automattic (7:03)First, you send an email to jobs@automattic.com (including a resume and a cover letter)If you are invited for an interview, you get invited for a slack chat (a screener) where you talk about your background and your skillsThen, you get invited to do a small project which takes 4-5 hours over a week. It's a small project with concrete instructions that you must follow. For example, improve some parts of a feature.If that works out well, then, you are invited to do a trial, where you work alongside an Automatic team for a period of 1-3 months for ~10 hours per week. This trial is paid with 25 Dollars per hour.Leif fills me in that you aren't working alongside your actual team. The team you are then hired into can be a different one, but you work with an actual team at Automattic and on an actual project. So, if all works out well, your code will be used in production. (9:40)Leif describes the tech stack of Automattic, and which skills and technologies you must possess to be able to apply for a position. (10:40)Leif says that the projects at WordPress are very diverse. The tech stacks and the tool chains are therefore very diverse as well. One of the critical skills for any engineer at Automattic is, therefore, the willingness and ability to learn.Leif moved within the company and worked on very different projects. Each project you can learn something new, he says. Not only because of the diverse tech stack but also, because each project might serve a different customer base and have a different purpose. (12:20)If you want to move to a new project or team, you send a private message to Matt, the founder, and he helps you find a new place within the company (13:01)Leif rationalizes that at Automattic, you usually aren't communicating per email. No, they use either chat systems like Slack or internal WordPress sites to communicate and keep track of everything (14:00)We talk about how communication processes and channels might differ from a non-remote and a remote company. I wonder, is Matt actually replacing some of the water-cooler conversations you would have at a non-remote company? (14:32)Another topic I want to discuss with Leif is how engineers at Automattic keep in contact with other employees if they aren’t in the same building? How do they "hang-out" together? Is there a place in cyberspace that they usually meet at? (15:00)People connect and stay informed through weekly calls, one-on-ones calls, and company-wide town halls that are held once a monthEach team and each larger project have its own blog, where you can find all information about everything you have to knowTwo times per year, each team meets, and once per year all Automattic engineers meet and make a connection with each other.Leif walks me through the engineering processes and tools look like at Automattic (17:18)Again, as the tech stack is so diverse, also the processes and tools diver from project to projectSome are using Git; some are still using Subversion. Obviously, something like this hugely impacts how the whole engineering process looks like.Is Automattic planning to consolidate its technologies and tools? (19:37)Leif clarifies that because they are an open-source company, it's not that easy. Consolidation isn't something you can just put on the agenda. First and foremost, the goals of the company have to align with the goals of the open source project. So only if the open-source project would move from Subversion to Git, Automattic could move as well.We discuss how having open source as the foundation of your company creates some tension between the goals of the company and the open-source community. But, embracing open-source also changes the whole company values. Leif describes how transparency is the basis for everything at Automattic. Transparency is reflected in communication and the decision, and although it might not directly influence how people develop software, it hugely impacts the company culture. (20:43)Automattic grew quite substantially, so I ask Leif if the culture of the company evolve and change as well?Yes, of course, says Leif. But on the other hand, they still hold on to their main values. The Automattic Creed, a sort of gospel that describes the main values and mindset of the employees of Automattic, helps steer the employees in the right direction.Leif reads the Automattic creed to me (25:04)I wonder if Automattic has something similar to the Automattic creed when it comes to their engineering processes and practices such as testing or code review? (26:28)Leif explains how testing works at Automattic. 26:38But what about test coverage? Does Automaticians care about that? Leif says no, because it feels like one metric isn't a healthy indicator. (27:36)How does Automattic use code reviews and what does Leif think about code reviews? (30:08)Leif explains that every code change is looked at by at least one other colleague.Code reviews are very fitting to the learning culture of Automattic. It's highly appreciated engineering practice there.I wonder how they ensure – especially at a remote company with many different timezones – that code reviews are looked at in a timely manner. At Automattic, Leif says, they use Trello to track the progress of code reviews, but in addition, they also use a slack app called "the stick" that reminds people if they haven't looked at their code reviews. This normally ensures that you do not have to wait too long for code review feedback. (32:18)How does the production process look like, I wonder? And how long does it take to deploy to production? (34:12)Leif says, after review, it's just a merge and a deploy. All is all automated. It's one press of a button. For a few projects, you first might have a staging area for some manual tests and deploy it afterward.How do Automatticians handle technical debt? (36:12)Leif explains that they try to move fast, and therefore might create more technical debt than desired. But, once a quarter, they have one week, in which every engineer works on reducing technical debt. Because this is scheduled and expected, they can reduce technical debt and improve the code quite substantially during those times and keep technical debt at bay.Another topic I’m interested in is how people at Automattic get assessed and how they get promoted? (39:50)Leif describes that at Automattic, they actually have no titles and that switching from an engineering role to a manager role isn't considered a promotion. Somehow promotions and pay raise work quite different here. I like it.How diverse is the technical workforce at Automattic? (44:56)Leif says also Automattic isn't as diverse as they want to be. They struggle with similar problems other tech companies struggle with. But they do actively work towards getting more diverse. How? Well, they are present at events with diverse set of participants, they hire without requiring you to show your face, and by having a very hiring committee that consists of at least 50% women.
Building a developer community with Sandeep Panda
Links:Hashnode – the developer communitySyed Fazle Rahman, Sandeep’s co-founderHashnode’s tech stackRemote – book from BasecampAccel – the venture capital (VC) firmAI Superpowers – Book on how China uses AIHighlights and overview for you:The first 30 minutes: the entrepreneurial journeyStarting from 26:00: we talk about the development processesHow and why Sandeep started his developer community (1:00)How he met the investor firm Accel and asked for funding (5:54)How he seeded and kickstarted the community (11:27)How they spend time building a different pivot system – blockchain-based community (14:43)How focusing on the wrong things led them down the wrong path. The friendly community wasn’t existent anymore. (21:15)Sandeep explains what it means to be working with a VC firm (23:17)Does Sandeep feel like an expert for software development? (26:09)Sandeep’s experience with Next.js and MERN (Mongo, Express, React, Node) tools? (27:05)How does their development process look like? (28:55)How do they check for site reliability and security issues? (32:14)Do they run static analysis tools? Do they measure test coverage? Which testing practice do they follow? (33:48)Why do they run a remote company? (38:29)What about their DevOps process? Who has access to the production server, and how does deployment work? (42:13)How do they deal with technical debt? (44:27)Which books is Sandeep reading currently? (49:18) All questions by McKayla:Sandeep, you’re running a developer community, are you a developer yourself? (0:50)So how did you become a developer? What was your way? Are you a self-taught developer or did you go to university? (1:00)Did you have the urge to start your own company already during University or did it just come later? (1:45)And, what was your first-day job after college? (2:40)And when you started Hashnode, did you do that full-time immediately, or was that as a side project again, so in addition to your nine to five job? (3:11)So how did you decide which technologies to use? How Hashnode, you know, this community should look like? And how did the whole process start? (3:45)And did you choose that tech stack because you wanted to make progress really fast and because you knew those technologies very well from your previous jobs and side projects you built while at university? (5:07)How did you validate the idea of Hashnode? (5:54)Can you tell me a little bit more about Accel, the VC firm? (7:18)Was Accel the first firm that you ask for money and pitched your idea, or did you also try somewhere else? (7:46)Was it sort of a smooth ride after talking to Accel or have there been ups and downs before you actually got they funding? (8:30)After you pitch your idea, do you just wait or ping them multiple times? (9:27)Do you have an idea of how many people used DevMag after the Producthunt launch? (10:50)How did you know to kickstart the community from scratch? (11:27)So your focus was really on building the community and not the system anymore, right? (12:49)Was your first hire a community manager? (13:33)How did you find your first employees? (14:09)Are the same people still at your company or have you had to turn in your employees? (14:36)What is a blockchain community? (15:42)Why did this idea fall apart? (16:27)OK so that’s actually another sort of pivot of your company, right? From this Q&A style website to blogging functionality for developers. So how is that going? (17:47)Did you raise money for that as well? (19:09)What’s your vision for this Devblog? What should be the end result? (19:18)And for some of the monetization strategies that you brainstorm is there the blockchain coming back? (19:42)With all those pivots, have you still been able to keep this 70-30% split between development and community management? (20:06)And in these six months that you stopped attending so much to the community what happened? (21:19)Does the venture capital (VC) firm give you some feedback on big decisions? (23:17)Do you have to ask the VC firm for permissions for big changes that you want to make? (24:16)Does the VC firm also have opinions about the software development side of the project for example best practices you should follow or which technologies you should use? (25:17)Do you feel like an expert for software development? (25:57)Which technical decisions were really good decisions? (27:05)How much of the codebase was really rewritten? (27:56)So how does your development process in general look like do you do testing or code reviews? (28:53)And so, there’s at least one person that has to look through the code review? (30:41)And it doesn’t matter who that is? So, if that person says that it looks fine to me than you can actually push it to production? (30:45)If they push it to production and there are any bugs how would they revert it? (31:11)How can a user report a problem? (31:41)How do you address site reliability issues and security related issues? (32:14)Something else I wanted to talk a little bit more about is testing. Do you follow some testing methodology, like test-driven development or is that up to everybody on the team to decide? (33:48)Do you do Test Driven Development (TDD)? (34:19)And do you have something like code coverage to know if you’re covered enough of the code? Do you use metrics like that? (35:31)Do you use other static analysis tools? (36:27)And why did you stop using static analysis tools? (36:44)So, is this your way of reducing the overhead while you just figuring out the features and what the product will look like? (37:57)So, a little bit before you told me about the offices that you actually got an office with the VC funding, but that you are remote. What’s the story behind that? (38:29)And why did you decide to go from being two people in an office to hiring all over the world and working remotely? (39:41)Did you adjust the way you work or the tools for remote development? (40:48)And have you ever met your two European employees already? (41:46)So especially remote work is really built upon trust. So as I can imagine at the beginning you have to put a lot of trust forward, how was that for you? (42:13)So, one of the other things I wanted to talk to you about is your DevOps and your deployment strategy. Has everybody access and the right to deploy to the production or is there some specific process you follow? (42:54)Do you have a specific time that you deploy to production? (43:50)How do you deal with technical debt? (44:27)Do you have rules or processes or tools that help you not to introduce new technical depth? (45:24)So you say you’re having no hard deadlines. Would you describe your way of working sort of an agile way working? (46:21)So, if you would hire now let’s say, two other people, what would their roles be? (47:25)What’s the key metrics that you think help you go in the right direction? (47:52)Is there some budget that people can spend like on books or conferences to learn? (48:34)What are the books you are looking forward to reading? (49:18)Do you have some ideas on how AI can bring your developer community to the next level? (49:42)
Getting a remote position at Microsoft with Scott Hanselman
**Links: ** Find a position at Microsoft through Microsoft's careers website Scott's blog post on feeling like a phony Rethinking how we interview in Microsoft’s Developer Division Website for newbies in open source: firsttimersonly.com Scott's productivity tips and Scott's talk about productivity Shownotes: To allow you to find interesting places here are the beginnings of some conversations: How and why Scott started to work remotely for Microsoft. (1:25) When does he have to be at the office? Scott talks about which situations merit a face to face meeting. (4:20) Does Scott think you can you get a remote position at Microsoft, and how? (6:20) Does Scott travel all the time? (5:20) Then, Scotts explains how you can land a remote position at Microsoft (6:35) Scott says Microsoft careers website hasn't caught up with remote work, but around 22% of the position for the developer division (aka Visual Studio) are remote. How should we overcome imposter syndrome and feeling like a phony when we apply for a job (7:45) How you can negotiate your way into a remote position. (8:30) Is Scott hiring right now? (9:40) Which interview questions would Scott ask a programmer or product manager? Well, when interviewing, Scott looks for "systems-thinking" skills. He says, everything else can be taught. (11:30) I want to know that you understand systems thinking and how systems work together. And the recognition that there are systems. (Scott Hanselman) John Montgomery - rolled out a interview system. You can read more about it here. Basically now, as an interviewee, you work on larger problems and solve them as if you are a consultant. You get to work with the people that work on such a problem. Scott says, we interview you as if you are a person that can help answer this problem, but you do not have to have the answer to the problem right away. (12:35) Scott says we have to recognise that not everybody does their best work in high pressure situations. And an interview is a high-pressure situation. So, how can we make a interview more comfortable? (13:50) Scott talks about preparing people and helping people with imposter syndrome feel more at ease at an interview (15:00) When interviewing for a product manager position, Microsoft developer division (aka Visual Studio team) shares the interview problem before so you can prepare yourself. Scott walks me through such an interview. (16:12) You get an actual problem the team wants to solve. You also get some data, mockups, costumer data The team works with you together to solve this problem, because they want to know how it is to work with you. Scott explains which kind of interviews there are at Microsoft (17:05) How can we hire diverse people if we are at the same time looking for cultural fit? (17:35) Scott talks about how to handle people that think differently, and why people think differently (19:30). I talk with Scott about his website for newbies in open source, and Scott explains how we can mentor and help newcomers in open source (22:10). The best way to get people involved in open source is small stuff. Get them working on docs, get them doing tests. Help them do things so they can have an early win. (Scott 25:10) How can Scott be so productive? What is his secret sauce to productivity, and what is his advice for you to increase your productivity? (26:40) Has Scott had a master plan to be as successful as he is today? (30:25) Scott answers a question from a listener on the importance of DevOps as a engineering practices and wether companies should invest in this practice or not? (32:20)